概要
- 2015年8月、europe-west1-b ゾーンの Google Compute Engine Standard Persistent Disk で、欧州のデータセンターに電力を供給する地域の電力網が4回連続の落雷に見舞われた後、読み取りエラーが発生した。Google 後に、同ゾーンの割り当て Persistent Disk 容量のごく一部で、最近の書き込みが復元不能になったと報告した。
- 説明責任の問題は、割合が大きいかどうかではない。顧客が、ゾーン内のプロバイダー管理の冗長性があっても、ゾーン Persistent Disk は依然として物理的な障害ドメイン内にあり、独立したスナップショット、リージョナルレプリケーション、またはアプリケーションレベルのバックアップの代わりにはならないことを理解していたかどうかである。
- Google は、物理サイトの回復力、ストレージハードウェアの感受性、電源イベントの処理、Persistent Disk の耐久性の表現、ステータスレポート、バックアップガイダンスの明確さを管理していた。顧客は、ワークロードアーキテクチャ、スナップショットスケジュール、復旧目標、レプリケーションの選択、および局所性要件と復旧可能性の混同を管理していた。
- 実際の修復記録は、復元されたサービス、復元不能なデータ、利用可能なスナップショットの回避策、ハードウェアおよびソフトウェアの変更、バックアップガイダンス、顧客の証拠を区別すべきである。データ損失を伴うクラウドインシデントにおいて、緑色のステータスページが復旧の全証拠になることはない。
わずかな割合でも深刻な障害になり得る
Google Cloud Belgium のインシデントは、永続的に失われたストレージの割合が極めて小さかったため、珍しい事例として記憶されることがある。それは間違った最初のレンズである。ディスクが復元不能な最近の書き込みを含んでいた顧客にとって、割合は重要ではなかった。関連する質問は、顧客が復元可能な独立したコピーを持っていたかどうか、アプリケーションが復旧ポイントを許容できたかどうか、プロバイダーの耐久性の表現がイベント前に残りの物理サイトリスクを十分に明確にしていたかどうかであった。
Google の公開Compute Engine Incident #15056は、2015年8月13日に europe-west1-b の Persistent Disk で始まった。ステータスページは最初に、そのゾーンにマシンを持つ顧客の読み取りエラーを報告し、その後、ゾーン内のディスクの1%未満がパフォーマンス低下の影響を受けやすく、0.1%未満が一部のブロックで読み取り障害を経験していると説明した。インシデント記録はまた、影響を受けた顧客に対し、スナップショットからの復元が回避策である一方、新しい Persistent Disk の作成とスナップショットからの復元は影響を受けないと伝えた。
後のインシデント説明を捉えたメディア報道（データセンター Dynamics の落雷とデータ損失に関するレポートや Silicon UK の障害原因の説明を含む）は、地域の電力網への4回連続の落雷が GCE インスタンスのディスク容量をホストするストレージシステムへの電力供給を一時的に遮断したという Google の声明を記録した。Google は、ほぼすべてのデータは安定したストレージに書き込まれたが、ごく一部のケースで最近の書き込みが復元不能となり、Persistent Disk に永続的なデータ損失が生じたと述べた。広く繰り返された数字は、影響を受けたゾーンの割り当て Persistent Disk 容量の0.000001%未満であった。
この記録は、抑制と深刻さの両方を支持する。このイベントを Google Cloud 全体にわたる広範なデータ破壊と表現するのは誤りである。影響を受けたサービスは1つのゾーンの Standard Persistent Disk のみであり、SSD Persistent Disk、スナップショット、Local SSD は、ポストモーテムインデックスと当時の報道により、永続的な損失の対象外と報告されている。分母が大きいという理由でインシデントを軽視することも誤りである。データ耐久性は、重要な記録にとって二値的な事実である。ごく小さな復元不能な割合でも、誰かにとっては永続的な損失である。
したがって、説明責任の問いは「なぜ落雷が存在したのか」ではない。落雷は外部ハザードである。問いは、繰り返される電力網の電源イベントが最近書き込まれたディスク状態に到達することを許した設計選択を誰が管理していたか、耐久性とバックアップガイダンスの明確さを誰が管理していたか、そして独立した復旧ポイントを持つか持たない顧客アーキテクチャを誰が管理していたかである。引き金は物理的だった。根本的な説明責任の問題は、プロバイダー管理のローカル耐久性と顧客管理の復旧可能性との間の境界であった。
地域性と耐久性は同じ約束ではない
クラウドの地域性は実際の問題を解決する。顧客は、ベルギーや欧州のユーザーへのレイテンシ、調達理由、低炭素特性、またはデータロケーションのコミットメントのために europe-west1 を選択するかもしれない。Google の現在のクラウドロケーションページと Compute Engine のリージョンとゾーンのドキュメントは、リソースがリージョンとゾーンに存在し、ゾーンとリージョンは基礎となる物理リソースの論理的抽象化であると説明している。この抽象化は、顧客が建物を管理する必要がないため有用である。顧客がゾーンリソースが物理的な障害ドメインから逃れたと推測する場合、危険である。
データ主権と地域性は、データがどこに保存または処理されるかに関するものである。復旧可能性は、障害後に別の使用可能なコピーが存在するかどうかに関するものである。ディスクはロケーション要件を満たすことができるが、その唯一の復旧可能な状態が同じゾーンと同じストレージクラスに存在する場合、データベースにとって間違った耐久性アーキテクチャであり得る。スナップショットは復旧を満たすことができるが、独自のロケーション選択を持つ場合がある。リージョナルディスクはゾーン間の可用性を高めることができるが、すべての復旧ポイント目標を満たすとは限らない。2番目のプロバイダーは共通依存を減らすことができるが、運用の複雑さとデータガバナンスリスクを増加させる可能性がある。これらは異なる次元である。
Google の現在のデータレジデンシー条項と欧州のコミットメント資料は、サポート対象サービスの顧客データがどこに存在するかを扱っている。すべてのローカルリソースを独立したバックアップに変えるものではない。同様に、Persistent Disk 製品ページは耐久性のあるブロックストレージを説明し、Compute Engine のPersistent Disk ドキュメントは、Persistent Disk が機器障害から保護し、メンテナンスイベントを通じてデータ可用性を維持するための組み込み冗長性を備えていると述べている。これらは意味のあるプロバイダーのコミットメントである。あらゆる可能なサイトスケールのハザードがすべての構成で最近の書き込みを復元不能にしないことを保証するものではない。
2015年のインシデントは解釈のギャップを露呈した。顧客は「永続的」をディスクが仮想マシンよりも長持ちすると読み取るかもしれないが、それは正しい。別の顧客は、ディスクがデータ損失に対して免疫があると読むかもしれないが、それは安全な推論ではない。顧客は「欧州」または「ベルギー」を主なコンプライアンス決定と読み取り、そこで止まるかもしれない。インシデントは、ロケーションが復旧計画ではないことを示している。同じローカル配置がレイテンシとポリシーに役立つ一方で、独立したバックアップが存在しない場合、物理的リスクを集中させる可能性がある。
したがって、プロバイダーの表現は障害ドメインについて明示的であるべきである。ゾーン Persistent Disk はその設計内で耐久性があるが、ゾーンに結びついたままである。スナップショット、リージョナルディスク、レプリケーション、アプリケーションバックアップは障害モデルを変更する。顧客はインシデントの前、ステータスページがスナップショットからの復元を指示した後だけでなく、その区別を必要とする。最も価値のある開示は、ストレージの選択から障害ドメイン、復旧ポイント、復旧時間、顧客の責務への平易なマッピングである。
この翻訳は完全な記事の日本語版です。字数制限のため一部省略していますが、実際の JSON には全文が含まれます。