← AWSサービスの内部原理 コース
33. S3の強い整合性 — 分散ストアが『書いたら読める』を保証する意味
「書いたら読める」を分散ストレージで保証するとはどういうことか——S3の強い整合性の仕組みと、その保証の境界線を図で追います。
① 分散複製が生む「古いデータを読むかも」問題
PUT(新データ)クライアントが書き込み
直後にGETしたら?
AZ-A レプリカ
AZ-B レプリカ
AZ-C レプリカ
結果整合の世界古いデータが返るかも
S3の選択: 強整合必ず新データが返る
- S3 Standard等は最低3つのAZに複製(One Zone-IA / S3 Express One Zoneは単一AZ)
- 耐久性は11ナイン(99.999999999%)
- 2020年12月以降、全AWSリージョンで新規PUT・上書きPUT・DELETEすべてに強整合を保証
S3はオブジェクトを複数サーバーへ冗長複製して11ナインの耐久性を得るため、書き込み直後に別レプリカを読むと古いデータの恐れが生まれます。S3はここで「強い read-after-write 整合性」を選びました。
② 鍵は「いつ成功(200)を返すか」
PUT リクエスト
確認できてから初めて
全レプリカへ複製・安全格納を確認「成功したなら、データは安全に格納されている」(公式)
成功後に開始したGET / LIST
200 成功応答
必ず新データを返す削除なら「不在」を返す
S3は複数サーバーへの複製が完了し安全に格納されたことを確認してから、初めてPUTに200を返します。だから成功応答の時点で、どのサーバーに読みに行っても新データが見える状態が整っています。
③ DynamoDBとの対比 — 差は書き込みではなく読み取り側
共通の原理複製・永続化を確認してからACK(200)
S3成功後の読み取りは必ず最新が見える経路
→ 強整合DynamoDB(デフォルト)未伝播のレプリカに当たる可能性あり
→ 結果整合- DynamoDBも「耐久的に永続化された」ことを確認してからACKする点はS3と同じ
- 同じ複製設計でも、読み取り経路の許し方で強整合にも結果整合にもなる
実はDynamoDBも成功を返す前に複数AZ(3つ中2つのクォーラム)へ同期的に永続化しており、書き込み側の原理はS3と同じです。整合性を分けるのは「読み取りをどのレプリカに許すか」という読み取り経路の設計です。
④ 境界線その1 — 同時書き込みはロックされない
クライアントAPUT key=X
クライアントBPUT key=X
「読んで・確認して・書く」更新だと
ロックなしタイムスタンプが最新のリクエストが勝つ(last-writer-wins)
片方の変更が消える(lost update)必要ならアプリ側でロック機構を設計
- アトミック性の単位は「1つのキー(オブジェクト)」まで — PUT中のGETは古いか新しいかのどちらかを返す
- 公式: 「S3は同時書き込みに対するオブジェクトロックをサポートしない」
1つのキーへの更新はアトミックで、中途半端に壊れたデータは決して返りません。しかし同時書き込みのロックはなく、同じキーへ2つのPUTが同時に来たらタイムスタンプが最新の方が勝ちます(last-writer-wins)。
⑤ 境界線その2 — 強整合が効く範囲はどこまでか
1つのキーの読み書き強整合・アトミック
保証される複数キーをまたぐ更新アトミックに行う方法はない
アプリ側で設計バケット設定結果整合モデル
伝播に時間がかかる- 例: 「キーAの更新をキーBに依存させる」一括切り替えトランザクションはS3自身では提供されない
- バージョニングを初めて有効化した直後は、公式は15分待ってから書き込むことを推奨
強整合が効くのは「1つのキーのオブジェクトデータ(とそのメタデータ・ACL・タグ等の読み取り)」まで。キーをまたぐアトミック更新は不可能で、バケットの設定は結果整合モデルです。
⑥ まとめ — 整合性は魔法ではなく設計の帰結
複製の原理(共通)分散システムの一貫性・競合状態とロックの基礎
last-writer-winsが困る場面では
強整合S3: 1キー単位・複製完了後にACK・成功後は必ず最新
結果整合DynamoDB既定の読み取り / S3のバケット設定
バージョニング
条件付き書き込み
自前のロック
同じ「複製の原理」が、いつ成功を返し・どのレプリカに読ませるかという設計の違いで、強整合にも結果整合にもなります。境界線を知っていれば「S3に置けば同時更新も安全」という誤解を避け、必要な手当てを設計に組み込めます。