共有ファイルストレージを伴う 3 台構成の高可用性移行
建築設計事務所が、社内で図面を共有する Web アプリケーションをオンプレミスで運用しています。アプリケーションは冗長性のために 3 台の Linux 仮想マシン上で動作し、各サーバーは同じファイル共有をマウントして図面ファイルを読み書きします。前段には HTTP のパスに基づいてリクエストを振り分けるロードバランサーが配置されています。同社は、このアプリケーションを可能な限り短期間で AWS へ移行し、AWS 上でも高可用性を確保する必要があります。アーキテクチャへの変更を最小限に抑えて要件を満たすソリューションはどれですか。
解説を読む（正解: B）
既存構成をできるだけそのまま持ち込む、いわゆるリホスト (リフト & シフト) が求められている設問です。オンプレミスの構成要素は、Linux サーバー 3 台、全台から同時マウントされる共有ファイルストレージ、HTTP のパスでルーティングするロードバランサーの 3 点であり、これらは AWS 上でそれぞれ複数アベイラビリティーゾーンに配置した Amazon EC2、Amazon EFS、Application Load Balancer に一対一で対応します。EFS は複数の EC2 インスタンスから同時にマウントできる NFS 互換の共有ファイルシステムで、既定で複数アベイラビリティーゾーンに冗長化されるため、アプリケーションコードを変更せずに共有ストレージと高可用性の両方を満たせます。ALB は HTTP のパスベースルーティングをネイティブにサポートするため、既存のロードバランサーの役割をそのまま引き継げます。よって選択肢 B が正解です。選択肢 A は、コンテナ化という追加作業が発生するうえ、Amazon S3 はオブジェクトストレージでありファイルシステム API を前提とするアプリケーションからは透過的に利用できません。また Network Load Balancer は L4 であり HTTP のパスによる振り分けができません。選択肢 C も同様に大規模な作り替えが必要で、FSx for Lustre は HPC 向けの高性能ファイルシステムであり用途が合わず、Network Load Balancer の問題も残ります。選択肢 D は、EBS が単一インスタンスに接続するブロックストレージで共有ができないこと、EBS にクロスリージョンレプリケーション機能が存在しないこと、ALB がリージョンをまたげないことから成立しません。
大量の VM とファイルサーバーを最短時間で移行する方式
産業機械メーカーが、自社データセンターの VMware クラスターで稼働する 90 台の仮想マシンを AWS へ移行しようとしています。仮想マシンのオペレーティングシステムは Windows と複数の Linux ディストリビューションが混在しており、社内で内製した制御ソフトウェアが多数インストールされています。加えて、オンプレミスには 12 TB のデータを保持する NFS ファイルサーバーがあります。移行のために 10 Gbps の AWS Direct Connect 接続はすでに開通済みです。移行を最も短い時間で完了できるソリューションはどれですか。
解説を読む（正解: A）
AWS Application Migration Service (AWS MGN) は、移行元サーバーにエージェントを導入してブロックレベルの継続的レプリケーションを行うリホスト (lift and shift) 用のマネージドサービスです。OS もインストール済みのソフトウェアもそのまま複製されるため、内製アプリケーションの再インストールや再設定が不要で、初回同期の完了後は数分のカットオーバーで切り替えられます。ファイルデータについては AWS DataSync が並列転送と整合性チェックを自動化し、専用線経由で高速に転送できます。10 Gbps の Direct Connect が開通済みであれば、12 TB のデータは理論上数時間で転送可能です。
A はこの 2 つを組み合わせ、OS とカスタムソフトを保ったまま 90 台をレプリケートし、NFS データは Direct Connect 経由で Amazon EFS へ転送するため、選択肢の中で最短の移行時間になります。
B は仮想マシンを 1 台ずつエクスポートして S3 にアップロードし VM Import/Export で AMI 化する手作業が多く、さらに NFS 部分は Snowball Edge の配送と返送で数日を要します。C は 90 台分の OS 構築と内製ソフトの再インストールを人手で行うため最も時間がかかり、失敗リスクも高く、Amazon FSx for Lustre は HPC 向けの高速並列ファイルシステムで一般的な NFS 共有の置き換え先としては適切ではありません。D は 10 Gbps の専用線が使える状況にもかかわらず、往復で 1 週間程度かかる Snowball Edge を 2 台使う選択であり、時間短縮の観点で明確に劣ります。
読み取り負荷の高い三層アプリの信頼性改善
オンラインで楽器を販売する企業が、自社サイトを AWS に移行しました。Web 層は Application Load Balancer (ALB) の背後にある 2 台の Amazon EC2 インスタンスで動作し、商品データは別の EC2 インスタンス上でセルフマネージドの MySQL に保存されています。アプリケーションのデータベース利用は圧倒的に読み取りが多く、商品画像などの静的コンテンツは各 EC2 インスタンスにアタッチされた Amazon EBS ボリュームから読み込むため、更新のたびに全ボリュームへコピーする運用が必要です。トラフィックは時間帯で大きく変動し、ピーク時にはリクエストを処理しきれません。トレースの結果、ピーク時の読み取り負荷にデータベースが追随できていないことが判明しました。アプリケーションの信頼性を最も高めるソリューションはどれですか。
解説を読む（正解: C）
この構成には信頼性を損なう要因が 3 つあります。第一に固定 2 台の Web 層がピークを吸収できないこと、第二に静的コンテンツを EBS ボリュームへ複製する運用が整合性と手作業のリスクを生むこと、第三にセルフマネージドの MySQL が単一障害点かつ読み取りのボトルネックになっていることです。正解の選択肢はこの 3 点を同時に解消します。アプリケーションをコンテナ化して Fargate 上の ECS サービスとして動かせば、サーバーの管理を排したうえで Application Auto Scaling により負荷に応じてタスク数を増減できます。静的コンテンツを Amazon EFS に集約すれば、複数のコンテナが同一のファイルシステムを同時にマウントでき、更新のたびに各ボリュームへコピーする必要がなくなり、EFS 自体も複数アベイラビリティーゾーンにデータを保持します。データベースは Aurora MySQL Serverless v2 へ移行しリーダーインスタンスを追加することで、読み取りをリーダーへ分散しつつ容量を自動でスケールでき、ライターに障害が起きてもリーダーへ昇格できます。A は Lambda 関数に EBS ボリュームをアタッチできないため技術的に成立せず、静的コンテンツの共有問題も解決しません。B は Step Functions ステートマシンを ALB のターゲットにできない点で成立しません (ALB のターゲットタイプは instance、ip、lambda のみです)。D は EBS ボリュームを単一のボリュームとして複数の Fargate タスクから共有マウントできないため誤りで、静的コンテンツの共有という中心的な課題が未解決のまま残ります。