S3のパフォーマンス・整合性・マルチパート

スループットとプレフィックス

S3 は非常に高いリクエストレートに耐えるよう設計されていますが、極端な集中を避けるため キーの先頭部分（プレフィックス） によって負荷が分散される、という理解が試験では有用です。日付・テナント ID・ランダムな接頭辞 などを付けて 複数プレフィックスにワークロードを分割 すると、並列 GET/PUT の合計スループットを伸ばしやすくなります。単一キーへのホットスポットは避けるのが定石です。

整合性モデル

近年の S3 は 新規書き込み・上書き・削除のあと、すぐに一貫した読み取り結果が得られる 強い整合性を前提に説明されています。アプリケーションは「書き込み直後に読めば古い値が返る」といった 結果整合性の読み取りリトライ を、S3 単体のために組み込む必要は通常ありません（キャッシュ層は別問題です）。

マルチパートアップロード

大きなオブジェクトを複数の パート に分けて並列にアップロードし、完了時に 完了リクエスト で一つのオブジェクトにまとめます。途中失敗したパートは 再送 でき、ネットワークが不安定な環境でも効率的です。完了されなかったアップロードはストレージを占有しうるため、ライフサイクルで不完全マルチパートを中止・削除 するルールがベストプラクティスとしてよく問われます。パート数やサイズの下限上限は仕様の範囲内で設計します。

S3 Transfer Acceleration

クライアントから 地理的に遠いリージョン のバケットへアップロードするとき、最寄りのエッジロケーション に一度受け取ってからバックエンドリージョンへ転送する Transfer Acceleration が有効な場合があります。バケット名にドットを含めると利用できないなど 制約 があるため、有効化前に要件を確認します。

高負荷時の挙動

短時間に 極端なリクエストレート が集中すると、HTTP 503 Slow Down などでスロットリングされることがあります。リトライと 指数バックオフ、先述の キー設計による分散 が対策になります。

整合性の検証

アップロード時に チェックサムやハッシュ をヘッダで渡し、ネットワーク上の破損を検知するオプションがあります。利用する SDK や署名バージョンに合わせて 推奨ヘッダ を選びます。