どーも！shihopowerです！
今回は、Amazon Kinesis Data Streams（KDS） と Amazon Data Firehose の違いについてお話しします。
以前、両者の違いをざっくり把握していたのですが、「実際のところどう使い分けるの？」という疑問が残っていたので、AWS公式ドキュメントをもとにがっつり深掘りしてみました！
📝 名称に関する注意
2024年2月に「Amazon Kinesis Data Firehose」は「Amazon Data Firehose」に改名されています。
APIやエンドポイント、AWS CLIに変更はないため、既存のアプリケーションはそのまま動作します。
目次
- そもそも Amazon Kinesis とは？
- Amazon Kinesis Data Streams（KDS）とは
- Amazon Data Firehose とは
- KDS と Data Firehose の違い（比較表）
- どちらを選ぶべきか？
- まとめ
1. そもそも Amazon Kinesis とは？
Amazon Kinesis は、ストリーミングデータをリアルタイムで収集・処理・分析するための AWS サービス群の総称です。
機械学習、分析、その他の用途に使用する動画、音声、アプリケーションログ、ウェブサイトのクリックストリーム、IoT テレメトリデータなどのデータをリアルタイムで取り込むことができます。データを受信してすぐに処理および分析でき、すべてのデータの収集が終わるまで待たずに処理を開始して直ちに応答できます。
Kinesis ファミリーは主に以下のサービスで構成されています。
| サービス名 | 役割 |
|---|---|
| Kinesis Data Streams（KDS） | リアルタイムのストリームデータ取り込み・処理 |
| Amazon Data Firehose | ストリームデータを宛先へキャプチャ・変換・ロード |
| Kinesis Data Analytics | SQL や Apache Flink でストリームをリアルタイム処理 |
| Kinesis Video Streams | 動画ストリームの取り込み・保存・分析 |
本記事では、このうち KDS と Amazon Data Firehose の2つに絞って解説します。
2. Amazon Kinesis Data Streams（KDS）とは
基本的な役割
Amazon Kinesis Data Streams は、データレコードの大量のストリームをリアルタイムで収集し、処理するためのサービスです。Kinesis Data Streams アプリケーションと呼ばれるデータ処理アプリケーションを作成でき、処理されたレコードはダッシュボードへの送信、アラートの生成、料金設定・広告戦略の動的変更、その他さまざまな AWS サービスへの送信に活用できます。
アーキテクチャの概要
KDS のアーキテクチャは、大きく プロデューサー → データストリーム（シャード） → コンシューマー の3層で構成されます。
- プロデューサー：Amazon Kinesis Data Streams にレコードを配置するもの。たとえば、ストリームにログデータを送信するウェブサーバーがプロデューサーです。
- データストリーム：シャードのセット。各シャードにはデータレコードのシーケンスがあり、各データレコードには Kinesis Data Streams によってシーケンス番号が割り当てられます。
- コンシューマー：Amazon Kinesis Data Streams からレコードを取得して処理するもの。これらは Amazon Kinesis Data Streams アプリケーション とも呼ばれます。
コンシューマーは Amazon EC2 で実行されているカスタムアプリケーションや Amazon Data Firehose 配信ストリームなどで、Amazon DynamoDB、Amazon Redshift、Amazon S3 などの AWS サービスを使用して結果を保存することができます。
また、複数のアプリケーションが1つのストリームを使用して、各アプリケーションが同時にかつ独立してストリームからデータを消費できます。これにより、同じデータを並列で処理する複雑なパイプラインを構築できます。
シャードとは
KDS を理解するうえで欠かせないのが シャード の概念です。
シャードは、ストリーム内の一意に識別されたデータレコードのシーケンスです。ストリームは複数のシャードで構成され、各シャードが容量の1単位になります。
各シャードのスループット上限は次のとおりです。
| 操作 | 上限 |
|---|---|
| 書き込み速度 | 1 MB/秒 |
| 書き込みレコード数 | 1,000 レコード/秒 |
| 読み取り速度 | 2 MB/秒 |
| 読み取りトランザクション数 | 5 トランザクション/秒 |
ストリームの総容量はシャードの容量の合計であるため、処理量が増えたらシャード数を増やし、減ったら減らすことでスケーリングが可能です。この操作を リシャーディング と呼びます。
データはどうシャードに振り分けられるか？
プロデューサーがデータレコードをストリームに送信する際、パーティションキーを指定します。Kinesis Data Streams は MD5 ハッシュ関数を使ってパーティションキーを 128 ビットの整数値にマッピングし、そのハッシュ値に基づいてどのシャードにデータを割り当てるかを決定します。
パーティションキーが同じデータレコードは同じシャードに割り当てられるため、順序を保ったまま処理したいデータには同じパーティションキーを使うという設計が重要になります。
容量モードとシャードの関係
KDS には2つの容量モードがあります。
- プロビジョンドモード：シャード数を自分で指定。総容量はシャードの容量の合計であり、シャードカウントに対して時間料金が発生します。
- オンデマンドモード：シャードを Kinesis Data Streams が自動的に管理。使用した実際のスループットに対してのみ課金されます。
主なユースケース（KDS）
KDS の代表的なユースケースは以下のとおりです。
ログとデータフィードの取り込みと処理の高速化
プロデューサーからストリームにデータを直接プッシュさせることができます。たとえば、システムとアプリケーションのログをプッシュすると、数秒で処理可能になります。これにより、フロントエンドサーバーやアプリケーションサーバーに障害が発生した場合でも、ログデータが失われることを防止できます。
リアルタイムのメトリクスとレポート作成
バッチデータを受け取るまで待つのではなく、データのストリーミング中にシステムおよびアプリケーションログに関するメトリクスやレポート作成を操作できます。
リアルタイムデータ分析
ウェブサイトのクリックストリームをリアルタイムで処理し、並行して実行される複数の異なる KDS アプリケーションを使用して、サイトの使いやすさなどを分析できます。
複雑なストリーム処理
KDS アプリケーションとデータストリームの DAG（有向非巡回グラフ）を作成できます。複数のアプリケーションから別のストリームにデータを出力し、さらに別のアプリケーションが下流処理を行うような複雑なパイプライン構成が可能です。
3. Amazon Data Firehose とは
基本的な役割
Amazon Data Firehose は、リアルタイムのストリーミングデータを指定した宛先に配信するためのフルマネージドサービスです。
アプリケーションを記述したりリソースを管理したりする必要はありません。データプロデューサーを設定してデータを送信するだけで、指定した宛先に自動的に配信されます。配信前にデータを変換することも可能です。
アーキテクチャの概要（バッファリングと配信）
Data Firehose では バッファサイズ（MB 単位） と バッファ間隔（秒単位） に基づいてデータをメモリにバッファリングしてから宛先に配信します。そのため、KDS のような「ほぼゼロレイテンシー」ではなく、ニアリアルタイム（near-real-time） の配信となります。
宛先ごとのデータフローは以下のとおりです。
- Amazon S3：ストリーミングデータが直接 S3 バケットに配信されます。
-
Amazon Redshift：ストリーミングデータはまず S3 バケットに配信され、その後 Firehose が Amazon Redshift の
COPYコマンドを発行して S3 から Redshift クラスターにデータをロードします。 - Amazon OpenSearch Service：ストリーミングデータが OpenSearch Service クラスターに配信され、オプションで S3 バケットにも同時バックアップできます。
- Splunk：ストリーミングデータが Splunk に配信され、オプションで S3 バケットにも同時バックアップできます。
対応している配信先
Data Firehose が対応している配信先は以下のとおりです。
- Amazon S3
- Amazon Redshift
- Amazon OpenSearch Service / Amazon OpenSearch Serverless
- Splunk
- Apache Iceberg Tables
- カスタム HTTP エンドポイント
- サードパーティサービス（Datadog、Dynatrace、LogicMonitor、MongoDB、New Relic、Coralogix、Elastic など）
主なユースケース（Firehose）
Parquet や ORC などのフォーマットへのデータ変換、データの解凍、AWS Lambda を使ったカスタム変換、属性に基づいた動的パーティショニングによる異なるロケーションへの配信といった機能を、**設定ベース（コードなし）**で実現できます。
また、Amazon Kinesis Data Streams（KDS）、Amazon Managed Streaming for Kafka（MSK）、その他 20 以上の AWS ソースからストリーミングデータを取り込んで統合することもできます。
4. KDS と Data Firehose の違い（比較表）
ここまでの内容を表にまとめます。
| 比較軸 | Kinesis Data Streams（KDS） | Amazon Data Firehose |
|---|---|---|
| 目的 | リアルタイムのストリーム取り込みと処理 | ストリームデータを宛先へ配信・ロード |
| レイテンシ | 通常 1 秒未満（リアルタイム） | バッファリングあり（ニアリアルタイム） |
| 管理の手間 | シャード数など利用者が管理（プロビジョンドモード）またはオンデマンド | フルマネージド・自動スケール |
| コンシューマー | 複数アプリが並列・独立して読み取り可能 | 限定された宛先のみ |
| データ変換 | アプリケーション側で実装 | Lambda 連携・フォーマット変換・動的パーティショニングを内蔵 |
| スケーリング | シャードの分割・結合（リシャーディング）で対応 | 自動スケール |
| コード実装 | コンシューマーアプリケーションの実装が必要 | 不要（設定ベース） |
| 主なユースケース | カスタム処理・リアルタイム分析・複雑なパイプライン | S3 / Redshift 等へのデータロード自動化 |
5. どちらを選ぶべきか？
KDS を選ぶ場面
- 1 秒未満のリアルタイム処理が必要なとき
- 複数のアプリケーションが同じストリームを並列で読み取る必要があるとき
- カスタムのデータ処理ロジックをアプリケーション側で実装したいとき
- **複雑なストリーム処理パイプライン（DAG）**を構築したいとき
Data Firehose を選ぶ場面
- S3・Redshift・OpenSearch などの決まった宛先にデータをロードしたいとき
- アプリケーションのコードを書かず、設定だけでパイプラインを構築したいとき
- フォーマット変換や Lambda による軽い変換を組み込みで行いたいとき
- ニアリアルタイムで十分（厳密なリアルタイムは不要）なとき
両者を組み合わせる構成パターン
KDS と Data Firehose は排他的な関係ではなく、組み合わせて使うことも一般的です。
Data Firehose は KDS をソースとして設定することができます。たとえば、KDS でリアルタイムの処理（異常検知・集計など）を行いながら、その同じストリームから Data Firehose が並行してデータを S3 に自動ロードするアーキテクチャが考えられます。
6. まとめ
- Kinesis Data Streams（KDS） は、シャードを単位とするリアルタイムストリームサービス。1秒未満の低レイテンシで、複数コンシューマーが並列でデータを処理できる。柔軟性が高い分、シャード設計やコンシューマーアプリの実装が必要。
- Amazon Data Firehose は、ストリームデータを S3・Redshift などの宛先へ自動配信するフルマネージドサービス。コード不要で設定ベースで動かせるが、バッファリングがあるためニアリアルタイム配信になる。
- 「今すぐ処理したい」→ KDS、「とにかく宛先に届けたい」→ Firehose というイメージが使い分けの基本。
- 両者は組み合わせて使えるため、要件に合わせてハイブリッドな構成も検討してみましょう！