AWS認定資格 WEB問題集＆徹底解説DevOpsエンジニア プロフェッショナル（DOP）

会員登録/ログイン

1. サービス概要

Amazon Data Firehose（旧 Amazon Kinesis Data Firehose）は、ストリーミングデータを受け取り、指定した保存先へ自動的に配信するフルマネージドサービスです。 2024年2月に名称が変更されましたが、APIやエンドポイント、IAMの権限名などは従来のまま利用できます。

データを送る側（プロデューサー）がFirehoseストリームに書き込むと、Firehoseがデータを一定量・一定時間バッファリングし、必要に応じて変換・圧縮・形式変換を行ってから、Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、HTTPエンドポイントなどへ届けます。 シャードの管理やコンシューマーアプリケーションの開発が不要で、「ストリームを保存先に流し込むだけ」の用途で最小の運用負荷になる点が、試験で最もよく問われる特徴です。

2. 主な特徴と機能

2.1 ソース（データの入口）

• Direct PUT: アプリケーションがPutRecord/PutRecordBatch APIで直接書き込む。Amazon Kinesis Agent、CloudWatch Logsのサブスクリプションフィルター、CloudWatchメトリクスストリーム、AWS WAFのログ、Amazon EventBridgeなど多くのAWSサービスもこの方式で送信できる。
• Amazon Kinesis Data Streams: 既存のデータストリームをソースに指定し、Firehoseがデータを読み取って配信する。
• Amazon MSK: MSKクラスターのトピックからデータを読み取り、S3などへ配信する。

2.2 配信先（デスティネーション）

Amazon S3、Amazon Redshift（S3に一時保存したうえでCOPYコマンドでロード）、Amazon OpenSearch Service/OpenSearch Serverless、Apache Icebergテーブル、Splunk、Snowflake、任意のHTTPエンドポイント、Datadog・New Relicなどのサードパーティ製監視サービスに対応しています。 1つのFirehoseストリームの配信先は1つです。複数の宛先へ送る場合はストリームを分けるか、Kinesis Data Streamsで受けて複数のコンシューマーへ分岐させます。

2.3 バッファリング

Firehoseは受信したデータをバッファサイズ（MB単位）とバッファ間隔（秒単位）のどちらかの条件を満たした時点でまとめて配信します。 そのため配信には通常、秒〜数分程度の遅延があり、ミリ秒単位のリアルタイム処理には向かない「ニアリアルタイム」のサービスと位置づけられます。 S3に小さなファイルが大量にできる問題は、バッファを大きくすることで緩和できます。

2.4 データ変換と形式変換

• Lambdaによる変換: 配信前にAWS Lambda関数を呼び出し、レコードの整形、フィールドの追加・削除、マスキングなどを行う。
• レコード形式の変換: JSONをApache ParquetまたはApache ORCの列指向形式に変換してS3へ保存する。スキーマはAWS Glue Data Catalogのテーブル定義を参照する。Athenaでのクエリ性能とコストを改善したい場合の定番。
• 圧縮: S3配信時にGZIP、Snappy、ZIPなどで圧縮できる。
• 動的パーティショニング: レコード内のキー（顧客ID、日付など）に基づいてS3のプレフィックスを動的に分けて保存し、後続のクエリで読み取る範囲を絞り込めるようにする。

2.5 エラー処理とバックアップ

配信や変換に失敗したレコードはS3のエラー用プレフィックスへ出力でき、変換前の元データをS3へバックアップする設定も可能です。 Direct PUTの場合、配信先が一時的に利用できなくてもFirehoseは最大24時間データを保持して再試行します。

3. アーキテクチャおよび技術要素

1. プロデューサー（アプリ、Kinesis Agent、AWSサービス）がFirehoseストリームへレコードを送信する。またはFirehoseがKinesis Data Streams/MSKから読み取る。
2. Firehoseが受信データをバッファに蓄積する。容量は自動的にスケールし、シャードやパーティションの設計は不要。
3. 設定に応じて、Lambdaで変換し、Parquet/ORCへ形式変換し、圧縮する。
4. バッファ条件を満たすと、配信先へまとめて書き込む。Redshiftの場合はいったんS3へ書き込んでからCOPYでロードする。
5. 失敗したレコードはエラー出力先のS3へ保存され、配信状況はCloudWatchメトリクスとCloudWatch Logsで監視する。

Kinesis Data Streamsとの違いは「保持と再読み込み」と「処理の自由度」です。Data Streamsはデータを一定期間保持し、複数のコンシューマーが独自のロジックで低レイテンシに読み取れますが、シャード容量の設計とコンシューマー実装が必要です。 Firehoseはデータを保持して再生する機能はなく、決まった宛先への配信に特化しています。両者を組み合わせ、Data Streamsで受けてリアルタイム処理を行いつつ、Firehoseで生データをS3にアーカイブする構成も一般的です。

4. セキュリティと認証・認可

• IAMロール: Firehoseが配信先（S3バケット、Redshift、OpenSearch）や変換用Lambda、Glue Data Catalogへアクセスするためのサービスロールを設定する。プロデューサー側には firehose:PutRecord などの権限を付与する。
• 保存時の暗号化: Direct PUTのストリームはAWS KMSによるサーバー側暗号化を有効にできる。Kinesis Data Streamsをソースにする場合は、ソース側ストリームの暗号化設定を使う。S3への出力はSSE-KMSなどで暗号化できる。
• VPC内の配信先: VPC内のOpenSearch ServiceやHTTPエンドポイントへは、FirehoseがVPC内にENIを作成して配信できる。
• プライベート接続: インターフェイスVPCエンドポイント（AWS PrivateLink）を使い、VPC内のプロデューサーからインターネットを経由せずにFirehoseへ送信できる。
• 監査と監視: 管理APIの呼び出しはCloudTrailに記録され、配信の成功数・遅延・失敗はCloudWatchで確認できる。

5. 料金形態

Firehoseは取り込んだデータ量（GB）に応じた従量課金で、最低料金や事前のキャパシティ予約はありません。

• 取り込み料金: Direct PUTとKinesis Data Streamsソースでは、各レコードのサイズを5KB単位に切り上げて計算する。小さなレコードを大量に送ると割高になるため、プロデューサー側でまとめて送るとコストを下げられる。
• MSKソース・ログ配信: ソースの種類によってGB単価が異なる（5KB切り上げがない方式もある）。
• オプション機能: Parquet/ORCへの形式変換、動的パーティショニング、VPC内の配信先への配信、Iceberg・Snowflakeなどの特定の宛先は、それぞれ追加料金がかかる。
• 関連サービス: 変換用Lambda、保存先のS3・Redshift・OpenSearchの料金、データ転送料金は別途発生する。

6. よくあるアーキテクチャ・設計パターン

• ログ/クリックストリームのデータレイク格納: アプリやWebサーバーのログをFirehoseでS3へ配信し、Parquet変換と動的パーティショニングを施してAthenaで分析する。
• 集中ログ基盤: 複数アカウントのCloudWatch Logsをサブスクリプションフィルター経由でFirehoseへ送り、ログ集約用アカウントのS3やOpenSearch Serviceに集約する。
• メトリクスのエクスポート: CloudWatchメトリクスストリームをFirehoseに接続し、S3やサードパーティの監視サービスへ継続的に送る。
• DWHへのニアリアルタイムロード: イベントデータをFirehoseでRedshiftへ配信し、数分遅れでダッシュボードに反映する。
• Data Streamsとの併用: Kinesis Data Streamsで受けたデータをLambdaやManaged Service for Apache Flinkでリアルタイム処理しつつ、同じストリームをFirehoseのソースにして生データをS3へアーカイブする。

7. 設定・デプロイ手順（ハンズオン例）

1. 保存先のS3バケットを作成する（暗号化とライフサイクルルールも設定しておく）。
2. Firehoseコンソールで「Firehoseストリームを作成」を選び、ソースに「Direct PUT」、送信先に「Amazon S3」を指定する。
3. 必要に応じてLambdaによるデータ変換を有効化し、Parquet形式への変換を使う場合はGlue Data Catalogのテーブルを指定する。
4. S3のプレフィックス（日付ベースまたは動的パーティショニング）、エラー出力用プレフィックス、バッファサイズとバッファ間隔、圧縮形式を設定する。
5. サービスロール（IAM）を自動作成または指定し、ストリームを作成する。
6. コンソールのテストデータ送信機能、またはAWS CLI/SDKのPutRecordでデータを送り、バッファ間隔の経過後にS3へオブジェクトが作成されることを確認する。
7. CloudWatchメトリクス（配信成功数、データ鮮度など）で配信状況を監視する。

8. 試験で問われやすいポイント