Amazon Data Firehoseによるストリーミングデータ配信

ストリーミングデータを配信先へ届ける

Amazon Data Firehoseは、連続して届くデータを受け取り、必要に応じてまとめたり変換・圧縮したりしてから、指定した保存先や分析先へ配信するフルマネージドサービスです。以前はAmazon Kinesis Data Firehoseという名称でした。現在のAWSサービス名はAmazon Data Firehoseです。

データを送る側は、アプリケーションからFirehose APIを呼び出す方法や、対応するAWSサービス・エージェントをデータソースに指定する方法を選べます。Kinesis Data Streamsをソースにする構成も可能です。Firehoseは受信したレコードを設定に応じて整え、Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、HTTPエンドポイントや対応するパートナーの宛先へ届けます。

たとえば、電動自転車の貸出拠点からバッテリー残量や車両の稼働状況が継続的に送られてくるとします。Firehoseはレコードを集めてからAmazon S3へ配信し、蓄積データの分析に使えるようにできます。配信前のデータ整形が必要ならLambdaを組み合わせ、S3上で分析しやすい形式に整えることもできます。

Firehoseの主な役割は、ストリーム上で複雑な分析を行うことではなく、受け取ったデータを設定済みの宛先へ安定して運ぶことです。自分で常時稼働する配信コンシューマーを作成・運用せずに済み、データ量の増減に合わせたサービス側のスケーリングを利用できます。利用者はシャード数を調整しませんが、サービスクォータ、配信先の処理能力、権限、変換処理などの設計は必要です。

バッファリングが配信のタイミングを決める

Firehoseは届いたデータをそのまま1件ずつ転送するのではなく、バッファサイズまたはバッファ間隔の条件に達するまで一時的にまとめます。通常はどちらかの条件が先に満たされた時点で配信が始まります。これにより、データ量の少ない時間帯は一定時間待ってまとまりを作り、データ量が多い時間帯はサイズ条件に達した段階で配信できます。

条件	配信を始める基準	主な影響
バッファサイズ	まとめたデータ量が指定値に達する	小さなファイルやリクエストが大量に発生するのを抑えやすい
バッファ間隔	前回の配信から指定時間が経過する	データ量が少なくても長時間ためずに配信できる

このバッファリングのため、Data Firehoseは一般にニアリアルタイムの配信サービスです。到着したデータを低い遅延で届けられますが、常に各レコードを受信直後に転送するわけではありません。配信先がファイル形式の場合、バッファリングは小さすぎるファイルを減らし、後続の分析処理を効率よく行う助けにもなります。一方、間隔やサイズを大きくすると配信頻度が下がるため、宛先にデータが現れるまでの時間は長くなります。

現在は、対応するアプリケーション宛先でバッファ間隔を0秒に設定でき、数秒以内の配信を目指せます。ただし、これは全宛先に共通する即時配信モードではありません。S3バックアップ先や動的パーティショニングではゼロ秒の設定を利用できないなどの制約があり、宛先によって推奨設定も異なります。遅延要件だけで判断せず、配信先の条件とファイル数・オブジェクトサイズへの影響を確認します。

また、バッファサイズや間隔は配信の目安として扱われ、Firehoseが宛先や処理状況に合わせて実際の値を調整する場合があります。厳密な秒単位の到着保証と誤解しないようにします。

AWS Lambdaでレコードを変換する

Data Firehoseは配信前にAWS Lambda関数を呼び出してレコードを変換できます。Lambdaは到着したデータのバッチを受け取り、形式の解析、項目名の変更、不要な属性の削除、補足情報の付与などを行い、変換後のデータをFirehoseへ返します。Firehoseはその結果を宛先へ配信します。

たとえば、各貸出拠点が異なる項目名で出力する車両稼働データを、Lambdaで共通のJSONスキーマにそろえ、時刻や拠点IDを付加してからOpenSearch Serviceへ送れます。独自形式のデータを整える場合や、データごとに業務ルールに基づく処理を行う場合に有効です。

Lambda変換にもバッファサイズと間隔を設定できます。Firehoseは一定量・一定時間分のレコードをまとめてLambdaへ同期呼び出しします。そのため、関数の処理時間や同時実行数、失敗時の再試行、返却するデータ量が配信の遅延やスループットに影響します。Lambdaの同期呼び出しにはリクエスト・レスポンスそれぞれ6 MBのペイロード上限があるため、変換バッチのサイズを設計する必要があります。

よくあるログ形式の変換には、AWSが公開するLambdaブループリントを出発点として使える場合があります。ブループリントは変換コードのひな型であり、適用するログ形式や必要な項目に合わせて確認・調整してから利用します。ブループリントを有効にするだけで、あらゆる独自形式が自動的に理解されるわけではありません。

JSONを列指向形式へ変換する

Lambdaによるレコード変換とは別に、Data FirehoseにはJSON形式の入力をApache ParquetまたはApache ORCへ変換する組み込み機能があります。ParquetとORCは列指向のデータ形式で、S3上に保存したデータをAthenaなどで分析する際に、行指向JSONに比べて保存容量や読み取り量を抑えやすくなります。

組み込みの形式変換では、入力JSONを読み取るデシリアライザー、データ項目の型を定義するAWS Glue Data Catalogのスキーマ、ParquetまたはORCを出力するシリアライザーを設定します。この形式変換の宛先はAmazon S3です。

入力がCSVや独自のテキスト形式であれば、LambdaでまずJSONに変換し、その後Firehoseの形式変換でParquetまたはORCへ変換できます。つまり、Lambdaはレコード内容を加工する手段、組み込み形式変換はスキーマに基づいてJSONを列指向形式へエンコードする機能です。Athena向けに保存形式を変えるだけなら、必要な構成を確認したうえで組み込み形式変換を検討できます。

配信先とデータ保護

宛先によって、Firehoseがデータを渡す方法は異なります。

宛先	配信の流れ
Amazon S3	バッファーした複数レコードをS3オブジェクトとして保存する
Amazon Redshift	いったんS3へデータを置き、そこからRedshiftへロードする
Amazon OpenSearch Service	バッファーしたレコードを一括リクエストでインデックスへ送る
Splunk・HTTPエンドポイント・対応するパートナー	宛先の形式や推奨設定に合わせてバッファーし、データを送信する

Firehoseは配信時の圧縮をサポートします。S3などで圧縮後のオブジェクトを保存すれば、ストレージ使用量を減らせる可能性があります。また、配信ストリームと宛先間の転送や保存時の暗号化を構成できます。暗号化はデータ保護を目的とする機能であり、保存量を小さくする機能ではありません。

Data Firehose自体は、利用者が読み取り位置を指定して過去のレコードを再生する保持ストリームではありません。サービス内部では配信に向けて一時的にデータをバッファーしますが、Kinesis Data Streamsの保持期間のように、コンシューマーが後から読み直すための履歴を提供するものではありません。長期保存や再処理が必要な場合は、S3などの宛先やバックアップ設定を含めて設計します。

Kinesis Data Streamsとの使い分け

両サービスはストリーミングデータを扱いますが、担う役割が違います。Kinesis Data Streamsはレコードをストリームに保持し、コンシューマーアプリケーションが読み取るためのサービスです。Data Firehoseは、データを設定した宛先へ配信するサービスです。Data StreamsをFirehoseのソースに指定して、既存ストリームから読み出したレコードをS3や分析先へ届ける構成も取れます。

観点	Kinesis Data Streams	Amazon Data Firehose
主な役割	レコードをストリームに取り込み、保持してコンシューマーに読ませる	レコードを受け取り、変換・圧縮などを行って指定先へ配信する
並列化・容量管理	プロビジョンドではシャード数の設計・調整が必要。オンデマンドではAWSが容量を管理する	シャードを公開・管理せず、配信サービスがデータ量に応じてスケールする
データの読み取り	コンシューマーが読み取り位置を管理し、保持期間中に再読込できる	コンシューマーが再読込するための保持期間や読み取り位置は提供しない
配信タイミング	コンシューマーアプリケーションの処理速度に合わせる	バッファサイズと時間の条件を基に、ニアリアルタイムで宛先へ届ける
データ変換	アプリケーションや別のストリーム処理サービスで実装する	Lambda変換や対応する形式変換を配信フローに組み込める

Kinesis Data Streamsの保持期間はデフォルト24時間で、設定により最大365日まで延長できます。保持期間内ならコンシューマーが独立してストリームを読み進め、必要に応じて過去のレコードを再処理できます。その代わり、プロビジョンドモードではシャード容量を設計・監視する必要があります。

Data Firehoseではシャードや独自コンシューマーアプリケーションの管理を減らし、設定済みの保存先へデータを届けられます。データを複数の宛先へ別々の処理で使いたい、読み取り位置を管理して再生したい、ストリーム処理ロジックを細かく制御したいといった要件ではData Streamsが候補になります。データをS3や分析サービスへロードすることが主な目的で、ストリーム容量管理を簡素化したいならData Firehoseが候補です。

EC2などのログファイルを取り込む

既存のLinuxサーバーにあるログファイルを継続的にFirehoseへ送るには、Kinesis Agentを利用できます。エージェントをサーバーにインストールして監視対象ファイルやFirehoseストリームを設定すると、追加されたログを読み取り、ストリームへ送信できます。アプリケーションのログを別の保存先へ配信したり、Lambdaで項目を抽出・整形して分析用に使ったりする構成に適しています。

たとえば、冷蔵設備の監視ゲートウェイが記録する稼働ログをKinesis AgentでFirehoseへ送り、Lambdaで機器番号と温度を共通形式に整えてからS3へ保存できます。元のアプリケーションにFirehose APIの呼び出しを組み込まなくても、ファイルを起点にした取り込み経路を作れます。

この構成では、Kinesis Agentを動かすサーバーの運用と権限設定は残ります。サーバーのIAMロールには、必要なFirehoseストリームへの書き込み権限を付与します。Kinesis AgentはデータをFirehoseへ送る取り込み側のエージェントであり、Firehoseの配信先や変換処理を置き換えるものではありません。

料金と構成時の確認点

Data Firehoseの料金は、基本的に取り込むデータ量などに基づきます。Direct PUTまたはKinesis Data Streamsをソースにする場合は、レコード単位のサイズ丸めが料金計算に影響します。Lambda変換、形式変換、動的パーティショニングなどの機能を使う場合や、S3・Redshift・OpenSearch Serviceなどの宛先を利用する場合は、それぞれの関連料金も発生します。圧縮による保存容量の削減と、取り込みや機能利用にかかる料金の両方を見積もります。

設計時には、次の条件を一緒に確認してください。

1. どのアプリケーションやAWSサービスからデータを受け取るか。
2. 配信先が要求するデータ形式、最大容量、バッファ間隔は何か。
3. Lambda変換が必要か、JSONからParquet・ORCへの形式変換で足りるか。
4. 許容遅延、オブジェクトサイズ、配信頻度のバランスをどう取るか。
5. 配信失敗時の再試行、バックアップ、長期保存をどのように行うか。
6. Firehose、変換機能、配信先のそれぞれに必要な料金とIAM権限は何か。

Firehoseは配信運用を大きく簡素化しますが、変換エラー、アクセス拒否、宛先のスロットリングがあれば、配信遅延や失敗が起こり得ます。CloudWatchメトリクスやログで取り込み量、配信の成功・失敗、宛先への到着状況を監視し、失敗データを調査・再処理できる経路を用意します。

試験での判断軸

• **「シャードを管理せず、ストリームデータをS3や分析先へロードしたい」**ならData Firehoseを検討する。
• **「データを一定期間保持し、複数の独自コンシューマーがそれぞれ読みたい」**ならKinesis Data Streamsを検討する。
• **「配信前にレコード内容を加工したい」**ならFirehoseとAWS Lambdaのデータ変換を組み合わせる。
• **「JSONをParquetまたはORCにしてS3へ保存したい」**ならGlue Data Catalogのスキーマを使うFirehoseの形式変換を検討する。
• **「ログファイルからFirehoseへ継続的に送りたい」**ならKinesis Agentなどの対応データソースを組み合わせる。
• **「リアルタイム」**という表現があっても、Firehoseは通常バッファリング後に配信するニアリアルタイムサービスだと押さえる。0秒設定には宛先ごとの条件がある。

公式ドキュメント

• Amazon Data Firehoseとは
• Firehoseストリームのソースと宛先を選ぶ
• Amazon Data Firehoseのバッファ設定
• Amazon Data Firehoseでソースデータを変換する
• Amazon Data Firehoseで入力データ形式を変換する
• Amazon Data Firehoseによるデータ配信
• Kinesis Data StreamsをFirehoseのソースとして使う
• Kinesis AgentでAmazon Data Firehoseへ書き込む
• Amazon Data Firehoseの料金