Railway-GCP 8 時間停止 — マルチクラウドのコントロールプレーン単一障害点
Railway-GCP 8 時間停止 — マルチクラウドのコントロールプレーン単一障害点
2026-05-19 22:20 UTC、Google Cloud のポリシー自動化が Railway のプロダクション GCP アカウントを事前通知なく一時停止した。データプレーンが GCP・AWS・Metal の 3 ベンダにメッシュで張られていたにもかかわらず、コントロールプレーンが単一の GCP プロジェクトに縛られていたため、約 1 時間後にルートキャッシュが失効すると同時に全リージョン・全ワークロードの 503 が 8 時間続いた。マルチクラウドは本当にマルチなのか、それともコントロールプレーンがどこにあるかの問題なのか。
導入 — 22:20 UTC のシングルクリック
2026 年 5 月 19 日 22 時 20 分 UTC、Railway のオンコールエンジニアのポケベルが一斉に鳴った。米国東部、ヨーロッパ、シンガポール、シドニー — すべての GCP リージョンのヘルスプローブが同じ分に赤に落ちた。最初の 5 分間、チームは自社インフラの問題を疑った。Argo、Istio、自前のビルダークラスタ — すべて平時どおり動作していた。5 分後、あるエンジニアが GCP コンソールにログインを試みた。“Your account has been suspended for policy violations.” 同じメッセージが全メンバーの画面に表示されていた。
Railway がその日 22:51 UTC に公開したポストモーテム [blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage] の最初の段落はこう始まる。“We were not warned. We were not contacted. We were not given a reason.” 22:20 UTC の単一の自動化アクションが、Railway のプロダクション GCP アカウント全体を一時停止した。8 時間 12 分後の 5 月 20 日 06:32 UTC まで、すべての GCP リージョンのすべての Railway ワークロードが 503 を返し続けた。同じ時間 status.railway.com/incident/I23M92U0 のタイムラインはその 8 時間を分単位で記録している。22:20 incident detected. 22:38 escalated to Google Cloud TAM. 23:14 status update: control plane offline. 00:47 partial restoration via fallback. 06:32 full restoration.
この事件の核心は単一の停止そのものよりも、その停止が浮かび上がらせた構造的な問いにある。Railway は 2024 年以来、“GCP + AWS + Metal” の 3 ベンダマルチクラウドを掲げてきており、データプレーンのメッシュネットワークは実際にその約束を守っていた。しかし 22:20 UTC のシングルクリックが 8 時間の全停止に至った理由は、データプレーンは本当にマルチだったが、コントロールプレーンは単一の GCP プロジェクトに縛られていた からである。HN の二つのスレッドは同じ日に 549 点 (240 コメント) と 409 点 (348 コメント) で合算 ~588 コメント、累計 958 点を記録し、この構造的な問いをその週の話題にした。本稿はその問いを追う。メッシュは 1 時間をどう持ちこたえ、なぜ崩れたのか。コントロールプレーンの単一障害点はどこまで一般的な問題なのか。そして Railway が 24 時間以内に公開した 3 つの約束は PaaS 業界全体に何を示唆しているのか。
本論 1 — 22:20 から 06:32 までの事実関係
タイムラインを再び分単位で再構成すると、事件の構造はより鮮明になる。22:20 UTC、GCP のポリシー違反検出自動化 — Google 内部文書では “Project Policy Enforcement” と呼ばれているシステム — が、Railway のプロダクション GCP アカウントに対して一時停止 (suspension) アクションを実行した。このアクションはアカウント保有のすべてのプロジェクト (Railway は約 47 個の分離プロジェクトを運用していた) の API アクセスを遮断し、コンソールログインを阻止し、すべての IAM キーを無効化する。Railway の GCP リージョンで稼働していたワークロード自体はすぐには死なない — コンピュートインスタンスはそのまま動作し、ディスクとネットワークもそのままだ。死ぬのは「それらのインスタンスを管理するために GCP API を呼び出すすべての経路」である。
最初の 60 分間、Railway のデータプレーンは正常だった。すでにデプロイされたコンテナは引き続きサービングし、すでにキャッシュされたルートは引き続きルーティングする。利用者から見れば 22:20 ~ 23:20 UTC の区間の影響はほとんどなかった。しかし 23:20 ごろからルートキャッシュが失効し始めた。Railway のルータはバックエンド IP とヘルス状態を 30 分 ~ 1 時間周期で更新するが、その更新のためには GCP API でコンピュートインスタンスのメタデータを問い合わせる必要がある。その API 呼び出しが一斉に 401 を返し始めた。ルータは期限切れのルートを安全側に倒して破棄し、新しいルートを受け取れないためトラフィックを 503 に落とす。23:30 UTC、最初の大規模な 503 の波が利用者側モニタリングに現れた。
23:14 UTC に Railway が status ページに掲示した一行は、事後に最も多く引用された文章となった。“Control plane offline. Data plane degrading as routes expire.” この一文が、コントロールプレーンとデータプレーンという二つの層がどのように分離されており、どのように共に崩れていくかを正確に言語化している。23:30 ~ 00:30 UTC の間に、Railway の DB シャードのうち GCP Cloud SQL に配置された約 60% が順次アクセス不能になった。同時刻、Railway のビルダークラスタ (利用者が新規デプロイをトリガするコンポーネント) は GCP Cloud Build の API キー認証失敗によりビルドキューを停止した。23:45 UTC、Railway は status ページに “All new deployments paused” を追加した。
00:00 UTC 付近で Railway の SRE チームは二方向の対応を開始した。第一に、Google Cloud の Technical Account Manager (TAM) と緊急チャネルを開き、登記簿謄本・税務申告書・創業者の身分証明書のような会社の正体証明資料を、ポリシー違反 (specific policy violation) が何なのか分からない状態で全て提出し始めた。第二に、データプレーンの一部を AWS と Metal 側のバックエンドへ強制フェイルオーバする作業を開始した。フェイルオーバは予め準備された IaC が存在したが、一度も実際の切り替えを行ったことがないコードパス (cold path) だったため、約 90 分の試行錯誤が続いた。00:47 UTC、AWS 側バックエンドを通じた部分復旧が始まった。トラフィックの約 30% が 503 から正常に回復した。しかし GCP Cloud SQL にデータが残っているワークロード (全体の約 60%) は依然としてアクセス不能だった。
03:18 UTC、Google Cloud の TAM から最初の意味ある返信が届いた。“We have identified the trigger. This was an automated action and is being reviewed.” 5 時間が経ってようやく、しかも自動化の人手レビューが始まったというだけの返信だった。06:32 UTC、GCP 側で一時停止が解除された。Railway 側は同じ分に status ページに “All systems operational” を掲示した。22:20 から 06:32 まで、正確に 8 時間 12 分の全面停止であった。影響を受けた利用者ワークロード数は約 17 万件。結果として Railway が SLA 返金として約定した金額は会社の月商の約 12% である (ポストモーテム本文に直接明記)。HN の共感コメントの空気を一行に要約すれば「8 時間の停止よりも、8 時間の停止を生み出した単一の自動化クリックの方が恐ろしい」である。
本論 2 — メッシュは 1 時間をどう持ちこたえ、なぜ崩れたのか
この事件が PaaS 業界全体に投げかける本当の問いは「なぜ Railway のマルチクラウドは単一の GCP 事件を防げなかったのか」である。Railway は 2024 年後半から GCP + AWS + Metal の 3 ベンダデータプレーンメッシュを掲げてきた。コンピュートは 3 ベンダに分散し、バックボーンネットワークは自前メッシュで束ねられ、DB シャードの約 40% は AWS RDS と Metal の自前 Postgres クラスタに分散している。それなのに単一の GCP 停止が 8 時間の全面 503 を生んだ理由は明瞭である。コントロールプレーンが単一だったからだ。
コントロールプレーン / データプレーンの分離は分散システム設計の古典的原則である。データプレーンは実際のトラフィックを処理するコンポーネント — ルータ、コンピュートインスタンス、DB、キャッシュ。コントロールプレーンはそのデータプレーンを管理するコンポーネント — デプロイオーケストレーション、ヘルスチェック集計、IAM、API キー発行、ビルドトリガ。この二つの層は異なるライフサイクルと異なる可用性要求を持つ。データプレーンが死ねば即座に利用者が影響を受ける。コントロールプレーンが死ねば新規デプロイ・新規ルートは不可能になるが、すでに敷かれたトラフィックは一定時間は生きている。
Railway のメッシュが最初の 1 時間を持ちこたえた理由がこの分離の自然な結果である。22:20 UTC の GCP 自動化が遮断したのは GCP API の認証 — つまり GCP コントロールプレーンへのアクセス — であって、GCP コンピュートインスタンス自体の実行ではない。すでに立ち上がっているインスタンスは引き続き動き、すでにキャッシュされたルートは引き続き作動する。データプレーンは約 1 時間分の「先行キャッシュ」を持っていた。しかしそのキャッシュが失効すると、新しいルートを得るためにコントロールプレーンが必要となり、Railway のコントロールプレーンは単一の GCP プロジェクトの中に 100% 配置されていた。
ここで二つの設計欠陥が露わになる。一つ目はコントロールプレーンのベンダ多重化の欠如だ。Railway の IAM、デプロイオーケストレーション、ルートコンパイラ、ヘルスチェック集計 — すべて単一の GCP プロジェクトの中のマイクロサービスとして稼働していた。AWS や Metal にはコントロールプレーンのいかなるコンポーネントも存在しなかった。理由は単純なコスト効率である。コントロールプレーンはデータプレーンに比べてトラフィックが小さく、一箇所に集めた方が運用複雑度がはるかに低い。二つ目の欠陥はフェイルオーバの cold path だ。メッシュはデータプレーンでは自動フェイルオーバが検証済みだったが、コントロールプレーンの非常迂回路 — 「GCP が丸ごと塞がれたときに AWS 側で部分的にでもルートをコンパイルしヘルスチェックを回す経路」 — は IaC のみが存在し、実訓練は一度も行われたことがなかった。事件当日 00:00 UTC からの 90 分の試行錯誤がまさにこの cold path のコストだった。
この二つの欠陥を一行にまとめるとこうなる。データプレーンはマルチだったが、コントロールプレーンは単一だった。 そして事件の核心は、その単一性が PaaS のコスト効率という合理的な理由で導入された設計選択だという点である。Railway 特有の異常値ではなく、Vercel、Netlify、Fly.io、さらに大きな Heroku に至るまで — PaaS 業界全体が似た形状を共有している。データプレーンは複数ベンダに敷くが、コントロールプレーンは一ベンダに集中させる。理由は同じだ。コントロールプレーンのベンダ重複は運用複雑度を 2 ~ 3 倍に押し上げ、一貫性を壊し、コストも 1.5 倍程度増やす。だからすべての PaaS が同じ折衷を選んできた。
ここに事件のもう一つの軸 — Google Cloud の enterprise 顧客に対する非対称なプラットフォーム権力 — が結合する。Railway は Google Cloud の enterprise PaaS 顧客であり、月 7 桁の請求を出す会社である。そのような会社を事前通知なく、ポリシー違反の内容を明示せずに、自動化のシングルクリックで一時停止できるという事実が、この事件で初めて可視化された。HN のあるコメントは「Google にとっては enterprise 請求 7 桁など大したことではないらしい」と評する (共感コメントの空気の要約、直接引用ではない)。この非対称は単なる Railway の不運な事故ではなく、enterprise PaaS が hyperscaler のポリシー自動化の上に乗っている限り、いつでも同じ事件が再現され得る という構造的リスクを可視化した事例である。同じ自動化が Railway に適用されたなら、他の PaaS にも同じ自動化が同じやり方で適用され得る。
本論 3 — 3 つの約束とクラウド主権の時代精神
Railway がポストモーテム (post-mortem) の最後に公開した 3 つの約束は、この事件の意味を PaaS 業界全体に投げかける。一つ目の約束、GCP をデータプレーンのホットパスから除去。現在 GCP コンピュートに 100% 単独配置されているワークロードが約 40% あるが、これを次の四半期までに GCP + AWS の同時配置 (active-active) に移すというもの。二つ目の約束、DB シャードを AWS と Metal に拡張。現在 GCP Cloud SQL に 60% ある DB シャードを次の 6 か月で AWS / Metal 側に 40% ずつ分散させ、GCP の比率を 20% 以下に下げるというもの。三つ目の約束が最も重い — コントロールプレーンの単一ベンダ依存の排除。これは IaC のみのフェイルオーバではなく、コントロールプレーン自体を GCP + AWS の active-passive で運用するという約束である。
3 つの約束のコストは小さくない。Railway のポストモーテムは「この変更は社内エンジニアリングコストとして 18 人年 (engineer-years)、追加インフラコストとして年 $4M の増加を見込む」と明記している。18 人年は Railway のような約 80 名規模の会社では約 6 か月 ~ 1 年分のコアエンジニアリング出力に相当する。言い換えれば、Railway は 8 時間の停止を一度防ぐために 6 ~ 12 か月のコアエンジニアリング出力をコントロールプレーンの多重化に投資することを決めた。これは SLA 返金 (月商の 12%) よりはるかに大きな恒久的コストである。それでもそのコストを約束する理由は単純だ — 次もまた同じ自動化クリックが同じように起こり得る、そして次は SLA 返金で済まないかもしれない という合理的な恐れである。
この約束が PaaS 業界全体に発する信号を整理しておく。Vercel、Netlify、Fly.io、Render — いずれも単一の hyperscaler (主に AWS、Vercel の場合は AWS + 一部 GCP) にコントロールプレーンを集中させている。Railway の事件はこの集中が運用効率の合理的な選択ではなく、単一の自動化決定に会社全体のダウンタイムを委ねる危険な折衷だという事実を暴いた。次の 6 か月の間に、Vercel、Netlify、Fly.io のうち少なくとも一社はコントロールプレーン多重化に関する公開的な約束を打ち出すと見られる。そしてその約束が出れば、PaaS 業界のコスト構造は恒久的に 1.3 ~ 1.5 倍重くなる。これは利用者の PaaS 請求書がそれだけ上がることをも意味する。
ここでこの事件が 5 月のより大きな時代精神と交わる地点がある。同じ週の HN で 903 点を記録した別スレッドは「EU 決済網の米国依存をどう切り離すか」という EU の決済主権 (payment sovereignty) 論争であった。表面的には PaaS コントロールプレーンと EU 決済網は無関係に見えるが、二つの事件は同じ構造的な問いを発している — インフラのホットパスが単一プラットフォームの政策決定に従属しているとき、それは本当に自分のインフラなのか。EU の場合は Visa / Mastercard が決済ホットパスを握っており、PaaS の場合は hyperscaler のポリシー自動化がコントロールプレーンを握っている。二つの事件のいずれもが「自分が金を払っているインフラの本当の決定権は誰が持っているか」という同じ問いを指し示す。これが 2026 年春の時代精神、クラウド主権 (cloud sovereignty) である。
HN の二つのスレッドの共感コメントを一行にまとめるとこうだ — 「Railway の事件は単なる運用事故ではなく、hyperscaler 時代の PaaS の基本前提 (single-vendor control plane is fine because it’s cheaper) が崩れた瞬間である」 (共感コメントの空気の要約、直接引用ではない)。そしてこの基本前提が崩れれば、次の四半期の PaaS 採用判断において「コントロールプレーンがどこにあるか」が、データプレーンのマルチクラウドの約束と同じくらい中核的な変数になる。
結論 — マルチはデータの約束ではなくコントロールの約束である
最初の問いに戻ろう。マルチクラウドは本当にマルチなのか、それともコントロールプレーンがどこにあるかの問題なのか。
5 月 19 日 22:20 UTC の事件が明確に示した答えは後者である。データプレーンを 3 ベンダに敷いても、コントロールプレーンが一ベンダに縛られていれば、その一ベンダのシングルクリックの自動化で 8 時間の全停止が生まれる。マルチクラウドの本当の価値はデータプレーンの分散ではなく コントロールプレーンの分散 にある。そしてコントロールプレーンの分散は高価である — 運用複雑度が 2 ~ 3 倍、インフラコストが 1.3 ~ 1.5 倍。そのコストを誰が負担するかの問いが、次の四半期の PaaS 市場で新たに始まる。
Railway の 18 人年 / 年 $4M の約束が実際の実行に移されるかは次の 6 か月以内に検証される。同じ期間に Vercel、Netlify、Fly.io のうち誰が似た約束を後追いするかが、もう一つの検証指標だ。そして同じ 6 か月の間に Google Cloud が enterprise PaaS 顧客のポリシー自動化の意思決定に人手レビューゲートを義務化する規程改定を打ち出すか — これは hyperscaler の自己規制意思の核心試験である。三つの指標がすべて否定的に出れば、この事件は PaaS 業界が hyperscaler のポリシー自動化の上で永遠に不安定に運営される事実を恒久的定数として固定する。三つのうち二つ以上が肯定的に出れば、2026 年 5 月 19 日は PaaS 業界のコントロールプレーン多重化時代を開いた分岐点として記録されることになる。
本稿が残すメッセージは一行である。マルチクラウドの本当の約束はデータの約束ではなくコントロールの約束であり、クラウド主権は決済網主権と同じ時代精神の二つの顔である。 22:20 UTC のシングルクリックは hyperscaler 時代の PaaS の最も深い単一障害点を可視化した。その単一障害点がコントロールプレーンのベンダ単一性という合理的な折衷の中に隠れていたという事実が、この事件を単なる一社の 8 時間停止ではなく一つの時代の分岐点に押し上げる。次の四半期の PaaS 採用判断において、「コントロールプレーンがどこにあるか」という一行の問いが、データプレーンのマルチの約束と同じくらい重く扱われ始めるだろう。
出典: