Google Cloudが大口顧客のアカウントを無予告停止、大規模障害に
年間数十億円を支払う顧客でも、理由の説明なしにサービスを止められる。そんな事態がまた起きた。
年間数十億円を支払う顧客でも、理由の説明なしにサービスを止められる。そんな事態がまた起きた。
アカウントが突然「存在しない」状態に
コードのデプロイを自動化するプラットフォーム「Railway」が、日本時間2026年5月20日早朝、大規模な障害に見舞われた。GitHubのリポジトリを渡すだけでクラウド上での稼働まで自動処理してくれる、開発者向けのPaaS（アプリの開発・実行環境をまとめて提供するサービス）だ。
障害の原因はGoogle Cloudによるアカウント停止だった。Railwayのソリューションエンジニア、アンジェロ・サラチェノ（Angelo Saraceno）氏によると、日本時間午前7時ごろに問題を検知した時点で、同社のリソースはすでに削除されたかのように見えない状態になっていた。Google Cloud側の説明によれば、実際にはアカウントが停止されており、リソースが不可視状態になっていたという。
Railwayのステータスページには「no healthy upstream」「unconditional drop overload」「ログイン不能」「ダッシュボードにアクセスできない」など、複数のエラーが報告された。
サラチェノ氏は「Googleの担当者も混乱していた。顧客は激怒している」と述べ、停止の引き金について「何らかの執行ルールを誤作動させた可能性がある」という見方を示した。サポートチームが対応を開始したのは、障害発生から1時間後だったという。
「We are livid and still trying to get all the details」（激怒している。詳細はまだ調査中だ）――サラチェノ氏
「リスク」だと分かっていても依存せざるを得ない構造
Railwayはこの問題の根深さをよく知っている。同社は2024年、Google Cloudが「事業の存続を脅かす複数の問題」を引き起こしたことを理由に、インフラの大部分をコロケーション（自社サーバーを外部のデータセンターに設置する形態）へ移行した。その翌2025年にも再びGoogle Cloudで障害が発生し、Railwayのサービスに影響が出ている。
それでも同社のコントロールプレーン（インフラ全体を管理する中枢機能）はGoogle Cloud上に残り、データベースも同プラットフォームで稼働し続けている。年間の支出は 1,000万ドル超（約15億9,000万円）に上るとされており、そのような大口顧客に対して事前通告なしの停止が行われたことになる。
「これが年間1,000万ドル以上を使っている対価なのか」という問いに、Google Cloudはまだ答えていない。
「Googleのせいでも、自分たちが謝る」
復旧作業は停止から5時間以上かかり、一部のワークロードは翌朝にかけて段階的に再稼働した。エンタープライズ向けのデプロイは影響を受けなかったが、それ以外のデプロイは一時停止となった。
Railwayのステータスページには謝罪文が掲載された。直接の原因はGoogle Cloud側にあるにもかかわらず、だ。
サラチェノ氏は「顧客はGoogle Cloudのせいだとは思っていない。私たちが稼働率に責任を持たなければならない」と語った。率直な言葉だが、同時に重い。インフラの根幹を他社に委ねる構造そのものの問題が、ここに凝縮されている。
クラウド事業者が顧客のビジネスを止めても、顧客側が謝る。その構図に慣れてしまっていいのか。
Google Cloudにとって初めてではない
今回の件で思い出されるのが、2024年に起きたユニスーパー（UniSuper）事件だ。オーストラリアの年金基金であるユニスーパーは、Google Cloudの内部設定ミスによってクラウドのサブスクリプション全体が削除され、約2週間にわたってサービスが使えなくなった。1,350億ドル（約21兆5,000億円）の資産を預かる機関が、クラウド事業者の誤操作で機能停止に追い込まれた事案だ。
あの時もGoogleは「世界で前例のない一回限りの出来事」と説明した。
今回のRailwayの件はミスではなく、何らかの判断による意図的なアカウント停止だ。どちらの事案も「Googleの行動が、顧客のビジネスを突然止めた」という点では変わらない。大口顧客であっても、クラウド事業者の決定に対抗する手段はほとんどない。インフラをGoogle Cloudから切り離せないまま謝り続ける構図は、今回で2度目になる。
参照元
他参照
