Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

データ配信の失敗を処理する

フォーカスモード
データ配信の失敗を処理する - Amazon Data Firehose

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Data Firehose の宛先ごとに、独自のデータ配信の失敗処理があります。

Firehose ストリームを設定するときは、OpenSearch、Splunk、HTTP エンドポイントなどの多くの宛先のために、配信に失敗したデータをバックアップできる S3 バケットも設定します。Firehose が配信に失敗した場合にデータをバックアップする方法の詳細については、このページの関連する宛先セクションを参照してください。配信に失敗したデータをバックアップできる S3 バケットへのアクセスを許可する方法については「Amazon S3 の宛先へのアクセスを Firehose に付与する」を参照してください。Firehose が、(a) ストリーム宛先へのデータ配信に失敗し、(b) 配信に失敗したためにバックアップ S3 バケットにデータを書き込みできない場合は、配信先へのデータ配信またはバックアップ用の S3 へのデータ書き込みが可能になるまで、ストリーム配信を効果的に一時停止します。

Amazon S3

S3 バケットへのデータ配信は、さまざまな理由で失敗する場合があります。例えば、バケットが存在しない、Amazon Data Firehose が引き受ける IAM ロールにバケットへのアクセスがない、ネットワークの障害、類似したイベントなどの理由があります。そのような状況では、Amazon Data Firehose は配信が成功するまで最大 24 時間にわたり再試行し続けます。Amazon Data Firehose の最大データ保存時間は 24 時間です。データ配信が 24 時間を超えて失敗した場合、データは失われます。

S3 バケットへのデータ配信は、次のようなさまざまな理由で失敗する可能性があります。

  • バケットが存在しなくなりました。

  • Amazon Data Firehose が引き受ける IAM ロールは、バケットにアクセスできません。

  • ネットワークの問題。

  • HTTP 500 やその他の API 障害などの S3 エラー。

このような場合、Amazon Data Firehose は配信を再試行します。

  • DirectPut ソース: 再試行は最大 24 時間続きます。

  • Kinesis Data Streams または Amazon MSK ソース: 再試行は、ストリームで定義された保持ポリシーまで無期限に続行されます。

Amazon Data Firehose は、Lambda 処理またはparquet 変換が失敗した場合にのみ、失敗したレコードを S3 エラーバケットに配信します。その他の障害シナリオでは、保持期間に達するまで S3 の再試行が継続的に試行されます。Firehose がレコードを S3 に正常に配信すると、S3 オブジェクトファイルが作成され、部分的なレコード障害が発生した場合は、配信を自動的に再試行し、正常に処理されたレコードで同じ S3 オブジェクトファイルを更新します。

Amazon Redshift

Amazon Redshift が宛先の場合、Firehose ストリームの作成時に、再試行の期間 (0~7200 秒) を指定できます。

Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループへのデータ配信は、いくつかの理由で失敗する場合があります。例えば、Firehose ストリームのクラスター設定が正しくない、クラスターまたはワークグループがメンテナンス中である、ネットワークの障害が発生している場合などです。そのような状況では、Amazon Data Firehose は指定された期間にわたって、その特定のバッチの Amazon S3 オブジェクトをスキップします。スキップされたオブジェクトの情報は、マニフェストファイルとして errors/ フォルダーの S3 バケットに配信されます。この情報は手動のバックフィルに使用できます。データを手動でマニフェストファイルにコピーする方法の詳細については、「マニフェストを使用し、データファイルを指定する」を参照してください。

Amazon OpenSearch Service と OpenSearch Serverless

OpenSearch Service と OpenSearch Serverless が宛先である場合、Firehose ストリームの作成中に、再試行の期間 (0~7,200 秒) を指定できます。

OpenSearch Service クラスターまたは OpenSearch Serverless コレクションへのデータ配信は、いくつかの理由で失敗する場合があります。例えば、Firehose ストリームの OpenSearch Service クラスターまたは OpenSearch Serverless コレクションの設定が正しくない、OpenSearch Service クラスターまたは OpenSearch Serverless コレクションがメンテナンス中である、ネットワークの障害が発生している、または同様のイベントが発生している場合などです。そのような状況では、Amazon Data Firehose は指定された期間にわたって再試行してから、その特定のインデックスリクエストをスキップします。スキップされたドキュメントは AmazonOpenSearchService_failed/ フォルダーの S3 バケットに配信され、手動のバックフィルに使用できます。

OpenSearch Service では、各ドキュメントは以下の 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~7,200 秒) を指定できます。再試行期間のデフォルト値は 60 秒です。

Snowflake テーブルへのデータ配信は、Snowflake の宛先設定の誤り、Snowflake の停止、ネットワーク障害など、いくつかの理由で失敗する可能性があります。再試行ポリシーは、取得不能なエラーには適用されません。例えば、JSON ペイロードに余分な列があったが、テーブルにはないために、Snowflake がその JSON ペイロードを拒否した場合、Firehose は再配信を試行しません。代わりに、JSON ペイロードの問題を理由とするすべての挿入失敗のバックアップを、S3 エラーバケットに作成します。

同様に、ロール、テーブル、またはデータベースが正しくないために配信に失敗した場合、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" }
プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.