S3の性能と癖 — プレフィックス分散・書き込み速度・スロットリング・スモールファイル問題

S3は「速いストレージ」ではありません。正確には「スケールする throughput を持つが、単発の操作は速くない」ストレージです。この性質を知らずに大量のバッチ出力やログをS3に叩き込むと、スロットリングと請求とLISTの遅さで足をすくわれます。S3の性能の癖を、設計に効く粒度で掘ります。

01書き込み速度の正体 — 単発は遅い、並列で稼ぐ

まず誤解を解きます。S3のPUTは、ローカルディスクのように「1本のストリームが爆速」ではありません。1回のPUTのレイテンシは数十ミリ秒オーダーで、単一ストリームのスループットはそれほど高くない。S3の速さは「並列度」から生まれます。複数のオブジェクトを同時にPUTする、大きなオブジェクトはマルチパートで分割して並列に送る——これで初めて高いスループットが出ます。

「S3に大きいファイルを1本、順次書き込む」設計は、S3の一番遅い使い方です。この癖を知らないSIerが「S3、思ったより遅い」と言うのは、たいてい並列化していないのが原因です。

021プレフィックスあたりの壁 — 3,500 PUT / 5,500 GET

S3の性能を語るうえで外せない数字です。S3は1つのプレフィックスあたり、毎秒少なくとも3,500回のPUT/COPY/POST/DELETE、5,500回のGET/HEADまでスケールします。そしてこの上限は「プレフィックスごと」なので、複数のプレフィックスに分散すれば全体のスループットは足し算で伸びます。

• 超高スループットが要るなら、キー設計でプレフィックスを分散させる（例：先頭に分散のためのキーを入れる）
• S3は内部でアクセスパターンに応じてパーティションを自動調整するが、急激なバーストには追いつかないことがある
• 特定のプレフィックスにアクセスが集中する「ホットプレフィックス」は、スロットリングの原因になる

03503 SlowDown — スロットリングは起きる

プレフィックスへのリクエストが上限を超えたり、パーティションの自動調整が追いつかないと、S3は503 SlowDownを返してスロットリングします。SDKは指数バックオフでリトライしますが、大量の並列バッチが同じプレフィックスに殺到すると、リトライ多発で全体が遅くなります。

04マルチパートアップロード — 大きいものは分割して並列に

大きなオブジェクトは、マルチパートアップロードで分割して並列に送るのが定石です。ある程度（目安として100MB超）から効果が出て、非常に大きいオブジェクトでは必須になります。利点は速度（並列化）と回復力（失敗したパートだけ再送）。

• 未完了のマルチパートアップロードは、放置すると課金され続ける。ライフサイクルで自動中止を設定する
• パートサイズと並列数はネットワーク帯域に合わせて調整
• この考え方は大量データ転送の設計と地続きです

05スモールファイル問題 — 無数の小オブジェクトが招く地獄

S3で最も静かに、しかし深刻に効いてくるのがこれです。数百万〜数億の小さいオブジェクトは、次の三重苦を招きます。

• リクエスト課金 — S3はリクエスト数でも課金される。1KBのファイルを1億個書けば、ストレージ費は安くてもPUTリクエスト費が膨らむ
• LISTの地獄 — 大量オブジェクトのLISTは遅く高価。「特定のファイルを探すために全件LIST」は破滅。S3 Inventoryや、プレフィックス設計での絞り込みで回避
• 分析の非効率 — Athena等でのクエリは、小ファイルが多いほどスキャンのオーバーヘッドが増え、遅く高くなる

対策は集約です。細かいレコードは、Parquet等の列指向フォーマットにまとめて「大きいファイル少数」にする。ログも、細切れに吐くのではなく、ある程度バッファして束ねてから置く。「小さいファイルを大量に」はS3の最も苦手なパターンだと覚えてください。

—まとめ

S3の性能は、ディスクの速さではなく「並列度とプレフィックス分散」で決まります。単発PUTは速くない、1プレフィックス3,500/5,500の壁、ホットプレフィックスの503、マルチパートでの並列化、そしてスモールファイルの三重苦。これらを踏まえて「並列に・分散して・大きく束ねて」書けば、S3は桁違いのスループットを出します。SIerが「S3遅い」とつまずくポイントは、ほぼ全部この癖の裏返しです。次は全ストレージをS3へ集約する設計へ。