Google Cloud、顧客のシステムを間違って全削除した大規模障害の原因を報告。プライベートクラウドの期間を1年と設定ミス

2024年5月28日

Google Cloudは、同クラウドユーザーであるオーストラリアの年金基金「UniSuper」で発生した大規模障害の原因について報告する記事「Sharing details on a recent incident impacting one of our customers」を公開しました。

fig

今月(2024年5月)初旬、Google Cloud上で稼働していた数百の仮想マシン、データベース、アプリケーションを含むUniSuperのプライベートクラウドが突如として原因不明のまま削除され、復旧されるまでの数日にわたってシステムが利用できなくなるという大規模障害が発生しました。

今回の報告では、実際になぜこのような大規模障害が発生したのか、その原因と復旧の経緯について明らかにされています。その概要を紹介しましょう。

Google Cloud VMware Engineの設定を間違う

UniSuperのシステムは、Google Cloud上のマネージドなVMware環境であるGoogle Cloud VMware Engine(GCVE)上のプライベートクラウドとして構築されていました。

そして今回の障害の直接の原因は、このプライベートクラウドがGoogle Cloud側の設定ミスによって丸ごと削除されてしまったことです。

具体的には、Googleのオペレータによってプライベートクラウドのプロビジョニングの有効期間が間違って1年と設定されてしまいました。その結果、先日その1年後がやってきて、何の事前通知もなくプライベートクラウドが削除されてしまったのです。

この設定ミスが起きた背景について、次のように報告されています。

In early 2023, Google operators used an internal tool to deploy one of the customer’s GCVE Private Clouds to meet specific capacity placement needs.

2023年初頭、Googleのオペレータは内部ツールを利用し、お客様のGoogle Cloud VMware Engineプライベートクラウドが指定されたキャパシティ配置の要求に対応しました。

つまりUniSuperが指定したGoogle Cloud VMware Engineプライベートクラウドのキャパシティ設定の裏側で、Googleオペレーターがツールをマニュアルで操作し対応したわけです。ここでミスが発生しました。

Google operators followed internal control protocols. However, one input parameter was left blank when using an internal tool to provision the customer’s Private Cloud. As a result of the blank parameter, the system assigned a then unknown default fixed 1 year term value for this parameter.

Googleのオペレータは内部管理手順に従って操作しました。しかし、お客様のプライベートクラウドをプロビジョニングをするための内部ツールを使用する際、入力パラメータの1つが空白のままでした。その結果、システムはこのパラメーターにデフォルトとして1年間固定という期間の値を割り当てたのです。

このようにGoogleは今回の障害について、自社のミスが原因であると全面的に認めています。そして現在は自動化が進んで、このツールは既に使われておらず、このようなミスが今後起きることはないとしています。

ちなみに、今回の障害で顧客のアカウントが削除されたとの報道が一部でありましたが、少なくとも今回の報告の中でアカウントが削除されたという説明はなく、プライベートクラウドのサブスクリプション期間が終了し、それによって自動的に削除が行われたと説明されています。

地理的に離れて二重化されたシステムが両方とも削除される

顧客であるUniSuperは、障害に備えて2つの地域に分散したシステムの二重化を行っていました。年金システムという重要なシステムでは当然の対応と言えるでしょう。

しかし、上記のプライベートクラウドの自動削除機能は、この二重化されたシステムを両方とも削除してしまったと、Google CloudとUniSuperの当初の共同声明で明らかになっています

UniSuper had duplication in two geographies as a protection against outages and loss. However, when the deletion of UniSuper’s Private Cloud subscription occurred, it caused deletion across both of these geographies.

障害や紛失に対する保護として、UniSuperは2つの地域に渡ってシステムを二重化していました。しかしプライベートクラウドの削除は、これらの両方の地域にわたって行われたのです。

これにより復旧作業は長期化し、両社は24時間体制での復旧体制を組みます。

結局、データのバックアップは同リージョン内のGoogle Cloud Storageに残っており、それが復旧の助けになったとのことです。

Data backups that were stored in Google Cloud Storage in the same region were not impacted by the deletion, and, along with third party backup software, were instrumental in aiding the rapid restoration.

同じリージョンのGoogle Cloud Storageに保存されていたデータのバックアップはサードパーティのバックアップソフトウェアとともに削除の影響を受けておらず、迅速な復元に役立ちました。

原因の内部ツールを廃止に、レビューもやり直す

Google Cloudは今回の障害の原因となった内部ツールを廃止してワークフローを自動化。さらに既存のGoogle Cloud VMware Engineの設定などをすべてレビューしなおして問題がないかを確認するなど、今後二度とこうしたことが起きない体制を作ったとしました。

あわせて読みたい

Google Cloud クラウド クラウド障害 Google




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本