Railwayが公開したIncident Reportによると、2026年5月19日、同社はGoogle Cloudの誤った処理により、production accountが suspended status（停止状態）にされたことで、プラットフォーム全体の障害に見舞われました。
障害時間は、5月19日 22:20 UTC から 5月20日 06:14 UTC 頃まで。ざっくり約8時間です。
対象になったのは、Railwayの中核機能です。
つまり、ユーザーから見える画面だけでなく、裏側の心臓部まで止まったということです。これはかなり重い。サービスの「見た目が遅い」ではなく、サービスそのものが機能しないレベルです。
Railwayは、まずGCP上のインフラ停止を受けましたが、さらに厄介だったのは、キャッシュされていたネットワーク経路情報（route table）が期限切れになると、MetalやAWS上のワークロードまで到達不能になったことです。
ここがこの事故の面白い、というか怖いところです。
「GCPが止まったならGCPだけの問題でしょ」と思いたくなりますが、実際にはそう単純ではありませんでした。ネットワークの案内役であるcontrol planeがGCPに依存していたため、他のクラウドや自社基盤まで巻き込まれたわけです。
ユーザー側では、かなり分かりやすく不便が出ています。
no healthy upstreamunconditional drop overload専門用語を少し補足すると、
つまり、障害の初期は「裏側が死んでるから返せない」、後半は「行き先そのものがわからない」という状態になっていた、という理解でよさそうです。
また、障害の余波としてGitHub側のOAuthやwebhook連携がrate limitingされたとも書かれています。
rate limiting は「短時間に呼び出しが集中したので、いったん制限する」という仕組みです。障害復旧時にリトライが一気に増えたことで、GitHub側から見ても「ちょっと多すぎる」と判断されたのでしょう。こういう障害の二次災害は、地味ですが本当に面倒です。
さらに、Terms-of-service acceptance records がリセットされ、ユーザーに再同意を求める状態にもなったとのこと。
これは地味に嫌ですね。私はこういう「機能停止ではないけど、ユーザー体験を壊す副作用」がいちばん現場を疲れさせると思います。
Railwayはかなり細かく時系列を公開しています。ここ、誠実さを感じます。隠さず出すのは簡単ではないので、広報的にも価値が高いです。
この流れを見ると、アカウントアクセス自体はすぐ戻っても、実際にサービスとして回る状態へ戻すには別作業が山ほどあるのがわかります。
クラウド事故のやっかいさはここです。「アカウントが戻った＝全部復旧」ではない。現実はそんなに甘くない。
Railwayの説明をまとめると、原因は大きく2層あります。
5月19日 22:20 UTC、Google Cloudが自動処理の一環としてRailwayのproduction accountを誤って停止状態にしたとされています。
しかもこれはGoogle Cloud内の多くのアカウントに対して行われたplatform-wide actionで、個別事前連絡はなかったとのことです。
ここはRailwayだけの責任ではありません。
むしろ直接原因としては、Google Cloud側の誤処理です。これははっきり言っていいと思います。
ただし、Railwayははっきりこうも述べています。
We take full responsibility for the architectural decisions that allowed a single upstream provider action to cascade into a platform-wide outage.
つまり、
「1つの上流プロバイダの操作で、プラットフォーム全体が落ちる構成にしてしまった」責任は自分たちにある
ということです。
これは重要です。
事故の引き金は外部でも、燃え広がる構造を作っていたのは自分たち、という認識です。こういう自己批判があるレポートは、読む価値が高いです。単なる他責では学びがありませんから。
Railwayのネットワークは、Metal・GCP・AWSをまたぐmesh ring（複数経路を持つネットワーク構成）だと説明されています。
一見すると冗長性がありそうですが、実際にはワークロード発見（どの実体がどこで動いているか）を担うcontrol plane APIがGCP上に依存していた。ここが弱点でした。
そのため、ルートキャッシュが生きている間は何とか動いても、期限が切れた瞬間にrouting tablesを再生成できず、全体が迷子になったわけです。
この設計、理屈としては「冗長に見える」のがまた怖いところです。
表面上はマルチクラウドでも、本当に重要な部分が1か所に寄っていると、結局は単一障害点になります。クラウド設計あるあるですが、かなり刺さる話です。
復旧は段階的でした。
ここで印象的なのは、いきなり全デプロイを流さず、キューをゆっくり捌いたことです。
復旧直後に一気に全部動かすと、今度は復旧したシステム自身が過負荷で再び落ちることがあります。だから“落ち着いて戻す”のは正解です。派手さはないけど、実務ではこういう判断が大事です。
Railwayは今後の対策もかなり具体的に示しています。
GCPサービスをdata planeのhot path（最重要経路）から外し、secondary/failover用途に限定していく方針です。
これは要するに、
「GCPが死んでも、即サービス全体は死なない構成にする」
ということです。
今のmeshは完全ではなく、まだGCP上のcontrol plane APIに依存していました。
これをなくし、どのインターコネクトが死んでも別経路が残る本当のmeshにする、としています。
この “true mesh” という表現、なかなか強いです。
ネットワークって、図面上は美しくても、実際には「ここだけ別管理」が残りがちなんですよね。そこを潰すのは地味だけど超重要です。
高可用性のために、database shardを複数クラウドに広げる予定です。
shard はデータベースを分割した単位のこと。分散して持つことで、1か所が壊れても全滅しにくくなります。
Railwayは、
の両方を新しい構成へ移行中だとしています。
ここまで読むと、今回の事故を単なる「復旧報告」で終わらせず、設計の作り直しに踏み込んでいるのがわかります。
こういうのは大変ですが、やらないとまた同じことが起きる。正直、ここは逃げずにやってほしいです。
個人的には、このレポートはかなり教訓的だと思います。
Google Cloud側の誤停止が引き金だったとしても、ユーザーにはRailwayの障害として見える。
結局、自分のサービスの可用性は自分の責任という話になります。
AWS、GCP、Metalを使っていても、重要な制御点が1つならそこが弱点です。
分散しているようで、実は集中している。これ、設計の罠としてかなり典型的です。
GitHubのrate limitingや、再同意が必要になった件を見ると、障害は「止まる」だけでは終わりません。
復旧後の雪崩まで含めて考えないといけない。ここは現場感が強く出ています。
責任の所在をあいまいにせず、時系列と対策まで公開しているのは評価したいです。
正直、こういうインシデントレポートは読んでいて胃が痛くなることもありますが、学びは大きい。隠すより、出して改善するほうがずっと健全です。
今回のRailwayの障害は、単なる「GCPが落ちた」話ではありませんでした。
GCPの誤ったアカウント停止をきっかけに、control plane依存とroute cache切れが連鎖し、最終的に全リージョン・全ワークロードが到達不能になる、かなり深刻な事故でした。
ただ、Railwayがこの事故を
まで公開しているのは、とても価値があります。
クラウド時代の教訓としては、やっぱりこれに尽きると思います。
「便利な依存は、雑に置くと一番高くつく」。
そして、ユーザーは内部事情を見てくれない。だからこそ、最終的な可用性はサービス提供者が背負うしかない。Railwayのコメントは、その現実をかなりストレートに言い当てているように感じました。