連鎖的な失敗：RailwayのGCPアカウント停止から学ぶ教訓

2026年5月19日、Railwayは、約8時間にわたる壊滅的なプラットフォーム全体のサービス停止を経験しました。Google Cloud Platform (GCP) による自動的なアカウント停止から始まった事象は、瞬く間に全停止へと発展し、GCP上でホストされているインフラストラクチャだけでなく、AWSやRailway自身のベアメタルサーバー上で動作しているワークロードにも影響を及ぼしました。

このインシデントは、クラウドアーキテクチャにおける重要なケーススタディであり、「レジリエント（回復力のある）」なマルチクラウド戦略であっても、異なる環境間で連鎖的な崩壊を引き起こす単一障害点（Single Point of Failure）を持ち得ることを示しています。

障害の解剖

UTC 22:20、Google Cloudは自動化されたアクションにより、Railwayのプロダクションアカウントを誤って停止状態に置きました。その影響は即座に現れました。Railway Dashboard、API、およびネットワークインフラの主要なコンポーネント（すべてGCP上でホスト）がオフラインになりました。

Railwayはハイブリッドインフラ（Metal、AWS、およびGCP）を利用していますが、そのアーキテクチャには隠れた重大な依存関係がありました。さまざまなワークロードにトラフィックをルーティングするエッジプロキシは、ルーティングテーブルを更新するために、GCP上でホストされているネットワークコントロールプレーンAPIに依存していました。

連鎖効果

障害は3つの異なる段階で展開されました：

即時の損失: すべてのGCPホストのコンピューティング、データベース、およびコントロールプレーンAPIが瞬時に消失し、ユーザーに503エラーを返しました。
キャッシュの猶予期間: 短い期間、Railway MetalおよびAWS上のワークロードは、エッジプロキシがキャッシュされたルーティングテーブルを使用していたため、アクセス可能な状態が維持されました。
全停止: キャッシュが期限切れになると、エッジプロキシはアクティブなインスタンスへのルートを解決できなくなりました。コントロールプレーンAPI（信頼できる情報源）がGCP上でオフラインであったため、ネットワークは再構築できませんでした。その結果、物理的なホスト場所に関係なく、すべてのリージョンにおけるすべてのワークロードに対して404エラーが発生しました。

復旧の課題と二次的な失敗

アカウントへのアクセスを復旧させても、即座にサービスが復旧することを意味するわけではありませんでした。Railwayは、永続ディスク、コンピューティングインスタンス、およびネットワーキングのすべてが、個別の逐次的な復旧プロセスを必要とすると指摘しました。これによりダウンタイムが数時間延長され、コアネットワーキングは翌日のUTC 01:30頃にようやく完全に復旧しました。

システムがオンラインに戻る際、「サンダリング・ハード（Thundering Herd）」効果が発生しました。キューに溜まったデプロイメントと再試行されたリクエストの膨大なバックログが、システムに同時に押し寄せました。これが二次的な失敗を引き起こしました：GitHubがRailwayのOAuthおよびwebhook統合に対してレート制限を開始し、一時的にユーザーのログインや新しいビルドがブロックされました。

技術的な分析とコミュニティの批判

このインシデントは、Hacker News上の技術コミュニティで大きな議論を巻き起こしました。議論は主に2つのテーマに焦点を当てています：GCPの信頼性と、「Platform-as-a-Service」 (PaaS) の抽象化のリスクです。

GCPとの「信頼」のギャップ

多くのエンジニアが、GCPの自動的なアカウント停止に関する同様の恐怖体験を共有しました。批判的な意見の共通認識は、Googleの自動化された強制メカニズムが、B2B顧客に対してあまりに攻撃的であり、十分な人間による監視が欠欠けているというものでした。

"Googleには文化的な問題があります... 私の同僚のC-suite（経営層）の間での会話は、このようなインシデントが数年間にわたって発生しない期間が経過するまでは、GCPを検討対象にすら入れられないということです。"

漏れのある抽象化

一部の観察者は、他のインフラストラクチャプロバイダーの上に構築されているRailwayのようなプロバイダーを利用することの価値に疑問を doubt 疑問を呈しました。その議論は、クラウドプロバイダーの利用規約や自動化されたボットによる根本的な脆弱性を排除することなく、コストとリスクのレイヤーを追加しているだけであるというものです。

予防策：真のメッシュへの移行

Railwayは、コントロールプレーンがマルチAZであったものの、マルチプロバイダーではなかったことを認めました。再発防止のため、彼らはいくつかのアーキテクチャの転換を実施しています：

真のメッシュネットワーキング: ワークロードの発見可能性のために、GCPホストのコントロールプレーンへの強固な依存関係を排除すること。これにより、あるクラウドプロバイダーが停止した場合でも、メッシュは他のパス経由でルートを解決できることを保証します。
クロスクラウド・データベース・クォーラム: 高可用性データベースシャードをAWSおよびMetalに拡張すること。これにより、あるクラウドプロバイダー全体が消失した場合でも、データベースのクォーラム（定足数）定足数を維持し、即時のフェイルオーバーを可能にします。
GCPをホットパスから外す: Google Cloudサービスをプライマリデータプレーンから移動させ、二次的またはフェイルオーバー用の役割に限定することを計画しています。

最終的な教訓

Railwayのインシデントレポートは、極端な透明性を示す稀な例であり、彼らのアーキテクチャの決定が、単一の上流アクションによって全停止へと連鎖することがあったことを認めています。プラットフォームエンジニアにとっての核心的な教訓は、冗長性は独立性と同じではないということです。データを3つのクラウドに配置しても、そのデータを見つけるための「地図」が1つしか保存されていないのであれば、それは無意味です。