← AWSサービスの内部原理 コース
31. 耐久性と可用性は別物 — データが消えないことと、今すぐ読めること
S3の比較表では耐久性が全クラス11ナインで横一線なのに、可用性だけクラスごとに差がつく——この「矛盾」を、二つの数字が測っている別々のものから図で解きほぐします。
① 二つの数字は「測っているもの」が違う
耐久性 Durabilityデータが失われず残っている確率
可用性 Availabilityいま応答が返ってくる確率
それぞれが測るもの
データの生存消えていないか(ストレージ側)
データへの到達いま読めるか(経路・設備側)
耐久性は「預けたデータが失われず残っている確率」、可用性は「いまリクエストして応答が返る確率」。前者はデータの生存、後者はデータへの到達を測る。
② S3の表そのものが証拠 — 耐久性は横一線、可用性はばらつく
Standard耐久性 11ナイン
Standard-IA耐久性 11ナイン
One Zone-IA耐久性 11ナイン
Glacier耐久性 11ナイン
同じ耐久性なのに、可用性だけ差がつく
99.99%
99.9%
99.5%
99.99%
※復元した後- 11ナイン = 99.999999999%。全ストレージクラスで共通
- 可用性はStandard 99.99% / Standard-IA 99.9% / One Zone-IA 99.5% と段階的に低下
全クラスの耐久性は99.999999999%(11ナイン)で同じなのに、可用性の設計値だけクラスごとに差がつく。この表が、二つが別々の設計目標であることの何よりの証拠。
③ 耐久性の正体 = コピーの数と配置
オブジェクトPUTされたデータ
最低3つのAZへ冗長コピー
AZ-a複数デバイスに保存
AZ-b複数デバイスに保存
AZ-c複数デバイスに保存
ディスク同時故障・DC1棟全損でも
残りのコピーから復元→ 耐久性 11ナイン
- AZ = 独立した電源・ネットワーク・空調を持つデータセンター群。互いに数km以上離して配置
- 失われた冗長度は自動検知して修復。チェックサムで中身の健全性も定期検証
S3は大半のクラスで、オブジェクトを最低3つのAZにまたがる複数デバイスへ冗長に保存する。11ナインはこの「コピーの数と配置」が生み出す数字。
④ One Zone-IA — 分離がいちばんはっきり見える例
One Zone-IAデータは1つのAZの中だけ
AZ内ではStandardと同様に冗長コピー
AZ-a複数デバイスにコピー
AZ-bコピーなし
AZ-cコピーなし
デバイス故障には耐える / AZ全損(地震・洪水)には耐えない
耐久性 11ナインStandard-IAと同じまま
可用性 99.5%AZ全損で到達不能に
- AWS曰く「Standard-IAと同じくらい耐久性は高いが、可用性は低く、耐障害性も低い」
- 既習の分散システムの原理(冗長化と単一障害点)がストレージクラスの選択肢として表に出た姿
可用性が99.5%に下がるのはコピーを減らしたからではない。到達経路と設備を1つのAZに集約し、「AZ全損」という単一障害点を許容したから。
⑤ Glacier — データは無事なのに「いま読めない」
Glacier Flexible / Deep Archive3つ以上のAZに保存・耐久性 11ナイン
普段はアーカイブ状態
いまGETしても読めないデータは3AZに無事に存在するのに
RestoreObjectで復元要求 → 数分〜数時間待つ
アクセス可能に可用性 99.99%(復元した後)
- 表の可用性欄の注記「99.99%(オブジェクトを復元した後)」がこの仕組みを示している
3AZ以上に保存され耐久性は満たされているのに、アーカイブ状態では応答が返らない。可用性は「データがあるか」ではなく「いま読み出せる状態か」を測っている。
⑥ 合流点 — クラス選びは必ず「二つの問い」に分けて立てる
ストレージ側SSD/ディスク + コピーの配置
サーバー側サーバー・ネットワーク・アクセス経路
クラス選択のときに立てる問い
耐久性の問いこのデータは絶対に失いたくないか?
可用性の問い落ちている時間・すぐ読めないことをどこまで許せるか?
- DynamoDBと同じ構図: 何個複製しどこに置くか(耐久性・整合性)と、そのパーティションに到達できるか(可用性)は別の問い
- 同じ分散・パーティショニングの原理が、DynamoDBでは整合性とホットパーティション、S3では耐久性と可用性として現れる
耐久性はディスクとコピー配置というストレージ側、可用性はサーバー・ネットワーク・経路というサーバー側の話。ディスクが無事でも前に立つ設備が落ちれば読めない。