目次
1. 結論
Amazon Kinesis Data Streamsは、「超高速で流れるデータの川」です。SQSが「メッセージを一つずつ確実に処理する」のが得意なのに対し、Kinesisは「大量のデータを高速に流し、複数の読者がそれぞれ好きなタイミングで解析する」のが得意です。データの入り口と出口を切り離すことで、スパイク的な負荷にも耐えうる弾力性を提供します。
2. SAAで出やすいポイント
- スケーラビリティ (シャード): 「シャード(Shard)」という単位を増やすことで、処理能力を水平に拡張できる。1つのシャードで書き込み1MB/s、読み取り2MB/s。
- 順序保証: パーティションキー(Partition Key)を同じにすることで、特定のユーザーやデバイスからのデータを常に同じ順序で処理できる。
- データ保存期間: デフォルトで24時間(最大365日まで延長可能)。一度読み取ってもデータは消えないため、複数のアプリで同じデータを再利用できる。
- リアルタイム処理: データの発生から解析まで、サブ秒(1秒未満)の遅延で処理が可能。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「大規模なストリーミングデータをリアルタイムで収集」 | Kinesis Data Streams | 高スループットが必要なため |
| 「同じデータを複数のアプリケーションで解析したい」 | Kinesis Data Streams | データの再利用が可能なため |
| 「ミリ秒単位の低遅延でデータを処理」 | Kinesis Data Streams | リアルタイム性の要求 |
4. ひっかけポイント
- SQSとの違い:
- SQS: 1つのメッセージは1人のコンシューマーしか処理できない(消える)。
- Kinesis: 1つのデータ(レコード)を複数のコンシューマーが独立して読み取れる。
- Kinesis Firehoseとの違い:
- Data Streams: リアルタイム。自分でプログラムを書く。シャード管理が必要。
- Firehose: ほぼリアルタイム(数分待機)。S3やRedshiftに「流し込む」だけ。管理不要。
- オンデマンドモード: 管理を楽にしたい場合、シャードを手動で増やさず自動調整する「オンデマンドモード」も選択可能。
5. 覚え方
- 「巨大なコンベアベルト」。
- 工場(プロデューサー)が次々と荷物(データ)をベルトに載せ、検品担当(コンシューマー)が流れてくる荷物を次々とチェックしていくイメージ。ベルトの幅(シャード)を広げれば、いくらでも荷物を増やせる。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| Lambda | Kinesisに流れてきたデータを即座に処理する主要なパートナー。 |
| Kinesis Firehose | Streamsの結果をS3などに長期保存するために繋げて利用する。 |
| Kinesis Analytics | ストリームデータに対してSQLを使ってリアルタイムに分析を行う。 |
7. Obsidian管理メモ
- 復習ポイント: 「順序保証」と「複数アプリでの利用」という言葉が出たらSQSではなくKinesisを疑う。
- 関連ノート: ストリーミングデータ処理の最適化
8. HTMLファイル名
amazon-kinesis-data-streams-realtime.html