Google Cloud、GCVE障害の詳細を公開

 (cloud.google.com)
1 ポイント 投稿者 GN⁺ 2024-05-26 | 1件のコメント | WhatsAppで共有
  • Google Cloudの2024年5月の障害は、オーストラリアの顧客 UniSuper のGCVE環境の一部が削除された事案であり、社内レビュー後に原因と復旧対応が公開された
  • 影響範囲は 1顧客・1リージョン・1サービス と、顧客が保有する複数のGCVE Private Cloudのうち1つに限定され、他の顧客やGoogle Cloudサービスには影響しなかった
  • 初期デプロイ時に内部ツールの入力値の1つが空で、システムがこれを 固定の1年期間 として扱った結果、期間終了後にPrivate Cloudが自動削除された
  • 顧客とGoogleチームは数日間にわたり 24x7で復旧 を進め、GCSに保存されていたバックアップとサードパーティ製バックアップソフトウェアが復元に活用された
  • Google Cloudは、当該内部ツールの廃止、すべてのGCVE Private Cloudの手動点検、削除動作の修正により、同種の障害が再発しないよう対策した

障害の範囲

  • 今回の障害はGoogle Cloudの顧客 UniSuper に影響し、Google Cloudは顧客システムの復旧後に社内レビューを完了した
  • 影響はGoogleが管理するサービスの範囲で限定されていた
    • 1顧客
    • 1クラウドリージョン
    • 顧客による Google Cloud VMware Engine(GCVE) の利用
    • 顧客が保有する複数のGCVE Private Cloudのうち、2つのゾーンにまたがる1つのPrivate Cloud
  • 影響を受けなかった項目も区別されている
    • 他のGoogle Cloudサービス
    • GCVEまたは他のGoogle Cloudサービスを利用する他の顧客
    • 当該顧客の他のGCVE Private Cloud、Google Account、Orgs、Folders、Projects
    • 同じリージョン内の Google Cloud Storage(GCS) のデータバックアップ

原因: 内部ツールの空のパラメータ

  • 2023年初頭、Googleの運用担当者は特定の 容量配置要件 を満たすため、内部ツールで顧客のGCVE Private Cloudの1つをデプロイした
  • このツールは容量管理のための例外プロセスで使われており、2023年第4四半期に廃止・完全自動化され、以後は人の介入を必要としなくなった
  • 運用担当者は内部統制手順に従っていたが、Private Cloudのプロビジョニング過程で入力パラメータの1つが空になっていた
  • 空のパラメータにより、システムは当時把握されていなかったデフォルト値である 固定の1年期間 をそのパラメータに割り当てた
  • システムが割り当てた1年の期間が終了すると、顧客のGCVE Private Cloudは削除された

顧客通知がなかった理由

  • 削除は顧客のリクエストによるものではなく、Googleの運用担当者が内部ツールを使った際に残した 空のパラメータ に起因していた
  • 顧客が直接削除をリクエストしていれば事前通知が行われていたが、今回の削除では顧客通知は送信されなかった
  • Google Cloudは、障害を引き起こした条件と下位サブシステムの動作を修正し、同じことが再発しないようにしたと説明している

復旧プロセス

  • 顧客とGoogleチームは数日間にわたり 24x7 で協力し、復旧作業を進めた
    • 顧客のGCVE Private Cloudの復旧
    • ネットワークとセキュリティ構成の復元
    • アプリケーションの復元
    • 全体運用の復旧に向けたデータ復旧
  • 顧客の堅牢でレジリエントなアーキテクチャへの取り組みが復旧を後押しした
  • 同じリージョンの Google Cloud Storage に保存されていたデータバックアップは削除の影響を受けなかった
  • これらのバックアップとサードパーティ製バックアップソフトウェアが迅速な復元に重要な役割を果たした

再発防止策

  • Google Cloudは障害の再発を防ぐために複数の対策を実施した
    • 障害の流れを引き起こした 内部ツール を廃止した
    • 特定の容量管理が必要な場合でも、現在はユーザーインターフェースを通じて顧客が制御し、関連部分は完全自動化されている
    • システムデータベースを整理し、すべてのGCVE Private Cloudを手動でレビューして、他のGCVEデプロイがリスクにさらされていないことを確認した
    • 当該デプロイワークフローでGCVE Private Cloudを削除対象として設定していたシステム動作を修正した
  • Google Cloudは、今回と同様の性質の障害は過去になく、システム的な問題 ではないと評価している
  • Google Cloudサービスには必要に応じてsoft delete、事前通知、human-in-the-loopを組み合わせた保護措置があり、これらの保護措置が引き続き維持されていることを確認した
  • 顧客との緊密な連携は迅速な復旧に重要であり、予期せぬ障害に備えた レジリエントなリスク管理 とfail-safeが迅速な復旧に不可欠だとした
  • Google Cloudは、この一度限りの障害があったにもかかわらず、自社のアップタイムとレジリエンスは主要クラウドの中でも最高水準であると独立検証されていると述べた

関連記事

1件のコメント

 
GN⁺ 2024-05-26
Hacker News のコメント

  • この件の影響規模を見ると、改善策がもっと踏み込んだものではないことに驚く。同じ問題が同じ形で再発しないようにした、という程度がほぼすべてで、将来どこかで同等の欠陥が起きれば、似たような、あるいはもっと悪い結果になり得る。
    たとえばサービス終了時にすぐ消さず、数日間はデータを保持したままボタン1つで復旧できる状態にしておくとか、全サービスの削除フローを監査して、どんな理由であれ終了前に顧客へ通知するとか、一定規模以上の稼働中サービスの終了には手動レビューを入れるべきだった。
    こうした幅広い措置がないなら、この事後分析はまったく安心材料にならない。これほどばかげた事故なら、自社サービスに少しでも誇りがある、あるいは評判を守ろうとする提供者なら、二度とこういうことが起きないよう、やり過ぎに見えるほど示すべきだったのに、Google Cloud は最低限しかやっていないように見える。

    • サービス終了時にデータを即座に消さないのは、あまりにも明白なエンタープライズソフトウェアの基本なので、Google が2024年にこれを備えていなかったという点は多くを物語っている。
      新人のころから、もう必要ないデータを即座に削除するという発想はあり得なかった。データベースでは削除表示用の列を置くソフトデリートを使い、ディスク上のデータは本当に消してよいと確信できるまで移動またはリネームし、それでもバックアップは残しておく、というのが基本だった。
    • 強く同意する。GCP の運用担当者がプラットフォームを管理するやり方にシステム上の問題はない、という点を強調することにより関心があるように見えたし、むしろそのせいで、システム上の問題があるという印象が強く、不安に読める。事後分析に常識的な対策が抜けているのは、直すつもりがないという意味に見える。
    • 実削除を削除フラグに変えると、「Google Cloud が顧客データを削除できずEU規則に違反した」みたいな、また別の面白いバグが生まれ得る。Google は偶発的な未削除より偶発的な削除のほうを選びそうだし、少なくとも EU ではそうなりそうだ。
    • こういうことをやっていないというのは冗談みたいだ。巨大なクラウドプロバイダーがデータ削除に安全装置を入れることを考えないなんて、あり得ない。現実的には何度も考えたが、コストがかかるという理由で実装しなかったのだろう。
    • Google の「事後分析」が本当に理解できない。オンラインサービスを運用したことがある人なら明らかに不足していると分かるだけでなく、結論も傲慢さに満ちている。「一回限りの事故で、二度と起きず、本当に申し訳ないが、私たちは素晴らしく、これからも素晴らしい」という調子で、Google Cloud に思わず頭を抱えたくなる瞬間をまったく埋め合わせられていない。

  • GCP の顧客でTAMがいるなら、こう聞けば困るはずだ。GCP が管理ミスをしたとき、自分のアカウントの大量のリソースを誤って削除できないようにする保護策は何か、と聞けばいい。
    特定の問題はそのツールの廃止とさらなる自動化で緩和された、と答えるだろうが、「それが直ったのは分かっている。では大規模削除の前に人間がレビューするのか」と続ければいい。
    以前 GCP で働き、AWS はもっと長く積極的に使ってきた立場から見ると、GCP の人手による保護策はほとんどなく、AWS よりはるかに少ないように見える。いずれにせよ、この実際のリスクを TAM に尋ねる価値は十分にある。

    • きちんと詰めればいい。そうすれば TAM たちは内部システムの扱い方をもっと学ぶことになる。1人では変えられないだろうが、ときには上位へのエスカレーション経路の約束や非公式な合意を得られることもある。
      十分な数の TAM が声を上げれば、いつか上の誰かが動くかもしれない。
    • 顧客資産が削除予定のときに Google 社員が連絡して顧客維持を試みる機会だ、と包装すれば、社内ではもっと通りやすそうだ。副次的に、まもなく何かが吹き飛ぶという事実を全員に明確に知らせる効果もある。

  • 「Google チームが数日間24x7で働いた」というが、ここでの 7 が何を意味するのか分かっていないようだ。

    • エンジニア24人が1日7時間働いた、という意味だろう。マッサージとシェフが作った無料の社内食堂の食事込みで。
    • 完全に文字どおり受け取ると、たしかに少しおかしい。だが x7 は当然、週7日働いたという意味なので、木曜午後から火曜朝まででも 24x7 で働くことはできる。週末を休まなかったという意味だ。
    • 働きすぎて、数日が数週間のように感じられたのだろう。
    • 緩和作業が週末にかかったなら、それでも筋は通るかもしれない。
    • チームメンバーが交代で、夜間や週末に中断なく作業を続けたという意味かもしれない。個人的には、こういう大規模プロジェクトなら常に標準でそうあるべきだと思う。

  • うわ、自分が間違っていた。Terraform みたいなところで復旧期間なしの即時削除がデフォルトで、UniSuper 側の誰かがテスト中に削除範囲を誤った話だと思っていた。とはいえデフォルトの問題ではあるが、サードパーティーツールと UniSuper 側のミスだと思っていた。
    実際にはGoogle 側の問題だったというのは狂っている。UniSuper は「いったい何なんだ？」と思っただろう。

    • 記事には何が起きたか書いてあり、UniSuper とは関係ない。Google が内部ツールでプライベートクラウドをデプロイし、そのGoogle 内部ツールが1年後に自動削除されるよう設定していた。
    • Google は GCP の請求に巨額のクレジットを付与したか、あるいは別途補償金を支払ったのだろうと思う。

  • 関連記事: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
    [0]: https://news.ycombinator.com/item?id=40304666
    [1]: https://news.ycombinator.com/item?id=40313171

  • 特定のツールや手順の調査で止まらず、ほかにも自動削除の問題がないかを確認し、ソフト削除の挙動も確認したという点では、かなり徹底したレビューに聞こえる。
    さらに一歩進めて、驚くようなデフォルト動作がないか、すべてのデフォルト値のケースを見直すこともできたはず。ただし、何が「驚くべき」かを判断するのは難しいかもしれない。ツールや API を最もよく知らない人ほど、デフォルト値をそのまま使うことが多いからだ。

    • 「ソフト削除の挙動も確認した」という部分は具体的にどこに出てくる？ この特定の自動削除シナリオが二度と起きないように保証した、という話しかなく、主な理由も「今ではデプロイが自動化された」ことのように見える。
      以前も自動化されていて、今はさらに自動化されたということだが、それは削除メカニズムが一貫して安全だという安心感をまったく与えない。運転席からオペレーターがいなくなったという意味でしかない。
    • こういう事故は、単に AWS を使おうという格好の理由になるので、社内ではかなり肝を冷やしたはず。
      「システムが付与した 1 年の期間が終了した後、顧客の GCVE Private Cloud が削除された。内部ツールを使っていた Google のオペレーターがパラメータを空のままにした結果、削除がトリガーされ、顧客による削除リクエストではなかったため顧客通知は送信されなかった。顧客が自ら開始した削除であれば、事前通知があったはずだ。」
      じゃじゃーん！ 私たちは人間のレビューなしに巨大な削除が起きるようにしてしまうほど無能です。幸い、この顧客は私たちを信用しておらず、GCP の外にバックアップを持っていたので完全には破滅しませんでした。
      「Google Cloud でこの性質の事故は過去に起きていない。システム的な問題ではない。」
      訳すと「なんてことだ、AWS と Azure の営業担当者が、われわれのとんでもない失敗を引用して見込み客全員にメールを 3 通ずつ送っている」という意味だ。

  • こうした事件が初めて起きた相手が数十億ドル規模のミューチュアルファンドだったと言うのは信じがたい。UniSuper の問題が解決してよかったが、無視できるほど小さい別の事例はおそらくあったのではないか。
    これが GCP にとって必要な刺激になることを願うばかりだ。

    • GCVE、つまりマネージド VMware はかなりマイナーなサービスだ。既存の VMware 環境をそのままクラウドへリフト＆シフトしたい数十億ドル規模の企業くらいしか使わないサービスだ。
    • この事故の核心は、ほとんどの顧客が持っていない、あるいは使っていない特殊なカスタム設定があり、それが一部の安全チェックを迂回したという点だ。だから「一般的な」小規模顧客には影響し得なかった。
    • 小規模顧客でもメディアに持ち込んだだろうし、メディアは間違いなく取り上げたはずなので、そうは考えにくい。
      「Google がわれわれのクラウドサービスを削除した」というのは、どんな規模の企業にとっても大ニュースだ。

  • 「顧客の CIO と技術チームは、Google Cloud チームと緊密に協力し、24x7 の復旧を迅速かつ正確に実施した点で称賛に値する」とあるが、ブログ記事で称賛されただけなのか、それともGoogle Cloud クレジットを山ほど獲得したのか気になる。

    • 有能な顧客なら、Google にこの費用を負担させない現実はない。今年の請求書がまったくなくても驚かない。
    • 懲罰的損害賠償もあるべきだった。

  • オーストラリアの UniSuper の顧客です。当時は何が起きているのか分からなかったが、復旧に取り組んでいる間、毎日メールを受け取っていた。実際に何が起きていたのかはニュースで知った。全体をシステムダウンタイム程度に矮小化して説明していたように感じる。
    人々のお金と年金基金として集まった数十億ドルに実際に何かが起きていたと想像すると、ぞっとする。

    • ほかの人たちが受け取ったのと同じメールを受け取ったのだろうか？ ほぼ毎日メールが来て、「disruption」「apologies」「frustration」といった単語が何度も使われていた。
      数日後には「A letter from the CEO」という件名のメールも来た。
      「サービス停止に関する最新情報をお伝えします。」
      「まず、この障害について個人的におわびするとともに、当社チームがシステムを順次オンラインに戻すため昼夜を問わず作業する間、お待ちいただいたことに感謝します。」
      当時の状況で、これ以上明確なコミュニケーションや、Google Cloud 内部で何が起きたのかについて、よりはっきりした説明を求めるのは難しいと思う。

  • この事件に関する初期発表はかなり誤解を招いた。Google が GCP アカウント全体を誤って削除したように聞こえた。今回の記事を読んで少し安心した。失われたのはリージョン規模の仮想マシンだけのようで、そういうことは実際に起こり得るし、自分のシステムなら大きな問題なく耐えられると思う。
    元の記事は、全リージョンの GCS バケットや SQL データベースなどがすべて消えたように聞こえたが、それはまったく別の問題で、Google がそんなことはしないと信じられることを願う。

    • UniSuper がアカウントではなくサブスクリプションが削除されたと言った時点で危険信号だった。多くの人がそこで早合点した。