← AWSサービスの内部原理 コース
29. マルチパートアップロード — 巨大データは分割して並列に運ぶ
マルチパートアップロードは「大きなデータを分割して並列に運ぶ」一手で、スループットの壁とやり直しコストを同時に解決する仕組みです。5枚の図で原理を追いましょう。
① なぜ分割するのか — 1本のストリームの限界
巨大ファイル(例: 100GB)
1本のTCP接続で単一PUT
スループット上限RTT × ウィンドウサイズで頭打ち
1回の切断で全滅最初から送り直し
解決策 = 分割して並列に運ぶ
マルチパートアップロード2つの問題を一手で解決
- 単一PUTの上限は5GB、マルチパートなら1オブジェクト最大50TB(旧上限5TBから引き上げ済み)
- AWS公式は100MB以上のオブジェクトでマルチパートをベストプラクティスとしている
1本のTCP接続はRTT×ウィンドウサイズでスループットの上限が決まり、遠距離では帯域を使い切れない。しかも途中で接続が切れると最初からやり直しになる。
② 処理は必ず3段階 — Create → UploadPart → Complete
CreateMultipartUploadS3がupload IDを返す
アップロードを一意に識別並列・順不同でOK
UploadPart #1
UploadPart #5
UploadPart #14番号は1〜10,000、連番不要
全パート送信後
CompleteMultipartUploadパート番号の昇順に連結して1オブジェクトに
- 複数パートを別々の接続で同時に送るから帯域を使い切れる(ここが並列化の要)
- 送った順ではなく番号順に結合されるので、順不同・並列でも正しい順序で復元される
開始APIでupload IDをもらい、パートを順不同・並列に送り、最後にCompleteでS3がパート番号の昇順に連結する。開始したアップロードに有効期限はなく、CompleteかStopまで途中状態のまま残る。
③ リトライの単位を小さくする — 障害の局所化
パート1 ✓
パート2 ✗ネットワーク障害で失敗
パート3 ✓
失敗したパート2だけ再送
パート2 ✓(再送で回復)
パート1・3はそのまま影響なし
- 『リトライの単位を小さくして障害の影響を局所化する』のは分散システムの定石
- DynamoDBがパーティション分割で障害やホットスポットを1パーティションに閉じ込めるのと同じ発想の別の現れ
あるパートの転送が失敗しても、そのパートだけを再送すればよく、他のパートには影響しない。オブジェクト全体をやり直す必要がなくなる。
④ 正しさの保証 — チェックサムのチェックサム
パート1 + CRC
パート2 + CRC
パート3 + CRCクライアントが計算して同送
S3が受信側で再計算 → 一致を確認(ビット化け検出)
各パートの検証済みチェックサム
さらにまとめる
ETag = チェックサムのチェックサム分割して運んだ事実が識別子の形に残る
- 既習のECC/CRCによる誤り検出がそのまま使われている
- チェックサム付きマルチパートではパート番号は1から始まる連番が必須。飛び番のままCompleteするとHTTP 500エラー
各パートのチェックサム(既定はCRC-64/NVME)をS3が受信側で再計算して照合し、ビット化けを検出する。完成品のETagは全体のMD5ではなく『各パートのチェックサムをさらにまとめたチェックサム』になる。
⑤ 途中状態は実在する — 課金と掃除の責任
途中で失敗したアップロード上げたパートはS3のディスク上に実在
Complete / Stop しない限り
課金が続くストレージ・帯域・リクエスト
自動では消えない有効期限なし
定石の対策
ライフサイクルルールAbortIncompleteMultipartUpload で一定日数後に自動掃除
- マネージドサービスといえども魔法ではない。途中状態は物理ストレージを占有する現実のデータ
- 未完了アップロードの掃除は利用者の責任
アップロード済みのパートはS3のディスク上に実在し、CompleteかStopするまでストレージ・帯域・リクエストに課金され続ける。プログラムが途中で死んでも、パートは黙って料金を発生させ続ける。