翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Data Firehose でのデータ配信を理解する
Firehose ストリームにデータを送信すると、そのデータは選択した送信先に自動的に配信されます。次の表は、さまざまな宛先へのデータ配信について説明するものです。
| 目的地 | Details |
| --- | --- |
| Amazon S3 | Amazon S3 へのデータ配信の場合、Firehose は、Firehose ストリームのバッファリング設定に基づいて、複数の着信レコードを連結します。次に、Amazon S3 オブジェクトとしてレコードを Amazon S3 に配信します。デフォルトでは、Firehose は区切り文字なしでデータを連結します。レコード間に改行区切り文字を使用する場合は、[[Firehose コンソール設定]](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3) または [[API パラメータ]](https://docs.aws.amazon.com/firehose/latest/APIReference/API_Processor.html) でこの機能を有効にすることで、改行区切り文字を追加できます。Firehose と Amazon S3 の宛先間のデータ配信は TLS (HTTPS) で暗号化されます。 |
| Amazon Redshift | 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 コマンドのデータ形式パラメータ](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-format.html)」を参照してください。 |
| OpenSearch Service と OpenSearch Serverless | OpenSearch Service と OpenSearch Serverless へのデータ配信では、Amazon Data Firehose は Firehose ストリームのバッファリング設定に基づいて着信レコードをバッファリングします。次に、OpenSearch Service または OpenSearch Serverless への一括リクエストを生成して、OpenSearch Service クラスターまたは OpenSearch Serverless コレクションに複数のレコードのインデックスを作成します。Amazon Data Firehose に送信する前に、レコードが UTF-8 でエンコードされ、1 行の JSON オブジェクトにフラット化されていることを確認します。また、1 秒ごとに設定される明示的なインデックスを使用して一括リクエストを行うには、OpenSearch Service クラスターの rest.action.multi.allow\$1explicit\$1index オプションを true (デフォルト) に設定する必要があります。詳細については、「Amazon OpenSearch Service デベロッパーガイド」の「[OpenSearch Service Configure Advanced Options](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-advanced-options)」を参照してください。 |
| Splunk | Splunk へのデータ配信の場合は、Amazon Data Firehose は送信するバイト数を連結します。データを改行文字などで区切る場合は、自分で挿入する必要があります。Splunk がそのような区切り記号を解析するように設定されていることを確認してください。S3 エラーバケット (S3 バックアップ) に配信されたデータを Splunk にリドライブするには、[Splunk ドキュメント](https://www.splunk.com/en_us/blog/tips-and-tricks/aws-technical-add-on-simplifying-error-data-re-ingestion.html)に記載されているステップに従います。 |
| HTTP エンドポイント | サポートされているサードパーティーサービスプロバイダーが所有する HTTP エンドポイントへのデータ配信のために、統合された Amazon Lambda サービスを使用して、着信レコードをサービスプロバイダーの統合が想定している形式に一致する形式に変換する関数を作成できます。受信したレコード形式の詳細については、送信先に HTTP エンドポイントを選択したサードパーティーサービスプロバイダーにお問い合わせください。 |
| Snowflake | Snowflake へのデータ配信のために、Amazon Data Firehose は内部的に 1 秒間データをバッファリングし、Snowflake ストリーミング API オペレーションを使用して Snowflake にデータを挿入します。デフォルトでは、挿入したレコードは 1 秒ごとにフラッシュされ、Snowflake テーブルにコミットされます。挿入呼び出しを実行すると、Firehose は、データが Snowflake にコミットされるまでにかかる時間を測定する CloudWatch メトリクスを出力します。Firehose は現在、レコードペイロードとして単一の JSON 項目のみをサポートしており、JSON 配列をサポートしていません。入力ペイロードが有効な JSON オブジェクトであり、余分な二重引用符、引用符、エスケープ文字なしで適切に形成されていることを確認してください。 |
Firehose の宛先ごとに、独自のデータ配信の頻度があります。詳細については、「[バッファリングのヒントを設定する](create-configure-backup.md#buffering-hints)」を参照してください。
**重複レコード**
Amazon Data Firehose は、データ配信に最低 1 回セマンティクスを使用します。データ配信がタイムアウトした場合など、状況によっては、元のデータ配信リクエストが最終的に通過すると、Amazon Data Firehose による配信の再試行が重複する可能性があります。これは、Amazon S3 送信先、Apache Iceberg テーブル、および Snowflake 送信先を除く、Amazon Data Firehose がサポートするすべての送信先タイプに適用されます。
**Topics**
+ [AWS アカウントとリージョン間の配信を理解する](across.md)
+ [HTTP エンドポイント配信リクエストとレスポンスの仕様を理解する](httpdeliveryrequestresponse.md)
+ [データ配信の失敗を処理する](retry.md)
+ [Amazon S3 オブジェクト名の形式を設定する](s3-object-name.md)
+ [OpenSearch Service のインデックスローテーションを設定する](es-index-rotation.md)
+ [データ配信を一時停止および再開する](pause-restart-stream.md)
# AWS アカウントとリージョン間の配信を理解する
Amazon Data Firehose は AWS 、アカウント間の HTTP エンドポイント送信先へのデータ配信をサポートしています。Firehose ストリームと送信先として選択した HTTP エンドポイントは、異なる AWS アカウントに属することができます。
Amazon Data Firehose は、 AWS リージョン間の HTTP エンドポイント送信先へのデータ配信もサポートしています。ある AWS リージョンの Firehose ストリームから別の AWS リージョンの HTTP エンドポイントにデータを配信できます。Firehose ストリームから AWS リージョン外の HTTP エンドポイント宛先にデータを配信することもできます。たとえば、HTTP エンドポイント URL を目的の宛先に設定することで、独自のオンプレミスサーバーにデータを配信できます。これらのシナリオでは、配信コストに追加のデータ転送料金が加算されます。詳細については、「オンデマンド料金」ページの「[データ転送](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)」セクションを参照してください。
# HTTP エンドポイント配信リクエストとレスポンスの仕様を理解する
Amazon Data Firehose がカスタム HTTP エンドポイントに正常にデータを配信するには、これらのエンドポイントがリクエストを受け入れ、特定の Amazon Data Firehose リクエストおよびレスポンス形式を使用してレスポンスを送信する必要があります。このセクションでは、Amazon Data Firehose サービスがカスタム HTTP エンドポイントに送信する HTTP リクエストの形式の仕様と、Amazon Data Firehose サービスが期待する HTTP レスポンスの形式の仕様について説明します。HTTP エンドポイントは、Amazon Data Firehose がそのリクエストをタイムアウトする前の 3 分以内にリクエストに応答します。Amazon Data Firehose は、適切な形式に従わないレスポンスを配信の失敗として扱います。
## リクエストの形式
**パスと URL パラメータ**
これらは、単一の URL フィールドの一部として直接設定されます。Amazon Data Firehose は、変更なしに設定されたとおりにそれらを送信します。https 送信先のみがサポートされます。URL 制限は、配信ストリーム設定時に適用されます。
現在、HTTP エンドポイントデータ配信では、ポート 443 のみがサポートされています。
**HTTP ヘッダー - X-Amz-Firehose-Protocol-Version**
このヘッダーは、リクエスト/レスポンス形式のバージョンを示すために使用されます。現在バージョンは 1.0 のみです。
**HTTP ヘッダー - X-Amz-Firehose-Request-Id**
このヘッダーの値は不透明な GUID であり、デバッグや重複排除に使用できます。エンドポイントの実装では、成功したリクエストと失敗したリクエストの両方について、可能であれば、このヘッダーの値をログ記録する必要があります。リクエスト ID は、同じリクエストを複数回試行しても同じに保たれます。
**HTTP ヘッダー - Content-Type**
Content-Type ヘッダーの値は常に `application/json` です。
**HTTP ヘッダー - Content-Encoding**
Firehose ストリームは、リクエストを送信するときに GZIP を使用して本文を圧縮するように設定できます。この圧縮を有効にすると、標準的な方法に従って Content-Encoding ヘッダーの値は gzip に設定されます。圧縮が有効にされない場合、Content-Encoding ヘッダーはまったく存在しません。
**HTTP ヘッダー - Content-Length**
これは標準的な方法で使用されます。
**HTTP ヘッダー-X-Amz-Firehose-Source-Arn:**
ASCII 文字列形式で表される Firehose ストリームの ARN。ARN は、リージョン、 AWS アカウント ID、ストリーム名をエンコードします。例えば、`arn:aws:firehose:us-east-1:123456789:deliverystream/testStream`。
**HTTP ヘッダー - X-Amz-Firehose-Access-Key**
このヘッダーは API キーまたはその他の認証情報を運びます。delivery-stream を作成または更新するときに、API キー (別名、認可トークン) を作成または更新できます。Amazon Data Firehose では、アクセスキーのサイズが 4096 バイトに制限されます。Amazon Data Firehose は、このキーを一切解釈しようとしません。設定されたキーは、このヘッダーの値に逐語的にコピーされます。ただし、Secrets Manager を使用してキーを設定する場合、シークレットは特定の JSON オブジェクト形式 `{"api_key": "..."}` に従う必要があります。
コンテンツは任意であり、JWT トークンまたは ACCESS\$1KEY を表すことができます。エンドポイントで複数フィールドの認証情報 (ユーザー名やパスワードなど) が必要な場合は、すべてのフィールドの値を、エンドポイントが認識できる形式 (JSON または CSV) で 1 つのアクセスキー内にまとめて保存する必要があります。元の内容がバイナリである場合、このフィールドは base-64 でエンコードできます。Amazon Data Firehose は、設定された値を変更やエンコードせず、コンテンツをそのまま使用します。
**HTTP ヘッダー - X-Amz-Firehose-Common-Attributes**
このヘッダーは、リクエスト全体やリクエスト内のすべてのレコードに関連する共通の属性 (メタデータ) を保持します。これらは、Firehose ストリームの作成時にユーザーが直接設定します。この属性の値は、次のスキーマを使用して JSON オブジェクトとしてエンコードされます。
```
"$schema": http://json-schema.org/draft-07/schema#
properties:
commonAttributes:
type: object
minProperties: 0
maxProperties: 50
patternProperties:
"^.{1,256}$":
type: string
minLength: 0
maxLength: 1024
```
例を示します。
```
"commonAttributes": {
"deployment -context": "pre-prod-gamma",
"device-types": ""
}
```
**本文 - 最大サイズ**
最大本文サイズはユーザーによって設定され、圧縮前に最大 64 MiB まで設定できます。
**本文 - スキーマ**
本文には、次の JSON スキーマ (YAML で記述) を持つ 1 つの JSON ドキュメントが含まれます。
```
"$schema": http://json-schema.org/draft-07/schema#
title: FirehoseCustomHttpsEndpointRequest
description: >
The request body that the Firehose service sends to
custom HTTPS endpoints.
type: object
properties:
requestId:
description: >
Same as the value in the X-Amz-Firehose-Request-Id header,
duplicated here for convenience.
type: string
timestamp:
description: >
The timestamp (milliseconds since epoch) at which the Firehose
server generated this request.
type: integer
records:
description: >
The actual records of the Firehose stream, carrying
the customer data.
type: array
minItems: 1
maxItems: 10000
items:
type: object
properties:
data:
description: >
The data of this record, in Base64. Note that empty
records are permitted in Firehose. The maximum allowed
size of the data, before Base64 encoding, is 1024000
bytes; the maximum length of this field is therefore
1365336 chars.
type: string
minLength: 0
maxLength: 1365336
required:
- requestId
- records
```
例を示します。
```
{
"requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f",
"timestamp": 1578090901599
"records": [
{
"data": "aGVsbG8="
},
{
"data": "aGVsbG8gd29ybGQ="
}
]
}
```
## レスポンスの形式
**エラー時のデフォルトの動作**
レスポンスが以下の要件に適合しない場合、Firehose サーバーは本文なしで 500 ステータスコードがあるかのように処理します。
**ステータスコード**
HTTP ステータスコードは 2XX、4XX、または 5XX でなければなりませんす。
Amazon Data Firehose サーバーはリダイレクト (3XX ステータスコード) に従いません。HTTP/EP へのレコードの正常な配信と見なされるのは、レスポンスコード 200 のみです。レスポンスコード 413 (サイズを超過) は永続的な障害と見なされ、レコードバッチが設定されている場合、エラーバケットに送信されません。その他のすべてのレスポンスコードは、再試行可能なエラーとみなされ、後で説明するバックオフ再試行アルゴリズムの対象となります。
**ヘッダー - コンテンツタイプ**
許容できるコンテンツタイプは application/json です。
**HTTP ヘッダー - Content-Encoding**
Content-Encoding は使用しないでください。本文は圧縮解除しなければなりません。
**HTTP ヘッダー - Content-Length**
Content-Length ヘッダーは、レスポンスに本文がある場合、存在しなければなりません。
**本文 - 最大サイズ**
レスポンス本文のサイズは 1 MiB 以下である必要があります。
```
"$schema": http://json-schema.org/draft-07/schema#
title: FirehoseCustomHttpsEndpointResponse
description: >
The response body that the Firehose service sends to
custom HTTPS endpoints.
type: object
properties:
requestId:
description: >
Must match the requestId in the request.
type: string
timestamp:
description: >
The timestamp (milliseconds since epoch) at which the
server processed this request.
type: integer
errorMessage:
description: >
For failed requests, a message explaining the failure.
If a request fails after exhausting all retries, the last
Instance of the error message is copied to error output
S3 bucket if configured.
type: string
minLength: 0
maxLength: 8192
required:
- requestId
- timestamp
```
例を示します。
```
Failure Case (HTTP Response Code 4xx or 5xx)
{
"requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f",
"timestamp": "1578090903599",
"errorMessage": "Unable to deliver records due to unknown error."
}
Success case (HTTP Response Code 200)
{
"requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f",
"timestamp": 1578090903599
}
```
**エラーレスポンスの処理**
すべてエラーの場合、Amazon Data Firehose サーバーは指数バックオフアルゴリズムを使用して同じレコードのバッチの配信を再試行します。再試行は、ジッタ係数 (15%) の初期バックオフ時間 (1 秒) を使用してバックオフされ、その後の各再試行はジッタを追加した式 (initial-backoff-time \$1 (multiplier(2) ^ retry\$1count)) を使用してバックオフされます。バックオフ時間は最大 2 分間隔で制限されます。例えば、「n」回目の再試行では、バックオフ時間は = MAX(120, 2^n) \$1 random(0.85, 1.15) となります。
前の数式で指定されたパラメータは変更の対象となります。エクスポネンシャルバックオフアルゴリズムで使用される正確な初期バックオフ時間、最大バックオフ時間、乗数、ジッターの割合については、 AWS Firehose のドキュメントを参照してください。
その後の再試行ごとに、レコードが配信されるアクセスキーや宛先が、Firehose ストリームの更新された設定に基づいて変更される場合があります。Amazon Data Firehose サービスは、再試行全体で同じリクエスト ID をベストエフォート方式で使用します。この最後の機能は、HTTP エンドポイントサーバーによる重複排除の目的で使用できます。許容される最大時間 (Firehose ストリーム設定に基づく) 後にリクエストが配信されない場合は、ストリーム設定に基づいてレコードのバッチをオプションでエラーバケットに配信できます。
## 例
CWLog ソースリクエストの例。
```
{
"requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f",
"timestamp": 1578090901599,
"records": [
{
"data": {
"messageType": "DATA_MESSAGE",
"owner": "123456789012",
"logGroup": "log_group_name",
"logStream": "log_stream_name",
"subscriptionFilters": [
"subscription_filter_name"
],
"logEvents": [
{
"id": "0123456789012345678901234567890123456789012345",
"timestamp": 1510109208016,
"message": "log message 1"
},
{
"id": "0123456789012345678901234567890123456789012345",
"timestamp": 1510109208017,
"message": "log message 2"
}
]
}
}
]
}
```
# データ配信の失敗を処理する
Amazon Data Firehose の宛先ごとに、独自のデータ配信の失敗処理があります。
Firehose ストリームを設定するときは、OpenSearch、Splunk、HTTP エンドポイントなどの多くの宛先のために、配信に失敗したデータをバックアップできる S3 バケットも設定します。Firehose が配信に失敗した場合にデータをバックアップする方法の詳細については、このページの関連する宛先セクションを参照してください。配信に失敗したデータをバックアップできる S3 バケットへのアクセスを許可する方法については「[Amazon S3 の宛先へのアクセスを Firehose に付与する](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3)」を参照してください。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 ロールにバケットへのアクセス権がない。
+ ネットワークに問題がある。
+ S3 エラー (HTTP 500 やその他の API 障害など) が発生した。
以下の場合、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 バケットに配信されます。この情報は手動のバックフィルに使用できます。データを手動でマニフェストファイルにコピーする方法の詳細については、「[マニフェストを使用し、データファイルを指定する](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-files-using-manifest.html)」を参照してください。
## 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 データ配信エラー](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-splunk-errors)」を参照してください。再試行期間が 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 エンドポイントデータ配信エラー](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-http-errors)」を参照してください。
以下に、エラーレコードの例を示します。
```
{
"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"
}
```
# Amazon S3 オブジェクト名の形式を設定する
Firehose がデータを Amazon S3 に配信する場合、S3 オブジェクトキー名は *<評価されたプレフィックス><サフィックス>* の形式に従います (ここで、サフィックスの形式は *--<年>-<月>-<日>-<時>-<分>-<秒>-<ファイル拡張子> *です)。これは 1 から始まり、Firehose ストリームの設定が変更されるたびに 1 ずつ増加します。Firehose ストリーム設定 (例: S3 バケットの名前、バッファリングのヒント、圧縮、暗号化) は変更できます。これを行うには、Firehose コンソールまたは [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html) API オペレーションを使用します。
** の場合、Firehose はデフォルトの時刻プレフィックスを `YYYY/MM/dd/HH` の形式で追加します。このプレフィックスはバケットで論理的階層を作成します。それぞれのフォワードスラッシュ (/) は階層でレベルを作成します。この構造は、実行時に評価される式を含むカスタムプレフィックスを指定することで変更できます。カスタムプレフィックスを指定する方法については、「[Amazon Simple Storage Service オブジェクトのカスタムプレフィックス](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html)」を参照してください。
デフォルトでは、時刻プレフィックスおよびサフィックスで使用されるタイムゾーンは UTC ですが、任意のタイムゾーンに変更できます。たとえば、UTC の代わりに日本標準時を使用するには、 AWS マネジメントコンソール または [API パラメータ設定 (CustomTimeZone)](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html) でタイムゾーンをアジア/東京に設定できます。次のリストには、Firehose が S3 プレフィックス設定のためにサポートするタイムゾーンが含まれています。
## サポートされているタイムゾーン
Firehose が S3 プレフィックス設定のためにサポートするタイムゾーンのリストを次に示します。
------
#### [ Africa ]
```
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
Africa/Asmera
Africa/Bangui
Africa/Banjul
Africa/Bissau
Africa/Blantyre
Africa/Bujumbura
Africa/Cairo
Africa/Casablanca
Africa/Conakry
Africa/Dakar
Africa/Dar_es_Salaam
Africa/Djibouti
Africa/Douala
Africa/Freetown
Africa/Gaborone
Africa/Harare
Africa/Johannesburg
Africa/Kampala
Africa/Khartoum
Africa/Kigali
Africa/Kinshasa
Africa/Lagos
Africa/Libreville
Africa/Lome
Africa/Luanda
Africa/Lubumbashi
Africa/Lusaka
Africa/Malabo
Africa/Maputo
Africa/Maseru
Africa/Mbabane
Africa/Mogadishu
Africa/Monrovia
Africa/Nairobi
Africa/Ndjamena
Africa/Niamey
Africa/Nouakchott
Africa/Ouagadougou
Africa/Porto-Novo
Africa/Sao_Tome
Africa/Timbuktu
Africa/Tripoli
Africa/Tunis
Africa/Windhoek
```
------
#### [ America ]
```
America/Adak
America/Anchorage
America/Anguilla
America/Antigua
America/Aruba
America/Asuncion
America/Barbados
America/Belize
America/Bogota
America/Buenos_Aires
America/Caracas
America/Cayenne
America/Cayman
America/Chicago
America/Costa_Rica
America/Cuiaba
America/Curacao
America/Dawson_Creek
America/Denver
America/Dominica
America/Edmonton
America/El_Salvador
America/Fortaleza
America/Godthab
America/Grand_Turk
America/Grenada
America/Guadeloupe
America/Guatemala
America/Guayaquil
America/Guyana
America/Halifax
America/Havana
America/Indianapolis
America/Jamaica
America/La_Paz
America/Lima
America/Los_Angeles
America/Managua
America/Manaus
America/Martinique
America/Mazatlan
America/Mexico_City
America/Miquelon
America/Montevideo
America/Montreal
America/Montserrat
America/Nassau
America/New_York
America/Noronha
America/Panama
America/Paramaribo
America/Phoenix
America/Port_of_Spain
America/Port-au-Prince
America/Porto_Acre
America/Puerto_Rico
America/Regina
America/Rio_Branco
America/Santiago
America/Santo_Domingo
America/Sao_Paulo
America/Scoresbysund
America/St_Johns
America/St_Kitts
America/St_Lucia
America/St_Thomas
America/St_Vincent
America/Tegucigalpa
America/Thule
America/Tijuana
America/Tortola
America/Vancouver
America/Winnipeg
```
------
#### [ Antarctica ]
```
Antarctica/Casey
Antarctica/DumontDUrville
Antarctica/Mawson
Antarctica/McMurdo
Antarctica/Palmer
```
------
#### [ Asia ]
```
Asia/Aden
Asia/Almaty
Asia/Amman
Asia/Anadyr
Asia/Aqtau
Asia/Aqtobe
Asia/Ashgabat
Asia/Ashkhabad
Asia/Baghdad
Asia/Bahrain
Asia/Baku
Asia/Bangkok
Asia/Beirut
Asia/Bishkek
Asia/Brunei
Asia/Calcutta
Asia/Colombo
Asia/Dacca
Asia/Damascus
Asia/Dhaka
Asia/Dubai
Asia/Dushanbe
Asia/Hong_Kong
Asia/Irkutsk
Asia/Jakarta
Asia/Jayapura
Asia/Jerusalem
Asia/Kabul
Asia/Kamchatka
Asia/Karachi
Asia/Katmandu
Asia/Krasnoyarsk
Asia/Kuala_Lumpur
Asia/Kuwait
Asia/Macao
Asia/Magadan
Asia/Manila
Asia/Muscat
Asia/Nicosia
Asia/Novosibirsk
Asia/Phnom_Penh
Asia/Pyongyang
Asia/Qatar
Asia/Rangoon
Asia/Riyadh
Asia/Saigon
Asia/Seoul
Asia/Shanghai
Asia/Singapore
Asia/Taipei
Asia/Tashkent
Asia/Tbilisi
Asia/Tehran
Asia/Thimbu
Asia/Thimphu
Asia/Tokyo
Asia/Ujung_Pandang
Asia/Ulaanbaatar
Asia/Ulan_Bator
Asia/Vientiane
Asia/Vladivostok
Asia/Yakutsk
Asia/Yekaterinburg
Asia/Yerevan
```
------
#### [ Atlantic ]
```
Atlantic/Azores
Atlantic/Bermuda
Atlantic/Canary
Atlantic/Cape_Verde
Atlantic/Faeroe
Atlantic/Jan_Mayen
Atlantic/Reykjavik
Atlantic/South_Georgia
Atlantic/St_Helena
Atlantic/Stanley
```
------
#### [ Australia ]
```
Australia/Adelaide
Australia/Brisbane
Australia/Broken_Hill
Australia/Darwin
Australia/Hobart
Australia/Lord_Howe
Australia/Perth
Australia/Sydney
```
------
#### [ Europe ]
```
Europe/Amsterdam
Europe/Andorra
Europe/Athens
Europe/Belgrade
Europe/Berlin
Europe/Brussels
Europe/Bucharest
Europe/Budapest
Europe/Chisinau
Europe/Copenhagen
Europe/Dublin
Europe/Gibraltar
Europe/Helsinki
Europe/Istanbul
Europe/Kaliningrad
Europe/Kiev
Europe/Lisbon
Europe/London
Europe/Luxembourg
Europe/Madrid
Europe/Malta
Europe/Minsk
Europe/Monaco
Europe/Moscow
Europe/Oslo
Europe/Paris
Europe/Prague
Europe/Riga
Europe/Rome
Europe/Samara
Europe/Simferopol
Europe/Sofia
Europe/Stockholm
Europe/Tallinn
Europe/Tirane
Europe/Vaduz
Europe/Vienna
Europe/Vilnius
Europe/Warsaw
Europe/Zurich
```
------
#### [ Indian ]
```
Indian/Antananarivo
Indian/Chagos
Indian/Christmas
Indian/Cocos
Indian/Comoro
Indian/Kerguelen
Indian/Mahe
Indian/Maldives
Indian/Mauritius
Indian/Mayotte
Indian/Reunion
```
------
#### [ Pacific ]
```
Pacific/Apia
Pacific/Auckland
Pacific/Chatham
Pacific/Easter
Pacific/Efate
Pacific/Enderbury
Pacific/Fakaofo
Pacific/Fiji
Pacific/Funafuti
Pacific/Galapagos
Pacific/Gambier
Pacific/Guadalcanal
Pacific/Guam
Pacific/Honolulu
Pacific/Kiritimati
Pacific/Kosrae
Pacific/Majuro
Pacific/Marquesas
Pacific/Nauru
Pacific/Niue
Pacific/Norfolk
Pacific/Noumea
Pacific/Pago_Pago
Pacific/Palau
Pacific/Pitcairn
Pacific/Ponape
Pacific/Port_Moresby
Pacific/Rarotonga
Pacific/Saipan
Pacific/Tahiti
Pacific/Tarawa
Pacific/Tongatapu
Pacific/Truk
Pacific/Wake
Pacific/Wallis
```
------
*<ファイル拡張子>* 以外のサフィックスフィールドを変更することはできません。データ形式変換または圧縮を有効にすると、Firehose は設定に基づいてファイル拡張子を付加します。次の表は、Firehose によって付加されるデフォルトのファイル拡張子を説明するものです。
| 設定 | ファイル拡張子 |
| --- | --- |
| データ形式変換: Parquet | .parquet |
| データ形式変換: ORC | .orc |
| 圧縮: Gzip | .gz |
| 圧縮: Zip | .zip |
| 圧縮: Snappy | .snappy |
| 圧縮: Hadoop-Snappy | .hsnappy |
Firehose コンソールまたは API で、希望するファイル拡張子を指定することもできます。ファイル拡張子はピリオド (.) で始まらなければならず、次の文字を含めることができます: 0-9a-z\$1-\$1.\$1‘()。ファイル拡張子は最大 128 文字です。
**注記**
ファイル拡張子を指定すると、[データ形式変換](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html)または圧縮が有効になっている場合に Firehose が追加するデフォルトのファイル拡張子が上書きされます。
# Amazon S3 オブジェクトのカスタムプレフィックスを理解する
Amazon S3 に配信されるオブジェクトは、 の[名前形式](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-namekey)に従います。実行時に評価される式を含むカスタムプレフィックスを指定できます。指定するカスタムプレフィックスは、`yyyy/MM/dd/HH` のデフォルトのプレフィックスを上書きします。
カスタムプレフィックスでは、フォーム `!{namespace:value}` の式を使用できます。ここで、`namespace` は、以下のセクションで説明されているとおり、以下のいずれかです。
+ `firehose`
+ `timestamp`
+ `partitionKeyFromQuery`
+ `partitionKeyFromLambda`
プレフィックスの最後がスラッシュの場合は、Amazon S3 バケット内のフォルダとして表示されます。詳細については、「*Amazon Data Firehose デベロッパーガイド*」の「[Amazon S3 オブジェクト名の形式](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name)」を参照してください。
## `timestamp` 名前空間
この名前空間の有効な値は、有効な [Java DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) 文字列である文字列です。例としては、2018 年には、式 `!{timestamp:yyyy}` は `2018` として評価されます。
タイムスタンプを評価するとき、Firehose は、書き込まれる Amazon S3 オブジェクトに含まれる最も古いレコードのおおよその到達タイムスタンプを使用します。
デフォルトでは、タイムスタンプは UTC です。ただし、希望するタイムゾーンを指定できます。たとえば、UTC の代わりに日本標準時を使用する場合は、 AWS マネジメントコンソール または API パラメータ設定 ([CustomTimeZone](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)) でタイムゾーンをアジア/東京に設定できます。サポートされているタイムゾーンのリストを確認するには、「[Amazon S3 Object Name Format](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name)」を参照してください。
`timestamp` 名前空間を同じプレフィックス式で複数回使用した場合、すべてのインスタンスが同じ時点として評価されます。
## `firehose` 名前空間
この名前空間では、2 つの値 `error-output-type` および `random-string` を使用できます。 次の表は、これらの値の使用方法を説明しています。
**`firehose` 名前空間の値**
| 変換 | 説明 | 入力例 | 出力例 | 注意事項 |
| --- | --- | --- | --- | --- |
| error-output-type | Firehose ストリームと失敗の理由に応じて、次の文字列のいずれかとして評価されます: \$1processing-failed、AmazonOpenSearchService-failed、splunk-failed、format-conversion-failed、http-endpoint-failed\$1。同じ式で複数回使用した場合、すべてのインスタンスが同じエラー文字列として評価されます。 | myPrefix/result=\$1\$1firehose:error-output-type\$1/\$1\$1timestamp:yyyy/MM/dd\$1 | myPrefix/result=processing-failed/2018/08/03 | error-output-type 値は、ErrorOutputPrefix フィールドでのみ使用できます。 |
| random-string | 11 文字のランダムな文字列として評価されます。同じ式で複数回使用した場合、すべてのインスタンスが新しいランダム文字列として評価されます。 | myPrefix/\$1\$1firehose:random-string\$1/ | myPrefix/046b6c7f-0b/ | 両方のプレフィックスタイプで使用できます。形式の文字列の先頭にこれを配置すると、ランダム化されたプレフィックスを取得できます。これは、Amazon S3 で非常に高いスループットを実現するために必要になることがあります。 |
## `partitionKeyFromLambda` および `partitionKeyFromQuery` 名前空間
[動的パーティショニング](dynamic-partitioning.md)では、S3 バケットプレフィックスで次の式形式を使用する必要があります: `!{namespace:value}`。ここで、名前空間は `partitionKeyFromQuery` または `partitionKeyFromLambda`、またはその両方です。インライン解析を使用してソースデータのパーティショニングキーを作成している場合は、次の形式で指定された式で構成される S3 バケットプレフィクス値を指定する必要があります: `"partitionKeyFromQuery:keyID"`。 AWS Lambda 関数を使用してソースデータのパーティショニングキーを作成している場合は、次の形式で指定された式で構成される S3 バケットプレフィックス値を指定する必要があります。`"partitionKeyFromLambda:keyID"`。詳細については、「[Creating an Amazon Firehose stream](basic-create.md#basic-create.title)」の「Choose Amazon S3 for Your Destination」を参照してください。
## セマンティックルール
`Prefix` および `ErrorOutputPrefix` 式には、以下のルールが制限されます。
+ `timestamp` 名前空間では、一重引用符で囲まれていないすべての文字が評価されます。言い換えると、値フィールドで一重引用符によりエスケープされたすべての文字列が文字どおりに解釈されます。
+ タイムスタンプ名前空間式が含まれないプレフィックスを指定した場合、Firehose は式 `!{timestamp:yyyy/MM/dd/HH/}` を `Prefix` フィールドの値に追加します。
+ シーケンス `!{` は、`!{namespace:value}` 式にのみ現れます。
+ `Prefix` に式が含まれていない場合、`ErrorOutputPrefix` は null にのみすることができます。この場合、`Prefix` は `yyyy/MM/DDD/HH/` と評価され、`ErrorOutputPrefix` は `yyyy/MM/DDD/HH/` と評価されます。`DDD` は日を表します。
+ `ErrorOutputPrefix` の式を指定した場合、`!{firehose:error-output-type}` のインスタンスを少なくとも 1 つ含める必要があります。
+ `Prefix` に `!{firehose:error-output-type}` を含めることはできません。
+ `Prefix` と `ErrorOutputPrefix` のどちらも、評価後に 512 文字を超えることはできません。
+ 送信先が Amazon Redshift の場合、`Prefix` に式を含めることはできず、`ErrorOutputPrefix` は null にする必要があります。
+ 宛先が Amazon OpenSearch Service または Splunk であり、`ErrorOutputPrefix` が指定されていない場合、Firehose は失敗したレコードに `Prefix` フィールドを使用します。
+ 送信先が Amazon S3 の場合、Amazon S3 送信先設定の `Prefix` および `ErrorOutputPrefix` は、それぞれ成功したレコードと失敗したレコードに使用されます。 AWS CLI または API を使用する場合は、`ExtendedS3DestinationConfiguration` を使用して Amazon S3 *バックアップ*設定をそれ自身の `Prefix` と `ErrorOutputPrefix` を用いて指定できます。
+ を使用して送信先を Amazon S3 に設定する AWS マネジメントコンソール と、Firehose は送信先設定`ErrorOutputPrefix`で `Prefix`と をそれぞれ成功レコードと失敗レコードに使用します。式を使用してプレフィックスを指定する場合は、`!{firehose:error-output-type}` を含むエラープレフィックスを指定する必要があります。
+ `ExtendedS3DestinationConfiguration` を AWS CLI、 API、または で CloudFormation使用する場合`S3BackupConfiguration`、Firehose はデフォルトの を提供しません`ErrorOutputPrefix`。
+ ErrorOutputPrefix 式を作成するときに、`partitionKeyFromLambda` および `partitionKeyFromQuery` 名前空間を使用することはできません。
## プレフィックスの例
**`Prefix` と `ErrorOutputPrefix` の例**
| Input | 評価されるプレフィックス (2018 年 8 月 27 日の午前 10:30 UTC) |
| --- | --- |
| `Prefix`: 未指定 `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/` | `Prefix`: `2018/08/27/10` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/` |
| `Prefix`: `!{timestamp:yyyy/MM/dd}` `ErrorOutputPrefix`: 未指定 | 無効な入力: Prefix に式が含まれている場合、ErrorOutputPrefix を null にすることはできません。 |
| `Prefix`: `myFirehose/DeliveredYear=!{timestamp:yyyy}/anyMonth/rand=!{firehose:random-string}` `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/!{timestamp:yyyy}/anyMonth/!{timestamp:dd}` | `Prefix`: `myFirehose/DeliveredYear=2018/anyMonth/rand=5abf82daaa5` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/2018/anyMonth/10` |
| `Prefix`: `myPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/` `ErrorOutputPrefix`: `myErrorPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/!{firehose:error-output-type}` | `Prefix`: `myPrefix/year=2018/month=07/day=06/hour=23/` `ErrorOutputPrefix`: `myErrorPrefix/year=2018/month=07/day=06/hour=23/processing-failed` |
| `Prefix`: `myFirehosePrefix/` `ErrorOutputPrefix`: 未指定 | `Prefix`: `myFirehosePrefix/2018/08/27/` `ErrorOutputPrefix`: `myFirehosePrefix/processing-failed/2018/08/27/` |
# OpenSearch Service のインデックスローテーションを設定する
OpenSearch Service が送信先の場合、[**NoRotation**]、[**OneHour**]、[**OneDay**]、[**OneWeek**]、[**OneMonth**] の 5 つのオプションの 1 つから、時間ベースのインデックスのローテーションオプションを指定できます。
選択するローテーションオプションに基づき、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 は -w の形式を使用してインデックスを自動作成します (たとえば、`2020-w33`)。ここで、週数は UTC 時間を使用し、次の米国の表記規則に従って計算されます。
週は日曜日から始まります
その年の最初の週は、今年の土曜日を含む最初の週です。
# データ配信を一時停止および再開する
Firehose ストリームを設定すると、ストリームソースで使用できるデータが継続的に宛先に配信されます。ストリームの送信先が一時的に使用できない状況 (計画的メンテナンスなど) になった場合は、データ配信を一時的に停止し、送信先が再び使用できるようになったら再開してください。
**重要**
以下で説明するアプローチを使用してストリームを一時停止および再開すると、ストリームを再開した後、Amazon S3 のエラーバケットに配信されるレコードはほとんどなく、残りのストリームは引き続き宛先に配信されているのがわかります。これはこのアプローチの既知の制限であり、以前、複数回再試行しても宛先に配信できなかった少数のレコードが失敗として追跡されるために発生します。
## Firehose ストリームを一時停止する
Firehose でストリーム配信を一時停止するには、まず、Firehose が配信に失敗したデータを S3 のバックアップ場所に書き込むため許可を削除します。例えば、OpenSearch の宛先への Firehose ストリームを一時停止する場合は、許可を更新することでそれを実行できます。詳細については、「[Firehose に公開 OpenSearch Service の宛先へのアクセスを付与する](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es)」を参照してください。
アクション `s3:PutObject` のアクセス許可 `"Effect": "Allow"` を削除し、アクション `s3:PutObject` のアクセス許可 `Effect": "Deny"` を、配信に失敗した場合に使用する S3 バケットに適用するステートメントを明示的に追加します。次に、ストリームの宛先をオフにする (宛先の OpenSearch ドメインをオフにするなど) か、Firehose が宛先に書き込みする許可を削除します。他の宛先への許可を更新するには、「[Controlling Access with Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html)」に記載されている宛先に関するセクションを参照してください。この 2 つのアクションを完了すると、Firehose はストリームの配信を停止します。[Firehose の CloudWatch メトリクス](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html)を使用してこれをモニタリングできます。
**重要**
Firehose でストリーム配信を一時停止するときは、ストリームのソース (Kinesis Data Streams や Managed Service for Kafka など) で、ストリーム配信が再開されてデータが宛先に配信されるまでデータを保持するように設定されていることを確認する必要があります。ソースが DirectPUT である場合、Firehose はデータを 24 時間保持します。データ保持期間内にストリームを再開してデータを配信しなければ、データが失われる可能性があります。
## Firehose ストリームを再開する
配信を再開するには、まず宛先を有効にし、Firehose にストリームを配信する許可があることを確認して、ストリームの宛先に対して以前行った変更を元に戻します。次に、失敗した配信をバックアップする S3 バケットに適用されたアクセス許可に対して、以前に行った変更を元に戻します。つまり、アクション `s3:PutObject` のアクセス許可 `"Effect": "Allow"` を適用し、配信に失敗した場合に使用する S3 バケットに対するアクション `s3:PutObject` のアクセス許可 `"Effect": "Deny"` を削除します。最後に、[Firehose の CloudWatch メトリクス](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html)を使用してモニタリングし、ストリームが宛先に配信されていることを確認します。エラーを確認してトラブルシューティングするには、「[Amazon CloudWatch Logs monitoring for Firehose](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html)」を参照してください。