インシデントレポート: Google Cloud によってブロックされた Railway [解決済み]

 (status.railway.com)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • Railway の広範なサービス障害は解決され、原因は Railway の Google Cloud アカウントのブロックであることが確認された
  • 障害中、ユーザーは "no healthy upstream"、"unconditional drop overload"、ログイン失敗、ダッシュボードにアクセスできない状態を経験する可能性があった
  • Railway は Google Cloud サポートチーム と直接連絡を取り、アカウントアクセスを復旧し、コントロールプレーンとワークロードの復旧を進めた
  • 復旧過程では Google Cloud の ネットワーク問題 が残り、一部サービスの起動が妨げられ、非エンタープライズ向けビルドは一時的に制限された
  • サービスは完全に復旧したが、異常として検知された一部の ワークロード は自動再デプロイ中であり、必要に応じてユーザーが手動で再デプロイする必要がある

障害の概要と最終状態

  • Railway は広範なサービス障害を解決しており、事後分析は Incident Report で確認できる
  • 障害期間中、ユーザーは "no healthy upstream"、"unconditional drop overload"、ログイン失敗、ダッシュボードにアクセスできない状態を経験する可能性があった
  • 原因は Railway の Google Cloud アカウントのブロック であり、一部の Railway サービスが利用できない状態になっていた
  • Railway は Google Cloud サポートチーム と直接連絡を取り、アカウントアクセスを復旧し、ワークロードの復旧を進めた
  • サービスは完全に復旧したが、異常状態として検知された一部ワークロードは自動再デプロイ中であり、応答が正常でないサービスはユーザーが手動で再デプロイしなければならない場合がある

復旧の経過とユーザーへの影響

  • 初期調査と原因確認

    • Railway は、ダッシュボード、API、内部ネットワークの コントロールプレーン を動かす Google Cloud インフラを復旧した
    • 上位クラウドプロバイダーへのアクセスが復旧した後も、Railway ダッシュボードおよびクラウドインフラ上で動作するサービスは、修正デプロイまで引き続き影響を受ける可能性があった
    • Google Cloud アカウントのブロック後、Railway プラットフォームチームは Google Cloud でホストされる一部インフラへのアクセスを確認し、残りのサービスアクセスを復旧した

  • Google Cloud とネットワーク問題

    • Railway は Google Cloud 上のコンピュートを復旧したが、Google Cloud 側の ネットワーク問題 が残り、一部サービスは起動できなかった
    • 復旧中は、Google Cloud でホストされるワークロードが断続的な問題を引き続き経験する可能性があった
    • Railway インフラチームは、影響を受けたサービスを再びオンラインに戻すための 代替経路 もあわせて検討した

  • ビルドとデプロイの制限

    • Railway metal ワークロードは段階的に復旧し始めた
    • 復旧過程では、ビルドインフラの過負荷を避けるため、すべての 非エンタープライズ向けビルド が一時的に制限された
    • その後も非エンタープライズ向けデプロイは一時停止のままとなり、エンタープライズ向けデプロイ は影響を受けなかった
    • デプロイが再び可能になった後も、Google Cloud 上に残るワークロードは、復旧完了まで断続的な問題を経験する可能性があった

  • 現在の対応

    • Railway サービスは完全に復旧しており、応答が正常でないサービスはダッシュボードまたは CLI から 再デプロイ する必要がある
    • 追加の文脈は FAQ で確認でき、個別のサポートが必要な場合は Railway Station にスレッドを立てることができる

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsのコメント

  • Railwayはこの障害を解決し、事後分析を公開した
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    5月20日 07:57 UTC時点でステータスページも公開されている
    https://status.railway.com/incident/I23M92U0

    • こういうケースでは Googleに損害賠償を請求できるべきだと思う。ネットワーク障害やサービス失敗のように利用規約に含まれる類の問題ではない
    • Railwayは障害が解決したと言っているが、まだ多くのサービスが 502 を返して停止している。こちらでは手動で再デプロイをトリガーして初めて復旧したが、Railwayが自動でやるべきだったと思う
      全体としてこちらのダウンタイムは 11時間超 だった

  • GCPがまたスタートアップを落とした日から0日目だ
    こういうのは少なくとも年に1回は見ている気がするし、AWSやAzureでは聞いたことがない
    真面目な話、それが理由でGCPは使わない。ビッグ3の中でいちばん使いやすいクラウドなのに、こういう評判で自分から台無しにしている

    • 逆にGCPで深刻な障害が起きた記憶はあまりない。AWS/Azureのほうが年に何回か壊滅的に落ちている気がする
    • AWSのほうが効率的だ。us-east-1 が落ちると複数のスタートアップをまとめて落としてくれる
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azureも去年、AzureとO365サービス全体のフロントドアを壊していた
      これらの会社にはそれぞれ得意分野があるが、ときどき盛大にやらかす
    • AWSがうちのサービスをひどく スロットリング して運用できなくなったことがある。彼らが1か月間うちの成長を止めたという記事を書こうと思っていたが、今となってはあまり意味がなさそうだ
    • うちも同じ理由でGCPには触らない

  • みんなGoogleを責めたがっているが、Railwayをかなり長く使ってきた立場としては、結論を出す前に GCP側の見解 も聞いてみたい。Railwayでは以前にもこういう問題があったし、そのチームの対処の仕方は信頼を与えるものではなかった
    いずれにせよ、今回の件は私にとって最後の限界だった

    • 私も逸話レベルではあるが同意する。Railwayの開発チームはあちこちで バイブコーディング を混ぜながら、かなり緩い感じで動いている印象だ。「まだスタートアップだから大目に見てほしい」にも限度があるが、Railwayはその線を越えている
    • その通り。別スレッドではクラウドプロバイダーを強く非難するアカウントが多く見えるのに、この怒りの流れの中で 根本原因 を気にしたり、その可能性を検討しようとする姿勢がほとんどないのは不思議だ
    • 2年前にサポートが必要だったが、あまりにひどかったので、そのままVercelに移って縁を切った
      他のサービスでも似たものが必要になって探していたら coolify を見つけた。coolifyが使えるならRailwayを使う理由はまったくない
    • 具体的な過去の事例を教えてもらえるなら読んでみたい
    • 知るべきでない詳細を聞いている。今回は 100% Googleの責任 だと自信を持って言えるし、Railwayがこれ以上共有できないなら失望すると思う
      GCPを完全に避ける以外に、Railwayに防ぐ方法は本当になかった

  • 2024年5月の UniSuper障害 もあった: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    UniSuper CEOのPeter ChunとGoogle Cloud CEOのThomas Kurianによる共同声明によれば、UniSuperのPrivate Cloudサービスをプロビジョニングする過程で不注意な設定ミスが発生し、その結果UniSuperのPrivate Cloudサブスクリプションが削除された
    Google Cloudは、これは世界中のどのGoogle Cloud顧客にも前例のない孤立した「一度きりの事象」だとしたが、このサブスクリプション削除が両リージョンの削除を引き起こし、復旧には数百台の仮想マシン、データベース、アプリケーションの復元が必要だった

    • 当時、UniSuperの問題について書いた: https://danielcompton.net/google-cloud-unisuper
      かなり深刻なバグで、彼らのVMWare環境は 1年の有効期限 を持つ状態で作成されていたが、Google Cloudの観点ではそれが1つの「リソース」だった
    • 「Private Cloudサブスクリプションの削除が両リージョンの削除を引き起こした」というのは 単一障害点 と呼ぶもので、安全性を担ってきた人なら誰でも悪夢のように感じる話だ
    • サブスクリプションを閉じるか削除した途端に世界規模で連鎖削除が起きる設計は、災害のレシピのように聞こえる。なぜ削除マークだけ付けて1日後か1週間後に消さないのか分からない

  • 月間利用額の大きい会社で、いったいどうしてこういうことが起きるのか分からない。前職でAWS上で怪しいワークロードが動いたときは、TAM が対応前にまず連絡してきた
    今回の件は何かおかしなAI自動化で、GCPは人間に実際に連絡して返答を受けるのを嫌うようだから、外注要員が何時間も後にサポートキューで見つけて定型文を送っただけなのではないかと思ってしまう

    • GCPサポート絡みの話なら、もう何が起きても驚かない。うちにはまったく必要ないのに、過去6年間で Account Executive が12人以上替わっていて、全員まったく役に立たなかった
      毎回自己紹介をして、エンジニアリング担当とのミーティングを設定してほしいと言い、うちとはまったく関係のない定型スライドデッキを持ってきて失笑するしかなく、次の連絡は新しいAEが割り当てられたときだった
      GCPとそのサービス自体は好きで何年も満足して使ってきたが、人の側は本当にひどく、なぜわざわざ運営しているのか分からない
    • 別スレッドにも意味のある返答があった気がする。うちも最終的にはアカウントを取り戻せたが、Account Rep とCSMがいても何が起きたのか把握するのに時間がかかった
      担当者がいなければもっとひどかったかもしれない
    • Googleだからな。サービスは使わせてくれるが、お前が規範から外れた瞬間に停止させる

  • 公開APIを運営する立場からすると、Railway IP から来るスパムが信じがたいほど多い。悪用対策がひどく、今回の件が運用改善のきっかけになってほしい

    • ホスティング会社を運営していたときの核心的な衝突はまさにこれだった。登録を簡単にすると新規ユーザーはたくさん来るが、悪用 も大量に入ってくる
      悪用防止策を入れるとうるさい誤検知が生まれるし、今回のGCPの件もそれかもしれない
      ホスティング会社を運営する人はうらやましくない。インターネットは表面の下が本当に汚い
      付け加えると、AWSはこの点を本当にうまくやっている。おそらく約30年にわたる小売詐欺と悪用対策の経験のおかげだろう

  • ちょっと待って、RailwayってGCP上で動いていたのか？ 「他のクラウドの上にクラウドを作らない」と大きく言っていなかったか？
    それともVPSを借りるのではなく、クラウドプロバイダーからベアメタルだけ借りるという意味だったのか？
    少なくともハイパースケーラーのどれか1社に金を払うだけではなく、コロケーションをしてスタックをより多く所有する別のプロバイダーが出てきたのだと思って期待していた
    https://blog.railway.com/p/heroku-walked-railway-run

    • Wayback Machineで見たリンク先の記事にはこう書かれていた
      「初日からこの考えを最前線に置いていた。
      そして私たちが直感したのは、他のクラウドの上に クラウド を作ることはできないということだ。Railwayのビジネス、ひいては顧客のビジネスが可能な限り堅牢になるよう、自社サーバーを運用し、他のクラウドとうまく共存する実務に何年も費やしてきた。」
    • そう、だから腹が立つ。彼らは嘘をついていた。GCPに完全に依存していた
      もう少し調べる必要がありそうだ。これより安定していて、1社の気まぐれにあまり依存しないものが必要だ
      Railwayにとっても良くない話で、彼らの大きな主張である 平和なソフトウェアデプロイ の核心をまさに突いているからだ。これは混沌だ

  • Railwayが自前のデータセンターを作っているのだと思っていた [0]
    「実際のところ、他人のクラウドの上にクラウドを作ることはできない。」
    本当にそうだな…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercelはそれをやれているように見える。PlanetScaleもデータベースに限ればそうだし、結局すべてはデータベースだ

  • Railwayに登録するとき、システム悪用や暗号資産マイニングなどに関する規約を読んで理解したか確認されるのが特徴的だ
    推測するに、多くのユーザーが 無料ティア を悪用してサービス提供者と問題を起こしているのだろう
    競合の立場であってもRailwayがこういう打撃を受けるのを見て喜びはしないが、無料コンピュートはあらゆる変なユーザーを引き寄せる。うちも経験があり、流入上部が減るとしても初期に無料コンピュートを避けることにした

  • Googleだけを責めるのは難しいと思う。Railwayはプラットフォームの安定性を維持するのにますます苦労しているように見える
    こういうことが サービス全体 を落としてはいけない。文字通り安定したバックエンドを提供するのが事業なら、バックアップがあるべきだ。私にはずさんな計画に見える

    • 何を言いたいのかよく分からない。Railwayがすべての顧客プロジェクトをホストするために マルチクラウドアーキテクチャ を使うべきだと本気で期待しているのか？ 全体としては、むしろ可用性を下げそうだ
    • 災害復旧ってかなり高くつかないか？ 特にRailwayの規模だと、なおさらそう思える