Railway を8時間止めた「GCPアカウント突然停止」── マルチクラウドでも防げなかった連鎖障害を技術的に解剖する
はじめに
2026年5月19日、PaaS プロバイダの Railway が約8時間にわたる全面障害に陥った。原因はバグでも DDoS でもない。Google Cloud が Railway の本番アカウントを「誤って」自動停止したためだ。さらに恐ろしいのは、Railway が AWS と自社データセンター（Railway Metal）を組み合わせたマルチクラウド構成を組んでいたにもかかわらず、GCP の停止が他クラウド上のワークロードまで巻き込んで落としたことだ。この記事では、公開されたインシデントレポートをもとに、何が起きたのか、なぜマルチクラウドでも連鎖したのか、そして我々エンジニアがこのリスクにどう備えるべきかを技術的に掘り下げる。
何が起きたか — 8時間のタイムライン
障害は UTC 5月19日 22:20 ごろに始まり、翌20日の早朝まで続いた。きっかけは Google Cloud によるプラットフォーム規模の自動アクションで、Railway のレポートによれば「この措置は Google Cloud 内の多数のアカウントに及んだ」とされる。つまり Railway をピンポイントで狙ったものではなく、自動化された一斉処理に巻き込まれた形だ。
停止の影響で、GCP 上にあった Railway のダッシュボード・API・ネットワークインフラの一部が無効化された。ユーザーには 503 / 404 エラーが返り、ログインすらできない状態に陥った。レポートに記載された主なタイムラインは以下の通り。
- 22:19 UTC 根本原因を特定
- 22:29 UTC GCP アカウントへのアクセスが復旧（ただしサービスはまだ停止）
- 23:54 UTC 永続ディスクの復旧完了
- 01:30 UTC（20日） コンピュートインスタンスが回復し始める
- 04:00 UTC コアサービスの稼働を確認
- 07:58 UTC インシデント完全解消
Railway は P0 チケットを起票しアカウントマネージャーに直接エスカレーションしたが、停止のトリガーとなった具体的な理由は本稿執筆時点でも「Google の内部調査待ち」とされ、明らかになっていない。
なぜマルチクラウドでも連鎖したのか — コントロールプレーン依存の罠
ここが今回の最も技術的に重要なポイントだ。Railway は GCP 単独ではなく、**Metal ⇔ GCP ⇔ AWS を高可用性ファイバーで相互接続した「メッシュリング」**を構築していた。AWS と Metal 上のワークロード自体は、GCP が止まっても物理的には稼働し続けていた。にもかかわらず、なぜ全面障害になったのか。
答えはルーティング情報の供給経路にある。Railway のエッジプロキシは、各ワークロードの所在を解決するためにルーティングテーブルをキャッシュしているが、そのキャッシュを生成・更新するネットワークコントロールプレーンの API が GCP 上に置かれていた。GCP が停止しても、キャッシュが生きている間は他クラウドのワークロードへ正常にルーティングできていた。しかしキャッシュの TTL が切れた瞬間、ルートを再解決できなくなり、生きているはずの AWS / Metal 上のワークロードが軒並み到達不能になった。リング状の冗長構成に見えて、ワークロード発見（service discovery）の経路だけは GCP に一本足で依存していた——これが「マルチクラウドなのに単一障害点が残っていた」連鎖の正体だ。
データプレーン（実トラフィック）を冗長化しても、それを制御するコントロールプレーンが単一クラウドに集中していれば、システム全体の可用性はそのクラウドに引きずられる。冗長化の議論でデータ経路ばかりに目が行きがちだが、「経路を決める仕組み」そのものの冗長化が抜けていた典型例と言える。
エンジニアへの影響 — アカウント停止という新しいリスク
従来、クラウドのリスクといえばリージョン障害やゾーン障害が中心だった。しかし今回浮き彫りになったのは、「技術的には正常なのにアカウントごと止められる」というアカウント停止リスクだ。Hacker News の議論でも、過去にも GCP が事前通知や人間によるエスカレーションなしにアカウントを停止した事例が繰り返し挙げられ、「本番を Google Cloud だけに載せるな」「大口アカウントは複数人の人間が確認するまで自動停止の対象外にすべき」といった声が相次いだ。一方で「ホスティング事業者は規約違反者を抱えうるため自動執行は避けられない」「顧客機密の都合で Google は公に詳細を出せない」という反論もあり、透明性と守秘のバランスが論点になっている。
実務への示唆は明確だ。リージョン冗長や DB バックアップだけでは、アカウント停止には無力である。対策として現実的なのは次のような層だ。
- コントロールプレーンを単一クラウドに集中させない。 service discovery や設定配信など「止まると全体が止まる」コンポーネントこそ多重化する。
- キャッシュは延命ではなく fail-safe を設計する。 ルート解決ができないとき、最後に成功した状態を保持し続ける（stale-while-revalidate 的な）挙動にしておく。
- 重要データのクラウド外バックアップと、別アカウント・別ベンダーへの復旧手順を用意する。 停止時にダッシュボードごと触れなくなる前提で逃げ道を作る。
実際 Railway は再発防止策として、GCP コントロールプレーン API へのハード依存の除去、AWS と Metal をまたいだ HA データベースシャードの拡張、そしてGCP をデータプレーンのホットパスから外し二次・フェイルオーバー専用に格下げする方針を打ち出した。「どこか1つの相互接続が切れても必ず別経路が残る真のメッシュ」への作り直しだ。
まとめ
- Google Cloud の自動アカウント停止により、Railway は約8時間の全面障害に陥った。
- AWS・Metal を含むマルチクラウド構成でも、service discovery のコントロールプレーンが GCP に一本足依存していたため連鎖した。
- データプレーンの冗長化だけでなく、コントロールプレーンの冗長化が可用性の鍵になる。
- リージョン障害と並んで「アカウント停止」を脅威モデルに加え、クラウド外バックアップと別ベンダーへの復旧経路を持つべき。
クラウドは「落ちない」のではなく「落ちる前提で設計する」もの——今回の事例は、その対象がインフラ障害だけでなく事業アカウントそのものにまで広がったことを示している。自分のシステムで「どこか1つのアカウントが止まったら何が連鎖するか」を、一度棚卸ししておく価値は十分にある。