Q18 — AWS SAA-C03 第17章
第 18/89 問 | ← 第17章
Q1318. ある企業は、オンプレミスのデータセンターでDockerコンテナを使用するアプリケーションを実行しています。このアプリケーションはコンテナホスト上で動作し、永続的なデータファイルをローカルボリュームに保存しています。コンテナインスタンスは、この保存された永続データを利用します。同社は、このアプリケーションを完全マネージド型のAWSサービスへ移行したいと考えています。 これらの要件を満たすソリューションはどれですか?
- A. Amazon Elastic Kubernetes Service(Amazon EKS)をセルフマネージドノードで使用します。Amazon EC2インスタンスにAmazon Elastic Block Store(Amazon EBS)ボリュームをアタッチし、そのEBSボリュームをコンテナにマウントして永続ストレージを提供します。
- B. Amazon Elastic Container Service(Amazon ECS)をAWS Fargate起動タイプで使用します。Amazon Elastic File System(Amazon EFS)ボリュームを作成し、そのEFSボリュームをコンテナにマウントして永続ストレージを提供します。 ✓
- C. Amazon Elastic Container Service(Amazon ECS)をAWS Fargate起動タイプで使用します。Amazon DynamoDBテーブルを作成し、アプリケーションがこのDynamoDBテーブルを永続ストレージとして利用するよう設定します。
- D. Amazon Elastic Container Service(Amazon ECS)をAmazon EC2起動タイプで使用します。Amazon Elastic File System(Amazon EFS)ボリュームを作成し、そのEFSボリュームをコンテナにマウントして永続ストレージを提供します。
正解: B. Amazon Elastic Container Service(Amazon ECS)をAWS Fargate起動タイプで使用します。Amazon Elastic File System(Amazon EFS)ボリュームを作成し、そのEFSボリュームをコンテナにマウントして永続ストレージを提供します。
解説
要件(Dockerベースのアプリケーションを、永続ストレージ付きで完全マネージド型のAWSサービスへ移行)を満たす正しいソリューションは、選択肢Bです。 ■ 選択肢Bが正しい理由: ・完全マネージド型サービス Amazon ECS+Fargateは、サーバーレスなコンテナオーケストレーションサービスであり、基盤となるインフラ(EC2インスタンス)をAWSが全面的に管理します。 Amazon EFSは、完全マネージド型・スケーラブルなNFSファイルシステムであり、Fargateとの連携による永続ストレージをシームレスに提供します。 ・永続ストレージのサポート EFSボリュームはFargateタスクに直接マウント可能で、コンテナが共有・永続的なデータ(オンプレミスのローカルボリュームと同様)にアクセスできます。EFSはストレージ需要に応じて自動スケールし、可用性ゾーン(AZ)間でレプリケートされるため、高い耐久性を実現します。 ・サーバー管理不要 ECS+EC2(選択肢D)やEKS+セルフマネージドノード(選択肢A)とは異なり、Fargateではサーバーのプロビジョニング・パッチ適用・スケーリングポリシー管理などの運用負荷が一切発生しません。 ■ 他の選択肢が不適切な理由: A:EKS+セルフマネージドノード+EBSは「完全マネージド」ではなく、EC2インスタンスの管理が必要です。またEBSは単一EC2インスタンスに紐づくブロックストレージであり、複数のコンテナ/タスク間で共有できません(EFSとは異なります)。 C:DynamoDBはNoSQLデータベースであり、ファイルシステムではありません。ログ、設定ファイル、ユーザーアップロードなど「ファイル単位の永続化」を必要とするアプリケーションには不適切です。 D:ECS+EC2起動タイプは、EC2インスタンスのスケーリング・パッチ適用など、サーバー管理が発生するため、「完全マネージド」という要件に反します。 ■ 選択肢Bの実装手順概要: 1. Amazon ECS(Fargate)クラスター作成:VPCおよびサブネットを指定し、「Networking only」タイプを選択。 2. Amazon EFSファイルシステム作成:同一VPC内に作成し、各AZにマウントターゲットを配置(高可用性のため)。暗号化(KMS)およびライフサイクルポリシー(例:低頻度アクセスへの移行)を有効化。 3. EFSボリュームを含むECSタスク定義作成:タスク定義内でEFSファイルシステムIDおよび(任意)アクセスポイントIDを指定し、コンテナ内のパス(例:/app/data)にマウント。 4. タスクまたはサービスとしてデプロイ:1回限りのタスクまたは長期実行向けサービスとして起動。CloudWatchメトリクスに基づくスケーリングも可能。 5. 永続性検証:タスク再起動後も/app/data以下のファイルが保持されることを確認。 ■ 補足考慮事項: ・パフォーマンス:EFSはNFSプロトコルのためEBSより遅延が大きいが、共有・スケーラブルという利点あり。高パフォーマンス要件には「Provisioned Throughput」(専用IOPS課金)を検討。 ・セキュリティ:EFSアクセスポイントでディレクトリ単位のアクセス制御を実施。VPCエンドポイントでトラフィックをAWSネットワーク内に閉じる。静止時(KMS)および転送時(TLS)の暗号化を有効化。 ・コスト最適化:EFSは使用容量(GB/月)とメタデータ操作数で課金。低頻度アクセスファイルはEFS Infrequent Access(EFS IA)へ自動移行するライフサイクルポリシーを活用。 結論:選択肢Bは、完全マネージド型のECS Fargateと、スケーラブルかつ共有可能な永続ストレージを提供するEFSを組み合わせており、要件を最も適切に満たします。他の選択肢は、不要な複雑さ(A・D)または不適切なストレージタイプ(C)という課題を抱えています。