概要
- 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