扱いされるようになります。ここまでの説明で質問が2つくらい浮かび上がると思います。失敗したリクエストはどう扱うのか?そもそもここでの失敗は何を意味するのか?失敗したリクエストは利用可能なサーバがあればそこへ再度流されます。内部の挙動で、ユーザー側からは1リクエストとして認識される、ということを忘れないようにしましょう。利用可能なサーバが存在しなければ?バックアップのサーバが存在するのならそれを使います。バックアップは名前からも推測できると思いますが、普段は使われません。リクエストを流します。利用されるようになります。利用されなくなります。どのようなレスポンスを失敗として扱うのか。使ってるモジュールによっては使える設定が違います。オプションの説明に一覧が乗っているので参考してください)にあります。この設定からはなにを持って失敗と定義するかを決められます。レスポンスを受け取りヘッダーを確認するまでの通信の中、なにか問題が起きれば失敗です。アプリが側の処理結果ではなく、通信がちゃんとできているかで判定している感じですね。ステータスコードを受け取った場合も失敗として扱うことが可能です。http_503;}のようにすればいいです。他のオプションや詳しい説明が必要であればドキュメントを参照してください。リクエスト失敗と判定し、切り出し元にリトライするということをすればいいです。コードを見ていきましょう。あればコントローラに以下のような感じで書けます。扱いされることなくすべてのリクエストを処理するようにします。ステータスコードを受け取ったら次のサーバにリトライするようにします。して設定するのは、リクエストに失敗したときのみ使われるようにするためです。)の場合でもリトライを有効にするためです。リトライすることができるコードの意味がそれなりに自然に見えるという基準で選択しました。利用した切り替え戦略の問題点さて、最初のお気持ちをもう一回思い出してみます。アクション単位で切り替えたいアクション単位で切り替えられるようになりましたすべての問題点を解決できていますね。全てが便利になるのか?というと違います。以下のような不便さがありえます。フォームで渡す引数の名前、ルーティングパスなど)を変えたい場合は慎重になる必要があると思いますが、この戦略の場合は特に切り替えの単位が細かいので、もっと気をつける必要があります。フォームは旧サービスから返すのに、提出は新サービス、という状況もあり得るためですね。同じ理由で、両サービスのルーティングテーブルは常に同期しておくのをおすすめします。ちなみにモバれぴの場合、前述したようにアクティブな開発は行われていないため、この制約によるデメリットはありませんでした。最後にレイテンシーに対する心配もあると思います。無駄になるからですね。ミドルウェアを一周します。返すだけなら、そこまでは影響しないはずある程度のレスポンスの遅れは許容する移植作業が進むにつれ、その遅れは自然解消するということからこの方式で問題ないと判断しました。平均レイテンシーのグラフです。設定変更が行われますが、誤差の範囲に収まってるような印象を受けるので、大抵の場合は問題がないと思っても良いでしょう。分離する中、切り替え作業を継続的かつ小コストで進めるために選択した戦略、そしてそこに至った経験談、それに必要な背景知識などを説明しました。どちらの場合もリソースの処理をしないのでおかしな実装をしないかぎり問題ありません。