511-AWS SAP AWS 「理論・実践・一問道場」S3イベント通知

type

status

date

slug

summary

理論

サーバーレスアーキテクチャとイベント駆動型デザインのベストプラクティス

1. ファイルストレージの選択

Amazon S3:

ネイティブなイベント通知機能（オブジェクト作成時のトリガー）を持つ。
S3イベント通知をAWS LambdaやAmazon SQSに連携可能。
高い耐久性と可用性を持ち、データ処理アーキテクチャに適している。

Amazon EFS:

ファイルシステムとして柔軟性は高いが、イベント通知機能がない。
高頻度のポーリングが必要になるため、S3より管理コストが高くなる場合がある。

2. AWS Lambdaの活用

特性:

サーバーレスで管理不要。最大15分の実行時間制限。
短時間のロジックやトリガー処理（例: コンテナ選択ロジック）に最適。

活用シナリオ:

S3イベント通知でトリガーされ、処理タスク（AWS Fargateなど）を動的に起動。

3. AWS Fargateの役割

用途:

長時間のコンテナベースのデータ処理（最大4時間）。
インフラ管理不要でスケーラブルなコンテナ運用が可能。

ユースケース:

AWS Lambdaで処理しきれない長時間のデータ処理を担当。

4. イベント駆動型アーキテクチャ

イベント通知:

S3イベント通知でLambdaをトリガー。
LambdaがFargateタスクを起動し、必要なコンテナイメージで処理を開始。

利点:

リアルタイム性の高い処理。
ポーリングを排除し、運用コストを削減。

まとめ

S3 + Lambda + Fargateは、柔軟性と効率性を兼ね備えたモダンなデータ処理アーキテクチャ。

これにより、サーバーレスかつスケーラブルな長時間処理を実現可能。

実践

略

一問道場

質問 #511

ある企業がデータ処理アプリケーションをAmazon EC2インスタンス上でホストしています。このアプリケーションは、新しくアップロードされたファイルを検出するためにAmazon Elastic File System (Amazon EFS) ファイルシステムをポーリングします。新しいファイルを検出すると、アプリケーションはファイルからデータを抽出し、ファイルを処理するための適切なDockerコンテナイメージを選択するロジックを実行します。その後、アプリケーションは適切なコンテナイメージを開始し、ファイルの場所をパラメータとして渡します。

コンテナ内で実行されるデータ処理は最大で2時間かかることがあります。処理が完了すると、コンテナ内で実行されるコードは、処理後のファイルをAmazon EFSに書き戻して終了します。

企業は、コンテナを実行しているEC2インスタンスを排除するためにアプリケーションをリファクタリングする必要があります。

この要件を満たすソリューションはどれですか？

選択肢

A. Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。処理をAWS Fargateタスクとして実行するように設定します。コンテナ選択ロジックをAmazon EventBridgeルールとして抽出し、新しいファイルがEFSファイルシステムに追加されたときに適切なFargateタスクを開始するようにEventBridgeルールを構成します。

B. Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。処理をAWS Fargateタスクとして実行するように設定します。コンテナ選択ロジックを更新してFargateサービスとしてコンテナ化し、適切なFargateタスクを開始するように設定します。新しいファイルがEFSファイルシステムに追加されたときにFargateサービスを呼び出すようにEFSイベント通知を構成します。

C. Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。処理をAWS Fargateタスクとして実行するように設定します。コンテナ選択ロジックをAWS Lambda関数として抽出し、適切なFargateタスクを開始するようにします。ファイルアップロードのストレージをAmazon S3バケットに移行し、処理コードをAmazon S3を使用するように更新します。オブジェクトが作成されたときにLambda関数を呼び出すようにS3イベント通知を構成します。

D. 処理用のAWS Lambdaコンテナイメージを作成します。Lambda関数がこれらのコンテナイメージを使用するように設定します。コンテナ選択ロジックを抽出し、適切なLambda処理関数を呼び出す意思決定Lambda関数として実行します。ファイルアップロードのストレージをAmazon S3バケットに移行し、処理コードをAmazon S3を使用するように更新します。オブジェクトが作成されたときに意思決定Lambda関数を呼び出すようにS3イベント通知を構成します。

解説

この問題の要点は以下の通りです：

EC2インスタンスの排除

現在、データ処理はEC2インスタンス上で実行されていますが、これを排除する必要があります。代わりにサーバーレスまたはマネージドサービスを使用します。

ファイル検出とイベント駆動型アーキテクチャ

ファイル検出のために現在使用されているポーリングを、イベント通知（Amazon S3やEFSイベント）に置き換える必要があります。

コンテナの選択ロジックとデータ処理の実行

コンテナの選択ロジックを適切に実行し、ファイル処理用のDockerコンテナをトリガーする必要があります。

以下に各選択肢の分析を示します。

選択肢の分析

A. Amazon ECS + AWS Fargate + EventBridge + EFS

内容:

Amazon ECSクラスターとAWS Fargateタスクを使用し、イベント駆動型で処理を実行。
コンテナ選択ロジックをAmazon EventBridgeルールとして実装。
EventBridgeが、EFSに新しいファイルが追加された際に適切なFargateタスクを開始。

問題点:

EFSにはネイティブなイベント通知機能がなく、EventBridgeを直接トリガーする方法はありません。そのため、新しいファイルの検出には別途ポーリングが必要になります。

評価: 不正解。

B. Amazon ECS + AWS Fargate + EFSイベント通知

内容:

Amazon ECSクラスターとAWS Fargateタスクを使用。
コンテナ選択ロジックをFargateサービスとしてコンテナ化。
新しいファイルがEFSに追加されたときにEFSイベント通知でFargateサービスをトリガー。

問題点:

EFSにはネイティブなイベント通知機能がありません。EFSイベント通知を直接Fargateサービスに連携させることはできません。

評価: 不正解。

C. Amazon ECS + AWS Fargate + S3 + Lambda

内容:

EFSではなく、ファイルストレージをAmazon S3に移行。
S3イベント通知を使用して、ファイルのアップロードをトリガー。
コンテナ選択ロジックをAWS Lambdaで実装し、Fargateタスクを起動。

利点:

S3にはネイティブなイベント通知機能があり、Lambdaをシームレスにトリガー可能。
LambdaがFargateタスクを動的に起動できるため、柔軟性が高い。
サーバーレスアーキテクチャで管理負荷を削減可能。

評価: 正解。

D. AWS Lambdaコンテナイメージ + S3 + Lambda

内容:

Lambda関数を使用してデータ処理を実行。
処理用のDockerコンテナイメージをLambdaに対応させて実行。
コンテナ選択ロジックを別のLambda関数として実装し、S3イベント通知でトリガー。

問題点:

AWS Lambdaには15分の実行時間制限があり、問題文の「処理に最大2時間かかる」という要件を満たせません。

評価: 不正解。

正解: C

解決策の流れ

ファイルストレージの移行:

EFSではなくAmazon S3を使用し、ファイルアップロードのイベント通知を簡素化。

イベント駆動型アーキテクチャ:

S3イベント通知を設定し、新しいファイルがアップロードされた際にAWS Lambdaをトリガー。

AWS Lambdaでのコンテナ選択:

Lambda関数でコンテナ選択ロジックを実行し、適切なAWS Fargateタスクを起動。

AWS Fargateでデータ処理:

Fargateタスクで最大2時間のデータ処理を実行し、結果をS3に書き戻し。

理論