Amazon Kinesis

解決する課題

• 大量データをリアルタイムに取り込みたい
• 複数の処理系で同じストリームを並行処理したい
• ストリームをS3/Redshift等へ自動ロードしたい

主要概念と用語

• Data Streams: シャードで構成するリアルタイムストリーム
• Data Firehose: S3/Redshift/OpenSearch等へニアリアルタイム配信（マネージド）
• Managed Service for Apache Flink: ストリームのリアルタイム分析
• シャード / パーティションキー / 保持期間

仕様・制限・クォータ

• Data Streamsはシャード単位でスループットが決まる（オンデマンド容量も可）
• 保持期間内はデータを再読み込み可能
• Firehoseはバッファサイズ/間隔で配信

内部の仕組み

Data Streamsはパーティションキーでレコードをシャードに分散し、順序を保って保持します。保持期間内なら複数のコンシューマが各自の位置から読み直せるのが特徴（SQSは取り出すと消える）。Firehoseはシャード管理不要のマネージド配信で、バッファ・変換しつつS3等へ自動ロードします。

設計パターン / ベストプラクティス

• 取り込み＝Data Streams、配信＝Firehose、分析＝Flink
• パーティションキー設計でホットシャード回避
• スループット変動が読めなければオンデマンド容量
• 簡単にS3へ貯めるだけならFirehoseが最小運用

運用・監視・トラブルシュート

• メトリクス: IncomingRecords IteratorAgeMilliseconds（遅延）WriteProvisionedThroughputExceeded
• スロットルはシャード不足/ホットキーを疑う
• コンシューマ遅延はIteratorAgeで検知

コスト

• Data Streams: シャード時間＋PUTペイロード（オンデマンドは取り込み量）
• Firehose: 取り込み量課金。運用は最小

セキュリティ

• 保存時暗号化（KMS）、転送時TLS
• IAMでプロデューサ/コンシューマを制御

Well-Architected の観点

• パフォーマンス効率: リアルタイム取り込み・並行処理
• 信頼性: 保持期間内の再処理・順序保証
• コスト最適化: オンデマンド/Firehoseで運用軽量化

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# オンデマンド容量でストリーム作成 → レコード投入
aws kinesis create-stream --stream-name events \
  --stream-mode-details StreamMode=ON_DEMAND

aws kinesis put-record --stream-name events \
  --partition-key user-123 --data "$(echo -n '{"click":1}' | base64)"