インシデント報告：鉄道プラットフォームの障害

🚨 お知らせ事項

本報告書は公表時の知見に基づいており、グーグル・クラウド（Google Cloud）内部審査の結果次第で更新される可能性があります。

---

影響範囲

2026 年 5 月 19 日、UTC 時間 22:20 から約 06:14（5 月 20 日）にかけての約 8 時間にわたり、グーグル・クラウドが我々のプロダクションアカウントのサービス利用を停止したことに伴い、鉄道プラットフォーム全体に障害が発生しました。これにより、API、制御プレーン、データベースに加え、グーグル・クラウド上にホストされた計算リソースも使用不能となりました。

ユーザー体験への影響

ユーザーは直ちにダッシュボードおよび API に対して 503 エラーを受信し、「no healthy upstream（健全な上流サービスが存在しない）」や「unconditional drop overload（無条件ドロープの過負荷）」といったエラーメッセージが表示されるなどしました。また、ログイン操作も行うことができませんでした。グーグル・クラウド上の計算リソースでホストされているすべてのワークロードはオフラインとなりました。

波及効果

一方で、鉄道独自のメタル環境および AWS のバーストクラウド環境上のワークロードは稼働を維持しました。しかしながら、鉄道のエッジプロキシはルーターテーブルの更新のためにグーグル・クラウド上にホストされた制御プレーン API に依存しており、その影響がグーグル・クラウドを超えて波及しました。ルートキャッシュの有効期限が切れるにつれ、これらの他のワークロードも到達不能となり、ネットワーク制御プレーンがアクティブなインスタンスへのルーティングを解読できなくなったため、404 エラーが返されるようになりました。ピーク時の影響においては、すべての地域にある鉄道のワークロード全体が到達不能となりました。

復旧プロセス

• デプロイのブロック: グーグル・クラウド環境の復旧が進むにつれ、個別のサービスを取り戻す作業を行っている最中、プラットフォーム全体でビルドおよびデプロイが制限されました。インフラストラクチャ全体の復旧完了後、プラットフォームへの負荷を過度にかけないよう、待ち行列にある大量の待機デプロイが一括して処理されました。
• OAuth と Webhook: 併せて、キャッシュがクリアされたことによるリトライコールの大量発生により、GitHub が鉄道の OAuth および webhook インテグレーションに対して一時制限をかけ始めました。その結果、ログインやビルドが一時的にブロックされる事態となりました。
• 利用規約: その副次的な効果として、利用規約同意記録も初期化され、ダッシュボードへの次回訪問時にユーザーが改めて同意を求められることとなりました。

われらは、単一のアップストリームプロバイダーの行動がプラットフォーム全体への障害に連鎖することを招いたアーキテクチャ上の判断に対して完全な責任を負うものです。以下では何が起きたのか、どのように復旧したのか、そしてこれ以降同じことが起きないよう何を変更しているかについて詳しく記述します。

---

インシデントのタイムライン

• 5 月 19 日 22:10 UTC - 自動モニタリングシステムが API のヘルスチェック失敗を検知し、オンコールチームに通知されました。調査を開始しました。
• 5 月 19 日 22:11 UTC - ダッシュボードが 503 エラーを返すようになり、ユーザーはログインできなくなりました。
• 5 月 19 日 22:19 UTC - 根本原因特定：グーグル・クラウドプラットフォーム（GCP）が鉄道のプロダクションアカウントの利用停止を誤って実行しました。
• 5 月 19 日 22:22 UTC - GCP に対して P0 クラスのチケットが提出され、GCP アカウント管理担当者との直接連絡が取れました。
• 5 月 19 日 22:29 UTC - インシデント正式宣言。
• 5 月 19 日 22:29 UTC - GCP のアカウントアクセスが再開されましたが、すべての計算インスタンスは停止状態であり、パーステントディスク（永続化ディスク）へのアクセスも不可能でした。
• 5 月 19 日 22:35 UTC - キャッシュされたネットワークルートが有効期限を迎え始めました。ネットワーク解析機能によるルートの解決ができなくなったため、鉄道メタルおよび 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 - インシデント解決。

---

何が起きたのか？

2026 年 5 月 19 日の UTC 時間 22:20 に、グーグル・クラウドは自動化されたアクションの一部として、誤って鉄道のプロダクションアカウントの利用停止措置を講じました。この措置はグーグル・クラウド内の多くのアカウントにも波及しました。プラットフォーム全体への対応であるため、制限実施前に個々の顧客へ事前の連絡が行われることはありませんでした。

インフラストラクチャへの影響

この利用停止状態により、鉄道のダッシュボード、API、ネットワークインフラストラクチャの一部、ならびにグーグル・クラウド上にホストされた追加のバースト計算リソースを支えていた GCP 関連のインフラストラクチャ全体が無効化されました。

鉄道の制御プレーンとは、ダッシュボードの提供、ビルドおよびデプロイのプロセス処理、そしてエッジデバイスで利用されるルーターテーブルの更新を行うための主要な依存関係を構成するものです。影響はグーグル・クラウド上のすべてのワークロードに対して即時に及びました。

ネットワーク全体の機能停止

鉄道のエッジプロキシは、グーグル・クラウド上にホストされたネットワーク制御プレーンからルーターテーブルのキャッシュを持っています。そのキャッシュが有効である間は、鉄道メタルおよび AWS 環境上のワークロードはトラフィックを提供し続けていましたが、キャッシュの有効期限が切れると、エッジ側でアクティブなインスタンスへのルートの解析ができなくなりました。結果として、メタルおよび AWS を含むすべての地域にあるワークロードから 404 エラーが返されるようになり、ワークロード自体はオンラインでもあったにもかかわらず、障害の影響がグーグル・クラウドを超えてこれらの地域にも波及しました。

復旧の遅延

鉄道のインフラストラクチャは高い可用性を備えた設計がなされています。データベースは複数のアベイラビリティゾーンにまたがって稼働しており、ネットワークは AWS、GCP、および鉄道メタル間の冗長接続を採用しています。しかしながら、アカウントへのアクセス復旧により、これらの個別のサービスが即座に復活するわけではありませんでした。パーステントディスク、計算インスタンス、ネットワークはそれぞれ別個の復旧プロセスを必要としました。この復旧プロセスの性質上、障害の継続時間は数時間延長されました。

ディスクは UTC 23:54 にレディ状態に戻りましたが、コアネットワークおよびエッジルーティングは完全には復旧せず、5 月 20 日約 01:30 頃までかかりました（この遅延に関連するエラーがグーグル側によるものかどうかを確認中です）。

ネットワークの復旧に伴い、鉄道のコアサービスやエンドユーザーワークロードの検証は層ごとに順次行われました。ビルドシステムへの負荷をかけないため、デプロイを一時的に一時停止し、徐々に再開させる措置をとりました。コアシステムの復旧と並行的に、GitHub はリトライ要求の大量発生およびバースト的な性質により、鉄道の OAuth および webhook インテグレーションをレート制限するようになり、ユーザーログインやビルドが一時的にブロックされました。

5 月 20 日約 04:00 を過ぎた時点では、API、ダッシュボード、および OAuth エンドポイントの稼働が確認され、残りのワークロードは引き続き復旧していました。

---

予防措置

鉄道のネットワーク制御プレーンは耐障害性を重視して設計されています。複数のアベイラビリティゾーンおよびゾーンにまたがる制御プレーンであり、複数のマシンやコンポーネントの故障を許容しながらも、ユーザーへの影響ゼロで機能し続けるようにしています。この設計は数ヶ月前のロールアウト前にステージング環境および実稼動トラフィックの両方でテスト済みです。

過去のインシデントから得た教訓に基づき、耐障害性への投資を行っております。以前の事例として、鉄道はセカンダリのレート制限を引き起こさずにユーザーの GitHub インストールを優雅に回復させることができました。しかしながら、複数のフォーラムで「なぜ鉄道のようなサービスは、単一の依存関係によってすべての顧客ワークロードに影響を与えるのか？」と問われています。

鉄道のネットワークはメッシュリング構造で構築されており、Metal と GCP 間でファイバ相互接続、GCP と AWS 間のそれを組み合わせて高い可用性を確保しています。しかしながら、このリングにおいても、グーグル・クラウド上で動作しているマシンの間にホストされるネットワーク制御プレーン API に依存してワークロードの発見可能性（discoverability）を維持しており、ここが脆弱点となりました。その結果、メッシュ自体は 1 時間程度は機能し続けていたものの、ルートキャッシュの有効期限を迎えると、メッシュ側でルーターテーブルのリポップが行われず、システム全体が機能不全に陥りました。

講じたおよび予定中の措置

1. 依存関係の撤廃: 直ちにこの依存関係を撤廃し、これを真の意味でのメッシュ構造へと変更する作業を進めています。これにより、相互接続内のいずれかが停止してもクラウド間の経路は常に確保されます。
2. データベースの高可用性: その結果として、AWS とメタルの両方にハイアベイラビリティデータベースシャードを拡張します。将来的に特定のクラウド上のすべてのインスタンスが一瞬で消失した場合でも、データベースクォーラムによりシステム全体は稼働を維持し、実行不能となったワークロードを即時にフェイルオーバーさせます。
3. アーキテクチャのモダナイゼーション: 最後に、データプレーンのホットパス（主要処理経路）からグーグル・クラウドサービスを取り除く計画を立てています。これにより、グーグル・クラウドサービスは二次的／フェイルオーバー用途にのみ限定されます。これは、データプレーン用の新アーキテクチャの実装（ホストへの接続性の確保）および制御プレーン用の新アーキテクチャの実装（ユーザーが鉄道を利用・管理するダッシュボードを稼働させる機能）と並行して進めています。これらのアーキテクチャアップグレードにより、コアサービス、特にユーザーFacing コンポーネントが特定のベンダーやプラットフォームに依存しないことを保証します。

鉄道の提供する製品に対する責任は完全に鉄道にあります。お客様の失敗はグーグルのものなのか鉄道のものなのかという議論は、お客様にとって irrelevant です。お客様が見ているのは貴社の製品だけだからです。サービスの稼働状況（アップタイム）の責任はわれらにあります。今後もこれを期に務めてまいります。