オンプレミス Linux サーバー群の DR で RTO 20 分 / RPO 10 分を満たす構成
ある自動車部品メーカーは、工場の製造実行システムの災害復旧サイトとして AWS を利用したいと考えています。このシステムは 300 台を超える Linux サーバーで構成され、すべてのサーバーが共通の NFS 共有をマウントしています。事業部門が定めた目標復旧時間 (RTO) は 20 分、目標復旧時点 (RPO) は 10 分です。同社は独自スクリプトの保守を避け、AWS ネイティブなフェイルオーバーおよびフェイルバック機能を利用したいと考えています。これらの要件を最もコスト効率よく満たすソリューションはどれですか。
解説を読む（正解: B）
RPO 10 分・RTO 20 分という厳しい目標を、本番同等の環境を常時二重に持たずに達成するには、ブロックレベルの継続的レプリケーションによってウォームスタンバイに近い状態を維持する方式が適しています。AWS Elastic Disaster Recovery (AWS DRS) は、ソースサーバーにエージェントを導入してディスクを継続的に AWS 上の低コストなステージング領域へレプリケートし、災害時にのみ本番用の Amazon EC2 インスタンスを起動する仕組みです。レプリケーションは継続的なので RPO は秒から分の単位に収まり、起動から復旧までも分単位で完了するため RTO 20 分を満たせます。さらに AWS DRS はネイティブなフェイルバック機能を備えており、復旧後にオンプレミスの新規または既存サーバーへデータを戻すことができるため、独自スクリプトの保守が不要という要件にも合致します。選択肢 B はこれに加えて共有 NFS のデータを AWS DataSync で 10 分ごとに複製し AWS 側で共有ファイルシステムとして利用するため、要件をすべて満たしつつ平常時のコストを抑えられます。選択肢 A はバックアップ間隔が 6 時間であり、RPO 10 分をまったく満たしません。選択肢 D は複製間隔が 15 分で RPO を超過するうえ、テンプレートのデプロイからサーバー復旧までを考えると RTO 20 分も危うく、フェイルバックも AWS ネイティブな DR 機能とは言えません。選択肢 C のマルチサイトアクティブ/アクティブは RTO と RPO は満たせるものの、本番同等の環境を常時二重に維持する最も高コストな方式であり、rsync による同期も AWS ネイティブなフェイルオーバー/フェイルバック機能ではないため、コスト効率の要件から外れます。
共有ファイルシステムのマルチ AZ 化による処理継続性の確保
動画変換サービスを運営する企業が、3 つのアベイラビリティーゾーンにまたがる Auto Scaling グループの EC2 インスタンス群から、Amazon EFS の One Zone ストレージクラスのファイルシステムを NFS でマウントし、素材ファイルと変換結果を共有しています。先日そのファイルシステムがあるゾーンで障害が発生し、他の 2 ゾーンのインスタンスも含めすべての変換ジョブが停止しました。運用チームは、単一ゾーンの障害が発生しても処理を継続できること、3 つのゾーンすべての EC2 インスタンスから同一のファイルへ POSIX セマンティクスで同時に読み書きできること、可能な限りマネージドサービスで運用負荷を抑えること、そして Linux 上の既存の NFS マウント構成とアプリケーションコードを変更しないことを求めています。最も適切な移行先はどれですか。
解説を読む（正解: D）
Amazon EFS には、データを 1 つのアベイラビリティーゾーン内にのみ保存する One Zone ストレージクラスと、リージョン内の複数のアベイラビリティーゾーンに冗長化して保存するリージョン (Standard) ストレージクラスがあります。One Zone はコストが低い一方で、そのゾーンが失われるとファイルシステム全体が利用できなくなり、他ゾーンのクライアントも巻き込んで停止します。今回の障害はまさにこの特性によるものです。
D は、リージョンストレージクラスの EFS ファイルシステムへ移行することで、単一ゾーンの障害が発生してもファイルシステム自体は利用可能なままとなり、他ゾーンの EC2 インスタンスは処理を継続できます。EFS は NFSv4 をネイティブにサポートし、複数のインスタンスから同一ファイルへ POSIX セマンティクスで同時アクセスできるため、既存のマウント構成やアプリケーションコードを変えずに済みます。各アベイラビリティーゾーンにマウントターゲットを作成して自ゾーン経由でマウントすれば、ゾーン間のデータ転送も回避できます。データ移行には EFS レプリケーションや AWS DataSync といったマネージドな手段が使え、運用負荷も抑えられます。
B は、EBS のマルチアタッチが単一のアベイラビリティーゾーン内の複数インスタンスにのみ対応しており、ゾーンをまたいだ共有はできません。さらにクラスター対応のファイルシステムが必要で、通常の ext4 や XFS を複数インスタンスから同時にマウントするとデータが破損します。C は、リストアが完了するまで処理が停止するため障害時に処理を継続できるという要件を満たさず、手動または自動化の実装が必要で運用負荷も増えます。A は、FSx for Windows File Server が SMB プロトコルを前提としたサービスであり、Linux からのマウント方法もアクセス権限モデルも変わるため、既存の NFS マウント構成を変更しないという要件に反します。
帯域制約下での大容量メディアアーカイブ移行
放送局のメディア資産部門が、オンプレミスの NAS とテープライブラリに保管している約 900 TB の映像アーカイブを Amazon S3 へ移行します。データセンターの回線は 500 Mbps で、日常業務のトラフィックと共有しているため移行に使えるのは実質半分程度です。経営層は 6 週間以内に移行を完了させることを求めています。移行後も編集チームが毎日生成する数 TB の新規素材を継続的に S3 へ同期する必要があります。最も適切なアプローチはどれですか。
解説を読む（正解: A）
移行時間の見積もりは「データ量 ÷ 実効帯域」から始めます。実質 250 Mbps 程度しか使えない回線で 900 TB を送ると単純計算で 300 日を超え、6 週間という期限には物理的に届きません。AWS Snow Family はこの帯域制約を回避するためのサービスで、AWS Snowball Edge Storage Optimized デバイスを複数台並行して使えばペタバイト級のデータでも数週間で AWS へ取り込めます。デバイス上のデータは暗号化され、鍵は AWS Key Management Service で管理されるため輸送中の安全性も確保されます。一方で日々発生する増分は容量が小さくネットワーク転送で十分間に合うため、差分検出と整合性検証を自動化できる AWS DataSync のスケジュールタスクが適しています。したがって A が正解です。B は Transfer Acceleration もマルチパートアップロードも回線の物理帯域そのものを増やすものではなく、ボトルネックが解消されないため期限に間に合いません。C は Direct Connect 専用接続のプロビジョニングに数週間を要するうえ、1 Gbps でも 900 TB の転送には 3 か月近くかかります。D の Tape Gateway はバックアップソフトウェア向けの仮想テープライブラリを提供するもので、データは結局同じ回線を通るため所要時間は変わらず、アーカイブを素材として活用する要件にも合いません。