その直後からユーザー側では次のような問題が発生しました。
Railwayのエンジニアによる説明では、Google Cloudのアカウントが「restricted」状態に移行し、そのアカウントに紐づく複数のリソースが削除されたとされています。
復旧には数時間を要し、RailwayはGoogle Cloudサポートと協力しながらアカウントのアクセス回復とサービス再構築を進めました。企業向けサポート契約があっても、制限の原因を特定するまでに時間がかかったと報告されています。
今回の制限は、Railwayが自社サービス運用に利用していた基盤レベルのコンポーネントに直接影響しました。
削除または停止された主なリソースは以下です。
特に重要だったのが APIの消失です。Railwayのコントロールプレーンの中心となるサービスであり、これがなくなることで多数の依存サービスが同時に機能停止しました。
その結果、次のような機能が広範囲で影響を受けました。
つまり、開発者向けUIと実際にホストされているアプリの両方が不安定、または完全にアクセス不能になりました。
問題がさらに深刻化したのは、Railwayのオーケストレーションやルーティング層が、制限されたGoogle Cloudリソースに依存していたためです。
Railwayは復旧作業の中で、ユーザーに アプリを再デプロイすることで正常なマシンへルーティングできる場合があると説明しました。
これは次のことを示唆しています。
といった処理を担うコントロールプレーンが、Google Cloudのリソースなしでは完全に機能しなかった可能性があるということです。
一部コミュニティでは、AWSやRailway自社ハードウェア上のワークロードにも影響が広がった理由として、ルーティング状態の更新ができなかった可能性が指摘されています。ただし、この仕組みの詳細は公式の完全なポストモーテムではまだ確認されていません。
この障害で最も議論を呼んだのは、マルチクラウド設計の落とし穴です。
RailwayはAWSや専用ハードウェアなど複数の環境でインフラを運用しています。しかし今回のケースでは、コントロールプレーンがGoogle Cloudアカウントに依存していたため、単一の制限イベントが全体停止につながりました。
アカウントへのアクセスを失うと、単なる計算リソースだけでなく次の機能も同時に失われます。
結果として、マルチクラウドでも実質的な単一障害点(Single Point of Failure)が存在していた形になります。
今回の出来事は、クラウドプロバイダーが採用している自動アカウント制御システムにも議論を呼びました。
大手クラウドでは次のような理由でアカウントが自動制限されることがあります。
ただし今回のケースでは、Google CloudがなぜRailwayのアカウントを制限したのかは公表されていません。
このため、
といった点は依然として不明のままです。
現時点の公開情報では、いくつかの重要な点が未解決です。
今後、より詳細な技術ポストモーテムが公開されれば全体像が明確になる可能性があります。
この障害が示した最大のポイントは、インフラの多様性よりもコントロールプレーンの依存関係が重要だということです。
複数クラウドにワークロードを分散していても、次の仕組みが単一プロバイダーに依存している場合、全体停止のリスクは残ります。
Railwayの5月19日の障害は、現代のクラウドアーキテクチャにおける重要な教訓を改めて示しました。
「マルチクラウド」であることと、「単一障害点がない」ことは同じではないということです。