Amazon Data Firehose は、以前は Amazon Kinesis Data Firehose と呼ばれていました。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Data Firehose データ配信を理解する
Firehose ストリームにデータが送信されると、選択した送信先にデータが自動的に配信されます。
重要
Kinesis Producer Library (KPL) を使用して Kinesis データストリームにデータを書き込む場合、集約を使用してその Kinesis データストリームに書き込むレコードを結合できます。次に、そのデータストリームを Firehose ストリームのソースとして使用すると、Amazon Data Firehose はレコードを宛先に配信する前にレコードの集約を解除します。データを変換するように Firehose ストリームを設定すると、Amazon Data Firehose はレコードを に配信する前にレコードの集約を解除します AWS Lambda。詳細については、「Kinesis Producer Library を使用した Amazon Kinesis Data Streams プロデューサーの開発」および Amazon Kinesis Data Streams 開発者ガイドの「集約」を参照してください。
トピック
データ配信形式を設定する
Amazon Simple Storage Service (Amazon S3) へのデータ配信の場合、Firehose は Firehose ストリームのバッファリング設定に基づいて複数の受信レコードを連結します。次に、Amazon S3 オブジェクトとしてレコードを Amazon S3 に配信します。デフォルトでは、Firehose は区切り文字なしでデータを連結します。レコード間に新しい行区切り文字を使用する場合は、Firehose コンソール設定または API パラメータ でこの機能を有効にすることで、新しい行区切り文字を追加できます。
Amazon Redshift へのデータ配信の場合、Firehose はまず、前述の形式で受信データを S3 バケットに配信します。次に、Firehose は Amazon Redshift COPY コマンドを発行して、S3 バケットから Amazon Redshift でプロビジョニングされたクラスターまたは Amazon Redshift Serverless ワークグループにデータをロードします。Amazon Data Firehose が複数の受信レコードを Amazon S3 オブジェクトに連結した後、Amazon S3 オブジェクトを Amazon Redshift でプロビジョニングされたクラスターまたは Amazon Redshift Serverless ワークグループにコピーできることを確認します。詳細については、「Amazon Redshift COPY コマンドのデータ形式パラメータ」を参照してください。
OpenSearch サービスおよび OpenSearch サーバーレスへのデータ配信の場合、Amazon Data Firehose は Firehose ストリームのバッファリング設定に基づいて受信レコードをバッファリングします。次に、 OpenSearch サービスクラスターまたは OpenSearch サーバーレスコレクションに複数のレコードをインデックスするための OpenSearch サービスまたは OpenSearch サーバーレス一括リクエストを生成します。Amazon Data Firehose に送信する前に、レコードが UTF-8 でエンコードされ、単一行の JSON オブジェクトにフラット化されていることを確認してください。また、サービスクラスターの OpenSearch rest.action.multi.allow_explicit_indexオプションを true (デフォルト) に設定して、レコードごとに設定された明示的なインデックスを持つ一括リクエストを受け取る必要があります。詳細については、Amazon OpenSearch Service デベロッパーガイドの「サービス設定の詳細オプション」を参照してください。 OpenSearch
Splunk へのデータ配信の場合、Amazon Data Firehose は送信するバイトを連結します。データを改行文字などで区切る場合は、自分で挿入する必要があります。Splunk がそのような区切り記号を解析するように設定されていることを確認してください。
サポートされているサードパーティーサービスプロバイダーが所有する HTTP エンドポイントにデータを配信する場合、統合された Amazon Lambda サービスを使用して、受信レコードをサービスプロバイダーの統合が想定している形式に一致する形式に変換する関数を作成できます。受信したレコード形式の詳細については、送信先に HTTP エンドポイントを選択したサードパーティーサービスプロバイダーにお問い合わせください。
Snowflake へのデータ配信の場合、Amazon Data Firehose は内部的に 1 秒間データをバッファリングし、Snowflake ストリーミング API オペレーションを使用して Snowflake にデータを挿入します。デフォルトでは、挿入したレコードは 1 秒ごとにフラッシュされ、Snowflake テーブルにコミットされます。挿入呼び出しを行うと、Firehose は Snowflake にデータがコミットされるまでにかかった時間を測定する CloudWatch メトリクスを出力します。Firehose は現在、レコードペイロードとして単一の JSON 項目のみをサポートしており、JSON 配列はサポートされていません。入力ペイロードが有効な JSON オブジェクトであり、余分な二重引用符、引用符、エスケープ文字なしで適切に形成されていることを確認してください。
データ配信の頻度を理解する
Firehose の各送信先には、独自のデータ配信頻度があります。詳細については、「バッファリングヒントを理解する」を参照してください。
データ配信の失敗を処理する
各 Amazon Data Firehose 送信先には、独自のデータ配信失敗処理があります。
- Amazon S3
-
S3 バケットへのデータ配信は、さまざまな理由で失敗する場合があります。例えば、バケットが存在しない場合、Amazon Data Firehose が引き受ける IAM ロールがバケットにアクセスできない、ネットワークが失敗する、または同様のイベントが発生する可能性があります。このような条件下では、Amazon Data Firehose は配信が成功するまで最大 24 時間再試行し続けます。Amazon Data Firehose の最大データストレージ時間は 24 時間です。データ配信が 24 時間を超えて失敗した場合、データは失われます。
- Amazon Redshift
-
Amazon Redshift の送信先では、Firehose ストリームの作成時に再試行時間 (0～7200 秒) を指定できます。
Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループへのデータ配信は、いくつかの理由で失敗する場合があります。例えば、Firehose ストリームのクラスター設定が正しくない、メンテナンス中のクラスターまたはワークグループ、ネットワーク障害などが考えられます。これらの条件下では、Amazon Data Firehose は指定された期間再試行し、Amazon S3 オブジェクトの特定のバッチをスキップします。スキップされたオブジェクトの情報は、マニフェストファイルとして
errors/フォルダーの S3 バケットに配信されます。この情報は手動のバックフィルに使用できます。データを手動でマニフェストファイルにコピーする方法の詳細については、「マニフェストを使用し、データファイルを指定する」を参照してください。 - Amazon OpenSearch Service と OpenSearchサーバーレス
-
OpenSearch サービスと OpenSearch サーバーレスの送信先では、Firehose ストリームの作成中に再試行時間 (0～7200 秒) を指定できます。
OpenSearch サービスクラスターまたは OpenSearch サーバーレスコレクションへのデータ配信は、いくつかの理由で失敗することがあります。例えば、Firehose ストリームのサービス OpenSearch クラスターまたは OpenSearch サーバーレスコレクション設定が正しくない、メンテナンス中の OpenSearch サービスクラスターまたは OpenSearch サーバーレスコレクション、ネットワーク障害、または同様のイベントがある可能性があります。これらの条件下では、Amazon Data Firehose は指定された期間再試行し、その特定のインデックスリクエストをスキップします。スキップされたドキュメントは
AmazonOpenSearchService_failed/フォルダーの S3 バケットに配信され、手動のバックフィルに使用できます。Service の場合 OpenSearch 、各ドキュメントの JSON 形式は次のとおりです。
{ "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Service)", "errorMessage": "(error message returned by OpenSearch Service)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "esDocumentId": "(intended OpenSearch Service document ID)", "esIndexName": "(intended OpenSearch Service index name)", "esTypeName": "(intended OpenSearch Service type name)", "rawData": "(base64-encoded document data)" }OpenSearch Serverless の場合、各ドキュメントの JSON 形式は次のとおりです。
{ "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Serverless)", "errorMessage": "(error message returned by OpenSearch Serverless)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "osDocumentId": "(intended OpenSearch Serverless document ID)", "osIndexName": "(intended OpenSearch Serverless index name)", "rawData": "(base64-encoded document data)" } - Splunk
-
Amazon Data Firehose が Splunk にデータを送信すると、Splunk からの確認応答を待機します。エラーが発生した場合、または確認タイムアウト期間内に確認が到着しない場合、Amazon Data Firehose は再試行期間カウンターを開始します。再試行期間が終わるまで再試行が続けられます。その後、Amazon Data Firehose はそれをデータ配信の失敗と見なし、データを Amazon S3 バケットにバックアップします。
Amazon Data Firehose がデータを Splunk に送信するたびに、最初の試行でも再試行でも、確認タイムアウトカウンターが再起動されます。Splunk から送達確認が来るのを待機します。再試行期間が終了しても、Amazon Data Firehose は確認応答を受信するか、確認タイムアウトに達するまで確認応答を待機します。確認がタイムアウトすると、Amazon Data Firehose は再試行カウンターに残り時間があるかどうかを確認します。残り時間がある場合は、確認が到着するか再試行時間が切れたと判断されるまで再試行されロジックが繰り返されます。
送達確認の受信失敗だけが、発生する可能性のあるデータ配信エラーのタイプではありません。他のタイプのデータ配信エラーの詳細については、「Splunk データ配信エラー」を参照してください。再試行期間が 0 より大きい場合、すべてのデータ配信エラーで再試行ロジックがトリガーされます。
以下に、エラーレコードの例を示します。
{ "attemptsMade": 0, "arrivalTimestamp": 1506035354675, "errorCode": "Splunk.AckTimeout", "errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.", "attemptEndingTimestamp": 13626284715507, "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==", "EventId": "49577193928114147339600778471082492393164139877200035842.0" } - HTTP エンドポイント送信先
-
Amazon Data Firehose が HTTP エンドポイントの送信先にデータを送信すると、この送信先からの応答を待機します。エラーが発生した場合、または応答タイムアウト期間内に応答が到着しない場合、Amazon Data Firehose は再試行期間カウンターを開始します。再試行期間が終わるまで再試行が続けられます。その後、Amazon Data Firehose はそれをデータ配信の失敗と見なし、データを Amazon S3 バケットにバックアップします。
Amazon Data Firehose は、最初の試行でも再試行でも、データを HTTP エンドポイントの送信先に送信するたびに、応答タイムアウトカウンターを再起動します。次に、HTTP エンドポイントの送信先から応答が到着するのを待ちます。再試行期間が終了しても、Amazon Data Firehose は応答を受信するか、応答タイムアウトに達するまで応答を待機します。レスポンスがタイムアウトした場合、Amazon Data Firehose は再試行カウンターに残り時間があるかどうかを確認します。残り時間がある場合は、応答が到着するか再試行時間が切れたと判断されるまで再試行されロジックが繰り返されます。
応答の受信失敗だけが、発生する可能性のあるデータ配信エラーのタイプではありません。他のタイプのデータ配信エラーの詳細については、「HTTP エンドポイントデータ配信エラー」を参照してください。
以下に、エラーレコードの例を示します。
{ "attemptsMade":5, "arrivalTimestamp":1594265943615, "errorCode":"HttpEndpoint.DestinationException", "errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}", "attemptEndingTimestamp":1594266081318, "rawData":"c2FtcGxlIHJhdyBkYXRh", "subsequenceNumber":0, "dataId":"49607357361271740811418664280693044274821622880012337186.0" } - Snowflake の送信先
-
Snowflake 送信先の場合、Firehose ストリームを作成するときに、オプションの再試行時間 (0～7200 秒) を指定できます。再試行時間のデフォルト値は 60 秒です。
Snowflake テーブルへのデータ配信は、Snowflake の送信先設定の誤り、Snowflake の停止、ネットワーク障害など、いくつかの理由で失敗することがあります。再試行ポリシーは、再試行不可能なエラーには適用されません。例えば、Snowflake が JSON ペイロードをテーブルに追加の列がないために拒否した場合、Firehose は再度配信しようとしません。代わりに、S3 エラーバケットへの JSON ペイロードの問題によるすべての挿入失敗のバックアップが作成されます。
同様に、ロール、テーブル、またはデータベースが正しくないために配信が失敗した場合、Firehose はデータを再試行せず、S3 バケットに書き込みます。再試行期間は、Snowflake サービスの問題、一時的なネットワーク障害などの障害にのみ適用されます。これらの条件下では、Firehose は指定された期間再試行してから S3 に配信します。失敗したレコードは Snowflake-failed/ フォルダに配信され、手動バックフィルに使用できます。
以下は、S3 に配信する各レコードの JSON の例です。
{ "attemptsMade": 3, "arrivalTimestamp": 1594265943615, "errorCode": "Snowflake.InvalidColumns", "errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation", "attemptEndingTimestamp": 1712937865543, "rawData": "c2FtcGxlIHJhdyBkYXRh" }
Amazon S3 オブジェクト名の形式を設定する
Firehose がデータを Amazon S3 に配信する場合、S3 オブジェクトキー名は ＜評価プレフィックス><suffix> の形式に従います。サフィックスの形式は、<Firehose ストリーム名>-<Firehose ストリームバージョン>-<year>-<month>-<day>-<hour>-<minute>-<second>-<uuid><file 拡張> <Firehose ストリームバージョン＞ は 1 で始まり、Firehose ストリームの設定変更ごとに 1 ずつ増加します。Firehose ストリームの設定 (S3 バケットの名前、バッファリングヒント、圧縮、暗号化など) を変更できます。これを行うには、Firehose コンソールまたは UpdateDestination API オペレーションを使用します。
<evaluated prefix> の場合、Firehose はデフォルトの時間プレフィックスを の形式で追加しますYYYY/MM/dd/HH。このプレフィックスはバケットに論理階層を作成し、各スラッシュ (/) は階層にレベルを作成します。この構造を変更するには、実行時に評価される式を含むカスタムプレフィックスを指定します。カスタムプレフィックスを指定する方法については、「Amazon Simple Storage Service オブジェクトのカスタムプレフィックス」を参照してください。
デフォルトでは、タイムプレフィックスとサフィックスに使用されるタイムゾーンは UTC ですが、任意のタイムゾーンに変更できます。例えば、UTC の代わりに日本標準時を使用するには、 AWS Management Console または API パラメータ設定 (CustomTimeZone） でタイムゾーンをアジア/東京に設定できます。次のリストには、Firehose が S3 プレフィックス設定でサポートするタイムゾーンが含まれています。
以下は、Firehose が S3 プレフィックス設定でサポートするタイムゾーンのリストです。
<file extension> 以外のサフィックスフィールドを変更することはできません。データ形式の変換または圧縮を有効にすると、Firehose は設定に基づいてファイル拡張子を追加します。次の表に、Firehose によって追加されたデフォルトのファイル拡張子を示します。
| 構成 | ファイル拡張子 |
|---|---|
| データ形式の変換: Parquet | .parquet |
| データ形式の変換: ORC | .orc |
| 圧縮: Gzip | .gz |
| 圧縮: Zip | .zip |
| 圧縮: スナップ | .snappy |
| 圧縮: Hadoop-Snappy | .hsnappy |
Firehose コンソールまたは API で必要なファイル拡張子を指定することもできます。ファイル拡張子はピリオド (.) で始まり、0～9a～z!～_.*‘() の文字を使用できます。ファイル拡張子は 128 文字を超えることはできません。
注記
ファイル拡張子を指定すると、データ形式の変換または圧縮が有効になっているときに Firehose が追加するデフォルトのファイル拡張子が上書きされます。
サービスのインデックスロー OpenSearchテーションを設定する
OpenSearch サービス送信先では、、、NoRotation、、OneHourOneDayOneWeekまたは の 5 つのオプションのいずれかから時間ベースのインデックスローテーションオプションを指定できますOneMonth。
選択したローテーションオプションに応じて、Amazon Data Firehose は指定したインデックス名に UTC 到着タイムスタンプの一部を追加します。追加されたタイムスタンプは、それに応じてローテーションされます。次の例は、各インデックスローテーションオプションの結果のインデックス名を OpenSearch Service で示myindexしています。指定されたインデックス名は で、到着タイムスタンプは です2016-02-25T13:00:00Z。
| RotationPeriod | IndexName |
|---|---|
NoRotation |
myindex |
OneHour |
myindex-2016-02-25-13 |
OneDay |
myindex-2016-02-25 |
OneWeek |
myindex-2016-w08 |
OneMonth |
myindex-2016-02 |
注記
OneWeek オプションでは、Data Firehose は <YEAR>-w<WEEK NUMBER> の形式を使用してインデックスを自動作成します (たとえば、2020-w33)。ここで、週数は UTC 時間を使用し、次の米国の表記規則に従って計算されます。
-
週は日曜日から始まります
-
その年の最初の週は、今年の土曜日を含む最初の週です。
AWS アカウントとリージョン間の配信を理解する
Amazon Data Firehose は AWS 、アカウント間で HTTP エンドポイントの送信先へのデータ配信をサポートしています。Firehose ストリームと送信先として選択した HTTP エンドポイントは、異なる AWS アカウントに属している可能性があります。
Amazon Data Firehose は、 AWS リージョン間の HTTP エンドポイント送信先へのデータ配信もサポートしています。あるリージョンの Firehose ストリームから別の AWS リージョンの HTTP エンドポイントにデータを配信できます AWS 。Firehose ストリームから AWS リージョン外の HTTP エンドポイントの送信先にデータを配信することもできます。例えば、HTTP エンドポイント URL を目的の宛先に設定することで、独自のオンプレミスサーバーにデータを配信することもできます。これらのシナリオでは、配信コストに追加のデータ転送料金が加算されます。詳細については、「オンデマンド料金」ページの「データ転送
重複レコード
Amazon Data Firehose は、データ配信に at-least-once セマンティクスを使用します。データ配信がタイムアウトした場合など、状況によっては、Amazon Data Firehose による配信の再試行によって、元のデータ配信リクエストが最終的に処理された場合に重複が発生することがあります。これは、Amazon Data Firehose がサポートするすべての送信先タイプに適用されます。
Firehose ストリームの一時停止と再開
Firehose ストリームを設定すると、ストリームソースで利用可能なデータが送信先に継続的に配信されます。ストリームの送信先が一時的に使用できない状況 (計画的メンテナンスなど) になった場合は、データ配信を一時的に停止し、送信先が再び使用できるようになったら再開してください。この方法については次のセクションで紹介します。
重要
以下に説明する方法を使用してストリームを一時停止および再開すると、ストリームを再開した後、Amazon S3 のエラーバケットに配信されるレコードはほとんどなく、残りのストリームは引き続き送信先に配信されます。これは、このアプローチの既知の制限であり、複数回の再試行が失敗として追跡された後に送信先に以前に配信できなかった少数のレコードが原因で発生します。
Firehose が配信失敗を処理する方法を理解する
Firehose ストリームを設定する場合、 OpenSearch、Splunk、HTTP エンドポイントなどの多くの送信先に対して、配信に失敗したデータをバックアップできる S3 バケットも設定します。Firehose が配信に失敗した場合にデータをバックアップする方法の詳細については、「データ配信の失敗処理」を参照してください。配信に失敗したデータをバックアップできる S3 バケットへのアクセスを許可する方法の詳細については、Amazon S3先 へのアクセス権を Firehose に付与する」を参照してください。Firehose は、(a) ストリームの送信先にデータを配信できず、(b) 配信に失敗したデータをバックアップ S3 バケットに書き込めない場合、データが送信先に配信されるか、バックアップ S3 の場所に書き込まれるまで、ストリーム配信を効果的に一時停止します。
Firehose ストリームの一時停止
Firehose でストリーム配信を一時停止するには、まず Firehose が配信に失敗した S3 バックアップ場所に書き込むためのアクセス許可を削除します。例えば、 OpenSearch 送信先で Firehose ストリームを一時停止する場合は、アクセス許可を更新することでこれを行うことができます。詳細については、「パブリック OpenSearch サービスの送信先 へのアクセスを Firehose に許可する」を参照してください。
アクション s3:PutObject のアクセス許可 "Effect": "Allow" を削除し、アクション s3:PutObject のアクセス許可 Effect": "Deny" を、配信に失敗した場合に使用する S3 バケットに適用するステートメントを明示的に追加します。次に、ストリームの送信先をオフにするか (送信先 OpenSearch ドメインをオフにするなど）、Firehose が送信先に書き込むためのアクセス許可を削除します。他の送信先のアクセス許可を更新するには、「Amazon Data Firehose によるアクセスの制御」で送信先の セクションを確認してください。これら 2 つのアクションを完了すると、Firehose はストリームの配信を停止し、CloudWatch Firehose のメトリクスを使用してこれをモニタリングできます。
重要
Firehose でストリーム配信を一時停止する場合、ストリームのソース (Kinesis Data Streams や Managed Service for Kafka など) が、ストリーム配信が再開され、データが送信先に配信されるまでデータを保持するように設定されていることを確認する必要があります。ソースが DirectPUT の場合、Firehose はデータを 24 時間保持します。データ保持期間内にストリームを再開してデータを配信しなければ、データが失われる可能性があります。
Firehose ストリームの再開
配信を再開するには、まず送信先をオンにし、Firehose が送信先にストリームを配信するアクセス許可を持っていることを確認して、ストリームの送信先に以前に行った変更を元に戻します。次に、失敗した配信をバックアップする S3 バケットに適用されたアクセス許可に対して、以前に行った変更を元に戻します。つまり、アクション s3:PutObject のアクセス許可 "Effect": "Allow" を適用し、配信に失敗した場合に使用する S3 バケットに対するアクション s3:PutObject のアクセス許可 "Effect": "Deny" を削除します。最後に、CloudWatch Firehose のメトリクスを使用してモニタリングし、ストリームが送信先に配信されていることを確認します。エラーを表示およびトラブルシューティングするには、Firehose の Amazon CloudWatch Logs モニタリングを使用します。
