Q53 — AWS SAP-C02 第2章
第 53/75 問 | ← 第2章
Q203. ソリューションアーキテクトは、Web層、アプリケーション層、NoSQLデータ層から構成される3層アプリケーション向けのリファレンスアーキテクチャを定義する必要があります。このリファレンスアーキテクチャは、以下の要件を満たす必要があります： - 1つのAWSリージョン内での高可用性 - ディザスタリカバリ（DR）のために、1分以内に別のAWSリージョンへフェイルオーバー可能であること - ユーザー体験への影響を最小限に抑えつつ、最も効率的なソリューションを提供すること これらの要件を満たすための手順の組み合わせはどれですか？（3つ選択してください。）
- A. Amazon Route 53 の加重ルーティングポリシーを使用し、選択した2つのリージョン間でトラフィック配分を100/0に設定します。 TTL（Time to Live）を1時間に設定します。
- B. Amazon Route 53 のフェイルオーバールーティングポリシーを使用して、プライマリリージョンからディザスタリカバリリージョンへフェイルオーバーします。 TTL（Time to Live）を30秒に設定します。 ✓
- C. Amazon DynamoDB のグローバルテーブル機能を活用し、選択した2つのリージョンでデータにアクセス可能にします。 ✓
- D. プライマリリージョンのAmazon DynamoDBテーブルから60分ごとにデータをバックアップし、Amazon S3に書き込みます。 S3クロスリージョンレプリケーションを使用して、プライマリリージョンからディザスタリカバリリージョンへデータをコピーします。 障害発生時に、スクリプトでS3からDynamoDBへデータをインポートします。
- E. Web層およびアプリケーション層に対して、各リージョン内の複数のAvailability ZoneにまたがるAuto Scalingグループを用いたホットスタンバイモデルを実装します。 最低限必要なサーバー数についてはゾーン別Reserved Instancesを、追加リソースにはOn-Demand Instancesを使用します。 ✓
- F. Web層およびアプリケーション層に対して、各リージョン内の複数のAvailability ZoneにまたがるAuto Scalingグループを使用します。 必要なリソースにはSpot Instancesを使用します。
正解: B. Amazon Route 53 のフェイルオーバールーティングポリシーを使用して、プライマリリージョンからディザスタリカバリリージョンへフェイルオーバーします。 TTL（Time to Live）を30秒に設定します。, C. Amazon DynamoDB のグローバルテーブル機能を活用し、選択した2つのリージョンでデータにアクセス可能にします。, E. Web層およびアプリケーション層に対して、各リージョン内の複数のAvailability ZoneにまたがるAuto Scalingグループを用いたホットスタンバイモデルを実装します。 最低限必要なサーバー数についてはゾーン別Reserved Instancesを、追加リソースにはOn-Demand Instancesを使用します。
解説
選択肢Aでは、Amazon Route 53の加重ルーティングポリシーと1時間のTTLが提案されていますが、これは障害発生時のフェイルオーバーが遅く、要件である「1分以内」を満たしません。 選択肢Dでは、Amazon DynamoDBのデータをS3へバックアップし、クロスリージョンレプリケーションを利用する方法が示されていますが、選択肢Cで推奨されるグローバルテーブルを活用すれば、このような手動またはバッチベースのバックアップは不要です。 選択肢Fでは、Auto ScalingグループにSpot Instancesを用いることが提案されていますが、Spot Instancesは中断される可能性があり、高可用性の維持やユーザー体験への影響低減という要件には不適切です。 したがって、選択肢B、C、Eの組み合わせが、提示された要件を最もよく満たすソリューションです。具体的には： ・Amazon Route 53のフェイルオーバールーティングポリシー（TTL 30秒）により、プライマリリージョン障害時に迅速かつ効率的なフェイルオーバーを実現します。 ・Amazon DynamoDBのグローバルテーブルにより、2つのリージョン間でリアルタイムにデータを同期・アクセス可能にし、DR時のデータ整合性と可用性を確保します。 ・各リージョン内で複数のAvailability ZoneにまたがるAuto Scalingグループによるホットスタンバイモデル（最低限のサーバーにゾーン別Reserved Instances、余剰負荷にOn-Demand Instances）により、高い可用性を維持しつつ、ユーザー体験への影響を最小限に抑えます。