Firehose が Amazon S3 に複数の小さなファイルを作成する理由を知りたいです。

簡単な説明

次の要因で、Firehose が配信するレコードは BufferingHints API が指定するレコードよりも小容量になります。

• 圧縮が有効になっている。
• Firehose の配信ストリームがスケーリングされた。
• Amazon Kinesis データストリームがデータソースのリストに含まれている。

解決策

圧縮が有効になっている

Firehose 配信ストリームで圧縮を有効にすると、Firehose は圧縮前に、BufferingHints API のパラメータ SizeInMBs および IntervalInSeconds を適用します。

レコードバッファのバッチごとに、Firehose はこれらのパラメータを適用します。次に、Firehose はデータレコードを圧縮し、Amazon S3 に小容量ファイルを作成します。

Firehose の配信ストリームがスケーリングされた

クォータの増加をリクエストした場合、または Firehose が自動的にスケーリングした場合、Firehose の配信ストリームはスケーリングされます。デフォルトでは、Firehose は配信ストリームを一定のクォータまで自動的にスケーリングします。この自動スケーリング動作により、クォータを増やすことなくスロットリングが削減されます。

Firehose の配信ストリームがスケーリングされると、BufferingHints API が影響を受ける可能性があります。

注: Firehose の設定時にバッファサイズを設定できます。

Firehose 配信ストリーム内では、Firehose はデータを並列チャネルにバッファし、同時にデータを配信します。たとえば、Firehose はデータをバッファし、バッファサイズのクォータに応じて単一ファイルを作成します。Firehose が現在のスループットクォータの 2 倍にスケーリングした場合は、2 つの別々のチャネルが同じ時間間隔でファイルを作成します。Firehose が 4 倍にスケールアップした場合は、4 つの異なるチャネルが、同じ時間間隔で Amazon S3 に 4 つのファイルを作成します。

配信ストリームのスケーリング時に、スケーリングの要因と受信トラフィック量が一致しない場合、Firehose は小容量ファイルを作成します。たとえば、Firehose が元の容量の 4 倍にスケーリングし、受信トラフィックが元のトラフィック量の 4 倍に増加した場合も、ファイルサイズは一定に保たれます。ただし、Firehose が 4 倍にスケーリングしてもトラフィックが変わらない場合は、Firehose は同じ量のデータをより多くのチャネルに分散します。その場合は、ファイルサイズが小さくなります。

注: どちらのシナリオでも、複数の並列バッファチャネルがあるため、ファイル数が増える可能性があります。

Firehose の配信ストリームがデフォルトのクォータを超えてスケーリングしないようにしてください。Firehose 配信ストリームの現在のクォータを確認するには、次の Amazon CloudWatch メトリクスを参照します。

• BytesPerSecondLimit
• RecordsPerSecondLimit
• PutRequestsPerSecondLimit

これらのメトリクスの値がデフォルトのクォータと異なる場合は、Firehose の配信ストリームがスケーリングされたことを示しています。

Amazon Kinesis データストリームがデータソースのリストに含まれている

データストリームを Firehose のデータソースとして含めた場合、Firehose は内部的にスケーリングされます。デフォルトでは、Firehose はデータストリームのボリューム容量に合わせてスケーリングします。Firehose がスケーリングすると、バッファサイズが変化し、配信されるレコードのサイズが小さくなる可能性があります。

注: Firehose はバッファリングヒントオプションをヒントとして扱います。その結果、Firehose はバッファの最適化には異なる値を使用する場合があります。