Google Cloud のベルギーディスク損失が示す、局所性がレジリエンスではなくなる境界

概要

• 2015年8月、europe-west1-b ゾーンの Google Compute Engine Standard Persistent Disk は、ヨーロッパのデータセンターに供給する地域電力網に4回の連続落雷が影響を及ぼした後、読み取りエラーが発生した。Google は後に、当該ゾーンの割り当て済み Persistent Disk 領域のごく一部で、最近の書き込みが回復不能になったと報告した。
• 説明責任の問題は、その割合が大きかったかどうかではない。重要なのは、ゾーン内でプロバイダー管理の冗長性があっても、ゾーン Persistent Disk は依然として物理的障害ドメインの中にあり、独立したスナップショット、リージョンレプリケーション、アプリケーションレベルのバックアップの代替にはならないことを顧客が理解していたかどうかである。
• Google は、物理サイトのレジリエンス、ストレージハードウェアの脆弱性、電力事象への対応、Persistent Disk の耐久性に関する表現、ステータス報告、バックアップガイダンスの明確さを管理していた。顧客は、ワークロードアーキテクチャ、スナップショットスケジュール、リカバリ目標、レプリケーションの選択、および地域要件が回復可能性と混同されていないかを管理していた。
• 実務上の修復記録では、サービス復旧、回復不能データ、利用可能なスナップショットによる回避策、ハードウェアとソフトウェアの変更、バックアップガイダンス、顧客証拠を区別すべきである。データ消失を伴うクラウドインシデントでは、ステータスページが緑色であることは復旧の完全な証明にはならない。

わずかな割合でも、深刻な障害となりうる

Google Cloud ベルギーインシデントは、恒久的に失われたストレージの割合が極めて小さかったため、しばしば珍しい事例として記憶される。しかしそれは誤った第一印象である。回復不能になった最近の書き込みを含むディスクを抱える顧客にとって、その割合は問題ではなかった。重要なのは、顧客が回復可能な独立したコピーを持っていたかどうか、アプリケーションがそのリカバリポイントを許容できたかどうか、そしてイベント前にプロバイダの耐久性に関する説明が、残存する物理サイトのリスクを十分に明確にしていたかどうかである。

Google の公開Compute Engine Incident #15056は、2015年8月13日に europe-west1-b 内の Persistent Disk を対象に開始された。ステータスページは当初、当該ゾーンのマシンを使用する顧客に読み取りエラーが発生していると報告し、その後、ゾーン内のディスクの1%未満がパフォーマンス低下の影響を受ける可能性があり、さらに0.1%未満で一部のブロックに読み取り障害が発生していると説明した。また、影響を受けた顧客に対し、スナップショットからの復元が回避策であること、新しい Persistent Disk の作成とスナップショットからの復元には影響がないことを伝えた。

データセンター Dynamics の落雷とデータ消失に関するレポートや、Silicon UK の障害原因の説明など、後のインシデント説明を伝えたメディア報道は、Google が、地域電力網への4回の連続落雷により、europe-west1-b 内の GCE インスタンス用ディスク容量をホストするストレージシステムへの一時的な電力喪失を引き起こしたと述べたと報じている。Google は、ほぼすべてのデータが安定ストレージにコミットされたが、ごく一部の最近の書き込みが回復不能となり、Persistent Disk 上のデータが恒久的に失われたと述べた。広く伝えられた数字は、影響を受けたゾーンの割り当て済み Persistent Disk 領域の0.000001%未満であった。

この記録は、抑制と深刻さの両方を裏付けている。このイベントを Google Cloud 全体にわたる広範なデータ破壊と表現するのは間違いである。影響を受けたサービスは1つのゾーン内の Standard Persistent Disk であり、SSD Persistent Disk、スナップショット、Local SSD は、事後分析や当時の報道によって、恒久的な損失の対象外と報告された。しかし、分母が巨大だったからといってインシデントを軽視するのも間違いである。データ耐久性は、意味のある記録においては二値的な事実である。ごくわずかな回復不能率でも、誰かにとっては恒久的な損失である。

したがって、説明責任の問題は「なぜ雷が存在するのか」ではない。雷は外部ハザードである。問題は、繰り返される電力網イベントが最近書き込まれたディスク状態に到達することを許した設計選択を誰が管理していたか、耐久性とバックアップガイダンスの明確さを誰が管理していたか、そして独立したリカバリポイントを持つか持たないかの顧客アーキテクチャを誰が管理していたかである。トリガーは物理的であった。根本的な説明責任の問題は、プロバイダー管理の局所的耐久性と顧客管理の回復可能性との境界線であった。

局所性と耐久性は同一の約束ではない

クラウドの局所性は現実的な問題を解決する。顧客は、ベルギーやヨーロッパのユーザーへのレイテンシ、調達上の理由、低炭素特性、またはデータ所在地コミットメントのために europe-west1 を選択するかもしれない。Google の現在のクラウドロケーションページと Compute Engine のリージョンとゾーンのドキュメントでは、リソースはリージョンとゾーンに存在し、ゾーンとリージョンは基礎となる物理リソースの論理的抽象化であると説明している。この抽象化は、顧客が建物を管理する必要がないため有用である。しかし、顧客がゾーンリソースが物理的障害ドメインから逃れていると推論するなら危険である。

データ主権と局所性は、データがどこに保存または処理されるかに関するものである。回復可能性は、障害後に別の使用可能なコピーが存在するかどうかに関するものである。ディスクはロケーション要件を満たすことができるが、その唯一の回復可能な状態が同一ゾーンかつ同一ストレージクラスに存在する場合、データベースにとって不適切な耐久性アーキテクチャである可能性がある。スナップショットはリカバリを満たすことができるが、それ自体にロケーション選択がある場合がある。リージョナルディスクはゾーン間の可用性を高めることができるが、すべてのリカバリポイント目標を満たすとは限らない。セカンドプロバイダーは共通の依存性を低減できるが、運用の複雑性とデータガバナンスリスクを高める可能性がある。これらは異なる次元である。

Google の現在のデータレジデンシー条項と欧州のコミットメント資料は、サポート対象サービスについて顧客データがどこに存在できるかを定めている。これらは、すべてのローカルリソースを独立したバックアップに変えるものではない。同様に、Persistent Disk 製品ページでは耐久性のあるブロックストレージと説明され、Compute Engine のPersistent Disk ドキュメントでは、Persistent Disk には機器障害から保護し、メンテナンスイベントを通じてデータ可用性を維持するための組み込みの冗長性があると述べている。これらは意味のあるプロバイダーコミットメントである。しかし、あらゆるサイト規模のハザードが、すべての構成で最近の書き込みをゼロ件で済ませることを保証するものではない。

2015年のインシデントは、解釈のギャップを露呈した。ある顧客は「永続的」をディスクが仮想マシンより長持ちするという意味に読むかもしれないが、それは正しい。別の顧客は、ディスクがデータ消失に対して免疫があるという意味に読むかもしれないが、それは安全な推論ではない。顧客は「ヨーロッパ」や「ベルギー」を主要なコンプライアンス決定として読み、そこで思考を止めるかもしれない。このインシデントは、ロケーションがリカバリ計画ではないことを示している。レイテンシとポリシーに役立つ同じローカル配置が、独立したバックアップが存在しない場合、物理的リスクを集中させる可能性がある。

したがって、プロバイダーの説明は障害ドメインについて明示的であるべきである。ゾーン Persistent Disk はその設計上耐久性があるが、ゾーンに紐付いたままである。スナップショット、リージョナルディスク、レプリケーション、アプリケーションバックアップは障害モデルを変える。顧客は、インシデント後にステータスページがスナップショットからの復元を指示する前に、その区別を必要とする。最も価値の高い開示は、ストレージ選択から障害ドメイン、リカバリポイント、リカバリ時間、顧客の責務への平易なマッピングである。

物理トリガーはクラウド説明責任の記録に含めるべき

クラウドは、顧客の日常業務から物理インフラを消し去ることができるが、物理的ハザードを消し去るわけではない。電力システム、バッテリー、ストレージコントローラー、ファームウェア、ラック、配電、電力網イベントは、依然としてサービスの一部である。顧客は、プロバイダーがより大きな規模と専門知識を持っているため、それらのレイヤーを管理するようプロバイダーに支払っている。そのため、物理的レジリエンスはプロバイダーの責務であり、アプリケーションのリカバリアーキテクチャは一部顧客に残る。

複数のメディアが伝えたインシデント説明によると、自動補助システムが迅速に電力を復旧し、ストレージシステムはバッテリーバックアップを備えて設計されていたが、最近書き込まれたデータの一部は、延長または繰り返しのバッテリー消耗による電力障害の影響を受けやすいシステム上にあった。この一文は、単一の落雷と、脆弱なストレージサブセットを見つけた繰り返しの物理的ストレスとを区別するため重要である。また、一部の報道で使用された「古いディスク」という表現を慎重に扱うべき理由も示している。公開記事はハードウェアの脆弱性を説明しているが、公開ステータス記録はすべてのコンポーネント、年数、内部エンジニアリング判断を公開しているわけではない。

Google は、配電、コンピューティングハードウェア、Persistent Disk レイヤーを制御するソフトウェアにわたる広範なレビューを実施し、この種の電力障害の影響を受けにくいようストレージハードウェアをアップグレードしていると報じられた。データセンター Knowledge の更新されたレポートは、Google がストレージシステムをより電力レジリエントなハードウェアに交換しており、多くの Persistent Disk ストレージは既に新しいハードウェア上にあると記録している。これらは対応策であり、顧客アーキテクチャのアクションではなく、物理およびストレージスタックに対するプロバイダー側の制御として理解すべきである。

プロバイダーはまた、インシデントステータスを管理していた。Cloud Status ページは、繰り返し更新、影響割合、スナップショットによる回避策ガイダンスを提供した。その記録は沈黙よりはるかに良い。しかし、調査の進行とともに、読み取りエラーやパフォーマンス低下から恒久的損失へと移行した。顧客は、どのディスクに読み取りエラーがあったか、スナップショットが使用可能か、新しいディスクを作成できるか、どの書き込みが回復不能か、新しいワークロードにとってストレージが安全かどうかを知る必要があった。データ消失イベントでは、影響の分類はサービスの可用性だけに関するものではなく、回復可能な状態に関するものである。

ステータスページは、Google がインシデントを解決済みとマークした時点で終了した。スナップショットから復元した顧客にとって、リカバリはアプリケーションの検証、データ調整、最近のトランザクションの潜在的喪失を通じて継続された。この区別は不可欠である。プロバイダーのサービス復旧はストレージサービスが稼働していることを意味する。顧客のリカバリは、ワークロードが一貫性のあるデータセットを持ち、ビジネスが失われた期間を説明できることを意味する。これらは非常に異なる時間軸であり得る。

スナップショットガイダンスは、責任共有が具体的になる場面

インシデント中、Google のステータス更新は、影響を受けた顧客にスナップショットから復元できると伝えた。この推奨は、使用可能なスナップショットを持っている顧客にのみ役立つ。存在しない、古すぎる、間違ったロケーションにある、アプリケーションの一貫性がない、またはテストされたことがないスナップショットは、リカバリパスではない。したがって、このインシデントは、クラウドの一般的なフレーズである責任共有を具体的な問いに変えた。物理イベントの前に、誰が実際にリカバリポイントを作成し、検証していたのか？

Google の現在のディスクとインスタンスのデータ保護オプションガイドは、リカバリ時間目標、リカバリポイント目標、ユースケース、コストを中心にリカバリを枠付けしている。スナップショット作成ドキュメントでは、標準スナップショットとアーカイブスナップショットを説明している。スナップショットの概要では、増分スナップショットについて説明している。スケジュールされたスナップショットガイドは、バックアップ手法としてスケジュールを推奨し、スナップショットのベストプラクティスページでは、実用的な制約と信頼性に関するアドバイスを追加している。この現在のドキュメントは、初期のクラウド時代の多くの前提よりも明確である。

アプリケーションの一貫性は、依然として顧客の関心事である。ディスクスナップショットはブロック状態をキャプチャするが、データベースは、復元された状態を使えるようにするために、静止、フラッシュ、または調整されたバックアップ操作が必要な場合がある。Google のアプリケーション一貫性のある Linux スナップショットのドキュメントでは、ゲストフラッシュを伴うスナップショットスケジュールを説明している。重要な点は、2015年当時と現在の正確な機能セットではない。永続的な制御原則は、リカバリ可能性には、単なるプロバイダーのストレージの約束ではなく、アプリケーションに合わせたバックアッププロセスが必要であるということだ。

小規模チームは、特にこのギャップにさらされる。スタートアップや自治体プロジェクトは、レイテンシとコストを削減するために単一のクラウドゾーンを選択するかもしれない。Persistent Disk 上でデータベースを実行し、製品名とプロバイダーの評判をバックアップ設計の代わりに頼るかもしれない。専任のストレージエンジニア、テスト済みの復元プロセス、ビジネス影響分析を持たないかもしれない。2015年のインシデントは、ドキュメントと製品のデフォルトがなぜ重要かを示している。内部の専門知識が少ない顧客には、障害ドメインの境界を明白にするストレージオプションと警告が必要である。

プロバイダーと顧客の責務は、運用言語で述べられるべきである。Google は、予想される物理的ハザードを乗り切るようにストレージシステムを設計し、明確な障害ドメイン情報を公開し、スナップショットとレプリケーションツールを提供し、インシデント証拠を保存し、影響を受けたリソースを特定すべきである。顧客は、リカバリ目標を選択し、バックアップをスケジュールし、復元を検証し、関連する障害ドメインの外にスナップショットまたはレプリカを配置し、ローカリティ制約がオフゾーンまたはオフリージョンのコピーを許可するかどうかを決定すべきである。どちらの側も、相手の完全な仕事を行うことはできない。

リージョナルディスクとレプリケーションは障害モデルを変えるが、リカバリ思考の必要性は変わらない

Google は現在、リージョナル Persistent Disk と Hyperdisk の高可用性オプションを提供している。リージョナルディスクのドキュメントでは、より高い可用性のためにゾーン間でレプリケートされるディスクについて説明し、リージョナルディスクのフェールオーバーガイドでは、プライマリゾーンに障害が発生した場合の強制アタッチについて説明している。Google の高可用性ワークロードのためのリージョナル Persistent Disk に関するブログでは、可用性のユースケースを明示している。

これらの機能は、多くのワークロードにとって意味のある改善であるが、アーキテクチャ判断を不要にするわけではない。リージョナルレプリケーションは、あるゾーンのゾーン停止やストレージエラーから保護できる。しかし、レプリケートされるアプリケーションレベルの破損、顧客による削除、侵害された認証情報、リージョン全体の制御問題、有用でないほど最近すぎるリカバリポイントからは保護できない場合がある。顧客は依然として、破損、保持、ロールバックのためにバックアップが必要である。レプリケートされたディスクは高可用性メカニズムであり、自動的に完全なデータ保護プログラムではない。

同様の注意がスナップショットにも当てはまる。スナップショットは障害のあるディスクから独立しており、別のゾーンに復元できる。しかし、古すぎる、アプリケーションの一貫性がない、適切なプロジェクトに利用できない、リカバリ環境がアクセスできないキーで暗号化されている、またはポリシーと競合するロケーションに保存されている可能性がある。Google のディスク暗号化ドキュメントは、ディスクとスナップショットが異なるキー選択を伴う可能性があることを顧客に注意喚起している。バックアップ戦略には、スナップショットエントリの存在だけでなく、アクセス、キー、保持、ロケーション、復元テストが含まれなければならない。

Compute Engine の現在の SLAと歴史的な2015年版 SLAは、別の区別を示している。SLA は、定義された条件下でのサービス可用性とクレジットを扱う。これらは、回復可能性やビジネス損失の完全な表明ではない。クレジットは、顧客が依然としてデータを復元し、トランザクションを調整し、ユーザーに通知し、信頼を再構築しなければならない間、サービス料金の一部を補償できる。ステータスページが影響を受けた顧客にスナップショットから復元するよう伝えたという事実は、運用上のリカバリが SLA クレジットの問題の外にあることを示している。

データ主権所有者にとって、レプリケーションの選択には慎重なポリシー作業が必要である。顧客はデータが欧州またはベルギーに留まることを要求するかもしれない。それはすべてのコピーが1つのゾーンに存在しなければならないことを意味しない。サービス条件、規制当局の期待、リスク許容度に応じて、欧州のマルチリージョンや別の欧州リージョンでのスナップショットを許可するかもしれない。逆に、厳格なロケーション要件は、一部のクロスリージョンバックアップを妨げ、より高いローカル可用性設計を必要とするかもしれない。説明責任のある行為は、データが失われる前にそのトレードオフを明示的にすることである。

顧客のリカバリ証拠はインシデントの一部である

プロバイダーのインシデントレポートは、多くの場合、サービス復旧で終わる。データ消失イベントには、第二の台帳、すなわち顧客のリカバリ証拠が必要である。どのディスクに読み取りエラーがあったか？どの書き込みが回復不能だったか？どの顧客がスナップショットから復元したか？どのスナップショットが失敗したか、または古すぎたか？どのアプリケーションが手動調整を必要としたか？どの顧客ワークロードにバックアップがなかったか？恒久的損失と回避策の手順について、どのようなメッセージが顧客に送られたか？この証拠の一部は非公開であるが、そのカテゴリは公的に重要である。

ステータスページの繰り返しの影響割合は、漠然とした安心感を避けるという点で有用だった。影響を受けやすいのが1%未満、読み取り障害が発生しているのが0.1%未満、恒久的損失が0.000001%未満というのは、絞り込まれたカテゴリを記述している。これらを単一の声明に統合すべきではない。影響を受けやすいディスク、積極的に障害が発生しているディスク、回復不能なデータは異なる状態である。各状態にある顧客には異なるアクションが必要である。

顧客はまた、リソース固有の通知を必要とする。一般的なステータスページは、市場に何かが間違っていることを伝える。特定のディスクが影響を受けているかどうかを一人のデータベースオペレーターに伝えることはできない。Google は、影響を受けたリソースを特定し、ストレージシステムを相関させ、アカウントレベルの通知を提供する最も強力な能力を持っていた。顧客は、アプリケーションの一貫性をチェックし、自身のスナップショットから復元し、失われた可能性のある最近のビジネスデータを決定する最も強力な能力を持っていた。両方の種類の証拠が必要である。

この分割は、監査人にとって特に重要である。このようなイベント後にクラウドワークロードをレビューする監査人は、プロバイダーが小さな割合を報告したかどうかだけを尋ねるべきではない。正しい質問は、組織がリカバリポイント目標を知っていたか、インシデント前にスナップショットが存在したか、復元テストに合格していたか、バックアップロケーションがポリシーに合致していたか、アプリケーション所有者が残存損失を受け入れたか、プロバイダーの通知が影響を受けたリソースを分類するのに十分な詳細を提供したかどうかである。答えがノーであれば、障害はプロバイダーのインシデントだけでなく、アーキテクチャガバナンスのギャップでもあった。

調達は、事前に同じ質問をすべきである。このディスクはどの障害ドメインを占有するのか？どのような独立したコピーが存在するのか？誰がスナップショットスケジュールを所有するのか？復元はどのようにテストされるのか？許容できる最大の失われた書き込み間隔はどれくらいか？ローカリティポリシーは別の場所へのレプリカを許可するか？ストレージメディア、電力、または制御システムがデータの耐久性を脅かす場合、プロバイダーはどのような通知を提供するのか？データ消失イベント中のサポートパスは何か？これらの質問は、「クラウドの耐久性」をスローガンからリスク決定に変える。

調達はリージョンをバックアップであるかのように購入すべきではない

ベルギーのインシデントは、一般的な近道を露呈するため、調達にとって特に有用である。バイヤーはデータがどこに存在するかを尋ねる。プロバイダーはリージョンやゾーンで答える。バイヤーはその答えをレジリエンスとして扱う。しかし、ロケーションの答えとリカバリの答えは異なる契約上の質問である。一方は配置を記述し、他方は損失、破損、または利用不能後に何が起こるかを記述する。データの所在地を確保するがバックアップ設計を未定義のままにする契約は、問題の半分しか解決していない。

強力な調達記録は、ストレージを選択する前に、ワークロードの必要なリカバリポイントとリカバリ時間を特定する。ロギングワークロードはある程度の遅延を許容できるが、サイレントロスは許容できないかもしれない。トランザクショナルデータベースは、数分ごとにアプリケーション一貫性のあるバックアップを必要とするかもしれない。公開レジストリは、不変のバックアップとテストされた復元を必要とするかもしれない。小規模な分析プロジェクトは、毎日のスナップショットを受け入れるかもしれない。ストレージ製品、スナップショットスケジュール、レプリカのロケーション、暗号化キー設計、復元演習は、ミッション要件に従うべきであり、その逆ではない。

調達はまた、プロバイダー通知モデルを要求すべきである。ストレージインシデント中、プロバイダーは、顧客がアプリケーションエラーから診断できるよりも前に、ディスクが影響を受けた母集団にあることを知っているかもしれない。契約またはサポートプランは、影響を受けたリソースがどのように特定されるか、復元が推奨されるかどうかを顧客にどのように伝えるか、恒久的損失がどのように報告されるか、ログがどのように保存されるか、テクニカルサポートがどのように優先されるかを指定すべきである。データ消失イベントでは、顧客のアクションがリソース固有であるため、一般的なサービスステータスページでは不十分である。

バイヤーはまた、主権とレジリエンスの間の誤った選択を避けるべきである。多くの欧州のワークロードにとって、別の欧州リージョンにある独立したコピーは、シングルゾーンリスクを低減しながらポリシーを満たす可能性がある。より厳格なワークロードには、国内でのリージョナルレプリケーションや慎重に管理されたバックアップロケーションが必要な場合がある。一部のデータでは、追加コピーのコストと複雑性が不釣り合いな場合がある。説明責任のポイントは、すべてのワークロードが同じ設計を必要とするわけではないということだ。重要なのは、失われた書き込みの結果を理解するビジネスオーナーによって、トレードオフが文書化され受け入れられることである。

監査人はチェックリストの回答を警戒すべきである。「データは欧州に保存されている」は復元できるかどうかに答えない。「Persistent Disk は耐久性がある」は、アプリケーションが最近の書き込み損失を許容できるかどうかに答えない。「スナップショットが利用可能である」は、それらが構成され、最近で、完全で、テストされているかどうかに答えない。「プロバイダーには SLA がある」は、顧客が使用可能なコピーを持っているかどうかに答えない。監査証拠には、復元テストの結果、バックアップの経過時間、バックアップロケーション、キーアクセス、および残存リスクを誰が受け入れたかの記録が含まれるべきである。

小規模チームには、回復可能性を見える化するデフォルトが必要

境界を誤解する可能性が最も高い顧客は、多くの場合、それを越えた場合の回復能力が最も低い。大企業は、ストレージチーム、バックアッププラットフォーム、監査委員会、机上訓練を持っているかもしれない。小規模チームは、エンジニア1人、プロジェクト1つ、リージョン1つ、そしてボリュームを削除せずに仮想マシンを削除できるためディスクが耐久性があるように見えるダッシュボードを持っているかもしれない。彼らのリスクは、軽蔑的な意味での無知ではなく、抽象化がその役割をあまりにうまく果たすことの通常の結果である。

クラウドプロバイダーは、デフォルトと警告を通じてこのリスクを減らすことができる。顧客がデータベース型のワークロード用に単一ゾーンディスクを作成する際、インターフェースはバックアップスケジュールについて尋ね、スナップショットポリシーを推奨し、障害ドメインを示し、独立したリカバリにはスナップショットが必要であることを警告できる。ドキュメントは、信頼性ガイドの奥深くではなく、作成ワークフローの近くに障害ドメイン表を配置できる。価格ページは、バックアップなしのコストをリスク受容として、スナップショットのコストを単なる追加としてではなく示すことができる。

顧客は、シンプルなルーチンでリスクを減らすことができる。すべての永続データストアには、指名された所有者、リカバリポイント目標、スナップショットまたはバックアップスケジュール、復元テスト日、バックアップロケーション、キーアクセス計画が必要である。最初の復元テストは、最初のインシデント中ではなく、本番稼働前に行われるべきである。テストでは、別の環境に復元し、アプリケーションの一貫性をチェックし、チームが認証、復号化、ワークロードの再接続ができることを確認すべきである。チームがリカバリ設計の余裕がない場合、それは意識的なビジネス上の決定であるべきだ。

2015年のイベントは、損失が派手でなかったため、優れた教材である。教訓を不可避にするようなグローバルな崩壊はなかった。割合は微小だった。しかし、影響を受けたディスクが1つで最近のスナップショットがない小規模チームは、依然として恒久的な損失に直面し得る。レジリエンス教育はしばしば大災害に焦点を当てるが、このインシデントは、まれで狭い障害が、テストされていないバックアップの前提を罰するのに十分であることを示している。

同じロジックが、企業が構築する内部プラットフォームにも当てはまる。企業プラットフォームチームは、製品チームに「承認済みクラウドテンプレート」を提供するかもしれない。それらのテンプレートは、単にゾーンディスクを作成し、ストレージレイヤーを理解していない可能性があるアプリケーション所有者にバックアップの選択を任せるべきではない。プラットフォームは、スナップショットスケジュール、レプリケーションオプション、保持期間、復元テストを要求するか、強く導くべきである。企業内部の責任共有は、クラウドプロバイダーとの責任共有を反映する。

データ消失はステータス言語の道徳的重みを変える

多くの停止ステータスは、エラーの増加、パフォーマンス低下、または復旧という観点で記述できる。データ消失には異なる語彙が必要である。顧客は、データが遅延しているのか、利用不能なのか、破損しているのか、ロールバックされているのか、部分的に回復不能なのか、恒久的に失われているのかを知る必要がある。これらのカテゴリは異なる義務を生み出す。遅延データはキュー処理を必要とするかもしれない。利用不能データはフェールオーバーを必要とするかもしれない。破損データは検証とロールバックを必要とするかもしれない。恒久的損失は、通知、調整、補償、または法的レビューを必要とするかもしれない。

Google のステータスページは、読み取りエラー、パフォーマンス低下、スナップショットによる回避策を慎重に移行した。当時の報道は後に、ごく一部のストレージにおける恒久的損失を記録した。影響を受けた母集団の絞り込みは有用だったが、公的な教訓は、恒久的損失が判明したら明確に名指しされるべきだということである。あまりに長く可用性言語に留まるステータスページは、顧客にデータ消失イベントを再試行問題として扱わせる可能性がある。恒久的損失をあまりに広く名指しするステータスページは、不必要なパニックを引き起こす可能性がある。したがって、正確さは装飾的ではなく、顧客の反応を制御する。

ストレージインシデントに関する優れたステータス言語は、影響を受けた製品、ゾーン、時間範囲、リソースクラス、症状、現在の顧客アクション、証拠ステータスを述べるべきである。リスクのあるリソース、読み取り障害が発生していることが判明しているリソース、回復不能データが確認されたリソースを分離すべきである。スナップショット、新しいディスク、リージョナルディスク、その他のストレージ製品が影響を受けているかどうかを述べるべきである。プロバイダーが影響を受けたリソースを直接特定できるかどうか、および顧客にどのように連絡するかを述べるべきである。プロバイダーがサービス修復からデータ調整に移行したときに更新すべきである。

この正確さは、顧客が自身のステークホルダーに報告するのにも役立つ。データ保護責任者、監査人、取締役会、または小規模事業主は、イベントが機密性、完全性、可用性、または回復可能性を変えたかどうかを知る必要がある。2015年のイベントは、狭いディスク母集団にとって可用性と回復可能性の両方の問題だった。これは不正アクセスの証拠ではなかった。すべてのクラウドインシデントを侵害として扱うのは間違いであり、すべてのストレージインシデントを一時的な可用性問題として扱うのも間違いである。カテゴリは事実に合致すべきである。

ローカリティ決定には退出ストーリーを含めるべき

すべてのローカリティ決定には、退出ストーリーを含めるべきである。このゾーン、リージョン、またはローカルストレージの選択が失敗した場合、ワークロードはどこに行き、どのデータがそれに続くのか？2015年に europe-west1-b を選択する顧客は、障害が発生したディスクを別のゾーンで復元できるか、スナップショットが障害が発生したシステムの外に存在したか、アプリケーションが復元されたディスクをアタッチできるか、DNS、認証情報、オペレーターがサービスを復帰できるかどうかを知る必要があった。これらの質問は、製品名や機能が変わった現在でも依然として有効である。

退出ストーリーにはいくつかの部分がある。第一にデータ：どのようなコピーが存在し、どれくらい古く、どこに存在するか。第二にコンピュート：復元されたデータを実行できる環境は何か。第三にアイデンティティとキー：誰がそれにアクセスし、復号化できるか。第四にネットワークとルーティング：ユーザーが復旧したサービスにどのように到達するか。第五に検証：チームは復元されたアプリケーションが正しいことをどのように知るか。第六にコミュニケーション：何が起こったか、どのデータ間隔が欠落している可能性があるかについて、ユーザーとステークホルダーにどのように伝えるか。

ローカリティ制約は退出ストーリーをより複雑にするが、オプションではなくする。データがベルギーに留まらなければならない場合、設計はマルチゾーンのローカルレジリエンス、より頻繁なスナップショット、より強力なオンサイトバックアップ制御を要求するかもしれない。データが欧州内に留まることができる場合、設計は別の欧州リージョンやマルチリージョンスナップショットストレージを使用するかもしれない。ポリシーが災害復旧のためのグローバルバックアップを許可する場合、設計は依然としてプライバシー、暗号化、アクセス制御を処理しなければならない。鍵は、デフォルトのディスク配置が黙って決定するのを許すのではなく、明示的に決定することである。

プロバイダーは、顧客言語で障害ドメインを提示することで、これを容易にすることができる。製品名だけでなく、インターフェースは「VM 削除に耐える」「ゾーンハードウェア障害クラスに耐える」「リージョンレプリケーションを通じてゾーン停止に耐える」「スナップショットを通じてポイントインタイム復元をサポートする」と記述できる。短いフレーズですべてのエッジをカバーできるわけではないが、平易な障害ドメイン言語は、広範な耐久性の形容詞よりも誤読されにくい。

未知の事項と慎重な境界

公開記録は、影響を受けたすべての顧客、すべての失われた書き込み、すべての内部ハードウェアモデル、すべてのインシデント後のエンジニアリング変更を名前で挙げているわけではない。特定の顧客のバックアップ障害がその損失を引き起こしたことを証明しているわけではない。法的違反、過失認定、損害賠償、またはコンプライアンス違反を立証しているわけではない。また、現在の Google Cloud ストレージ製品すべてが2015年と同じリスクを抱えていることを証明しているわけでもない。クラウドインフラと製品機能は、それ以来大幅に変化している。

公開記録は、いくつかの確固たる結論を支持している。このイベントは europe-west1-b の Persistent Disk に影響を与えた。顧客は読み取りエラーを経験した。Google は影響を受けた顧客にスナップショットから復元するよう指示した。Google の説明に基づく当時の報道は、地域電力網への4回の連続落雷、ストレージシステムへの一時的な電力喪失、一部のストレージにおけるハードウェアの脆弱性、および割り当て済み Persistent Disk 領域のごく一部の恒久的損失を記述した。Google はスタックをレビューし、ストレージハードウェアをアップグレードすると述べた。現在の Google のドキュメントは、スナップショット、スケジュールされたバックアップ、リージョナルディスク、データ保護の選択を明示的にしている。

最も重要な推論は支持されているが、推論としてマークされるべきである。より明確な障害ドメインの開示とテストされた独立したバックアップは、物理サイトのハザードが恒久的なアプリケーション損失になる可能性を減らす。これは、スナップショットのないすべての顧客が過失であるとか、Google が法的義務を果たさなかったと言うことと同じではない。これは実用的な制御の結論である。プロバイダーは境界を見える化し、よりレジリエントなインフラを構築できる。顧客は、1つのローカルディスクに依存しないリカバリ設計を選択できる。

このインシデントはまた、2つの反対の誤りに対して警告している。第一はクラウド運命論である。ハイパースケールプロバイダーがかつて少量のデータを失ったからといって、クラウドストレージは信頼できないと結論づけることだ。第二はクラウドの自己満足である。割合が微小だったからといって、誰も独立したバックアップを必要としないと結論づけることだ。成熟した立場は、より要求が厳しく、より有用である。プロバイダーの耐久性を利用するが、それをリカバリポイントと混同しない。ローカリティを利用するが、それをレジリエンスと混同しない。SLA を利用するが、クレジットを復元された状態と混同しない。

実用的な証拠テストは、調達が締結される前に実行できるほど単純である。バイヤーは、ライブディスク、最新の独立したリカバリポイント、復元ターゲット、アイデンティティとキーパス、復元の責任者、直近の成功したテストを指し示すことができるべきである。プロバイダーは、障害ドメイン、リソース固有の通知パス、インシデントステータスのカテゴリ、恒久的損失に直面している顧客のためのサポートパスを指し示すことができるべきである。まれなストレージイベントの前に、どちらの側もこれらの質問に答えられない場合、アーキテクチャは立派な製品名の中に隠された希望に依存している。

だからこそ、2015年の小さなイベントは2026年の説明責任プログラムに依然として属している。それは抽象的な責任共有モデルを、目に見える運用契約に変える。プロバイダーのスタックは今より強力になっているかもしれず、顧客にはより多くのツールがあるが、決定のロジックは変わらない。ローカリティは回復可能なコピーとペアにされなければならず、回復可能なコピーはテストされなければならず、テストされたリカバリは、データが欠落しているときにユーザーに直面するビジネスオーナーによって理解されなければならない。

その決定の最終的な所有者は、インフラの省略形の中に隠されるべきではない。それは、失われた1時間、失われた1日、または失われたトランザクション間隔のコストを理解する指名されたサービスオーナーであるべきだ。

そのオーナーはまた、バックアップに資金を提供する権限を持つべきである。

タイポグラフィとは、書かれた言語を見やすく、読みやすく、視覚的に魅力的にするために文字を配置する芸術および技術である。これには書体、ポイントサイズ、行長、行間、文字間隔の選択が含まれる。

• タイポグラフィは、15世紀に Johannes Gutenberg が活版印刷を発明したことに始まる。
• 主要な要素には、フォント選択、カーニング、トラッキング、行取りがある。
• 優れたタイポグラフィは可読性を高め、デザインにおけるムードやトーンを伝える。

ベルギーのディスク損失の記録は、研究対象として十分小さく、実践を変えるのに十分深刻であるため、依然として有用である。これは、プロバイダー管理の冗長性が物理的ハザードの端で失敗し得ること、ステータスの割合はカテゴリ別に読まなければならないこと、スナップショットは存在しクリーンに復元される場合にのみ意味を持つこと、そしてローカリティは独立した回復可能性の代わりにはならないことを示している。Google はデータセンターとストレージスタックを管理し、顧客はリカバリアーキテクチャを管理し、監査人と調達チームは、次のまれなイベントの前にこれら二つの責任が精査されたかどうかを管理した。説明責任のある結果とは、データがどこに存在し、回復可能なコピーがどこに存在し、それがどれほど新しいか、誰がそれを復元できるか、そしてローカルゾーンがもはや復元できないときにリカバリを証明する証拠が何かを言えるストレージ計画である。