Q28 — AWS SAP-C02 第1章

第 28/75 問 | ← 第1章

Q103. ある企業は、Application Load Balancer（ALB）の後ろで動作するAmazon EC2インスタンスのクラスター上で実行されるマルチティアWebアプリケーションを運用しています。これらのインスタンスはAuto Scalingグループに属しています。ALBおよびAuto Scalingグループは、バックアップ用の別のAWSリージョンにも複製されています。ただし、Auto Scalingグループの最小値および最大値は両方とも0に設定されています。アプリケーションのデータはAmazon RDS Multi-AZ DBインスタンスに格納されており、そのDBインスタンスにはバックアップリージョンに配置された読み取り専用レプリカが存在します。エンドユーザー向けのアプリケーションエンドポイントは、Amazon Route 53レコードを用いて提供されています。この企業は、アプリケーションを自動的にバックアップリージョンへフェイルオーバーさせる機能を実装し、RTO（Recovery Time Objective）を15分未満に短縮する必要があります。ただし、アクティブ・アクティブ戦略を実装するための十分な予算はありません。これらの要件を満たすために、ソリューションズアーキテクトは何を推奨すべきでしょうか？

• A. アプリケーションのRoute 53レコードを、2つのALB間でトラフィックをロードバランスするレイテンシーベースのルーティングポリシーに再設定します。バックアップリージョンにAWS Lambda関数を作成し、読み取り専用レプリカの昇格およびAuto Scalingグループの値変更を実行します。プライマリリージョンのALBにおけるHTTPCode_Target_5XX_Countメトリクスに基づくAmazon CloudWatchアラームを作成し、このアラームがLambda関数を呼び出すように設定します。
• B. バックアップリージョンにAWS Lambda関数を作成し、読み取り専用レプリカの昇格およびAuto Scalingグループの値変更を実行します。Route 53にWebアプリケーションを監視するヘルスチェックを設定し、ヘルスチェックのステータスが異常になった場合にAmazon Simple Notification Service（Amazon SNS）通知をLambda関数に送信するよう構成します。アプリケーションのRoute 53レコードを、ヘルスチェックの失敗時にバックアップリージョンのALBへトラフィックをルーティングするフェイルオーバーポリシーに更新します。 ✓
• C. バックアップリージョンのAuto Scalingグループを、プライマリリージョンのものと同じ値に設定します。アプリケーションのRoute 53レコードを、2つのALB間でトラフィックをロードバランスするレイテンシーベースのルーティングポリシーに再設定します。読み取り専用レプリカを削除し、代わりにスタンドアロンのRDS DBインスタンスを配置します。RDS DBインスタンス間のクロスリージョンレプリケーションを、スナップショットとAmazon S3を用いて構成します。
• D. AWS Global Acceleratorにエンドポイントを設定し、2つのALBを等しい重みのターゲットとして登録します。バックアップリージョンにAWS Lambda関数を作成し、読み取り専用レプリカの昇格およびAuto Scalingグループの値変更を実行します。プライマリリージョンのALBにおけるHTTPCode_Target_5XX_Countメトリクスに基づくAmazon CloudWatchアラームを作成し、このアラームがLambda関数を呼び出すように設定します。

正解: B. バックアップリージョンにAWS Lambda関数を作成し、読み取り専用レプリカの昇格およびAuto Scalingグループの値変更を実行します。Route 53にWebアプリケーションを監視するヘルスチェックを設定し、ヘルスチェックのステータスが異常になった場合にAmazon Simple Notification Service（Amazon SNS）通知をLambda関数に送信するよう構成します。アプリケーションのRoute 53レコードを、ヘルスチェックの失敗時にバックアップリージョンのALBへトラフィックをルーティングするフェイルオーバーポリシーに更新します。

解説

RTO（Recovery Time Objective）を15分未満に短縮し、アクティブ・アクティブ戦略を採用せずにバックアップリージョンへの自動フェイルオーバーを実現するには、以下の選択肢Bが最も適しています。 B. バックアップリージョンにAWS Lambda関数を作成し、読み取り専用レプリカの昇格およびAuto Scalingグループの値変更を実行します。Route 53にWebアプリケーションを監視するヘルスチェックを設定し、ヘルスチェックのステータスが異常になった場合にAmazon SNS通知をLambda関数に送信するよう構成します。アプリケーションのRoute 53レコードを、ヘルスチェックの失敗時にバックアップリージョンのALBへトラフィックをルーティングするフェイルオーバーポリシーに更新します。 解説： ・バックアップリージョンのLambda関数により、読み取り専用レプリカの昇格（プライマリDB化）およびAuto Scalingグループの最小／最大値を0から適切な値へ変更する処理を自動化できます。 ・Route 53のヘルスチェックは、アプリケーションの可用性を継続的に監視し、異常検知時にSNS経由でLambda関数を起動できます。 ・Route 53のフェイルオーバーポリシーは、ヘルスチェックの失敗を検知した時点で即座にバックアップリージョンのALBへトラフィックを切り替えるため、RTOの短縮に直接寄与します。 選択肢Aは不適切です。レイテンシーベースのルーティングは、主にアクティブ・アクティブ構成でのパフォーマンス最適化を目的としており、フェイルオーバー機能を提供しません。 選択肢Cは不適切です。Auto Scalingグループの値を事前に設定しても、読み取り専用レプリカの昇格やヘルスチェックによる自動検知・対応がなく、また「アクティブ・アクティブ戦略の予算がない」という前提に反します。 選択肢Dは不適切です。AWS Global Acceleratorはネットワークレイテンシー低減に有効ですが、アプリケーション層の可用性監視やDBフェイルオーバーなどの自動復旧機能は提供しておらず、RTO短縮の要件を満たしません。 したがって、正解はBです。バックアップリージョンのLambda関数作成、Route 53ヘルスチェックの設定、およびフェイルオーバーポリシーへのRoute 53レコード更新という組み合わせが、要件を最も的確に満たします。 Aは不適切：これはアクティブ・アクティブではなく、レイテンシーベースのルーティングは主にアクティブ・アクティブ用途であり、フェイルオーバーにはフェイルオーバーポリシーが必要です。 Cは不適切：「アクティブ・アクティブ戦略を実装する予算がない」という条件に明確に反しています。