ハクソク

世界を動かす技術を、日本語で。

インシデントレポート：2026年5月19日 – GCPアカウントの停止

2026年5月20日原文(blog.railway.com)

概要

  • 2026年5月19日から約8時間、RailwayはGoogle Cloudの誤ったアカウント停止により全サービス停止
  • 主要なAPI、ダッシュボード、ネットワークインフラが影響を受け、全ワークロードが停止
  • キャッシュ切れにより他クラウドにも障害が波及
  • 復旧には複数段階を要し、GitHub連携にも一時的な制限が発生
  • 今後の再発防止策とアーキテクチャ改善を実施予定

Railway 全面障害発生レポート（2026年5月）

  • 2026年5月19日22:20 UTCから約8時間、 Google Cloud による誤ったアカウント停止により Railway のプラットフォーム全体に障害発生
  • API、ダッシュボード、コントロールプレーン、データベース、Google Cloud上のコンピュート基盤が全て停止
  • ユーザーはダッシュボードやAPIで 503エラー （"no healthy upstream"や"unconditional drop overload"）を即時体験、ログイン不可状態
  • Google Cloud上のワークロード全停止、Railway MetalやAWSの一部ワークロードは一時的に稼働継続
    • ただし、エッジプロキシがGoogle Cloud上のコントロールプレーンAPI依存のため、ネットワークルートキャッシュ切れ後はこれらも404エラーで到達不能
  • 復旧作業中、ビルド・デプロイは全体で一時停止、復旧後はバックログを段階的に処理
  • キャッシュクリアの影響でGitHubはRailwayのOAuth・Webhook連携をレート制限、一時的にログインやビルド不可
  • 利用規約受諾記録もリセットされ、ユーザーは再受諾が必要に

インシデントタイムライン

  • 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チケット提出、アカウントマネージャーと直接連絡
  • 5/19 22:29 UTC：インシデント宣言、GCPアカウントアクセス回復（計算インスタンス・ディスクは停止状態）
  • 5/19 22:35 UTC：キャッシュルート切れ始め、Metal/AWSも404エラー返却
  • 5/19 23:09 UTC：最初のディスクが復旧
  • 5/19 23:54 UTC：全ディスクが復旧、ネットワークは未復旧
  • 5/20 00:39 UTC：ディスク準備完了、ネットワーク復旧待ち
  • 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が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：インシデント解決

障害原因の詳細

  • 5/19 22:20 UTC、Google CloudがRailway本番アカウントを 自動処理で誤って停止
    • 複数アカウントに影響、事前連絡なし
  • この停止により、 ダッシュボード、API、ネットワーク制御、バースト計算基盤 などGCP依存インフラが全停止
  • コントロールプレーンAPI停止により、エッジプロキシのルートテーブルが更新不可となり、キャッシュ切れ後に他クラウド（Metal/AWS）も到達不能
  • 高可用性設計（マルチAZ、冗長ネットワーク）でも、 アカウント復旧だけでは個別サービス復旧不可
    • ディスク、計算、ネットワーク各レイヤーで個別復旧が必要で、復旧に数時間を要した
  • 復旧中、GitHub連携がリトライ急増により レートリミット、ログイン・ビルドに影響
  • 5/20 04:00 UTC時点で主要サービス復旧、残りワークロードも順次回復

再発防止策と今後の改善

  • コントロールプレーンは マルチAZ・マルチゾーン で設計済み、ユーザー影響最小化を目指す
  • しかし、 ネットワーク制御APIがGCP上に依存 しており、キャッシュ切れ時に全体障害へ波及
  • 今後、この依存を排除し、 真のメッシュ構成 へ移行予定
    • どのクラウドが停止しても他クラウド経由で必ずルートが確保できる設計へ
  • 高可用性データベースシャードを AWS・Metalへも拡張、どのクラウド全停止でも即時フェイルオーバー可能に
  • Google Cloudサービスをデータプレーンのホットパスから除外、セカンダリ/フェイルオーバー用途のみに
  • 新アーキテクチャ（データプレーン・コントロールプレーン）を導入し、 単一ベンダ依存の排除 とユーザー向けサービスの堅牢化を図る
  • ベンダ選定・運用責任はRailwayにあり、 ユーザー体験・稼働率の責任を全うする方針

参考リンク

  • 前スレッド: Incident Report: Railway Blocked by Google Cloud [resolved] https://news.ycombinator.com/item?id=48201484

Hackerたちの意見

鉄道業界は、最近のテックプレスであまりいい月じゃなかったよね？どちらの場合も、他の誰かの自動化されたプロセスが原因で、評判を傷つけられたみたい。Gemini CLIの件についてGoogleの担当者と話そうと思ってたけど、こっちの方が心配だわ。

└

他の誰かのプラットフォームの上に構築するのは常にリスクがあるし、他の誰かのプラットフォームの上にプラットフォームを構築するのはさらにリスキーだよね。うちの会社は、基本的にはAWSにいくつかの追加保証をつけたホスティングプロバイダーを使ってたけど、今は必要なものを直接提供してくれる通常のAWSに移行したばかり。

└

AIに管理者権限を与えて、彼らの本番データベースを削除させた場合、それは彼らの責任だよ。彼らだけが管理者アカウントの認証情報をAIに入力したんだから。その後、個人的な責任を全く取らなかった。それは確実に彼らの評判を傷つけたね。ここでは、少なくとも彼らは責任を取ってる。改善してるのは評価できるよ。それに、GCPには本当に深刻な信頼性の問題があるし、Googleには顧客サポートの問題もある。

Google Cloudが顧客のアカウントを本気でめちゃくちゃにしたのは、これが初めてじゃないよね。https://cloud.google.com/blog/products/infrastructure/detail...

質問：小規模なSaaSツールや内部製品について。もしチームがAWSや他のIaaSプロバイダーを管理したくない場合、以下の選択肢の中でベストな代替は何？1.) Vercel - 今月は調子悪い 2.) Supabase - 今月は調子悪い 3.) Railway - 今月は調子悪い

└

Railwayは使ったことないけど、Herokuに似たものだって聞いたよ。Fly.ioはそのニッチな分野の小さなプロジェクトにはかなり良かった。Vercelについては、Next.jsのサイトが静的にコンパイルできるなら、ほぼどんなものでも上げられると思う。以前は自分たちでホスティングしてたけど、設定が簡単だけど、画像の最適化とかは結構手間がかかるよね。

└

DigitalOceanだよ。マジで。彼らは長い間存在していて、毎日頼りにしているコアインフラの多くを構築してきた（例えば、Cephとか）。

└

FlyやRender、Herokuの方がRailwayよりもずっといい選択肢だと思う。

└

何を作ってるかによるけど、これらは全部VPSみたいなもんだね。慣れてないとマシンの管理やセキュリティの負担がちょっとあるけど、他の人も言ってるようにNext.jsはセルフホスティングできるよ。サーバーレスやエッジの機能が必要なければ、Cloudflare Workersに行くのがいいと思う。

└

もしIaaSを直接使えないなら、自分のサービスがダウンする可能性を受け入れなきゃいけないよ。AWSみたいなものを使っても、複数のAZに冗長性を持たせてないなら、時々ダウンタイムがあるからね。それに、複数のAZで冗長性を持たせても、AWSは完全に孤立してるわけじゃないから、サービスが失敗することもある。だから、ダウンタイムは受け入れて、自分に合った最適なツールを使うべきだよ（本当にひどい場合、例えばGitHubレベルのひどさじゃない限り）。ダウンタイムを全く受け入れられないなら、何百万ドルもかけて、ダウンタイムがないことを期待できる自信を持つために数ヶ月の作業が必要になるよ。Netflixのカオスモンキーやインフラがあれば十分だね。

└

Hetzner（またはどのVMプロバイダーでも）+ Dokkuが一番いいよね。

└

ここでのメッセージは、どのクラウドプロバイダーも一つだけじゃ信頼できないってことだと思う。少なくとも、完全な運用能力を持つ二つは必要だよ。

Hacker Newsで議論の続きを見る