会員向けの申込みを受け付ける API は、1 つのリージョンで動いています。会員の 4 割は遠く離れた地域におり、その地域の会員からは、送信してから受付番号が表示されるまでに他の地域の 3 倍かかるという報告が続いています。申込みの内容はその場で記録され、会員は送信の直後に受付番号を確認します。監査部門からは、1 つのリージョンが使えなくなっても会員が申込みを続けられる高可用性の構成にするよう求められています。追加の環境を本番と同じ規模で用意できる予算は確保されており、次の四半期にもう 1 つのリージョンを追加する計画です。 これらの要件を満たすソリューションはどれですか。
追加するリージョンを平常時にも活かしつつ、片方の喪失にも耐える構成を選ぶ
両方のリージョンにアプリケーション一式とデータベースを配置する。
どちらのリージョンにも申込みを受けられる構成があり、平常時から両方が会員のリクエストを処理します。ヘルスチェックで異常を判定させておけば、片方が使えなくなっても残ったリージョンで申込みを続けられます。
Amazon Route 53 の加重ルーティングで 50 対 50 に振り分ける。
加重ルーティング が決めるのは、それぞれのレコードを返す割合だけです。
会員は近さに関係なくどちらのリージョンへも同じ割合で導かれる。
どこから来た会員かは考慮されないため、遠い地域の会員のうち半分は遠いほうのリージョンへ導かれ続け、応答時間の差は半分しか縮みません。
両方のリージョンにアプリケーション一式を配置する。
アプリケーション層が 2 つのリージョンで動くため、会員とのやり取りは近いほうのリージョンで行われます。
データベースは既存のリージョンのものを両方から参照させる。追加したリージョンからは広域のネットワークを越えて読み書きすることになる。
データベースを 1 か所にまとめておけば、内容が食い違う心配はありません。ただし申込みが登録される先は既存のリージョンのデータベース 1 か所なので、そのリージョンが使えなくなると、もう 1 つでアプリケーション層が動いていても登録できません。会員は受付番号を受け取れず、監査部門の条件を満たせません。
両方のリージョンにアプリケーション一式とデータベースを配置する。
どちらのリージョンにも申込みを受けられる構成がそろいます。
Amazon Route 53 のフェイルオーバールーティングを構成する。
フェイルオーバールーティング は、プライマリのヘルスチェックが異常と判定されたときにセカンダリのレコードを返す設定です。既存のリージョンが失われれば会員は自動的にもう 1 つのリージョンへ導かれ、業務が止まりません。
既存のリージョンをプライマリにし、追加したリージョンをセカンダリにする。
セカンダリのレコードが返るのはプライマリが異常なときだけで、平常時はすべての会員が既存のリージョンへ導かれます。可用性の条件は満たしても、遠い地域の会員の応答時間は今と変わりません。
両方のリージョンにアプリケーション一式とデータベースを配置する。
申込みを書き込む先も両方のリージョンにあるので、片方が使えなくなっても残ったリージョンがそのまま申込みを受け続けます。書き込みを両方で受け付けるために、データベースは Amazon DynamoDB の グローバルテーブル のように複数のリージョンで書き込みを受けて相互に複製する形で構成します。
Amazon Route 53 のレイテンシールーティングを構成する。
レイテンシールーティングは、その会員にとって応答時間が短いほうのリージョンのレコードを返します。
会員は応答の速いリージョンへ導かれ、片方が失われたときは残りへ導かれる。
遠い地域の会員は近いほうのリージョンで申込みを処理されて待ち時間が縮み、どちらのリージョンも平常時から申込みを受け付けている状態になります。片方が失われたときに残りへ導かれるのは、ヘルスチェック でリージョンの異常を判定させておき、異常と判定されたリージョンのレコードを Route 53 が応答に含めなくなるためです。
リージョンを 2 つ使う構成では、同じアプリケーション一式を両方に置いたかだけでなく、平常時に会員がどちらへ導かれるかまで見ます。
・異常のときだけ振り分ける（フェイルオーバールーティング） — 平常時に返るのは片方のレコードだけで、応答時間や負荷の分散には効きません。
・割合で振り分ける（加重ルーティング） — 両方が平常時から処理しますが、決めているのは返す割合だけで、どこから来た会員かは考慮されません。
・応答時間の短いほうへ振り分ける（レイテンシールーティング） — 会員は速いほうで処理され、両方が平常時から受け付けています。ヘルスチェックで異常と判定されたリージョンのレコードは返らなくなるので、片方が失われても残りが受け続けます。
・アプリケーション層だけを両方に置く — 書き込む先が増えていなければ片方の喪失で業務が止まります。