Amazon Data Firehose

解決する課題

ログやイベント、IoTのテレメトリのように絶え間なく流れてくるデータを、S3やデータウェアハウスへ確実に貯めたい場面は多くあります。自前でコンシューマを書くと、バッファリング・リトライ・スケーリング・形式変換の面倒を全部抱え込むことになります。Amazon Data Firehoseはこの「配送」部分をマネージドに引き受けます。

• ストリーミングデータをS3/Redshift/OpenSearch等へ自動配信したい
• 配信のためのサーバーやコンシューマを運用したくない
• 配信の途中で形式変換（JSONからParquetなど）・圧縮・暗号化もまとめて行いたい

取り込んだ端からリアルタイムに自前処理する必要はなく、「少し溜めてから届けばよい」準リアルタイム用途に向きます。

主要概念と用語

• デリバリーストリーム（配信ストリーム）: Firehoseの基本単位。データの入口と配信先（送信先）をひとつ定義したもの
• ソース（送信元）: データの入口。直接PUT（SDK/エージェント経由）や、Kinesis Data Streamsを入口にする方式がある
• デスティネーション（送信先）: 配信先。S3、Redshift、OpenSearch、各種サードパーティ先などを指定できる
• バッファリング: レコードを一定のサイズまたは一定の時間溜めてからまとめて配信する仕組み。どちらかの条件に達すると送信する
• データ変換: 配信前にLambda関数でレコードを加工する仕組み
• 形式変換: JSONを列指向のParquetやORCへ変換する機能（スキーマはデータカタログを参照）
• バックアップ: 変換失敗や配信失敗時に、元データや失敗分をS3へ退避する設定

仕様・制限・クォータ

• 配信はバッファのサイズまたは時間のどちらかに達したタイミングで行われ、厳密な秒単位のリアルタイムではなく準リアルタイム
• バッファのサイズ・時間には設定可能な範囲があり、リアルタイム性を上げるほど小さなオブジェクトが増えやすい
• 1配信ストリームあたりのスループットには上限があり、必要に応じて引き上げを申請できる
• レコード1件あたりのサイズや、まとめて送る際の上限など、リクエスト面のクォータが存在する
• 圧縮（gzip等）、保存時暗号化、配信前のLambda変換、Parquet/ORCへの形式変換に対応する

内部の仕組み

Firehoseはソースから受け取ったレコードをバッファに蓄積し、設定したサイズか時間のいずれかの条件を満たすとデスティネーションへまとめて配信します。コンシューマやシャードをユーザーが管理する必要はなく、スループットに応じてマネージドにスケールします。

配信の流れの中で、任意で次の加工を挟めます。

• Lambdaによるデータ変換: 受け取ったレコードを関数で整形・フィルタしてから配信できる
• 形式変換: JSONレコードをParquet/ORCの列指向形式へ変換し、後段の分析を効率化できる
• 圧縮・暗号化: S3配信時に圧縮し、保存時暗号化を適用できる

配信や変換に失敗したレコードは、設定したS3のバックアップ先へ退避され、データを失わずに後から再処理できます。Redshift宛の配信は、いったんS3に置いてからロードする方式を取ります。

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

• データレイクへの自動取り込み: ストリーミングログをFirehoseでS3へ集約し、AthenaやRedshift Spectrumで分析する
• 形式変換でクエリを安く速く: S3配信時にParquet/ORCへ変換しておくと、後段のスキャン量が減りコスト・性能が改善する
• バッファ設定のバランス: 時間を短くするとリアルタイム性は上がるが小さなファイルが増える。分析しやすいサイズになるよう調整する
• Lambda変換は冪等に: リトライで同じレコードが再投入される可能性を踏まえ、変換処理は繰り返しに強く作る
• 失敗時バックアップを必ず設定: 変換・配信失敗分をS3へ退避し、データ欠損を防ぐ

運用・監視

• 配信の成否やスループットはCloudWatchメトリクスで監視する（配信レコード数、配信先別の成功・失敗バイト数など）
• 配信エラーやLambda変換エラーはCloudWatch Logsへ出力でき、原因調査に使う
• 配信が滞る場合は、スループットのクォータ超過や配信先（S3権限、Redshiftロード、OpenSearchの拒否）側の問題を疑う
• バックアップ先S3に失敗レコードが溜まっていないかを定期的に確認する

コスト

• 基本は取り込んだデータ量に応じた従量課金で、待機中の固定費は小さい
• 形式変換（Parquet/ORC化）やデータ取り込みの加工には追加の料金要素が発生し得る
• 配信先のストレージ料金（S3など）やLambda変換の実行料金は別途かかる
• 圧縮や形式変換で後段のストレージ・スキャン量を減らせば、トータルコストの最適化につながる

セキュリティ

• アクセス制御はIAMで行い、Firehoseが配信先へ書き込むためのロール権限を最小限に絞る
• 保存時暗号化はKMSで管理した鍵を利用でき、転送時はTLSで保護される
• VPC内のOpenSearch等へ配信する場合は、プライベート経路での配信に対応する
• 操作はCloudTrailで監査でき、誰がいつ設定を変更したかを追跡できる

Well-Architected の観点

• 運用上の優秀性: コンシューマやスケーリングを自前運用せず、配信をマネージドに任せられる
• コスト最適化: 従量課金で待機コストが小さく、形式変換・圧縮で後段コストも下げられる
• 信頼性: リトライと失敗時のS3バックアップでデータ欠損を防ぐ
• パフォーマンス効率: バッファ設定で準リアルタイム性とファイルサイズのバランスを取れる

試験で問われるポイント

関連サービス・比較

取り込み用の Amazon Kinesis Data Streams とよく比較されます。届いた端から自前で処理したいのか、溜めて自動で配信したいのかで選びます。

ハンズオン / CLI例

# 直接PUT型のデリバリーストリームをS3宛で作成
aws firehose create-delivery-stream \
  --delivery-stream-name web-logs \
  --delivery-stream-type DirectPut \
  --s3-destination-configuration \
    RoleARN=arn:aws:iam::111122223333:role/firehose-delivery-role,BucketARN=arn:aws:s3:::my-data-lake

# レコードを1件投入（準リアルタイムでS3へ配信される）
aws firehose put-record \
  --delivery-stream-name web-logs \
  --record Data="$(echo -n '{"status":200,"path":"/"}' | base64)"