← AWSサービスの内部原理 コース
28. オブジェクトの正体 — データ+メタデータ+キー、そして丸ごと置き換えの世界
S3のオブジェクトを「バイト列+メタデータ+キー」という構成と「変更は常に丸ごと置き換え」という性質の2本柱で、図を追いながら原理から理解します。
① オブジェクトの正体 — 「ファイル」より中身が多い複合体
S3オブジェクト1個の不可分な単位
分解すると
値任意のバイト列 0〜50TB
キーバケット内で取り出す名前
バージョンIDキーと組で一意に識別
メタデータ名前と値のペアの集合
全く同じ構図(既習)
ファイル = バイト列 + メタデータinode: サイズ・所有者・タイムスタンプ・データブロックへのポインタ
- ほかにサブリソース(ACL=誰にどの権限を与えるかの許諾リスト)、アクセス制御情報、タグが従属する
- バージョンIDはバージョニング有効時にS3が生成する文字列
- inodeも実データ本体と管理情報を分離して持つ——S3は別世界に見えて、設計の骨格は既知のファイルの原理
S3のオブジェクトはバイト列の本体に、それを説明する情報が束ねられた複合体。データ本体とメタデータを分けて持つ骨格は、既習のファイル(inode)の原理そのもの。
② メタデータは2種類 — 土台はHTTPヘッダー
HTTPリクエスト(REST API)アップロード時にヘッダーで送る
2系統のメタデータ
ユーザー定義x-amz-meta- で始まるヘッダー
自由に付ける名前と値システム定義Content-Type / Content-Disposition など
S3が管理のため自動付与オブジェクトと一緒に保存
ダウンロード時にそのまま返るブラウザはContent-Typeで画像/HTMLを解釈できる
- ユーザー定義メタデータ: キーも値もUS-ASCII準拠、合計2KBまで
- システム定義の多くは標準HTTPヘッダー由来——HTTPの既習知識がそのままS3に直結する
S3のAPIがHTTP(REST)であることは飾りではなく、メタデータモデル自体がHTTPのヘッダー体系の上に作られている。バイト列にHTTP由来のラベルを貼って自己記述させるのがオブジェクト。
③ サイズの数字 — 50TBまで、ただし上げ方に上限
オブジェクト0バイト 〜 50TB
アップロード経路は3つ
単一PUT最大5GB / 1オブジェクト
マルチパート最大10000パートに分割、5MB〜50TBを扱える
コンソール単一ファイル最大160GB
マルチパートの強み
各パートは独立任意の順序・並列でアップロード可
- パートを順不同・並列に流せるのは「オブジェクトが最終的に丸ごと1つとして確定する」性質があるから——途中のパートは相互に依存しない
1オブジェクトは0バイト〜最大50TB(かつての「最大5TB」は古い値)。ただし単一PUTは5GBまでで、それ以上はマルチパートアップロードで分割して上げる。
④ 核心 — 部分更新は存在しない、変更=丸ごとPUT
ファイルシステム / ブロックデバイス固定長ブロックの配列。任意のブロックにシークして上書き可(1TBの真ん中の4KBだけ書き換えOK)
S3ではこうならない
メタデータ変更
ストレージクラス変更
名前(キー)変更
すべて内部的には
新しいオブジェクト全体のPUT古いオブジェクトを置き換える新オブジェクトが作られる(公式明記)
- 値の一部だけを差分で書き換えるAPIは存在しない——変更とは常に新しいバイト列全体を送り直すこと
- バージョニング有効時は既存を消さず新バージョンを作り、既存は旧バージョンになる
- 既習の「イミュータブル=書き換えず置き換える」設計原理の、ストレージレベルでの徹底
ファイルシステムでは当たり前だった「真ん中の4KBだけ書き換え」がS3にはない。メタデータ1つの変更ですら、内部的には新しいオブジェクト全体のPUT(置き換え)になる。
⑤ なぜ「丸ごと置き換え」が分散ストレージを解ける問題にするか
部分更新を許す世界あるレプリカのブロック17を書き換え中に別リクエストが同じ場所を読む——細粒度の競合を分散システム全体で調停
丸ごと置き換えの世界調停すべきは「どのPUTが最後だったか」だけ
単純化の帰結
強い整合性2020年12月以降。キー単位でアトミック
last-writer-wins同じキーへの並行書き込みは最後の書き込みが勝つ
強力な複製保証も現実的に
耐久性 11ナイン99.999999999%。最低3つのAZへ複製
可用性Standard 99.99% / Standard-IA 99.9% / One Zone-IA 99.5%
- DynamoDB編のパーティションキー単位の整合性と同じ原理の別の現れ——あちらはアイテム単位、こちらはオブジェクト(キー)単位の不可分性
- イミュータブルという一見不便な制約が、分散耐久ストレージを「解ける問題」に変えている
部分更新を許すとレプリカ間でブロック単位の競合調停が必要になり極めて難しい。丸ごと置き換えなら調停は「どのPUTが最後か」だけ——この単純さが強い整合性と11ナインの耐久性を成立させる。