← AWSサービスの内部原理 コース
34. プレフィックスとリクエストレート — 3,500/5,500の壁と自動スケールの仕組み
S3の「3,500/5,500の壁」も自動スケールも503エラーも、内部の1つの仕組み — キー空間をプレフィックスで区切って並列に捌くパーティショニング — から図で追っていきます。
① S3の性能単位は「パーティション化されたプレフィックス」
photos/2006/January/プレフィックス(キーの先頭部分)
sample.jpgオブジェクト名
パーティション化されたプレフィックスキー空間を区切った内部の区画
- S3の内部 = 1つの巨大な倉庫ではなく、キーの範囲で分割された多数の区画の集合体
- 各区画(パーティション)は並列に処理される
キーの先頭部分がプレフィックス。S3の性能はバケット単位ではなく、この単位で決まります。
② 1プレフィックスあたりの天井 — 書き3,500・読み5,500
3,500回/秒PUT / COPY / POST / DELETE(書き込み系)
5,500回/秒GET / HEAD(読み込み系)
1つのパーティション化プレフィックス= 1区画分の処理能力
- プレフィックスの数には上限がない → 区画はいくらでも増やせる
1つのパーティション化されたプレフィックスは、少なくともこのレートを処理できます。1区画の能力には限りがある一方、プレフィックスの数に上限はありません。
③ 分散すればスケール、集中すれば頭打ち
読み込みリクエスト10個のプレフィックスへ均等に分散
5,500 × 10
prefix-15,500/秒
prefix-25,500/秒
…5,500/秒
prefix-105,500/秒
毎秒55,000回バケット合計の読み込み
- 書き込みも同様に、複数プレフィックスへ分ければ本数分だけ伸びる
- 全リクエストが同じプレフィックスに集中 → 読み5,500・書き3,500の天井で頭打ち
- S3のスループットはストレージ容量ではなく「キー設計」で決まる。キーの散らし方 = 並列度
10個のプレフィックスに読み込みを並列化すれば 5,500 × 10 = 毎秒55,000回。逆に1つに集中すると、バケットに空きがあってもそのプレフィックス1本分で詰まります。
④ スケールは段階的 — 過渡期に503(Slow Down)が透けて見える
リクエスト急増特定のプレフィックスに負荷が集中
分割が完了
パーティションを細かく分割中過渡期:503(Slow Down)が返ることがある
新しい高いレートへ引き上げ503は自然に消える
- 503の意味 =「今スケール中なので少し速度を落として再試行してほしい」という合図
- 対策① 指数バックオフを入れた再試行
- 対策② はじめから負荷をプレフィックスへ分散しておく
公式いわくスケーリングは「段階的(gradual)であり瞬間的ではない」。分割が追いつくまでの過渡期に返る503は、故障ではなく内部動作の表面化です。
⑤ DynamoDBのホットパーティションと同じ原理の別の現れ
DynamoDBパーティションキーをハッシュして区画へ割り当て
助言:パーティションキーをよく散らせS3キーの範囲(プレフィックス)で区画を区切る
助言:プレフィックスへ負荷を分散せよキー空間を分割して並列に捌く特定のキーに集中すると1区画の上限で絞られる
- マネージドサービスの表面上のAPIは違っても、内部で並列度を稼ぐ手段はこの一点に収束する
ハッシュかキー範囲かの違いはあれど、「キー空間を分割して並列に捌く」という一点は同じ。だから両者の助言も同じになります。
⑥ まとめ — 性能特性はすべて内部パーティショニングから因果的に説明できる
内部パーティショニングキー空間を区画に分割して並列処理
読5,500・書3,500の上限1区画の処理能力には限りがある
プレフィックス数は無制限キー空間はいくらでも細かく分割できる
分散で55,000/秒分割した区画を並列に走らせる
段階的スケール+503負荷を観測してから分割する適応的な仕組み
- マネージドで隠されているのは運用の手間だけ。分散システムの原理は隠せず、キー設計という形でこちら側に残り続ける
速く使う鍵は容量やインスタンスサイズではなく、負荷が偏らないプレフィックス設計とバックオフ付き再試行に尽きます。