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 は配信ストリームのバッファリング設定に基づいて複数の受信レコードを連結します。次に、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 OpenSearch Service デベロッパーガイド」の「サービス設定の詳細オプション」を参照してください。
Splunk へのデータ配信の場合、Amazon Data Firehose は送信するバイトを連結します。データを改行文字などで区切る場合は、自分で挿入する必要があります。Splunk がそのような区切り記号を解析するように設定されていることを確認してください。
サポートされているサードパーティーサービスプロバイダーが所有する HTTP エンドポイントにデータを配信する場合、統合された Amazon Lambda サービスを使用して、受信レコードをサービスプロバイダーの統合が想定している形式に一致する形式に変換する関数を作成できます。受信したレコード形式の詳細については、送信先に HTTP エンドポイントを選択したサードパーティーサービスプロバイダーにお問い合わせください。
データ配信の頻度
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 サービスと OpenSearchサーバーレス
-
OpenSearch サービスおよび OpenSearch サーバーレスの送信先では、配信ストリームの作成時に再試行期間 (0～7200 秒) を指定できます。
OpenSearch サービスクラスターまたは OpenSearch Serverless コレクションへのデータ配信は、いくつかの理由で失敗することがあります。例えば、Firehose ストリームの誤った OpenSearch サービスクラスターまたは OpenSearch サーバーレスコレクション設定、メンテナンス中の OpenSearch サービスクラスターまたは OpenSearch サーバーレスコレクション、ネットワーク障害、または同様のイベントがある可能性があります。これらの条件下では、Amazon Data Firehose は指定された期間にわたって再試行し、その特定のインデックスリクエストをスキップします。スキップされたドキュメントは
AmazonOpenSearchService_failed/フォルダーの S3 バケットに配信され、手動のバックフィルに使用できます。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 サーバーレスの場合、各ドキュメントの 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" }
Amazon S3 オブジェクト名の形式
Firehose が Amazon S3 にデータを配信する場合、S3 オブジェクトキー名は <evaluated prefixTAKsuffix> という形式に従います。ここで、サフィックスの形式は <delivery stream name>-<delivery stream version>-<year>-<month>-<day>-<hour>-<minute>-<second>-<uidTAKfile extension> <delivery stream version> は 1 から始まり、Firehose 配信ストリームの設定変更ごとに 1 ずつ増加します。配信ストリーム設定 (例: S3 バケットの名前、バッファリングのヒント、圧縮、暗号化) は変更できます。これを行うには、Firehose コンソールまたは UpdateDestination API オペレーションを使用します。
<evaluated prefix> の場合、Firehose はデフォルトの時間プレフィックスを 形式で追加しますYYYY/MM/dd/HH。このプレフィックスは、バケットに論理階層を作成します。各スラッシュ (/) は階層にレベルを作成します。実行時に評価される式を含むカスタムプレフィックスを指定することで、この構造を変更できます。カスタムプレフィックスを指定する方法については、「Amazon Simple Storage Service オブジェクトのカスタムプレフィックス」を参照してください。
デフォルトでは、時間プレフィックスに使用されるタイムゾーンは UTC ですが、必要なタイムゾーンに変更できます。例えば、UTC の代わりに日本標準時を使用する場合は、 AWS Management Console または API パラメータ設定 (CustomTimeZone） でタイムゾーンをアジア/東京に設定できます。次のリストには、Firehose の S3 プレフィックス設定でサポートされているタイムゾーンが含まれています。
<file extension> 以外のサフィックスフィールドは変更できません。データ形式の変換または圧縮を有効にすると、Firehose は設定に基づいてファイル拡張子を追加します。次の表は、Firehose によって追加されたデフォルトのファイル拡張子について説明しています。
| 構成 | ファイル拡張子 |
|---|---|
| データ形式の変換: Parquet | .parquet |
| データ形式の変換: ORC | .orc |
| 圧縮: Gzip | .gz |
| 圧縮: Zip | .zip |
| 圧縮: Snappy | .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 アカウント間および AWS リージョン間の HTTP エンドポイント送信先の配信
Amazon Data Firehose は、 AWS アカウント間の HTTP エンドポイント送信先へのデータ配信をサポートします。Amazon Data Firehose Firehose ストリームと送信先として選択した HTTP エンドポイントは、異なる AWS アカウントに存在する可能性があります。
Amazon Data Firehose は、 AWS リージョン間の HTTP エンドポイント送信先へのデータ配信もサポートしています。ある AWS リージョンの Firehose ストリームから別の AWS リージョンの HTTP エンドポイントにデータを配信できます。Firehose ストリームから AWS リージョン外の HTTP エンドポイントの送信先にデータを配信することもできます。例えば、HTTP エンドポイント URL を目的の宛先に設定することで、独自のオンプレミスサーバーにデータを配信できます。これらのシナリオでは、配信コストに追加のデータ転送料金が加算されます。詳細については、「オンデマンド料金」ページの「データ転送
重複レコード
Amazon Data Firehose は、データ配信に at-least-once セマンティクスを使用します。データ配信がタイムアウトした場合など、状況によっては、元のデータ配信リクエストが最終的に通過すると、Amazon Data Firehose による配信の再試行が重複する可能性があります。これは、Amazon Data Firehose がサポートするすべての送信先タイプに適用されます。
Firehose 配信ストリームを一時停止および再開する方法
Firehose で配信ストリームを設定すると、ストリームソースで使用可能なデータが送信先に継続的に配信されます。ストリームの送信先が一時的に使用できない状況 (計画的メンテナンスなど) になった場合は、データ配信を一時的に停止し、送信先が再び使用できるようになったら再開してください。この方法については次のセクションで紹介します。
重要
以下に説明する方法を使用してストリームを一時停止および再開すると、ストリームを再開した後、残りのストリームが送信先に配信され続けている間、Amazon S3 のエラーバケットに配信されるレコードが少なくなることがわかります。これは アプローチの既知の制限であり、複数回の再試行後に送信先に以前に配信できなかった少数のレコードが失敗として追跡されるためです。
Firehose が配信エラーを処理する方法を理解する
Firehose で配信ストリームを設定する場合、、Splunk OpenSearch、HTTP エンドポイントなど、多くの送信先に対して、配信に失敗したデータをバックアップできる S3 バケットも設定します。配信に失敗した場合に Firehose がデータをバックアップする方法の詳細については、「データ配信失敗の処理」を参照してください。配信に失敗したデータをバックアップできる S3 バケットへのアクセスを許可する方法の詳細については、「Amazon S3 の送信先へのアクセス権を Firehose に付与する」を参照してください。Firehose は、(a) ストリームの送信先にデータを配信できず、(b) 配信に失敗したためにバックアップ S3 バケットにデータを書き込めない場合、ストリーム配信を一時停止して、そのデータを送信先に配信するか、バックアップ S3 の場所に書き込むことができます。
Firehose 配信ストリームの一時停止
Firehose でストリーム配信を一時停止するには、まず、Firehose が配信に失敗した S3 バックアップ場所に書き込むためのアクセス許可を削除します。例えば、 OpenSearch 送信先で配信ストリームを一時停止する場合は、アクセス許可を更新することでこれを行うことができます。詳細については、「Grant Firehose Access to a Public OpenSearch Service Destination」を参照してください。
アクション 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 モニタリングを使用します。
