あるメディア企業がニュースサイトのクリックストリームデータをリアルタイムで処理するパイプラインを構築しています。
ピーク時に毎分500,000イベントを受信し、各イベントはAmazon DynamoDBのユーザープロファ

Question

あるメディア企業がニュースサイトのクリックストリームデータをリアルタイムで処理するパイプラインを構築しています。
ピーク時に毎分500,000イベントを受信し、各イベントはAmazon DynamoDBのユーザープロファイルで補完（エンリッチメント）されます。
エンリッチ済みイベントを5分間の集計ウィンドウでリアルタイム集計し、結果をAmazon RedshiftとAmazon S3の両方へエンドツーエンド1分以内に届ける必要があります。
この要件を満たすアーキテクチャとして最も適切なものはどれですか？

Accepted Answer

正解: Amazon Kinesis Data Streams → Amazon Managed Service for Apache Flink → AWS Lambda → Amazon Redshift と S3。Amazon Managed Service for Apache Flink（MSAF）はリアルタイムストリーム処理エンジンで、5分間のタンブリングウィンドウ集計をSQLまたはJava/Python APIでネイティブに記述できます。DynamoDBとの統合コネクターによりイベントごとのエンリッチメントを実装でき、ステートフルなウィンドウ状態管理はFlinkのCheckpointが自動処理します。処理結果をLambda経由でRedshiftへの書き込みとS3への出力に送信することでエンドツーエンド1分以内の配信が可能です。

選択肢AのAWS LambdaはステートレスなFaaSで、5分間のウィンドウ集計にはDynamoDBでの外部状態管理が必要となり設計が複雑化します。実行時間の制限とコールドスタートにより正確なウィンドウ境界の管理も困難です。
選択肢BのAmazon EKS上のKafka StreamsはウィンドウSQLに対応できますが、MSK・EKSクラスターの管理とKafka Streams実装が必要で運用負荷が高く、AWS Glue ETLを経由することでエンドツーエンド1分以内の達成も難しくなります。
選択肢DのAmazon SQSはリアルタイムストリーム処理向けではなく、時間ウィンドウ集計をLambda + DynamoDBで実装するのは複雑です。EventBridge Pipesを経由する設計ではRedshiftへのリアルタイム書き込みにも追加遅延が生じます。

Answer

Amazon Kinesis Data Streams → AWS Lambda（エンリッチメントと5分ウィンドウ集計をDynamoDBで状態管理）→ Amazon Data Firehose → Amazon Redshift と S3 — LambdaはステートレスなFaaSで、5分間のタイムウィンドウ集計にはDynamoDBでの外部状態管理が必要です。ウィンドウ境界の正確な制御が複雑になるほか、Lambda実行時間の上限がリアルタイム集計の安定性に影響します。

Answer

Amazon MSK → Amazon EKS上のKafka Streams（5分タンブリングウィンドウ集計）→ AWS Glue ETL → Amazon Redshift と S3 — EKS上のKafka StreamsはウィンドウSQLを記述できますが、EKSクラスターとKafka Streamsの管理が必要です。AWS Glue ETLを経由するバッチ的な処理が加わるため、エンドツーエンド1分以内の要件を満たすことが難しくなります。

Answer

Amazon SQS標準キュー → AWS Lambda（DynamoDBでウィンドウ状態を管理しながらバッチ集計）→ Amazon EventBridge Pipes → Amazon Redshift と S3 — SQSはリアルタイムストリーム処理向けではなく、時間ウィンドウ集計をLambda + DynamoDBで実装する設計は複雑です。ピーク時毎分500,000イベントに対してSQSポーリングモデルでは正確なウィンドウ境界の管理が困難です。

解説

解説