障害レポート: 2026年5月19日 – GCPアカウント停止
(blog.railway.com)- Railwayプラットフォーム全体の障害が2026年5月19日22:20 UTCから約8時間続き、直接の原因はGoogle Cloudの本番アカウント停止だった
- ダッシュボードとAPIは直ちに503エラーを返し、Google Cloudでホストされていたコンピュート、データベース、コントロールプレーン、burst-computeインフラがオフラインになった
- Railway MetalとAWSワークロードは稼働を継続したが、エッジプロキシがGoogle CloudのコントロールプレーンAPIに依存していたため、ルートキャッシュの期限切れ後に404エラーが広がった
- アカウントアクセス復旧後も、永続ディスク、コンピュートインスタンス、ネットワーキングはそれぞれ個別に復旧が必要で、さらにGitHub OAuthとwebhookのレート制限がログインとビルドを妨げた
- Railwayは、単一の上位プロバイダーの措置が全体障害に波及したアーキテクチャ上の判断の責任を認め、Google Cloudをデータプレーンのホットパスから外す再設計を進めている
影響
- 2026年5月19日22:20 UTCから5月20日約06:14 UTCまでの約8時間、Railwayでプラットフォーム全体の障害が発生した
- Google CloudがRailwayの本番アカウントのサービスを停止したことで、API、コントロールプレーン、データベース、Google Cloudでホストされていたコンピュートインフラがオフラインになった
- ユーザーはダッシュボードとAPIで直ちに503エラーに遭遇し、
"no healthy upstream"および"unconditional drop overload"というメッセージとともにログインできなくなった - Google Cloudコンピュート上でホストされていたすべてのワークロードがオフラインになった
- Railway MetalとAWS burst-cloud環境のワークロード自体は動作を継続したが、Railwayのエッジプロキシはルーティングテーブルを埋めるためにGoogle CloudでホストされていたコントロールプレーンAPIに依存していた
- キャッシュされたネットワークルートの期限が切れると、Google Cloud外のワークロードも到達不能となり、ネットワークコントロールプレーンがアクティブなインスタンスのルートを解決できず404エラーを返した
- 影響が最大だった時点では、全リージョンのRailwayワークロードが到達不能な状態となった
- Google Cloud環境の復旧中は、個別サービスを復旧する間、プラットフォーム全体でビルドとデプロイがブロックされた
- インフラ全体の復旧後は、待機中だった大量のデプロイ作業をプラットフォームに過負荷を与えないよう段階的に処理した
- 同時にGitHubがRailwayのOAuthおよびwebhook統合にレート制限をかけ、ログインとビルドが一時的に妨げられた
- 呼び出し量の増加は、Google Cloud障害でキャッシュが空になった結果だった
- 利用規約への同意記録もリセットされ、ユーザーは次回ダッシュボード訪問時に再度同意する必要があった
- Railwayは、単一の上位プロバイダーの措置がプラットフォーム全体の障害へと広がることを許したアーキテクチャ上の判断の責任を認めた
障害タイムライン
- 5月19日22:10 UTC: 自動監視がAPIヘルスチェック失敗を検知し、オンコール担当者へ通知
- 5月19日22:11 UTC: ダッシュボードが503エラーを返し、ユーザーがログインできなくなる
- 5月19日22:19 UTC: Google Cloud PlatformがRailwayの本番アカウントを停止したことが根本原因だと確認
- 5月19日22:22 UTC: Google CloudにP0チケットを提出し、RailwayのGCPアカウントマネージャーが直接関与
- 5月19日22:29 UTC: 障害を宣言
- 5月19日22:29 UTC: GCPアカウントアクセスは復旧したが、すべてのコンピュートインスタンスは停止状態のままで、永続ディスクにはアクセスできなかった
- 5月19日22:35 UTC: キャッシュされたネットワークルートが期限切れを起こし始め、Railway MetalとAWSワークロードが404エラーを返す
- 5月19日23:09 UTC: 最初の永続ディスクがオンラインに復帰
- 5月19日23:54 UTC: すべての永続ディスクがready状態に復旧したが、ネットワークは依然ダウンしていた
- 5月20日00:39 UTC: ディスクのready状態を確認、復旧はGoogle Cloudネットワーキングの回復に阻まれる
- 5月20日01:30 UTC: コンピュートインスタンスの復旧が始まる
- 5月20日01:38 UTC: エッジトラフィックの提供が再開され、ネットワーキングが復旧
- 5月20日01:57 UTC: オーケストレーションおよびビルドインフラが復旧し、待機ジョブが同時実行でシステムを圧迫しないようデプロイを一時停止
- 5月20日02:04 UTC: コンピュートホストが段階的にオンラインへ復帰
- 5月20日02:47 UTC: GitHubがRailwayのOAuthおよびwebhook統合へのレート制限を開始し、一部ユーザーがログインできずビルドもブロックされる
- 5月20日02:55 UTC: ダッシュボードへのアクセスが再び可能になる
- 5月20日03:59 UTC: 全ティアでデプロイ処理を再開
- 5月20日04:00 UTC: API、ダッシュボード、OAuthエンドポイントの動作を確認し、残るワークロードの復旧を継続
- 5月20日06:14 UTC: 障害を監視フェーズへ移行
- 5月20日07:58 UTC: 障害を解決
発生原因と復旧過程
-
Google Cloudアカウント停止
- 5月19日22:20 UTC、Google Cloudが自動措置の一環としてRailwayの本番アカウントを誤って停止状態へ移行した
- この措置はGoogle Cloud内の複数アカウントに影響した
- プラットフォーム全体の措置だったため、制限前に個別顧客への事前連絡はなかった
- 停止状態により、Railway Dashboard、API、ネットワークインフラの一部、Google Cloudでホストされていた追加のburst-computeインフラを含むGCP関連インフラが無効化された
-
コントロールプレーン依存
- Railwayのコントロールプレーンは、ダッシュボード提供、ビルドとデプロイ処理、エッジが使用するルーティングテーブルの充填を担う中核的な依存関係の集合である
- Google Cloud上のすべてのワークロードには直ちに影響が出た
- Railwayのエッジプロキシは、Google Cloud内部でホストされていたネットワークコントロールプレーンのルーティングテーブルキャッシュを保持していた
- キャッシュが維持されている間、Railway MetalとAWSのワークロードは引き続きトラフィックを処理した
- しかしキャッシュが期限切れになると、エッジはアクティブなインスタンスのルートをもはや解決できなくなり、MetalとAWSを含む全リージョンのワークロードが404エラーを返し始めた
- ワークロード自体はオンラインだったが、ネットワーク障害の影響はGoogle Cloud外のリージョンにも波及した
-
高可用性設計の限界
- Railwayインフラは高可用性を目指して設計されており、データベースは複数アベイラビリティゾーンにまたがって動作し、ネットワークはAWS、GCP、Railway Metal間の冗長接続を利用している
- アカウントアクセスが復旧しても、個別サービスが自動的に復旧することはなかった
- 永続ディスク、コンピュートインスタンス、ネットワーキングはそれぞれ別個の復旧を必要とし、この復旧特性のため障害はさらに数時間続いた
- ディスクは23:54 UTCにready状態へ復旧したが、中核ネットワーキングとエッジルーティングは5月20日約01:30 UTCまで完全には復旧しなかった
- Railwayは、この遅延と関連エラーがGoogle側で発生したものかどうかの確認を待っている
-
段階的復旧と二次影響
- ネットワーキング復旧に伴い、Railwayの中核サービスとエンドユーザーワークロードの検証が層ごとに進められた
- ビルドシステムの過負荷を防ぐためデプロイを一時停止し、その後段階的に再開した
- 中核システムの復旧と並行して、GitHubがRailwayのOAuthおよびwebhook統合にレート制限をかけた
- すべての再試行リクエストのボリュームとburst特性により、ユーザーログインとビルドは一時的にブロックされた
- 5月20日約04:00 UTC時点で、API、ダッシュボード、OAuthエンドポイントが動作中であることを確認し、残るワークロードの復旧は継続された
予防措置
-
既存のレジリエンス設計
- Railwayのネットワークコントロールプレーンはmulti-AZ, multi-zone構成で設計されており、複数のマシンやコンポーネントを失ってもユーザー影響なく動作を継続できる
- この設計は数か月前のリリース前にステージングと実トラフィックでテストされていた
- 以前の障害以降、レジリエンスへの投資を続けており、その結果としてユーザーのGitHubインストールを二次的なレート制限なしで安定的に復旧させた実績がある
-
単一依存の排除
- Railwayネットワークは、Metal <> GCP <> AWS間の高可用性光ファイバー相互接続で構成されたmesh ringである
- しかしこのリング内でも、ワークロード発見可能性がGoogle Cloudマシン上で動作するネットワークコントロールプレーンAPIに結び付けられた強い依存が残っていた
- メッシュは約1時間動作を継続したが、ルートキャッシュが期限切れになるとルーティングテーブルを再充填できず失敗した
- Railwayはこの依存を直ちに取り除き、真のmeshにする作業を進めている
- 目標は、どの相互接続が切れてもクラウド間に常に経路が残るようにすることだ
-
データベースとフェイルオーバー改善
- Railwayは高可用性データベースシャードをAWSとMetal全体へ拡張する予定である
- 将来的には、特定クラウドの全インスタンスが即座に消失しても、データベースquorumがサービスを維持し、もはや稼働していないワークロードを直ちにフェイルオーバーさせる方向を目指す
-
データプレーンとコントロールプレーンの再設計
- Google Cloudサービスをデータプレーンのホットパスから外し、補助またはフェイルオーバー用途にのみ残す計画が進んでいる
- これは、ホスト接続を可能にするデータプレーンと、ユーザーがRailwayにアクセスして管理するダッシュボードを動かすコントロールプレーンに新アーキテクチャを実装する作業と並行している
- このアップグレードは、中核サービス、とりわけユーザー向けコンポーネントが単一のベンダーやプラットフォームに依存しないようにするためのものだ
責任と結論
- ベンダー選定の責任はRailwayにあり、今回の選択も最終的にはRailwayの責任である
- 顧客は障害原因がGoogleかRailwayかよりも製品そのものを見るため、Railwayの稼働率はRailwayの責任である
1件のコメント
Hacker Newsの意見
興味深く、なお説明されていない点は、Googleがなぜアカウントにフラグを立てたのかということだ
事後分析で観測したタイムスタンプをいくら並べても、根本原因は扱われていない
話の中で「筋が通らない」部分には、まだ誰も公表したくない実際の説明がある可能性が高い
Googleが予告なくアカウントを止め、当時は月 1万ドル ほど使っていた
しかもプレミアムサポートのアカウントまでロックされ、サポートチームに「自分たちがロックされた」という事実すら伝えられなかった
約8時間後、適当なGoogleのサポートエンジニアが、私たちがビットコインを採掘したからだと言ったが、完全にでたらめだった
全期間のCPU使用率グラフとログがあり、スパイクもなかった
12時間ほどして再開され、「不正利用検知の設定ミス」だったと言われ、クレジットとして100ドルほど渡された
AWSについて何を言おうと、AWSなら担当者からの連絡もなく顧客にこんなことはしなかったはずだ
それ以来、GCP は信用していない
自動化システムはミスもするが、より大きな問題は完全に不透明なことだ
Googleでさえそのシステムが正確にどう動いているのか分かっていない可能性が高い
Railwayに対して、GCPを離れる代わりにこちらに力を使えという意味なら、ブランドや長期的な顧客維持の損失を回収するためにGCPを相手取って訴訟でも起こすつもりでない限り、なぜそうすべきなのか分からない
GCPが事前警告なしに止めた時点でもう終わった話で、これ以上聞く必要もないと思う
Railwayは今月、技術メディアでの印象が良くなかったようだ
どちらのケースでも、相手側の 自動化された手順 が原因となって評判が損なわれた
もともとはGoogle担当者にGemini CLIを殺した問題を話そうと思っていたが、こちらの件のほうがはるかに心配だ
管理者アカウントの資格情報をAIに入れたのは彼らだけだった
そして個人的責任も負わず、それが確実に評判を傷つけた
今回は少なくともある程度責任を認めているので、その点は改善として認める
また、GCPの信頼性の問題 とGoogleの顧客サポートの問題は実際に深刻だ
修正: 下で最初の2段落が誤って帰属されており、RailwayではなくRailwayの顧客の件だったと知った。ごめん、Railway！
うちの会社は以前、AWSにいくつか追加保証を載せた形のホスティング事業者を使っていた
今ではAWSが必要な機能を直接提供しているので、通常のAWSへの移行を終えた
残念ながら、この件のせいで昨日 Azureへの緊急移行 をしなければならなかった
幸い、データベースはRailwayに置いていなかったので、数時間で復旧できた
Railwayが提供していたシンプルさは本当に良かったが、B2Bエンタープライズアプリをそのインフラで動かし続けるには、インシデントと制約が多すぎた
悲しい日だ :(
よく知っているサービスではないが、独自機能があって選んだのか、それとも事実上VM用途だったのか？
独自機能が理由だったなら、そこから抜け出す移行がどれだけ大変だったのかも気になる
小さなSaaSツールや社内プロダクトという前提で、チームがAWSや他の IaaSプロバイダー を直接管理したくないなら、次の代替案として何が良いだろうか？
AWSのようなものを使っていても、複数の アベイラビリティゾーン にまたがる冗長構成をしていなければ、ときどきダウンタイムは起きる
複数AZで冗長化していても、AWSは完全に分離された構造ではないため、一部サービスが失敗してダウンタイムが生じることはある
だからダウンタイムを受け入れて、自分に最も合うツールを使えばいい。ただしGitHubレベルで極端にひどい場合は別だ
ダウンタイムをまったく受け入れられないなら、ダウンタイムがないと期待できるほどの信頼性を得るには、数百万ドルと数か月の作業が必要だ
Netflixの Chaos Monkey とそのインフラくらいあれば十分だろう
少なくとも完全な運用能力を備えたプロバイダー 2社 は必要だ
従量課金なしでもかなり先まで行ける
主要クラウドプロバイダーは、Railwayがやっていることより少し難しい程度のサービスを提供しており、必要が増えるにつれてより高度な機能へ拡張できる
機能、セキュリティ、可用性を管理する第三者を追加する必要がない
たとえばこのタイムラインによれば、GCPは7分以内に応答していた
Cloud Run を使っていたなら、ダウンタイムを7時間以上短縮できていたはずだし、未知のトリガーが他の顧客の活動やRailwayの奇妙な挙動と関係していたなら、そもそも停止していなかった可能性も高い
複雑さの問題もある
Railwayが修正する必要があったと書いている複雑なインフラの多くは、自分のアカウントだけを使うなら不要だったはずだ
そのコードは明らかに有用な仕事をしているのだろうが、ホスティング事業者には必要でも一般ユーザーには不要な可動部品が多い
今回の障害は全員を巻き込んだが、個別のAWSユーザーやベアメタル利用者は本来影響を受けなかったはずだ
誰にとっても同じグローバル最適解はないが、開発者はデプロイ手順を数段階減らして節約できる時間に比べ、直接コストや他人の環境で働く見えにくいコストを大きく過小評価しがちだ
「5月19日 22:10 UTC - 自動監視がAPIヘルスチェックの失敗を検知し、オンコールを呼び出し、担当者が調査を開始した」
「5月19日 22:20 UTC - Google Cloudが自動措置の一環としてRailwayの本番アカウントを誤って停止状態に切り替えた」
タイムスタンプが正確なら、アカウント停止 10分前 のエラーは何が引き起こしたのだろうか？
最も単純な説明は、どちらか一方のタイムスタンプが間違っているということだが、それ自体は大した問題ではない
しかしタイムスタンプを確信していないなら、明らかに矛盾しているのに確定事項のようにレポートへ載せたのはかなり奇妙だ
22:10が出てくるタイムラインの節はそれ自体で整合しており、次の内容も含まれている
「5月19日 22:19 UTC - 根本原因を確認: Google Cloud PlatformがRailwayの本番アカウントを停止した」
発生前に根本原因を確認することはできない
たとえばGoogleの社員が設定を誤って触り、過去の事故と同じように停止が必要に見えるシグナルを作り、それが停止手続きへ流れるまでに10分かかったのかもしれない
あるいはRailwayの顧客が不正、もしくは不正に見えることを行い、Googleのシステムがアクセス制限を始めた後、その後10分かけて停止へ格上げするか判断していたのかもしれない
承認プロセスに人が入っていたなら、なおさらありそうだ
ただ、その人はそれをやるべきでないと分かるほど十分に掘り下げなかったのは明らかだ
GCPを運用している誰にとっても、これは警告になるべきだ
GCPは自分たちが何をしているかも考えずに、あちこちでアカウントを停止しているように見える
本番の意思決定をGemini 3.1 Proに任せているようなものだ
TKには、OCIでのように組織文化を完全に壊した前歴があり、聞くところではGCPでも似たことをしたようだ
GCPとGoogleは仕事の進め方がまったく異なる組織だ
名前だけ見てGoogle品質を期待してはいけない
Nokiaのように、今では安価なライセンス製品に付く古いブランドに近い。誇張ではあるが、真実から遠くない
それだけでなく、サービスをランダムに終了しつつ、移行期間を6か月程度与えることでも知られている
手の空いたエンジニアが多いので、社内ユーザーをそのサービスから移す作業に投入できるが、顧客の大半にはそれができない
元GCP社員が書いた優れた記事があったが、今は見つけられない
ビジネスを真剣にやるなら、GCPは疫病のように避けるべきだ
修正: 皮肉にもGeminiがその記事を見つけてくれた。読む価値がある: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
HNのトップページ上位に載る程度には名前があり、どこかの時点でGoogle内で介入してくれる人を見つけられそうな規模だ
もし自分の小さなプロダクトだったら、救済手段はまったくなかっただろう
実際の製品品質は良いほうなので、なおさら残念だ
簡単に2位のプロバイダーになれたはずなのに、Azure は非常に不安定で、ドキュメントも低水準だ
GCPが3位なのはかなりの部分で自業自得だ
完全に根拠のない私見だが、Googleの緩いエンタープライズ対応を正すために、規律ある大人役として入ってきたのだと思う
この事故が示すようにまだ課題は多いが、「本気の」エンタープライズ組織になるには必要だったのかもしれない
ただ、その過程でGoogleの他部門と衝突する文化を作った可能性はある
それでも、Oracle部門であるOCIに壊すべき文化があったのだろうか？ むしろTKがその文化をGoogleへ持ち込んだ可能性のほうがありそうだ
重要なことには絶対に使ってはいけない
Google Cloudが顧客アカウントを深刻に壊したのは今回が初めてではない: https://cloud.google.com/blog/products/infrastructure/detail...
「Railwayはベンダー選定の責任を負っており、結局この選択も私たちの責任だ。顧客は障害がGoogleのせいかRailwayのせいかを気にしない。顧客に見えるのは私たちの製品だ。皆さんのアップタイムは私たちの責任であり、私たちはそれを提供し続ける」
PR的な言い回しではなく、これを認めた点は評価できる
GCPを信じたことがRailway側の アーキテクチャ上の失敗 であり、それを是正しようとしていることを示している
事前に予見すべきだったか？ そうだ。それでも、何もしないより遅れてでもやるほうがましだ
「最後に、Google Cloudサービスをデータプレーンのホットパスから外し、補助／フェイルオーバー用途のみに残す計画を立てている」
かなり明確だ
Googleはもはや B2Bサービスプロバイダー として信頼できない
ある会社では、開発者社員1人の個人Facebookアカウントが理由もなくMetaにブロックされたせいで、MetaのOAuthアプリが完全に使えなくなった
何度もエスカレーションしたが、どこにも届かなかった
Metaはアカウントが「個人」でなければならないので、よりひどい
Business Managerがあっても、そこに追加されるユーザーは全員、個人のMeta/Facebookアカウントにひも付く
ばかげている
Googleはまさにこの種の問題のせいで、サービスプロバイダーとして信頼できないことを何度も証明してきた
だから数十の断片に分割すべきなのだ
ユーザーが怒りを公にし、事件が拡散した後になってようやく遅れて元に戻すことがよくあった
Googleは有料顧客に対して何の義務もないかのように、昔から振る舞ってきた
私には、それが最も重要な部分に思える
クラウドプロバイダーが何の理由もなくアカウント全体を停止することはない