Amazon DVA-C02: メッセージング、ストリーミングとイベント駆動型アーキテクチャ (SNS, SQS, Kinesis, EventBridge, Step Functions) — 学習ガイド

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Developer Associate DVA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

適切なメッセージングおよびストリーミングプリミティブの選択

SNS、SQS（標準 vs FIFO）、Kinesis、EventBridge、Step Functionsの中から選択する際は、まず通信パターンから始めます。具体的には、pub/sub、ポイントツーポイント、順序付きストリーミング、イベントバスルーティング、ワークフローオーケストレーションのどれに当たるかです。SNSはファンアウト型のpub/subパブリッシャーです。Publish（SDKコール: Publish/PublishBatch）を使用し、SQSエンドポイント、Lambda、HTTP/S、またはモバイルエンドポイントをサブスクライブします。SQSはReceiveMessage/DeleteMessageセマンティクスを持つ、耐久性のあるポイントツーポイントのバッファです。CreateQueueでキューを作成し、VisibilityTimeout、ReceiveMessageWaitTimeSeconds（ロングポーリング）、MessageRetentionPeriodといった属性や、DLQをリンクするリドライブポリシーを設定します。FIFOキューではFifoQueue=trueが必要で、順序付けと重複排除のためにMessageGroupIdとMessageDeduplicationId（またはContentBasedDeduplication）を使用します。Kinesis Data Streamsは順序付けされたシャードベースのストリーミングです。プロデューサーはPutRecord/PutRecordsを呼び出し、コンシューマーはGetShardIterator（TRIM_HORIZON、LATEST、AT_SEQUENCE_NUMBER）を使用してからGetRecordsを呼び出します。Kinesis FirehoseはS3/Redshift/OpenSearchへの配信を管理し、BufferingHints（SizeInMBs、IntervalInSeconds）やLambdaによる変換機能を提供します。EventBridgeはPutEventsとルールベースのフィルタリングでイベントをルーティングし、スキーマレジストリやクロスアカウントバスをサポートします。Step Functionsは複雑なフローをオーケストレーションします。StartExecution（標準）または同期的なExpressパターンのためのStartSyncExecutionを使用し、arn:aws:states:::lambda:invokeのようなTask統合が可能です。スループット、順序性、配信保証、保持期間、オーケストレーションのニーズが競合する場合は、これらのトレードオフを考慮してください。

SNS: 高スループットのファンアウト、順序保証なし、Publish/Subscribe、ルーティングにはMessageAttributesを使用。
SQS Standard: at-least-once（少なくとも1回）、ベストエフォートでの順序保証、ロングポーリング、分離（デカップリング）目的ではより安価。
SQS FIFO: MessageGroupId内でのexactly-once（厳密に1回）の順序保証、厳密な順序付けと重複排除に使用。
Kinesis Data Streams: シャードごとの順序保証、高スループットのストリーミング、PutRecord/PutRecords、シャードのスケーリングが必要。
Kinesis Firehose: マネージド型の配信とバッファリング、サーバーサイド暗号化とLambdaによる変換をサポート。
EventBridge: ルーティングルールを持つイベントバス、スキーマレジストリ、アーカイブ＆リプレイ、PutEvents API。
Step Functions: ステートフルなオーケストレーション、リトライ/Catch、耐久性とスループットに関する標準とExpressのトレードオフ。

SQSとSNSのパターン、重複排除、コンシューマーのスケーリング

耐久性のある分離（デカップリング）が必要な場合、SQSが最適な選択肢です。プロデューサー側でSendMessage/SendMessageBatchを実装し、コンシューマー側ではWaitTimeSecondsを指定したReceiveMessageを使用してロングポーリングを有効にし、空の受信を減らします。厳密な順序保証と重複排除のためには、CreateQueue（FifoQueue=true）でFIFOキューを作成し、順序付けられたパーティションのためにMessageGroupIdを設定します。重複排除期間内に同一ペイロードが抑制されるように、MessageDeduplicationIdを使用するか、ContentBasedDeduplicationを有効にします。標準キューはメッセージを重複して配信する可能性があるため、コンシューマーをべき等にする必要があります。具体的には、データベースへの条件付き書き込み（DynamoDBのPutItemでConditionExpression attribute_not_exists(pk)を使用）や、RDSの一意性制約とトランザクション内でのupsertを利用します。maxReceiveCountを超えた後に失敗したメッセージをDLQにルーティングするために、リドライブポリシーを設定します。GetQueueAttributesを介してApproximateNumberOfMessagesとApproximateNumberOfMessagesNotVisibleを監視します。Lambdaとの統合では、SQSに対してCreateEventSourceMappingを使用します。BatchSize、MaximumBatchingWindowInSecondsを設定し、FunctionResponseTypes = [“ReportBatchItemFailures”]を有効にすることで、部分的なバッチ応答セマンティクスを利用し、成功したレコードの再処理を回避します。FIFO Lambdaのセマンティクスに注意してください。メッセージグループの順序保証により、MessageGroupIdごとにシングルスレッドでの処理が強制され、グループごとの並行性が制限されます。多くのグループIDにパーティショニングするか、SNSから複数のキューへ配信する並列コンシューマーを使用することでスケールします。また、可視性タイムアウトにも注意してください。処理に時間がかかる場合はChangeMessageVisibilityを設定しないと、重複処理のリスクがあります。

Kinesis Data StreamsとFirehose: 順序保証、保持期間、バックプレッシャーへの対応

Kinesis Data Streamsは、ストリーミングのユースケースに対して、シャードごとの順序保証と耐久性のあるデータ保持を提供します。プロデューサーは、シャードにマッピングされるPartitionKeyを指定してPutRecordまたはPutRecords（バッチ）を呼び出します。コンシューマーはGetShardIteratorとGetRecordsを呼び出し、KCL（Kinesis Client Library）またはカスタムのDynamoDBチェックポイントテーブルを使用してオフセットをチェックポイントします。デフォルトの保持期間は24時間です（ストリーム設定ごとに、より長い期間に調整可能で、利用可能な場合は拡張保持機能もあります）。書き込みスループットとリーダーの並列性に合わせて、UpdateShardCountでシャード数を計画します。コンシューマーのスケーリングには制約があります。単一のLambdaイベントソースマッピングは1つのシャードを1つのLambda同時実行数にマッピングするため、コンシューマーの同時実行数を増やすにはシャードを増やすか、拡張ファンアウトを有効にして各コンシューマーに独自の2 MB/secのパイプを与え、SubscribeToShard API（コンシューマー登録）を使用して独立してスケーリングします。効率的なバッチ処理にはPutRecordsを使用します。バックプレッシャーは、コンシューマーが遅延した場合に発生します（GetRecords.IteratorAgeMillisecondsを監視）。急増に対応するには、Kinesis上でバッファリングするか、前段にSQSを配置し、指数関数的バックオフ付きのプロデューサーリトライを使用し、PII（個人を特定できる情報）にはKMSによるストリームレベルの暗号化を使用します。Kinesis Data Firehoseは配信を簡素化します。BufferingHints（SizeInMBs、IntervalInSeconds）、CompressionFormat、およびLambdaによるデータ変換を設定します。Firehoseは送信先へのリトライ/バックオフを処理し、失敗したレコードをバックアップ用のS3バケットに書き込むことができます。よくある落とし穴は、シャードのプロビジョニング不足です。これにより、コンシューマーが枯渇し、レイテンシーが急上昇します。積極的に測定し、スケーリングしてください。

ルーティングとオーケストレーションのためのEventBridgeとStep Functions

EventBridgeは、スキーマ駆動のイベントルーティングやアカウント間/イベントパートナー連携に優れています。PutEventsを使用してイベントを投入し、PutRule/PutTargetsを使用してSQS、Lambda、Kinesis、Step Functions、またはHTTPエンドポイントにルーティングします。EventBridgeはフィルタリングにイベントパターンを使用し、状態を再構築するためのアーカイブとリプレイをサポートしています。ルールにはデッドレターキュー（SqsParametersまたはDeadLetterConfigを持つTarget）を使用し、EventBridgeが指数関数的バックオフによるリトライを提供し、失敗時にはDLQに送られることを認識しておいてください。オーケストレーションにはStep Functionsを選択します。実行履歴と組み込みのリトライ/Catchを備えた、長時間実行される耐久性のあるワークフローには標準ステートマシンを、低コストでベストエフォートな実行が可能な、高スループットで短時間のワークフローにはExpressを選択します。サービス統合（arn:aws:states:::lambda:invoke や arn:aws:states:::aws-sdk:apigateway:invoke）によるタスク統合や、「waitForTaskToken」を使用したコールバックパターンを利用して、非同期の外部承認を実装します。指数関数的バックオフを用いたリトライとCatchを実装し、長時間のタスクにはHeartbeatSecondsを使用します。Mapステートを使用して大規模なコレクションを並列化しますが、同時実行数とダウンストリームのスロットリングに注意してください。よくある落とし穴は、厳密に1回の実行と耐久性のある履歴が必要なワークフローにExpressを誤って選択することです。可監査性のためには標準ステートマシンを選んでください。また、べき等トークンを渡し、ターゲットサービスが書き込み時に一意性を強制するようにすることで、Step Functionsによって呼び出されるタスクのべき等性を確保してください。

実践的な問題：ユースケースシナリオ

シナリオ：StreamlyGamesは、マルチアカウントのAWS環境でグローバルなゲームバックエンドを運用しています。プレイヤーは10MBのゲームプレイクリップをS3にアップロードします。処理パイプラインは、動画をトランスコードし、ML分析を実行し、順序付けされた重複排除処理とスケーラブルなコンシューマーを用いて、結果をAurora Serverlessに書き込む必要があります。

課題：アップロードされた各ファイルが、プレイヤーごとに順序を保ちながら厳密に1回だけ処理をトリガーするようにし、イベントを失うことなくスパイクに対応し、ML推論のためのコンシューマーをスケールさせつつ、DBへの重複書き込みを防ぐこと。

推奨アプローチ：

S3イベント通知を作成し、オブジェクト作成イベントをEventBridgeカスタムバス（PutEvents）と、SQS FIFOキュー（CreateQueueでFifoQueue=trueを指定）の両方に発行します。SQS FIFOキューでは、PlayerIDをMessageGroupIdとしてキー指定し、S3のETagに基づくMessageDeduplicationIdを使用します。
BatchSize=1、FunctionResponseTypes=[“ReportBatchItemFailures”]を使用してSQSイベントソースマッピング（CreateEventSourceMapping）を持つLambdaコンシューマーを設定し、VisibilityTimeoutを最大処理時間より長く設定します。サードパーティのML APIを呼び出す際にはChangeMessageVisibilityを使用します。
Lambdaは、決定論的なべき等キー（INSERT … ON CONFLICT DO NOTHINGまたは一意性制約）を使用してAuroraにべき等なDB書き込みを行い、進捗をチェックポイントします。長時間のML呼び出しには、タスクトークン（arn:aws:states:::lambda:invoke.waitForTaskToken）を使用した非同期のStep Functions、または高スループットのためのStep Functions Expressを使用します。
推論をスケールさせるために、高スループットのコンシューマー向けに中間イベントをリージョンごとのシャード単位でKinesis Data Streamsに書き込み、専用のMLワーカフリートのために拡張ファンアウトコンシューマー（SubscribeToShard）を有効にします。スケールさせるためにIteratorAgeMillisecondsを監視し、UpdateShardCountを使用します。

論理的根拠：SQS FIFOを使用してプレイヤーごとの順序保証と取り込み時の重複排除を行い、べき等なDB書き込みによって厳密に1回のセマンティクスを強制します。そして、Kinesisと拡張ファンアウト、またはStep Functionsを使用して、バースト性のある高スループットなML処理に対応しつつ、コンシューマーを疎結合でスケーラブルに保ちます。

← データベースとキャッシュ (RDS · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →