はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon Kinesis 関連の知識をまとめました。
Kinesis ファミリーの使い分け、Data Streams と Firehose の違い、Enhanced Fanout、スループット例外の対策など、試験で問われるポイントを網羅しています。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
Kinesis ファミリー
| サービス | 役割 | リアルタイム性 |
|---|---|---|
| Kinesis Data Streams | ストリーミング取り込み・バッファ、カスタム処理 | ミリ秒 |
| Kinesis Data Firehose | データ配信（S3 / Redshift / OpenSearch 等） | 60秒バッファ |
| Kinesis Data Analytics | ストリーミングデータのリアルタイム SQL 分析 | ✅ |
| Kinesis Video Streams | 動画ストリーム | - |
Data Streams vs Data Firehose
| Data Streams | Data Firehose | |
|---|---|---|
| 複数コンシューマー | ✅ | ❌ 単一の配信先のみ |
| リアルタイム性 | ミリ秒〜秒 | 60秒バッファ |
| 配信先 | カスタム | S3 / Redshift / OpenSearch / Splunk |
| 管理 | シャード管理必要 | フルマネージド |
判断のポイントはシンプルです。
- 複数コンシューマー / カスタム処理 → Data Streams
- 特定の配信先に自動配信 → Firehose
- リアルタイム SQL 分析 → Data Analytics
Enhanced Fanout
| デフォルト | Enhanced Fanout | |
|---|---|---|
| スループット | 2MB/秒/シャード（全コンシューマーで共有） | 2MB/秒/シャード/コンシューマーごと |
| 配信方式 | ポーリング（Pull） | プッシュ（HTTP/2） |
| レイテンシー | 約200ms | 約70ms |
複数コンシューマーでパフォーマンスラグが発生したら Enhanced Fanout を検討します。
ProvisionedThroughputExceededException の対策
| 対策 | コスト | 効果 |
|---|---|---|
| バッチメッセージ（PutRecords） | なし | 高い（最優先） |
| Exponential Backoff | なし | 一時的 |
| シャード追加 | 高い | 高い |
| 保持期間短縮 | なし | 効果なし |
コスト最小で対処するならバッチメッセージ（PutRecords API） が最優先です。
試験で問われる設計パターン
基本構成系
リアルタイムストリーミング + 順序保証 + 運用最小 → Kinesis + Lambda + DynamoDB
シナリオ: IoT デバイスからのリアルタイムストリーミングデータを順序保証付きで処理し、DynamoDB に保存したいです。運用負荷を最小にする構成は？
正解: Kinesis Data Streams → Lambda → DynamoDB
- Kinesis は順序保証 + 大規模対応
- Lambda とのネイティブ統合
- EC2 を含む選択肢は「管理最小」で除外
リアルタイム分析パイプライン → Data Streams → Data Analytics → Firehose → S3
シナリオ: ストリーミングデータをリアルタイムで SQL 分析し、結果を S3 に保存したいです。
正解: Kinesis Data Streams → Kinesis Data Analytics → Kinesis Data Firehose → S3
- Data Analytics がリアルタイム SQL 分析を担当
- Athena はバッチクエリ
- QuickSight は可視化（Kinesis Data Streams ソース非対応）
リアルタイムストリーミング + カスタム処理 → Data Streams
シナリオ: ストリーミングデータに対して独自のカスタム処理を行いたいです。
正解: Amazon Kinesis Data Streams
- Firehose は配信先が固定（カスタム処理不可）
- SQS はキュー（ストリーミングではない）
パフォーマンス系
複数コンシューマー + パフォーマンスラグ → Enhanced Fanout
シナリオ: Kinesis Data Streams に複数のコンシューマーが接続していますが、コンシューマーが増えるにつれてパフォーマンスが低下しています。どう対処すべきでしょうか？
正解: Enhanced Fanout を有効化
- デフォルトは 2MB/秒/シャードを全コンシューマーで共有
- Enhanced Fanout で各コンシューマーに専用 2MB/秒
- レイテンシーも 200ms → 70ms に改善
ProvisionedThroughputExceededException + コスト最小 → バッチメッセージ
シナリオ: Kinesis Data Streams で ProvisionedThroughputExceededException が発生しています。コストを最小限に抑えて解決するにはどうすべきでしょうか？
正解: バッチメッセージ（PutRecords API）
- バッチ化はコスト増なし
- シャード追加はコストが増える
- 保持期間の短縮はスループットに無関係
30分処理系
30分処理 + サーバーレス + リアルタイムストリーミング → Kinesis + ECS Fargate
シナリオ: ストリーミングデータを取り込み、1件あたり最大30分の処理を行いたいです。サーバーレスで実現する構成は？
正解:
- Kinesis Data Streams（取り込み）
- ECS on Fargate（30分処理）
- Lambda は15分制限で不可
- DMS は DB 移行用
分析・検索系
リアルタイム検索 + 分析プラットフォーム → Kinesis + OpenSearch + QuickSight
シナリオ: ストリーミングデータをリアルタイムで検索・分析し、ダッシュボードで可視化したいです。
正解: Kinesis Data Streams → OpenSearch Service → QuickSight
- OpenSearch = リアルタイム検索 + 分析
- Athena はバッチクエリ
- Redshift は全文検索には最適でない
データ取り込み系
S3 → Kinesis Data Streams ストリーミング（最速構築）→ DMS
シナリオ: S3 のデータを Kinesis Data Streams にストリーミングしたいです。最速で構築する方法は？
正解: AWS DMS
- DMS は S3 ソース、Kinesis ターゲットをネイティブサポート
- EventBridge + Lambda や S3 Event + Lambda はカスタム開発が必要
複数コンシューマー系
ニアリアルタイム + 複数コンシューマー + データクレンジング → Data Streams + Lambda
シナリオ: ストリーミングデータを Lambda でクレンジングして DynamoDB に保存しつつ、別の内部アプリケーションも同じストリームを消費したいです。
正解: Kinesis Data Streams → Lambda（クレンジング）→ DynamoDB + 内部アプリも Data Streams から消費
- 複数コンシューマー → Data Streams（Firehose は単一配信先）
- Firehose は ETL + 単一配信先向け
リトライ・耐障害性系
リアルタイムヘルスデータ + リトライ + 分析 → Kinesis Data Streams
シナリオ: リアルタイムのヘルスデータを取り込み、処理が失敗した場合はリトライしたいです。
正解: Kinesis Data Streams + Lambda / Kinesis Data Analytics
- データ保持期間内であればリプレイ可能
- SNS はプッシュ型（リトライの仕組みがない）
おわりに
Kinesis は「リアルタイムストリーミング」の代表的なサービスです。「複数コンシューマー / カスタム処理 → Data Streams」「特定配信先 → Firehose」「リアルタイム SQL → Data Analytics」「コンシューマー増でラグ → Enhanced Fanout」「スループット超過 → バッチメッセージ」という判断パターンを押さえておけば、試験で迷うことはなくなります。
間違いや補足があればぜひコメントで教えてください。