S3 の 11 ナイン (99.999999999%) はどう実現されているのか - オブジェクトストレージの耐久性の裏側
S3 が公称する 99.999999999% の耐久性を支える内部アーキテクチャを、データ分散、整合性検証、自動修復の 3 つの仕組みから解説し、11 ナインが実際に何を意味するのかを具体的な数字で示します。
11 ナインとは具体的にどういう数字なのか
99.999999999% という数字は、直感的に理解しにくい桁数です。具体的に言い換えると、S3 に 1,000 万個のオブジェクトを保存した場合、1 万年に 1 個のオブジェクトが失われる確率です。あるいは、全人類 80 億人がそれぞれ 1 個のオブジェクトを S3 に保存した場合、100 年間で失われるオブジェクトは統計的に 1 個未満です。この数字は「可用性」ではなく「耐久性」(Durability) である点に注意が必要です。可用性はサービスにアクセスできる時間の割合で、S3 Standard の可用性は 99.99% (年間約 52 分のダウンタイム) です。耐久性はデータが失われない確率で、一度保存したオブジェクトが物理的に消失しないことを保証します。つまり、S3 に一時的にアクセスできない瞬間はあり得ますが、データ自体が消えることは事実上ないという設計です。この区別を理解していないと、S3 の障害時に「データが消えたのでは」と誤解するケースがあります。
データ分散 - 最低 3 つの AZ に冗長化する仕組み
S3 の耐久性の第 1 の柱は、データの物理的な分散です。S3 Standard にオブジェクトをアップロードすると、AWS は同一リージョン内の最低 3 つの Availability Zone (AZ) にデータを冗長化します。PUT リクエストに対して 200 OK が返る時点で、少なくとも 2 つの AZ へのデータ書き込みが完了しています。3 つ目の AZ への複製は非同期で行われますが、通常は数秒以内に完了します。各 AZ は物理的に数十キロメートル以上離れた独立したデータセンター群で構成されており、電力系統、冷却系統、ネットワーク接続がすべて独立しています。つまり、1 つの AZ が自然災害や大規模障害で完全に破壊されても、残りの 2 つの AZ にデータが存在するため、オブジェクトは失われません。2 つの AZ が同時に完全破壊される確率は極めて低く、これが 11 ナインの耐久性の物理的な基盤です。S3 One Zone-IA は例外で、単一の AZ にのみデータを保存するため、耐久性は 99.999999999% のままですが、AZ 全体の物理的破壊に対しては脆弱です。
整合性検証 - すべてのビットを常に監視する
データを複数の AZ に分散するだけでは、11 ナインは達成できません。ディスクの経年劣化、宇宙線によるビット反転、ファームウェアのバグなど、データが静かに破損する「サイレントデータコラプション」への対策が不可欠です。S3 はオブジェクトの保存時に MD5 チェックサムを計算し、メタデータとして保持します。さらに、2021 年からは追加のチェックサムアルゴリズム (CRC32、CRC32C、SHA-1、SHA-256) をユーザーが指定できるようになりました。S3 はバックグラウンドで定期的にすべてのオブジェクトのチェックサムを再計算し、保存時の値と照合しています。この「スクラビング」と呼ばれるプロセスにより、ビットレベルの破損を早期に検出します。AWS は 2023 年の re:Invent で、S3 が 1 日あたり数十億回のチェックサム検証を実行していることを公表しました。検出された破損は、他の AZ に保存されている正常なコピーから自動的に修復されます。この検出と修復のサイクルが、データの劣化を未然に防ぐ仕組みです。
自動修復 - 障害を検知したら人間の介入なしに復旧する
S3 の自動修復メカニズムは、ディスク障害、サーバー障害、AZ レベルの障害に対して段階的に動作します。個々のディスクが故障した場合、S3 は即座に検知し、そのディスクに保存されていたデータフラグメントを他の正常なディスクに再複製します。AWS のデータセンターでは毎日大量のディスクが故障しており、この自動修復は 24 時間 365 日、人間の介入なしに実行されています。サーバー単位の障害でも同様のプロセスが動作します。重要なのは、修復の速度です。障害が発生してから再複製が完了するまでの間は、冗長性が一時的に低下した状態になります。この「脆弱ウィンドウ」を最小化するために、S3 は修復処理を最優先のバックグラウンドタスクとして実行します。AWS は具体的な修復時間を公表していませんが、設計上、冗長性の低下が長時間続かないよう最適化されています。また、S3 はイレイジャーコーディング (消失訂正符号) を使用しており、データを複数のフラグメントに分割して保存します。全フラグメントのうち一部が失われても、残りのフラグメントから元のデータを完全に復元できます。この仕組みにより、単純な 3 重コピーよりも少ないストレージ容量で高い耐久性を実現しています。
11 ナインでもデータが失われるシナリオ
S3 の耐久性は極めて高いですが、データ損失のリスクがゼロになるわけではありません。11 ナインが保証するのは、AWS 側の物理的な障害によるデータ損失に対してです。ユーザー側の操作ミスは保証の対象外です。最も多いデータ損失の原因は、誤った DELETE 操作です。S3 のバージョニングを有効にしていない状態でオブジェクトを削除すると、即座に完全に削除されます。バージョニングを有効にしていても、バージョン ID を指定した DELETE は永久削除です。この問題への対策として、S3 Object Lock (WORM: Write Once Read Many) を設定すれば、指定期間中はオブジェクトの削除や上書きを物理的に不可能にできます。MFA Delete を有効にすれば、削除操作に MFA 認証を要求できます。もう一つの見落としがちなリスクは、暗号化キーの紛失です。SSE-C (顧客提供キー) で暗号化したオブジェクトは、キーを紛失すると復号不可能になります。S3 側にはデータが存在しますが、読み取れない状態です。SSE-KMS を使用し、KMS キーの削除に待機期間 (7〜30 日) を設定することで、このリスクを軽減できます。データ保護の設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。