メニュー
Amazon Simple Storage Service
開発者ガイド (API Version 2006-03-01)

リクエスト率およびリクエストパフォーマンスに関する留意事項

Amazon S3 は非常に高いリクエストレートをサポートするように拡張されます。 Amazon S3 バケットのワークロードが毎秒 100 回の PUT/LIST/DELETE リクエストまたは毎秒 300 回の GET リクエストを頻繁に超える場合は、最高のパフォーマンスとスケーラビリティを確保するため、このトピックのガイドラインに従ってください。リクエストレートが一貫して増加している場合、Amazon S3 は、高いリクエストレートをサポートするため、必要に応じて自動的にバケットを分割します。ただし、バケットに対するリクエストレートが急速に増加して、毎秒 300 回の PUT/LIST/DELETE リクエストまたは毎秒 800 回の GET リクエストを超えることが予想される場合は、リクエストレートの一時的な制限を防ぐため、サポートケースを開いてワークロードの増加に備えることをお勧めします。サポートケースを開くには、お問い合わせを参照してください。

このトピックでは、2 つのタイプのワークロードについて説明します。

  • 複数のリクエストタイプの組み合わせが含まれるワークロード – お客様のリクエストが GET、PUT、DELETE、または GET Bucket(List Objects)の組み合わせであることがほとんどの場合は、オブジェクトに対して適切なキー名を選択することで、Amazon S3 のインデックス(次のセクションで説明)へのアクセスでのレイテンシーが短くなるため、確実にパフォーマンスが向上します。また、この選択により、1 秒あたりに送信されるリクエスト数の影響も受けないレベルでの拡張性が保証されます。

  • 大量の GET を使用するワークロード – ワークロードの大部分が GET リクエストで構成される場合、Amazon CloudFront コンテンツ配信サービスを使用することをお勧めします。

注記

1 秒あたり 100 個以上のリクエストを定常的に処理している場合は、このセクションのガイドラインが該当します。通常のワークロードで 1 秒あたり 100 個以上のリクエストが発生するのが極めてまれであり、1 秒あたりのリクエストが 800 個未満である場合、このセクションのガイドラインに従う必要はありません。

Amazon S3 のワークロードで、AWS キー管理サービスによるサーバー側の暗号化 (SSE-KMS) を使用している場合、ユースケースでサポートされるリクエストレートの詳細については、『AWS Key Management Service Developer Guide』の「制限」を参照してください。

複数のリクエストタイプの組み合わせが含まれるワークロード

大量のオブジェクトをアップロードする場合、キー名の一部として連番や日付と時刻の値を使用することがあります。例えば、日付と時刻の組み合わせを使用するキー名を選択できます。このような例を次に示します。この例では、タイムスタンプがプレフィックスに含まれています。

Copy
examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg examplebucket/2013-26-05-15-00-00/cust3857422/photo2.jpg examplebucket/2013-26-05-15-00-00/cust1248473/photo2.jpg examplebucket/2013-26-05-15-00-00/cust8474937/photo2.jpg examplebucket/2013-26-05-15-00-00/cust1248473/photo3.jpg ... examplebucket/2013-26-05-15-00-01/cust1248473/photo4.jpg examplebucket/2013-26-05-15-00-01/cust1248473/photo5.jpg examplebucket/2013-26-05-15-00-01/cust1248473/photo6.jpg examplebucket/2013-26-05-15-00-01/cust1248473/photo7.jpg ...

キー名を連続するパターンにすると、パフォーマンス上の問題が発生します。この問題を理解するため、キー名が Amazon S3 でどのように格納されるかを説明します。

Amazon S3 では、各 AWS リージョンにオブジェクトキー名のインデックスを保持しています。オブジェクトキーは、インデックス内の複数のパーティションに分散して辞書におけるのと同じ順序で格納されています。つまり、Amazon S3 はキー名をアルファベット順に格納しています。キー名により、自動的にそのキーが格納されるパーティションが決まります。タイムスタンプやアルファベット順などの連続するプレフィックスを使用すると、Amazon S3 が大量のキーに対して特定のパーティションを対象にするため、そのパーティションの I/O 能力がひっ迫する可能性が増大します。キー名のプレフィックスをランダムにすると、キー名、したがって I/O ロードは複数のパーティションに分散されます。

ワークロードが 1 秒あたり 100 個のリクエストを常に超えることが予想される場合、連続するキー名は避けてください。キー名で連番や日付と時刻のパターンを使用する場合は、キー名にランダムなプレフィックスを追加します。プレフィックスがランダムであることで、キー名が複数のインデックスパーティションに均等に分散されます。ランダムにする例は、このトピック内で後述します。

注記

次のセクションのキー名プレフィックスについてのガイドラインは、バケット名にも適用できます。Amazon S3 がキー名をインデックスに格納する場合、格納するキー名の一部はバケット名になります(例、examplebucket/object.jpg)。

例 1: 16 進のハッシュプレフィックスをキー名に追加する

キー名をランダムにする 1 つの方法は、キー名のプレフィックスとしてハッシュ文字列を追加することです。例えば、キー名として付ける文字列の MD5 ハッシュを計算することができます。ハッシュから特定の数の文字を選択し、キー名のプレフィックスとして追加します。以下の例では、4 文字のハッシュが追加されたキー名を示します。

注記

3 ~ 4 文字のハッシュプレフィックスを追加すれば十分です。 プレフィックスとしては、16 進のハッシュを使用することを強くお勧めします。

Copy
examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg examplebucket/7b54-2013-26-05-15-00-00/cust3857422/photo2.jpg examplebucket/921c-2013-26-05-15-00-00/cust1248473/photo2.jpg examplebucket/ba65-2013-26-05-15-00-00/cust8474937/photo2.jpg examplebucket/8761-2013-26-05-15-00-00/cust1248473/photo3.jpg examplebucket/2e4f-2013-26-05-15-00-01/cust1248473/photo4.jpg examplebucket/9810-2013-26-05-15-00-01/cust1248473/photo5.jpg examplebucket/7e34-2013-26-05-15-00-01/cust1248473/photo6.jpg examplebucket/c34a-2013-26-05-15-00-01/cust1248473/photo7.jpg ...

このランダム性が興味深い課題につながることに注意してください。Amazon S3 では、GET Bucket(List Objects)オペレーションが可能です。これは、アルファベットのキー名のリストを返すものです。次に副作用をいくつか示します。

  • ただし、ハッシュプレフィックスのために、アルファベットのリストはランダムに並んでいます。

  • キー名に特定の日付が含まれるオブジェクトキーをリストしようとすると、問題はさらに悪化します。前の例では、4 文字の 16 進のハッシュを使用していたので、65536 通りの文字の組み合わせが考えられます(4 文字のプレフィックスで、各文字は 16 進文字 0 ~ f のいずれかであるため)。4 桁のハッシュと日付の組み合わせである特定のプレフィックスを使用して 65536 個の List Bucket リクエストを送信します。たとえば、キー名に 2013-26-05 が含まれるすべてのキーを検索するとします。この場合、[0-f][0-f][0-f][0-f]2013-26-05 のようなプレフィックスを使用して、List Bucket リクエストを送信します。

オブジェクトをグループ化する必要がある場合は、キー名のハッシュ文字列の前にさらにプレフィックスを追加します。次の例では、キー名に animations/videos/ のプレフィックスを追加しています。

Copy
examplebucket/animations/232a-2013-26-05-15-00-00/cust1234234/animation1.obj examplebucket/animations/7b54-2013-26-05-15-00-00/cust3857422/animation2.obj examplebucket/animations/921c-2013-26-05-15-00-00/cust1248473/animation3.obj examplebucket/videos/ba65-2013-26-05-15-00-00/cust8474937/video2.mpg examplebucket/videos/8761-2013-26-05-15-00-00/cust1248473/video3.mpg examplebucket/videos/2e4f-2013-26-05-15-00-01/cust1248473/video4.mpg examplebucket/videos/9810-2013-26-05-15-00-01/cust1248473/video5.mpg examplebucket/videos/7e34-2013-26-05-15-00-01/cust1248473/video6.mpg examplebucket/videos/c34a-2013-26-05-15-00-01/cust1248473/video7.mpg ...

この場合、GET Bucket(List Objects)オペレーションで返される整列済みのリストは、animationsvideos のプレフィックスでグループ化されています。

注記

ここでもまた、オブジェクトをグループ化するために追加したプレフィックスは連続していてはなりません。連続していると、単一のインデックスパーティションが前述のようにひっ迫するためです。

例 2: キー名の文字列を左右反転する

プレフィックスに昇順のアプリケーション ID が含まれるキー名のオブジェクトをアプリケーションでアップロードする場合を考えます。

Copy
examplebucket/2134857/data/start.png examplebucket/2134857/data/resource.rsrc examplebucket/2134857/data/results.txt examplebucket/2134858/data/start.png examplebucket/2134858/data/resource.rsrc examplebucket/2134858/data/results.txt examplebucket/2134859/data/start.png examplebucket/2134859/data/resource.rsrc examplebucket/2134859/data/results.txt

このようなキー名のスキームで書き込みオペレーションを行うと、 単一のインデックスパーティションがひっ迫します。これに対して、アプリケーション ID 文字列を左右に反転すると、ランダムなプレフィックスの付いたキー名が得られます。

Copy
examplebucket/7584312/data/start.png examplebucket/7584312/data/resource.rsrc examplebucket/7584312/data/results.txt examplebucket/8584312/data/start.png examplebucket/8584312/data/resource.rsrc examplebucket/8584312/data/results.txt examplebucket/9584312/data/start.png examplebucket/9584312/data/resource.rsrc examplebucket/9584312/data/results.txt

キー名の文字列を左右反転することで、1 文字めが異なるキー名ごとに Amazon S3 が固有のパーティションを使用するようになるための準備が整います。examplebucket はアプリケーションデータのアップロード先となるバケットの名前を指しています。

Copy
examplebucket/7 examplebucket/8 examplebucket/9

この例では、Amazon S3 がキー名の先頭文字をどのようにパーティション分割に使用できるかを示しました。ただし、非常に大きな作業負荷(1 秒あたり 2,000 個を超えるリクエストまたは数十億個のオブジェクトを格納するバケット)の場合、Amazon S3 はパーティション分割方式にさらに多くの文字を使用できます。キーのカウントとリクエスト率は時間と共に増大するため、Amazon S3 が自動的にこれらのパーティションをさらに分割する場合があります。

大量の GET を使用するワークロード

お客様のワークロードが主に GET リクエストを送信することである場合は、パフォーマンスを最適化するために、前述のガイドラインに加えて、Amazon CloudFront の使用を検討してください。

Amazon CloudFront を Amazon S3 と合わせて使用することで、短いレイテンシーと高いデータ転送速度でユーザーにコンテンツを配信することができます。また、Amazon S3 に送信される直接リクエストが減少するため、負荷が削減されます。

例えば、使用頻度の高い少数のオブジェクトがあるとします。Amazon CloudFront はこのようなオブジェクトを Amazon S3 から取得し、キャッシュします。これにより、Amazon CloudFront はキャッシュを使用してオブジェクトに対する後続のリクエストを処理できるようになるため、Amazon S3 に送信する GET の数が削減されます。詳細については、Amazon CloudFront の製品詳細ページを参照してください。