5月19日のRailway障害はなぜ起きたのか：Google Cloudのアカウント制限がプラットフォーム全体を停止させた理由

• CloudSQL（プラットフォームのデータベース）
• Railway API（内部・外部の中心的サービス）
• Overflow VM（追加計算リソース）

特に重要だったのが APIの消失です。Railwayのコントロールプレーンの中心となるサービスであり、これがなくなることで多数の依存サービスが同時に機能停止しました。

その結果、次のような機能が広範囲で影響を受けました。

• ダッシュボードとログイン
• アプリのデプロイ
• アプリケーションのルーティング
• 新しいワークロードのビルドやプロビジョニング

つまり、開発者向けUIと実際にホストされているアプリの両方が不安定、または完全にアクセス不能になりました。

障害がプラットフォーム全体に広がった理由

問題がさらに深刻化したのは、Railwayのオーケストレーションやルーティング層が、制限されたGoogle Cloudリソースに依存していたためです。

Railwayは復旧作業の中で、ユーザーに アプリを再デプロイすることで正常なマシンへルーティングできる場合があると説明しました。

これは次のことを示唆しています。

• ワークロード配置
• ルーティング状態
• インフラ再構築

といった処理を担うコントロールプレーンが、Google Cloudのリソースなしでは完全に機能しなかった可能性があるということです。

一部コミュニティでは、AWSやRailway自社ハードウェア上のワークロードにも影響が広がった理由として、ルーティング状態の更新ができなかった可能性が指摘されています。ただし、この仕組みの詳細は公式の完全なポストモーテムではまだ確認されていません。

「マルチクラウド」でも安全とは限らない

この障害で最も議論を呼んだのは、マルチクラウド設計の落とし穴です。

RailwayはAWSや専用ハードウェアなど複数の環境でインフラを運用しています。しかし今回のケースでは、コントロールプレーンがGoogle Cloudアカウントに依存していたため、単一の制限イベントが全体停止につながりました。

アカウントへのアクセスを失うと、単なる計算リソースだけでなく次の機能も同時に失われます。

• デプロイ情報の管理
• ルーティング設定
• インフラのプロビジョニング
• ワークロード復旧

結果として、マルチクラウドでも実質的な単一障害点（Single Point of Failure）が存在していた形になります。

自動アカウント制限への懸念

今回の出来事は、クラウドプロバイダーが採用している自動アカウント制御システムにも議論を呼びました。

大手クラウドでは次のような理由でアカウントが自動制限されることがあります。

• 請求トラブル
• ポリシー違反
• セキュリティ異常

ただし今回のケースでは、Google CloudがなぜRailwayのアカウントを制限したのかは公表されていません。

このため、

• 自動判定による措置だったのか
• 誤検知だったのか
• 何らかの運用問題だったのか

といった点は依然として不明のままです。

まだ分かっていないこと

現時点の公開情報では、いくつかの重要な点が未解決です。

• Google Cloudがアカウントを制限した具体的な理由
• CloudSQL、API、ルーティング、計算基盤の詳細な依存関係
• 障害が他クラウド環境に波及した正確な技術的メカニズム

今後、より詳細な技術ポストモーテムが公開されれば全体像が明確になる可能性があります。

クラウド時代のインフラ設計への教訓

この障害が示した最大のポイントは、インフラの多様性よりもコントロールプレーンの依存関係が重要だということです。

複数クラウドにワークロードを分散していても、次の仕組みが単一プロバイダーに依存している場合、全体停止のリスクは残ります。

• オーケストレーション
• デプロイ管理
• ルーティング
• 認証
• データベース

Railwayの5月19日の障害は、現代のクラウドアーキテクチャにおける重要な教訓を改めて示しました。

「マルチクラウド」であることと、「単一障害点がない」ことは同じではないということです。