Google Cloud、豪州の取引ファンドのインフラを削除
オーストラリアの巨大退職金基金が Google Cloud の誤削除により全データ喪失の危機に直面し、他社バックアップのおかげで救われた事案は、クラウドベンダー依存リスクとマルチクラウド戦略の重要性を浮き彫りにした。
キーポイント
リージョン間複製機能の致命的欠陥
Google Cloud は通常、地域障害を防ぐために複数リージョンにデータを複製するが、今回の件では削除コマンド自体が複製されたデータにも適用され、冗長性が完全に無効化された。
他社バックアップによる救済
UniSuper は Google Cloud への信頼を完全に捨てず、外部プロバイダーにバックアップを持っていたことで、2 週間のダウンタイムと全データ喪失を回避し、サービスの復旧を果たした。
CEO の異例の責任受諾
通常は双方の過失が問われるケースだが、Google Cloud CEO Thomas Kurian が公式発表で全ての責任を Google 側が負うという異例の声明を出し、信頼回復に努めた。
クラウド依存リスクの再認識
単一のクラウドプロバイダーへの依存は、稀なバグやアカウント停止時に致命的となり得るため、大規模組織における「Plan B(マルチクラウド/オンプレミス)」戦略の必要性が再確認された。
ブランド信頼性の損傷
最大615,000人のオーストラリア人が、UniSuperとGoogle Cloudを「信頼できないもの」として認識するようになった。
競合他社との比較におけるGCPの弱点
地域障害への対応が遅く、ゾーン障害がリージョン全体に波及し、データ消失に至るなど、主要クラウドプロバイダーの中で最悪の結果を記録している。
マルチクラウド戦略の重要性
高価値なデータを扱う場合、Google Cloudへの依存を避け、他のクラウドやオンプレミス環境にバックアップを持つことが不可欠である。
影響分析・編集コメントを表示
影響分析
この事象は、クラウドネイティブアーキテクチャにおける「単一障害点」の概念を再定義するものであり、ベンダーロックインの危険性を浮き彫りにしました。特に金融機関のような大規模データを持つ組織にとって、クラウドプロバイダーの内部エラーに対抗するための独立したバックアップ戦略(Plan B)が、単なる冗長化ではなく生存戦略として必須であることを示しています。
編集コメント
クラウドの信頼性が高いと信じている企業ほど、この種の「ブラックボックス化されたリスク」に無防備になりがちです。今回の教訓は、技術的な冗長化だけでなく、組織レベルでの戦略的バックアップ計画の重要性を強く示唆しています。
オーストラリアの1240億ドル規模のファンドは、サードパーティ製のバックアップに依存していなければ、Google Cloud に保存されていたすべてのデータを失っていたでしょう。これは GCP における稀な過ちであり、地域間レプリケーションが削除を防げなかった事例です。また、Google Cloud の CEO が責任を認めたという極めて珍しい声明も出されました。
以下は、2024年5月16日に最初に公開された『The Pulse #93: OpenAI makes Google dance』からの抜粋です。私はこれを再掲載します。なぜなら、2026年5月20日、Google Cloud は再び同様の過ちを犯したからです。彼らは Railway の Google Cloud アカウントをブロックすることで、オフラインクラウドインフラプロバイダーである Railway を停止させたのです。以下は警告です:もしあなたが GCP を利用しているなら、GCP があなたのアカウントやデータを削除・ブロックした場合に備えて、必ずプラン B(代替案)を用意してください。
Google Cloud がクラウドプロバイダーの中で第3位の遠く離れた位置にあるという状況から、最近の出来事が、同社がトップ3の中で最も信頼性が低いという評判を確固たるものにする可能性があります。
UniSuper はオーストラリアで最大の退職金貯蓄口座の一つであり、615,000人の市民に利用されています。これは「スーパーアニュエーションファンド(年金基金)」としても知られています。UniSuper の運用資産は1240億ドルに達し、国内でも最大級の規模を誇ります。
4月29日、同サービスで障害が発生しました。会員はオンライン口座へのログインや資金管理ができず、その状態が2週間後の5月15日まで続きました。
その理由は、Google Cloud が誤って UniSuper のサブスクリプションを削除し、それに関連するすべてのデータも同時に消去してしまったことによるものでした。UniSuper は地域障害に備え、Google Cloud 内の2つのリージョン間でレプリケーションを設定していましたが、なんと Google Cloud はそのレプリカさえも削除してしまいました!
UniSuper がデータの損失を免れたのは、Google 以外の別のサービスプロバイダーにバックアップを持っていたおかげです。驚くべきことに、クラウドプロバイダーの障害により、もし UniSuper が Google のみに依存していたらすべてのデータを失っていたはずです。UniSuper がサービスを復旧できた唯一の理由は、データバックアップを保持していた別のプロバイダーが存在したからです。つまり、Google の2地域間レプリケーションへの信頼が誤りだったという UniSuper の判断は、100% 正しかったのです。「Google が失敗した場合に備えたバックアップ」のために追加のリソースを投入する決定を下した人物こそが、退職基金の危機を救ったと言えます。
この事案は Google にとって非常に恥ずべき出来事です。UniSuper は、Google Cloud の CEO トーマス・クリアンとの共同声明の発行を通じて、Google Cloud に行動を迫ったようです。その中で Google Cloud は今回の失敗に対するすべての責任を引き受けています。私の経験則では、このような状況が白黒はっきりしていることは稀で、通常は両当事者の何らかの要因が重大な障害を引き起こすものです。UniSuper のスタッフがこの失敗に関与していた可能性も否定できませんが、Google Cloud には十分な過失があり、プレスリリースですべての責任を転嫁することが可能でした。私は Google Cloud に、このプレスリリースが本当に共同発表であったか、追加する事項はないかと尋ねましたが、同社は「プレスリリースは正確であり、追加事項はない」と確認しました。
どちらに非があるにせよ、主要なファンドにとって 2 週間のダウンタイムは非常に長いです。私の理解では、UniSuper への被害は主に評判に関わるものであり、資金自体は安全かつ確実であると考えられています。
ユーザーは数週間、自分の残高を確認できず、Google Cloud が事態を混乱させたのだと聞かされました。これは、最大で 615,000 人のオーストラリア人の心の中に、UniSuper と Google Cloud が信頼できないものと不可分に結びついてしまったことを意味します。
Google Cloud がクラウドに何を提供したいのかについて、明確な戦略を持っていないという話をよく目にします。数ヶ月前、AWS、Azure、GCP が地域的な障害に対応する方法を掘り下げた際、GCP にはプロセスに従う以上の戦略が見えず、3 つのクラウドプロバイダーの中で最も印象に残らない対応をしていると結論付けました。地域障害への対応で最速であることが市場シェア獲得に不可欠であり、また、地域レプリケーションが行われているにもかかわらず、ゾーン障害がリージョン全体をダウンさせたり、顧客データをすべて失ったりする原因となるようなプロバイダーでは、市場シェアを拡大するのは困難です。
今回の事案は、クラウドプロバイダを完全に信頼すべきではないという教訓を与えてくれます。UniSuper は Google Cloud 内のデータについて他の場所にバックアップを用意した点で賢明でした。Google Cloud を責めたくなる気持ちは分かりますが、別のベンダーが将来同様の前代未聞のミスを犯さないことを確約するものもありません。
得られる教訓は、非常に価値のあるデータを保有している場合は、必ず他の場所にバックアップを保持しておくべきだということです。どのクラウドプロバイダを利用する場合でも、別のクラウド、オンプレミスでのバックアップ、あるいはその他の手段を活用すべきです。
The Pulse 誌の完全版はこちらで読むことができます
原文を表示
A $124B fund in Australia would have lost all data stored with Google Cloud, had they not relied on a third-party backup. A rare blunder from GCP, where regional replication did not stop the deletion – and a just as rare statement from Google Cloud’s CEO taking the blame.
The below is an excerpt from The Pulse #93: OpenAI makes Google dance, originally published on 16 May, 2024. I am republishing it because on 20 May 2026 Google Cloud has done it again: they took offline cloud infra provider Railway by blocking Railway's Google Cloud account. The below is a warning: if you are on GCP, have a plan B, should GCP delete your account and data, or block your account.
Following on from Google Cloud being a distant third among cloud providers, a recent event could cement its reputation as the least reliable of the top three.
UniSuper is one of the largest retirement savings accounts in Australia, used by 615,000 citizens, that’s also known as a “superannuation fund.” UniSuper has $124B of assets under management and is one of the biggest in the country.
On 29 April, the service suffered an outage. Members could not log into their online accounts, or manage their funds until two weeks later, on 15 May.
The reason was that Google Cloud accidentally deleted UniSuper’s subscription, which also deleted all data associated with the subscription. UniSuper had set up replication across two regions in Google Cloud to protect from a regional failure, but Google Cloud deleted the replica as well!
UniSuper could only avoid data loss thanks to having a backup on another service provider outside Google. In a surprising admission, UniSuper would have lost all data with Google thanks to the failure of the cloud provider. The only reason UniSuper could restore services was by having another provider with whom they’d backed up the data. Basically, UniSuper not trusting Google’s replication across two regions turned out to be a 100% correct assumption. Whoever pushed through the decision to spend additional resources in “a backup in case Google fails” saved the day at the retirement fund.
The incident is incredibly embarrassing for Google. UniSuper seems to have forced Google Cloud’s hand by issuing a joint statement with Google Cloud CEO Thomas Kurian, in which Google Cloud takes all the blame for this failure. In my experience, the situation is rarely this black-and-white, as it usually takes two parties to cause such a major outage. I would not be shocked if it turned out UniSuper’s staff played a role in this failure, but Google Cloud made enough mistakes that the press release could dump all blame on it. I asked Google Cloud if the press release really was a joint release, and if they had more to add. The company confirmed the press release is correct and added nothing else.
Whoever was at fault, two weeks of downtime is still very long for a major fund. As I understand, the damage to UniSuper is mainly reputational because the funds are safe and secure.
Users could not see their balances for a few weeks, and were told Google Cloud had messed things up. This means there are up to 615,000 Australians in whose minds UniSuper and Google Cloud are indelibly linked with unreliability.
I keep seeing that Google Cloud has no apparent strategy for what it wants its cloud to offer. A few months ago, we dived into how AWS, Azure and GCP respond to regional outages, and I concluded it’s hard to see a strategy at GCP beyond following processes, while doing the least impressive job of all three cloud providers. It’s hard to gain market share if you remain the slowest to respond to regional outages, and the provider for whom a zone outage takes down a region, or which loses all customers’ data, despite regional replication, by deleting it.
This incident is a reminder you shouldn’t fully trust your cloud provider. UniSuper was smart to have backups elsewhere for its data in Google Cloud. And while it’s tempting to point fingers at Google Cloud: there are no definite assurances that another vendor would not make a similarly unprecedented mistake in the future!
The learning is that if you have really valuable data, keep a backup somewhere else. If you use any cloud provider, use another cloud, on-prem backups, or something else.
Read the full The Pulse issue
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み