👏

【AWS SAP試験学習メモ】Kinesis Data FirehoseとKinesis Data Streamsどっちなんだい!!

に公開

【AWS SAP対策】Kinesis Data Firehose と Kinesis Data Streamsについて

本記事では、AWS 認定 Solutions Architect – Professional(SAP)で頻繁に問われる、Kinesis Data Firehose と Kinesis Data Streamsの違いと、どのケースでどちらを使うべきかを端的にまとめてみます。

一度覚えたつもりでも時間が経つと、
き○に君よろしく「どっちなんだい!!」となる自分がいます。

基本的なまとめとなりますので初学者向きです。

1. Kinesis Data Firehose

Kinesis Data Firehose は フルマネージドのデータ配信サービスです。
ストリーミングデータを S3、Redshift、OpenSearch、Splunk などへ
自動的に届けることに特化しています。

特徴

  • フルマネージドで運用負荷が非常に低い
  • 数秒〜数分の遅延(バッファリングあり)
  • データ保持なし → 即送信
  • Lambda による軽量な変換が可能
  • スケールは完全自動
  • 主に「収集・保存」用途向け

2. Kinesis Data Streams

Kinesis Data Streams は リアルタイムデータ処理基盤です。
データを Streams に投入し、Lambda・KCL アプリ・Kinesis Data Analytics などが
低遅延でデータを読み取り処理します。

特徴

  • 1 秒未満のリアルタイム処理が可能
  • データ保持(24 時間〜365 日) → 再処理できる
  • 複数のコンシューマが同じデータを同時に読み取れる
  • 順序保証(パーティションキー単位)
  • スループットはシャード単位で管理
  • リアルタイム分析・IoT・高頻度イベント処理向け

3. Firehose と Streams の比較表

項目 Kinesis Data Firehose Kinesis Data Streams
主目的 データを保存先へ自動配送 リアルタイム処理プラットフォーム
遅延 数秒〜数分 1 秒未満
データ保持 なし 24 時間〜365 日
スケーリング 完全自動 シャード管理
再処理 不可 可能
主な用途 ログ収集、S3 へのロード IoT、クリック解析、RT 処理
運用負荷 非常に低い 高め(アプリ運用あり)

4. SAP試験によく出る出題ケース

要件毎にそれぞれ向いているケースをまとめてみました。

【Firehose が向いているケース】

ケース①:S3 などにログを簡単に集めたい

  • S3 / Redshift / OpenSearch への 自動配信が目的
  • 設定だけで動き、運用負荷が非常に低い
    → Firehose

ケース②:とにかく運用負荷を下げたい

  • スケール、バッファ、再試行すべて自動
  • アプリ不要
    → Firehose

ケース③:保存前に“軽い”変換を行いたい

  • Lambda Transform で JSON→Parquet など簡易 ETL が可能
    → Firehose(軽量変換向け)

【Data Streams が向いているケース】

ケース④:1 秒未満のリアルタイム処理が必要

  • IoT、クリックストリーム、ゲームイベントなどで即時処理したい
    → Data Streams

ケース⑤:後からデータを再処理したい

  • Streams は 24h〜365日保持し、再読み取りできる
    → Data Streams

ケース⑥:複数コンシューマで並行処理したい

  • 複数のアプリが同じデータを同時に読みたいケース
  • Enhanced Fan-out にも対応
    → Data Streams

ケース⑦:順序保証・スループット制御が必要

  • シャード単位で順序・スループットを設計
    → Data Streams(設計自由度が必要)

5. 試験対策まとめ早見表

要件 最適なサービス 理由
S3 へログを簡単に送りたい Firehose 送信先(S3/Redshift/OpenSearch)への 自動配送ができ、設定だけで動作するため。
運用負荷を最小化したい Firehose スケーリング・バッファ管理・再試行すべてが 完全マネージドで、アプリ運用が不要なため。
軽いデータ変換をして保存したい Firehose Firehose の Lambda Transform で JSON→Parquet などの軽量 ETL が可能で手軽。
1 秒未満のリアルタイム処理 Data Streams Streams は 1 秒未満の低遅延処理が可能で、リアルタイム性が最も高い。
データを後から再処理したい Data Streams 24 時間〜365 日の データ保持ができ、保持期間中は再読込み・再処理が可能。
複数コンシューマで処理したい Data Streams 同じデータを複数アプリで同時に処理できる マルチコンシューマ機能を備えているため。
順序保証・スループット管理が必要 Data Streams シャード単位で 順序保証 と スループット制御ができ、設計自由度が高い。

一言コメント

これで今後は迷わないはず!!

パワー!!!!!!!!!!!


参考資料

Discussion