355-AWS SAP AWS 「理論・実践・一問道場」Amazon ECS

type

status

date

slug

summary

理論

1. コンテナベースのアプリケーションの移行

コンテナ化されたアプリケーションは、インフラの管理負担を減らし、移行をスムーズにします。AWSにはコンテナを管理するためのサービスがいくつかあり、最も代表的なのは Amazon ECS (Elastic Container Service) と Amazon EKS (Elastic Kubernetes Service) です。

AWS Fargate は、ECSおよびEKSと連携し、サーバーレスでコンテナを実行するためのサービスです。Fargateを使用すると、インフラストラクチャの管理をAWSに任せることができ、アプリケーションに集中できます。

2. ストレージソリューションの選定

アプリケーションがデータを保存するために使用するストレージの選定は、アプリケーションの要求に基づいて行います。特に、低レイテンシ、スケーラビリティ、共有アクセスが必要な場合、以下のストレージオプションが考えられます：

Amazon EFS (Elastic File System): 複数のインスタンスからの共有アクセスを提供するスケーラブルなファイルシステム。高い可用性と耐障害性を持ち、コンテナ化されたアプリケーションに適しています。EFSはファイルシステムインターフェースを提供し、アプリケーションが既存のファイル操作に依存している場合に最適です。
Amazon EBS (Elastic Block Store): 個々のEC2インスタンスにアタッチするブロックストレージですが、EBSは単一インスタンスでしか共有できません。従って、スケーラブルなコンテナアプリケーションにはEBSは不向きです。

3. AWS FargateとEFSの組み合わせ

AWS Fargate と EFS の組み合わせは、コンテナ化されたアプリケーションにとって理想的なソリューションです。Fargateは、コンテナの実行をマネージドサービスとして提供し、EFSは複数のコンテナから同時にアクセス可能なファイルストレージを提供します。これにより、インフラストラクチャの管理が不要になり、アプリケーションのスケーリングも簡単に行えます。

4. AWSサービスの選定基準

EFS vs. EBS: アプリケーションのデータが複数のインスタンスやコンテナによって共有される場合、EFSが最適です。一方、EBSは単一のインスタンスに対するストレージを提供するため、共有アクセスが必要ない場合に適しています。

Fargate vs. EC2: EC2はインフラストラクチャの管理が必要ですが、Fargateはサーバーレスでコンテナを実行でき、インフラ管理の負担を軽減します。Fargateを使用すると、アプリケーション開発者はインフラの管理から解放され、アプリケーションの開発に集中できます。

5. スケーラビリティと低レイテンシ

ストレージがスケールする能力と低レイテンシを提供することが重要です。EFSは必要に応じて自動的にスケールするため、トランザクションデータなど高負荷なデータ処理に適しています。また、EFSは数ミリ秒のレイテンシでアクセスでき、コンテナ間でのデータ共有に優れたパフォーマンスを発揮します。

結論

この問題の解答で最適な選択肢は、AWS Fargate for ECS と EFSの組み合わせです。Fargateはサーバーレスで管理が不要なコンテナ環境を提供し、EFSはスケーラブルで低レイテンシのファイルシステムを提供するため、コンテナ間での共有ストレージに最適です。この組み合わせにより、インフラストラクチャの管理負担を軽減し、アプリケーションのスケーリングを自動化することができます。

実践

略

一問道場

ある会社が、オンプレミスのトランザクション処理アプリケーションをAWSに移行する計画をしています。このアプリケーションは、会社のデータセンター内の仮想マシン（VM）上でホストされるDockerコンテナ内で動作しています。Dockerコンテナには、アプリケーションがトランザクションデータを記録するための共有ストレージがあります。このトランザクションは時間に敏感であり、アプリケーション内のトランザクション量は予測できません。会社は、需要の増加に対応してスループットを自動的にスケールできる低遅延のストレージソリューションを実装する必要があります。会社はアプリケーションのさらなる開発を行えず、Dockerホスティング環境の管理も続けることができません。

会社はこの要件を満たすためにどのようにアプリケーションをAWSに移行すべきですか？

A. アプリケーションを実行するコンテナをAmazon Elastic Kubernetes Service（Amazon EKS）に移行します。トランザクションデータをコンテナが共有するためにAmazon S3を使用します。

B. アプリケーションを実行するコンテナをAWS Fargate for Amazon Elastic Container Service（Amazon ECS）に移行します。Amazon Elastic File System（Amazon EFS）ファイルシステムを作成します。Fargateタスク定義を作成し、タスク定義にボリュームを追加してEFSファイルシステムを指すようにします。

C. アプリケーションを実行するコンテナをAWS Fargate for Amazon Elastic Container Service（Amazon ECS）に移行します。Amazon Elastic Block Store（Amazon EBS）ボリュームを作成します。Fargateタスク定義を作成し、EBSボリュームを各実行中のタスクにアタッチします。

D. Amazon EC2インスタンスを起動し、EC2インスタンスにDockerをインストールします。コンテナをEC2インスタンスに移行します。Amazon Elastic File System（Amazon EFS）ファイルシステムを作成し、EFSファイルシステムのマウントポイントをEC2インスタンスに追加します。

解説

この問題では、オンプレミスのトランザクション処理アプリケーションをAWSに移行する方法を選択する必要があります。アプリケーションはDockerコンテナで実行され、トランザクションデータを共有ストレージに保存しています。また、トランザクションの処理は時間に敏感であり、スループットを自動的にスケールできるストレージが必要です。加えて、会社はアプリケーションの開発を続けられないため、管理負担を軽減する方法を選ばなければなりません。

各選択肢の詳細な解説は以下の通りです：

A. Amazon EKSとS3を使用

不適切。Amazon EKSはKubernetesを使用してコンテナを管理するサービスです。しかし、トランザクションデータのストレージにAmazon S3を使用する提案は、低遅延のアクセスが必要な状況には適していません。S3はオブジェクトストレージであり、ファイルシステムのように直接的な低レイテンシのアクセスを提供するものではないため、トランザクションデータの格納には不向きです。

B. EFSを使用

適切。AWS Fargate for Amazon ECSを使用してコンテナをホストし、Amazon Elastic File System（EFS）をストレージとして使用する選択肢です。EFSは、複数のコンテナインスタンスで共有可能なスケーラブルなファイルシステムを提供します。EFSは、低レイテンシでスケール可能なストレージソリューションであり、このシナリオに最適です。Fargateは、インフラ管理を不要にし、完全にマネージドなコンテナ環境を提供します。

C. EBSを使用

不適切。Amazon EBS（Elastic Block Store）は、EC2インスタンスに接続するブロックレベルのストレージですが、EBSは1つのEC2インスタンスにアタッチされるため、複数のコンテナインスタンスで共有することができません。アプリケーションが複数のコンテナでスケールする場合、EBSは適切ではありません。さらに、EBSのスケールは自動的に行われませんので、手動での管理が必要となる場合があります。

D. EC2インスタンスとEFSを使用

不適切。EC2インスタンスにDockerをインストールしてコンテナを管理する方法は、EFSとの組み合わせで機能しますが、Fargateの方が管理のオーバーヘッドを減らせるため、より好ましい選択肢です。EC2で直接コンテナを管理する場合、インフラストラクチャの管理が必要であり、これが質問の要件に合致しません。