大量のストリーミングデータをリアルタイムに処理する場合、SQS/SNSとは異なる特性を持つ Kinesisファミリーが適しています。本記事ではその使い分けを整理します。

SAA レベル：基礎概念

Kinesisファミリーの役割分担

サービス	役割
Kinesis Data Streams	リアルタイムのストリームデータ収集・カスタム処理
Kinesis Data Firehose	ストリームデータをS3/Redshift/OpenSearch等へ自動配信（ETL含む）
Kinesis Data Analytics	SQLまたはApache Flinkでストリームデータをリアルタイム分析

SAA 試験のポイント

Kinesis Data Streamsは消費者が自分でコードを書いて処理する必要がありますが、Firehoseは宛先を指定するだけで自動的に配信してくれるマネージド度の高いサービスです。「カスタムのリアルタイム処理ロジックが必要か」「単純に宛先へ流し込みたいだけか」が選定の分かれ目になります。

シャードの基本

Kinesis Data Streamsのスループット単位はシャード
1シャードあたり: 書き込み1MB/秒または1000レコード/秒、読み取り2MB/秒

SAP レベル：高度な設計シナリオ

シャード設計とスループット計算

SAP 試験のポイント

必要なシャード数は、想定される書き込みスループット（MB/秒）と読み取りスループット（コンシューマー数×MB/秒）の両方から逆算する必要があります。SAPでは「1秒あたり5MBの書き込みと、3つの独立したコンシューマーアプリケーションがそれぞれ全量を読み取る」といった具体的な要件から、必要シャード数を計算させる問題が出題されることがあります。

Enhanced Fan-Outによる読み取り性能の改善

SAP 試験のポイント

複数のコンシューマーアプリケーションが同じシャードを読み取る場合、標準的な仕組み（ポーリングベース）では2MB/秒の読み取り容量を全コンシューマーで共有することになり、コンシューマー数が増えるほど1つあたりのスループットが低下します。Enhanced Fan-Outを有効にすると、各コンシューマーが専用の2MB/秒の読み取りスループットを（HTTP/2のプッシュ型で）確保でき、コンシューマー数が増えてもボトルネックになりません。

リアルタイム処理とバッチ配信の違い

観点	Kinesis Data Streams（カスタム処理）	Kinesis Data Firehose
レイテンシ	ミリ秒〜秒単位でリアルタイム処理可能	バッファリングによる遅延あり（数十秒〜数分）
処理の柔軟性	完全にカスタムのコンシューマーロジック	変換Lambdaの組み込みは可能だが基本は配信特化

設計上の落とし穴

「とにかくリアルタイム性が必要だからKinesis Data Streamsを使う」という判断だけでなく、SAPではS3やRedshiftへの単純な配信・保存が目的であれば、より運用負荷の低いFirehoseで十分というコスト・運用効率の観点からの判断も問われます。過剰にカスタムなStreams実装を選ぶことが、常に正解とは限りません。

SQS/SNSとの使い分け

順序性のある大量のイベントストリームを、複数の異なるコンシューマーが独立して繰り返し読み取りたい（リプレイ性が必要） → Kinesis Data Streams
単発のタスクを1回だけ確実に処理させたい → SQS
複数の疎結合なシステムに同時通知したいだけ（大量ストリームではない） → SNS/EventBridge

まとめ

SAA: Kinesis Data Streams・Firehose・Data Analyticsの役割分担、シャードの基本スループット単位を理解する。
SAP: シャード数の計算、Enhanced Fan-Outによる複数コンシューマー時のスループット確保、Firehoseとの使い分け判断ができる。

次は **API Gateway設計（REST/HTTP/WebSocket）**を見ていきましょう。