グローバル公開に向けた読み取り中心サイトの応答時間短縮 料理動画のサブスクリプションサイトを運営するメディア企業が、今月から初めて世界同時配信を開始します。現在のサイトは、ウェブ層の前段に Application Load Balancer、ウェブ層とアプリケーション層に Amazon EC2 インスタンスのフリート、バックエンドに Amazon Aurora MySQL という構成です。ページの多くはレシピ画像やサムネイルなどの静的コンテンツを含んでおり、トラフィックのほぼすべてが読み取りです。同社は配信開始直後にインターネットトラフィックが大幅に急増すると予想しており、最初の 1 週間はパフォーマンスを最優先とする方針です。世界中のユーザーに対するシステム応答時間を短縮するために取るべき手順の組み合わせはどれですか。2 つ選択してください。
A 論理的なクロスリージョンレプリケーションで Aurora MySQL データベースをセカンダリリージョンにレプリケートする。ウェブサーバーを Amazon S3 に置き換え、S3 バケットをクロスリージョンレプリケーション構成でデプロイする。 B ウェブ層とアプリケーション層をそれぞれ Auto Scaling グループに配置する。AWS Direct Connect 接続を導入し、ウェブ層とアプリケーション層を世界中のリージョンにデプロイする。 C データベースを Amazon Aurora から Amazon RDS for MySQL に移行する。ウェブ層、アプリケーション層、データベース層の 3 層をすべてプライベートサブネットに配置する。 D 物理的なクロスリージョンレプリケーションを行う Aurora Global Database を使用する。静的コンテンツとアセットはクロスリージョンレプリケーションを構成した Amazon S3 に配置する。ウェブ層とアプリケーション層を世界各地のリージョンにデプロイする。 E Amazon Route 53 のレイテンシーベースルーティングと Amazon CloudFront ディストリビューションを導入する。ウェブ層とアプリケーション層をそれぞれ Auto Scaling グループに配置する。
判定する 複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: D、E） 世界中のユーザーの応答時間を短縮するには、ユーザーに近い場所でコンテンツを返すことと、動的処理とデータ読み取りをユーザーに近いリージョンで完結させることの両方が必要です。Amazon CloudFront は世界中のエッジロケーションで静的コンテンツをキャッシュし、動的リクエストも AWS のバックボーン経由でオリジンへ転送するため、初回アクセス以外のラウンドトリップを大幅に短縮できます。これを Route 53 のレイテンシーベースルーティングと組み合わせれば、ユーザーは最も速いリージョンのスタックへ誘導され、Auto Scaling グループが急増するトラフィックを吸収します (E)。さらに Aurora Global Database は専用のストレージ層レプリケーションによって、通常 1 秒未満の遅延でセカンダリリージョンに読み取り可能なクラスターを提供するため、読み取り中心のワークロードを各リージョンでローカルに処理でき、静的アセットを S3 のクロスリージョンレプリケーションで各地に配置すればオリジンまでの距離も縮まります (D)。A はウェブサーバーを S3 に置き換えるとしていますが、本サイトは動的サイトであり静的ホスティングだけでは成立せず、Aurora の論理レプリケーションは Global Database より遅延が大きく運用も煩雑です。B の AWS Direct Connect はオンプレミス拠点と AWS を結ぶ専用線サービスであり、インターネット経由でアクセスする一般消費者の応答時間には寄与しません。C は Aurora から RDS for MySQL への移行でむしろ読み取りスケーラビリティが下がり、サブネット配置の変更はセキュリティ上の話でレイテンシーとは無関係です。
オンプレミス 3 層 Web アプリの可用性重視の移行設計 全国にクリーニング店舗を展開する企業が、会員向けの 3 層構成 Web アプリケーションを自社データセンターで運用しています。年末セール時のアクセス集中でサービスが数時間停止し、売上に大きな損失が出たため、経営層は AWS への移行を決定しました。アプリケーションは .NET で実装され、バックエンドは MySQL データベースに依存しています。ソリューションアーキテクトは、1 日あたり 35 万人の利用者を処理できる、スケーラブルで可用性の高い構成を設計しなければなりません。この要件を満たすために実行すべき手順はどれですか。
A AWS Elastic Beanstalk で新しい Web サーバー環境を作成し、環境内に Amazon RDS for MySQL の Multi-AZ 配置を含める。複数のアベイラビリティーゾーンにまたがる Amazon EC2 Auto Scaling グループの前段に Network Load Balancer を配置し、Amazon Route 53 のエイリアスレコードで自社ドメインから NLB へルーティングする B AWS CloudFormation スタックで、3 つのアベイラビリティーゾーンにまたがる Amazon EC2 Auto Scaling グループの前段に Application Load Balancer を配置する。同じスタックで Amazon Aurora MySQL 互換の Multi-AZ DB クラスターを Retain 削除ポリシー付きで作成し、Amazon Route 53 のエイリアスレコードで自社ドメインから ALB へルーティングする C AWS Elastic Beanstalk で 2 つのリージョンに Auto Scaling 対応の Web サーバー環境を作成し、各リージョンに Application Load Balancer を配置する。Amazon Aurora MySQL 互換 DB クラスターの Multi-AZ 配置をクロスリージョンリードレプリカで構成し、Amazon Route 53 の地理的近接性ルーティングポリシーで 2 リージョンにトラフィックを分散する D AWS CloudFormation スタックで、3 つのアベイラビリティーゾーンにまたがるスポットインスタンスのみで構成した Amazon ECS クラスターの前段に Application Load Balancer を配置する。同じスタックで Amazon RDS for MySQL の単一 DB インスタンスを Snapshot 削除ポリシー付きで作成し、Amazon Route 53 のエイリアスレコードで自社ドメインから ALB へルーティングする
解説を読む（正解: B） オンプレミスの 3 層 Web アプリケーションを AWS へ移行する際は、Web 層の水平スケールとデータベース層の自動フェイルオーバーを同時に確保することが可用性設計の要点になります。HTTP/HTTPS を扱う Web 層には、パスやホストによるルーティング、HTTP レベルのヘルスチェック、スティッキーセッションを備えた Application Load Balancer が適しており、これを複数アベイラビリティーゾーンの EC2 Auto Scaling グループの前段に置くことで、需要変動と AZ 障害の双方に対応できます。データベースは Aurora MySQL 互換の Multi-AZ DB クラスターにすることで、共有ストレージによる高速なフェイルオーバーとリードレプリカによる読み取りスケールが得られます。さらに CloudFormation で構築し、DB クラスターに Retain 削除ポリシーを設定しておけば、スタック操作の誤りでデータが失われる事故を防げます。したがって選択肢 B が最適です。選択肢 A は Network Load Balancer がレイヤー 4 の負荷分散であり、Web アプリケーションに必要な HTTP レベルの機能を提供しません。加えて Elastic Beanstalk 環境の中に RDS を作成すると DB のライフサイクルが環境と結び付き、環境削除時にデータを失うリスクがあります。選択肢 C は要件にないマルチリージョンのアクティブ構成であり、コストが跳ね上がるうえ、クロスリージョンリードレプリカは書き込み可用性を高めません。選択肢 D はスポットインスタンスのみで本番 Web 層を構成しているため中断リスクがあり、単一 AZ の RDS インスタンスも単一障害点として残ります。
RTO 10 時間・RPO 3 時間を満たす最小コストの DR 設計 動物病院向けの電子カルテ SaaS を提供する企業が、サービスを AWS へ移行しました。構成は Application Load Balancer、Amazon ECS クラスターで動作する Docker アプリケーション、診療記録を保持する Amazon RDS for PostgreSQL、そしてコンテナイメージを保管する Amazon ECR から成ります。企業は契約する動物病院に対し、リージョン規模の障害が発生した場合でも RTO 10 時間以内、RPO 3 時間以内で復旧するというディザスタリカバリ SLA を提示する必要があります。平常時の追加コストはできる限り抑えたいと考えています。この要件を最もコスト効率よく満たすソリューションはどれですか。
A AWS Backup で RDS データベースのバックアップを 3 時間ごとに取得し、別リージョンへコピーする。災害発生時は AWS CLI で最新のバックアップからデータベースを復元し、ECS タスクを手動で起動する。 B Amazon Aurora グローバルデータベースへ移行してプライマリリージョンとセカンダリリージョン間でデータを同期し、セカンダリリージョンに AWS Fargate のキャパシティを常時確保する。災害発生時に Fargate タスクを起動する AWS Lambda 関数を構成する。 C Amazon ECR のクロスリージョンレプリケーションでコンテナイメージを両リージョンに保持する。RDS のスナップショットを 3 時間ごとに取得し、セカンダリリージョンへコピーする。災害発生時は AWS CloudFormation テンプレートでセカンダリリージョンに VPC、ALB、ECS クラスター、RDS をデプロイし、最新スナップショットから復元したうえで Amazon Route 53 のレコードをセカンダリの ALB へ切り替える。 D AWS Site-to-Site VPN でプライマリリージョンとセカンダリリージョンを接続する。AWS DataSync で 3 時間ごとに RDS のデータを Amazon S3 へバックアップし、クロスリージョンレプリケーションで同期する。災害発生時は S3 から手動でデータを復元する。
解説を読む（正解: C） ディザスタリカバリ戦略は、要求される RTO と RPO に見合った最小コストのものを選ぶのが原則です。RTO 10 時間・RPO 3 時間という比較的緩やかな目標であれば、セカンダリリージョンに常時リソースを稼働させるウォームスタンバイやアクティブ-アクティブは過剰投資であり、バックアップ&リストアで十分に達成できます。選択肢 C は、Amazon ECR のクロスリージョンレプリケーションでコンテナイメージを事前に配置し、RDS の 3 時間ごとのスナップショットをセカンダリへコピーすることで RPO 3 時間を満たし、復旧時に AWS CloudFormation で環境一式を再構築して Route 53 を切り替える手順で RTO 10 時間に収めます。平常時に発生するのはスナップショットとイメージのストレージ料金だけなので、最もコスト効率に優れます。選択肢 A は、データベースは復元できてもコンテナイメージ、VPC、ALB、ECS クラスターといった周辺リソースをセカンダリリージョンに用意する手段が定義されておらず、手作業中心の復旧では RTO を担保できません。選択肢 B の Aurora グローバルデータベースは RPO 秒単位・RTO 分単位を実現できますが、セカンダリクラスターを常時稼働させるため要件に対してコストが過大であり、RDS for PostgreSQL からのエンジン移行という追加作業も伴います。選択肢 D は、AWS DataSync がファイルおよびオブジェクトストレージ間の転送サービスであり、稼働中の RDS から一貫性のあるバックアップを取得する用途には使えないため、そもそも成立しません。