クラウド・オン・クラウドのジレンマ：RailwayとGoogle Cloudの障害から学ぶ教訓
2026年5月19日、人気のデプロイメントプラットフォームであるRailwayは、大規模なサービス中断に見舞われ、ユーザーがダッシュボード、API、およびホストされたワークロードにアクセスできなくなる事態が発生しました。その原因は、伝統的な意味での技術的な不具合ではなく、管理上の問題でした。すなわち、Google Cloud Platform (GCP) がRailwayのアカウントをブロックしたのです。
この出来事は、現代のクラウドスタックの脆弱性、「クラウド・オン・クラウド」アーキテクチャの危険性、およびハイパースケーラー環境における自動化されたアカウント管理がもたらすシステム的なリスクについて、開発者コミュニティで広範な議論を巻き起こしました。
障害の解剖
障害のタイムラインを辿ると、一般的なエラーからプラットフォーム全体のブラックアウトへと急速にエスカレートしていく様子が見て取れます。Railwayのステータスアップデートによると：
- 初期の兆候: ユーザーは最初に「no healthy upstream」や「unconditional drop overload」といったエラー、およびログインの失敗を報告しました。
- 発見: 1時間以内に、Railwayはアップストリームのクラウドプロバイダーへのアクセスが遮断されたことを特定しました。
- 根本原因: Railwayは明確に次のように述べています。「Google Cloudが私たちのカウントをブロックしたため、一部のRailwayサービスが利用不可になっています。」
- 復旧: コンピュートリソースは最終的に復旧しましたが、GCP側のネットワーク問題が数時間にわたりサービスの復旧を妨げ続けました。
「クラウド・オン・クラウド」のリスク
Railwayは、他の開発者のためのデプロイメントを簡素化するPaaS (Platform-as-a-Service) として運営されています。しかし、Railway自体がGCPのようなハイパースケーラーの上に構築されているため、層状の依存関係が生じています。これは、批判的な人々によって「クラウド・オン・クラウド」または「clown-on-a-clown」パターンと呼ばれます。
基盤となるプロバイダー（GCP）がアクセスを停止すると、ダウンストリームのエコシステム全体（Railwayとその数千の顧客）が崩壊します。これにより、単一の管理アクションがプロバイダーレベルで行われるだけで、企業全体のフリートを消し去ってしまうという、巨大な爆発半径（blast radius）が生じます。
Hacker Newsのあるコミュニティメンバーが次のように指摘しています：
"If you buy a cloud-on-a-cloud, you're a clown-on-a-clown."
自動化されたガバナンスの危険性
事後分析（post-mortem）の議論において繰り返し現れたテーマは、「自動化されたBAN」への恐怖です。多くの開発者は、高収益のアカウントが、人間の介入や事前の警告なしにどのようにしてブロックされたのか疑問を呈しました。
推測は、AI駆動のセキュリティエージェントや自動化された不正利用防止システムに集中しました。これは、一部のユーザーがRailwayのIPから大量のスパンが送信されていると報告していたことを踏まえると、特に切実な問題です。GCPの自動化システムがRailwayを不正利用としてフラグを立て、自動的にアカウントを停止させた可能性があります。
"How is such a (presumably) high revenue account just magically blocked without human intervention? I'm quite perplexed."
これは、現代のスタートアップにとっての重大な脆弱性、「サブスクリプションが単一の障害点（single point of failure）になる」という事実を浮き彫りにしています。マルチリージョンでのバックアップを行っていたとしても、アカウント自体が無効化されれば、データにはアクセスできなくなります。
レジリエンス（回復力）のための戦略
障害への対応の中で、Railwayの創設者は、彼らのネットワークがAWS、GCP、およびベアメタル（bare metal）の間でメッシュリングを形成するように意図されていると明らかにしました。しかし、今回の事態は、Google VPC (Virtual Private Cloud) が依然として重大な単一の障害点であったことを露呈させました。将来的なリスクを軽減するため、RailwayはMetalとAWSにシャード（shards）を追加し、特定のプロバイダーへの依存をさらに切り離す計画です。
エンジニアやアーキテクトにとって、この出来事はいくつかの重要なアーキテクチャ上の原則を強化するものです：
1. 3-2-1バックアップルールの適用範囲を超えて
従来のバックアップルール（3つのコピー、2つのメディア、1つのオフサイト）は、クラウド時代においては不十分です。すべてのバックアップが同じクラウドアカウント内に存在する場合、爆発半径はアカウント自体を含んでしまいます。真のレジリエンスには、クロスアカウントまたはクロスプロバイダーのバックアップが必要です。
2. ベンダーロックインの回避
単一のプロバイダーの利便性は魅力的ですが、「管理上の障害」のリスクは現実的なものです。インフラストラクチャを複数のハイパースケーラーに分散させ、あるいは別のプロバイダー上でスタンバイ状態のディザスタリカバリ（DR）計画を維持することは、もはやFortune 500企業のためだけのものではありません。
3. 「爆発半径」の管理
他のプラットフォームの上にプラットフォームを構築する企業は、自らの不正利用防止策について細心の注意を払う必要があります。PaaSがユーザーの管理を徹底できていない場合、ハイパースケーラーはPaaS全体を悪意のあるアクターとして扱い、今回の事態のようにアカウントブロックが引き起こされる可能性があります。
結論
Railwayの障害は、クラウドが魔法のようなユーティリティではなく、契約関係であることを痛烈に思い出させてくれます。その関係が、暴走したAIエージェント、設定ミス、あるいは不正利用のフラグによって断たれたとき、インフラストラクチャの技術的な冗長性は無意味になります。重要なサービスを構築している人々にとって、目標は単なる高可用性ではなく、自らのビジネスを支えるインフラストラクチャに対する主権的なコントロール（sovereign control）をを持つことなのです。