クラウドデプロイプラットフォームのRailwayが、2026年5月19日（UTC）、Google Cloudによる誤ったアカウント停止を起因とする約8時間の全面障害を経験した。GCPの制御プレーン停止が引き金となり、AWSや自社インフラ「Railway Metal」にまで障害が波及するカスケード障害が発生し、全リージョンのワークロードが到達不能となった。

何が起きたか

日本時間2026年5月20日早朝（UTC 22:20頃）、RailwayのダッシュボードおよびAPIが突如として503エラーを返し始め、ユーザーはログインすら不可能な状態に陥った。

原因はGoogle Cloudがプロダクション環境のRailwayアカウントを誤って停止状態に設定したことだった。Railwayは即座にGCPのP0チケットを起票し、アカウントマネージャーを直接呼び出した。GCPのアクセス権自体は約9分後（22:29 UTC）に回復したものの、本当の混乱はそこから始まった。

カスケード障害の連鎖

RailwayはGCPにホストされた制御プレーンAPIを、エッジプロキシのルーティングテーブル更新に使用していた。GCPへのアクセスが一時的に失われた間、この制御プレーンが停止し、ルーティングテーブルへの書き込みができなくなった。

問題はGCPアクセス回復後も既存のキャッシュが徐々に失効したことだ。キャッシュが切れるにつれ、GCPとは無関係のAWS環境や自社インフラ（Railway Metal）のワークロードも404エラーを返し始めた。制御プレーンがルーティングを解決できないため、稼働中のインスタンスへの経路が消えてしまったのだ。ピーク時には全リージョンの全ワークロードが到達不能になった。

障害タイムライン（UTC）

時刻 出来事

22:10 自動監視がAPIヘルスチェック失敗を検知、オンコール調査開始

22:11 ダッシュボード503エラー、ユーザーログイン不可

22:19 根本原因特定：GCPがRailwayアカウントを停止

22:22 GCPにP0チケット起票、アカウントマネージャーと直接連絡

22:29 GCPアクセス権回復（コンピュートインスタンスは停止継続）

22:35 キャッシュ失効開始、Railway Metal・AWSも404エラーへ

23:54 全永続ディスクが準備完了状態に

01:38（翌日） エッジトラフィック再開、ネットワーク復旧

06:14 全面復旧

復旧後にはGitHubがOAuthとWebhook連携でRailwayをレート制限するという二次障害も発生した。GCP障害によりキャッシュが全クリアされた影響で、GitHub APIへのコール数が急増したためだ。また、利用規約の同意レコードもリセットされ、ユーザーが次回ログイン時に再同意を求められるという問題も生じた。

実務への影響

マルチクラウドの「見せかけ」に注意

今回の事例が示すのは、物理的にマルチクラウドであっても、制御プレーンが一カ所に集中していれば単一障害点になり得るという事実だ。Railwayは実際にAWS・GCP・自社インフラという複数環境を持っていたにもかかわらず全体が機能不全に陥った。

設計段階で確認すべき重要な問いは次の3つだ。

  • 制御プレーン（ルーティング・DNS・認証基盤）は分散化されているか？
  • 特定クラウドのAPIへの依存がどこに存在するか？ 障害時のフォールバックはあるか？
  • キャッシュのTTLは適切か？ 長すぎれば変更が反映されず、短すぎれば障害時の猶予がなくなる

アカウント停止リスクへの備え

今回はGCPによる誤停止だったが、クラウドプロバイダーによるアカウント停止は請求問題・ポリシー違反の誤検知など様々な理由で発生し得る。これはGCPに限らずAzure・AWSでも起こりうるリスクだ。

  • 重要なサービスは複数のプロジェクト・サブスクリプションへの分散を検討する
  • クラウドプロバイダーとのサポート契約・エスカレーションパスを事前に確認しておく
  • アカウント停止を想定した緊急フェイルオーバー手順書を整備し、定期的に訓練する

筆者の見解

今回のRailway障害が突きつけたのは、マルチクラウド戦略は「存在する」だけでは意味がないという厳しい現実だ。制御プレーンという神経系が一点に依存していれば、どれだけワークロードを分散させても、その一点の障害で全体が止まる。

RailwayがP0チケット起票から9分でGCPのアクセス権を回復させたことは評価に値する。エンタープライズレベルのサポート体制の効果は確かにある。一方で、アクセス権回復からフル復旧まで約8時間を要したことは、「回復への準備」がいかに重要かを改めて示している。回復できることと、素早く回復できることは全く別の話だ。

自社システムを設計・運用するすべてのエンジニアに問いたい。あなたのシステムの「制御プレーン」はどこにあるか？ そしてそれが突然消えたとき、どう振る舞うかを実際に検証したことがあるか？ 「今動いているから大丈夫」は通用しない。障害の想定と実際の訓練こそが、本物の耐障害性を生む。

出典: この記事は Incident Report: Railway Blocked by Google Cloud (Resolved) の内容をもとに、筆者の見解を加えて独自に執筆したものです。