Q64 — AWS SAA-C03 第15章
第 64/100 問 | ← 第15章
Q1164. ある企業が、ドキュメント管理アプリケーションを AWS に移行しようとしています。このアプリケーションは Linux サーバー上で実行されます。企業は、このアプリケーションを Auto Scaling グループ内の Amazon EC2 インスタンスに移行する予定です。企業は、共有ストレージファイルシステム上に 7 TiB のドキュメントを保存しています。外部のリレーショナルデータベースがこれらのドキュメントを追跡しています。ドキュメントは一度だけ保存され、その後、いつでも参照のために複数回取得される可能性があります。移行中にアプリケーションを変更することはできません。ストレージソリューションは、高い可用性を備え、将来的な規模拡大にも対応できる必要があります。これらの要件を最もコスト効率よく満たすソリューションはどれですか?
- A. 強化ネットワーキングを有効にした EC2 インスタンスを共有 NFS ストレージシステムとして展開し、NFS シェアをエクスポートします。Auto Scaling グループ内の EC2 インスタンスからその NFS シェアをマウントします。
- B. S3 Standard-Infrequent Access(S3 Standard-IA)ストレージクラスを使用する Amazon S3 バケットを作成し、Auto Scaling グループ内の EC2 インスタンスからその S3 バケットをマウントします。
- C. AWS Transfer for SFTP と Amazon S3 バケットを用いて SFTP サーバーエンドポイントを展開します。Auto Scaling グループ内の EC2 インスタンスをその SFTP サーバーに接続するよう設定します。
- D. 複数の可用性ゾーンにマウントポイントを持つ Amazon Elastic File System(Amazon EFS)ファイルシステムを作成し、EFS Standard-Infrequent Access(Standard-IA)ストレージクラスを使用します。Auto Scaling グループ内の EC2 インスタンスからその NFS シェアをマウントします。 ✓
正解: D. 複数の可用性ゾーンにマウントポイントを持つ Amazon Elastic File System(Amazon EFS)ファイルシステムを作成し、EFS Standard-Infrequent Access(Standard-IA)ストレージクラスを使用します。Auto Scaling グループ内の EC2 インスタンスからその NFS シェアをマウントします。
解説
企業のドキュメント管理アプリケーションを AWS へ移行するにあたり、最もコスト効率が良く、かつ要件を満たすストレージソリューションを特定するため、以下の要件を確認し、各選択肢を検討します。主な要件:・高い可用性:障害発生時にも耐える必要がある。・スケーラビリティ:ドキュメント量の増加に伴い、ストレージも柔軟に拡張可能である必要がある。・コスト効率:上記要件を満たしつつ、総所有コスト(TCO)を最小限に抑える必要がある。・アプリケーションの変更不可:既存の Linux サーバー環境および NFS を想定した共有ストレージとの互換性が必須である。・7 TiB のデータ量:この規模を効率的に扱えること。・アクセスパターン:ドキュメントは一度書き込まれ、その後複数回読み出される(読み取り中心のワークロード)。各選択肢の検討:選択肢 A:EC2 インスタンスを共有 NFS ストレージとして使用する。利点:NFS サポートにより、アプリケーションの変更なしで利用可能。欠点:単一障害点(EC2 インスタンスの障害でサービス停止)であり、高可用性を実現するにはマルチAZ構成やクラスタリングなどの追加設定が必要(運用負荷・コスト増加)。また、NFS サーバー自体のスケーリングや管理が手動で必要であり、長期的なストレージ用途としては非効率。→ 要件である「高い可用性」と「スケーラビリティ」を十分に満たさない。選択肢 B:S3 Standard-IA バケットを s3fs などを使って EC2 にマウントする。利点:S3 は極めて高い可用性・耐久性・スケーラビリティを備え、Standard-IA はアクセス頻度の低いデータにコスト効率的。欠点:S3 はオブジェクトストレージであり、NFS プロトコルをネイティブにサポートしない。s3fs などのツールは本番環境での使用が推奨されておらず、パフォーマンス・一貫性・信頼性に課題がある。アプリケーションが NFS ファイルシステムを前提としているため、変更なしでは動作保証ができない。→ アプリケーション互換性の観点から不適切。選択肢 C:AWS Transfer for SFTP を用いた SFTP エンドポイント+S3。利点:S3 のメリットを活かしつつ、SFTP 経由でアクセス可能。欠点:アプリケーションはファイルシステムレベル(NFS)でのアクセスを前提としており、SFTP への変更にはアプリケーション側の大幅な改修(SFTP クライアントの導入・処理ロジック変更など)が必要。Transfer for SFTP の追加コストと複雑さも無駄となる。→ アプリケーション変更不可という制約に反する。選択肢 D:マルチAZ 対応の Amazon EFS(Standard-IA)を採用し、EC2 インスタンスから NFS でマウント。利点:・Amazon EFS は、完全マネージド型・マルチAZ 対応・NFS プロトコルをネイティブサポートする、高可用性かつ自動スケーリング可能なファイルシステム。・Standard-IA ストレージクラスは、アクセス頻度の低いデータに最適化されており、Standard より低コスト(ただし、取得時に少量のリトリーバル料金が発生)。・Linux の標準 NFS クライアントで接続可能であり、アプリケーションの変更は一切不要。・7 TiB のデータ量にも容易に対応可能。欠点:S3 より若干高いストレージコストだが、NFS 互換性・運用簡易性・可用性向上によるトータルコスト削減効果が大きく、全体として最もバランスの取れた選択。→ 全要件(高可用性、スケーラビリティ、コスト効率、アプリケーション非変更)を最もよく満たす。最終的な正解:D。複数の可用性ゾーンにマウントポイントを持つ Amazon Elastic File System(Amazon EFS)ファイルシステムを作成し、EFS Standard-Infrequent Access(Standard-IA)ストレージクラスを使用します。Auto Scaling グループ内の EC2 インスタンスからその NFS シェアをマウントします。このソリューションは、高い可用性、自動スケーリング、NFS 互換性を確保しつつ、アクセス頻度の低いドキュメントに最適化されたコスト効率を実現します。