日次のバッチ処理は、Amazon S3 のバケットに保存した画像を読み出しています。キーはすべて images/2026/ で始まる同じ命名規則で作られており、バッチは処理の間ずっと秒間 18,000 件の GET リクエストを出します。ところが処理を始めた直後から一部のリクエストが 503 (Slow Down) を返すようになり、完了時刻が読めなくなりました。画像は 1 枚あたり数百 KB で、バケットには 2 億件のオブジェクトが入っており、バッチは全件を 1 日に 1 回ずつ読み出します。 最小限の運用上のオーバーヘッドでこの状況を解消するには、どうすればよいですか。
1 か所に集中したオブジェクトの読み出しで断られる状況を、性能の割り当ての単位から解消する
バッチが同時に送信するリクエストの数を増やし、読み出しの並列度を上げる。
読み出しが間に合わないときに、同時に送るリクエストを増やして並列度を上げるのは自然な発想です。多くの場面では実際にスループットが上がり、完了までの時間も縮みます。
503 (Slow Down) を返しているのは、Amazon S3 の側です。リクエストレートはパーティション分割されたプレフィックスごとに割り当てられるため、同じプレフィックスへ集中させたまま同時送信数を増やしても受け付けられる件数は変わりません。断られるリクエストが、そのぶん増えるだけです。
キーの先頭に分散用の値を付けて複数のプレフィックスへ振り分ける。
Amazon S3 のリクエストレートは、パーティション分割されたプレフィックス単位で割り当てられます。プレフィックスは、オブジェクトのキーの先頭にある文字列（本問の images/2026/ など）です。1 つのプレフィックスあたり少なくとも毎秒 5,500 件の GET を処理できるため、キーを複数へ散らせばその数に応じて読み出しの性能が伸びます。
1 つのバケットに作れるプレフィックスの数に上限はないため、キーの先頭に分散用の値を挟めばバケットを増やさずに秒間 18,000 件を受けられます。なお割り当ての拡大は段階的に進むため、負荷を一気に上げた直後に 503 が返ることがあります。
日付ごとに別のバケットを作成し、キーをバケット単位に振り分ける。
バケットを分ければリクエストの宛先が分かれるので、1 か所に集中していた読み出しは実際にばらけます。性能という面だけを見れば効果があります。
ただし 1 つのバケットに作れるプレフィックスの数に上限はないため、同じ分散をバケットを増やさずに実現できます。バケットを増やすと設定の管理先がそのぶん増え、日付が変わるたびに用意する運用も生まれるため、得られる効果に対して構成が重くなります。
バッチが読み出すオブジェクトを Amazon CloudFront 経由で取得するようにする。
Amazon CloudFront をオリジンの前に置くと、エッジロケーションにキャッシュされたオブジェクトはそこから返るため、同じオブジェクトを何度も読む使い方では S3 へのリクエスト自体が減ります。一桁ミリ秒の応答が要る場面では、実際に使われる組み合わせです。
ただしキャッシュが効くのは同じオブジェクトを繰り返し読むときで、2 億件をそれぞれ 1 回ずつ読む日次バッチではほとんどがオリジンまで届きます。同じプレフィックスへの集中は解けず、503 (Slow Down) も収まりません。
Amazon S3 の性能を考えるときは、リクエストレートがどの単位で割り当てられるかを押さえます。
・割り当ての単位はパーティション分割されたプレフィックスで、1 つあたり少なくとも毎秒 3,500 件の PUT / COPY / POST / DELETE、または 5,500 件の GET / HEAD を処理できます。
・1 つのバケットに作れるプレフィックスの数に上限はありません。10 個のプレフィックスを作れば読み取りは毎秒 55,000 件まで伸ばせます。
・拡大は段階的で即時ではありません。急に負荷を上げると 503 (Slow Down) が返ります。
「503 (Slow Down) が出る」なら、まずキーの設計を疑います。バケットを分けるのは過剰で、キーの先頭を分けるだけで同じ効果が得られます。割り当てはリクエスト元ではなく宛先の側に付いているため、送信元の台数を増やしても増えません。