Google Cloudの18時間に及ぶ書き込み障害、容量対応ルーティングの弱点を示す

要約

• 10月8日と9日のCloud Storage障害は、us-central1とus-central1-bで合計18時間11分続いた。公表された症状は主に書き込みに表れた。
• Googleは初回を容量を考慮する経路制御を迂回した最適化、再発を不完全なロールバックに起因すると説明した。影響した顧客名や損失額は公開されていない。

クラウドストレージの障害は、データの複製先を問う話になりがちだ。Googleの記録が示すのは、保存オブジェクトになる前の書き込み要求が、どの経路を通るのかという問題である。10月8日、us-central1を利用するCloud Storageの顧客は、書き込み遅延とエラーの増加を12時間30分経験した。翌日、us-central1-bゾーンで5時間41分の再発があった。合計は18時間11分だが、途中で復旧を挟んだ二つの事象であり、18時間連続の停止ではない。

公開された症状は限定されている。Googleによると、顧客が主に見たのはWriteObject操作のHTTP 503 UNAVAILABLEとクライアント側のタイムアウトで、成功した書き込みも通常より大幅に遅かった。最終報告は、今回の事象について他のCloud StorageリージョンとGoogle Cloudの他サービスは影響を受けなかったとしている。初期報告には読み取りへの軽微な影響も記されたが、最終の影響要約は読み取りを数値化していない。したがって確認できるのは、一つのリージョンの書き込み経路で局所的な問題が起き、再発時は一つのゾーンに絞られたことだ。リージョン内の全顧客、全書き込み、保存済みオブジェクトの損失まで示すものではない。

Googleは最初の引き金を、局所的な容量不足への対処を狙ったトラフィック分類の設定変更と説明する。その最適化は通常の容量対応ルーティングを迂回した。その結果、処理余力の小さいバックエンドノードの一部に書き込み要求が偏った。ノードの資源が枯渇し、オブジェクト取り込みサービスがタイムアウトを起こし、そこへ振り向けられた要求が遅延または失敗した。最初の障害期間には、別のデータベース問題が一部のメタデータ処理エラーを加えた。単一部品の故障というより、配分変更による負荷集中とメタデータ側の問題が重なった構図である。

翌日の再発は、運用面で最も重い記録だ。Googleはアップロード計画機能のロールバックが不完全で、負荷分散が崩れ、小規模なバックエンドノードが過負荷になったと説明した。最初の復旧策は従来の安全状態を完全には取り戻していなかった。これはすべてのロールバックが信頼できないという証明ではないし、より広範なリージョン障害があったという意味でもない。ただ、インシデントの終息と設定の復元は別の判定だと示す。サービスが戻っても残った変更が同じ故障経路を温存することがある。

復旧手順は、容量追加が万能な非常手段ではないことも示した。Googleは当初、緊急容量を追加しようとしたが、リージョンの容量上限に阻まれたという。技術者は過負荷ノードからトラフィックを抜き、最適化を無効化または撤回し、別のデータベース更新も戻して要求経路を切り替えた。負荷と利用率が安定してから、退避したノードを再び稼働させた。リージョンが必要なときにすぐ拡張できないなら、ルーティング、トラフィック分離、正確なロールバックが残る制御手段になる。

Cloud Storageの公開資料は、事故の意味を限定しながら読む助けになる。Googleは、リージョンバケットのデータを選択したリージョン内の少なくとも二つのゾーンに冗長保存すると説明する。デュアルリージョンとマルチリージョンでは、最初の書き込みを一つのリージョン内の二つのゾーンに保存した後、リージョン間で非同期に複製する。広域の配置では地域障害時に別リージョンから自動提供するとする一方、複製が非同期であることも明記している。一貫性に関する資料は、成功応答を得たオブジェクトは直ちに読み取り可能だと説明する。しかし、障害に遭った顧客がどのバケット配置を使っていたかは分からない。

この境界は崩してはならない。報告はマルチリージョン複製の失敗、データ損失、地理的なコピーの利用不能を述べていない。記録されたのは、新しい書き込みを受け付ける経路のボトルネックだ。地理的冗長化は場所に固有の障害リスクを下げるが、書き込みサービスが共有するソフトウェアと容量制御への対策は別に必要になる。ストレージの耐障害性は一つの属性ではない。コピーの耐久性、書き込み受付、メタデータ処理、読み取り、アプリケーションの復旧にはそれぞれ異なる依存関係がある。

Googleが発表した予防策もその連鎖をたどる。負荷分散の変更を大規模で高利用率のリージョンへ展開する前に、小規模リージョンで検証する。トラフィック処理が事前の容量確保策を迂回できないようにする。利用率の高いストレージセル内でデータをより速く移動できるよう改善する。いずれもGoogleが述べた今後の施策であり、完了を外部が確認した制御ではない。公開記録にはテスト結果、影響した要求数、顧客名、バケット配置の内訳、損失額がない。ここから言えるのは、ルーティング最適化と不完全なロールバックが局所的な容量保護を二度突破した一方、地理的冗長性の適用範囲は別の問いとして残ったことだ。

出典：Googleの最終事故報告、Cloud Storageの可用性と耐久性、バケットのロケーション、一貫性, 再試行戦略。