RailwayがまとめたGCP障害とGoogle Cloud離脱の決定
(blog.railway.app)- Railwayは、Google Cloudベースのプラットフォーム運用中にus-westの一部マシンが順次停止し、自動フェイルオーバーが失敗するインシデントに遭遇し、ユーザーワークロードの復旧に手動対応が必要になった
- 個々のインスタンスはローリング方式で約10分ずつオフラインになり、16:40 UTCの開始後、20:53 UTCにすべてのワークロードのフェイルオーバーとサービス復旧が完了した
- Railwayは直近18か月間にネットワークの不安定さ、Artifact Registryのクォータ削減、サポート対応の問題を経験し、独自のネットワークスタックと独自レジストリを構築した
- 調査の過程でCPU soft lockupと
kvm_wait、__pv_queued_spin_lock_slowpathのスタックトレースが確認され、RailwayはGCPゲストとハイパーバイザーの相互作用が有力な原因だと見ている - RailwayはGoogle Cloudサービスを終了し、独自のbare metalインスタンスへ移行することを決定。最初のインスタンスはすでに立ち上げており、2024年に全面移行を進める計画
us-westで発生したローリング障害
- RailwayはGoogle Compute EngineなどのGoogle Cloud Platform製品上で、アプリケーション開発プラットフォームを運用してきた
- 2023年12月1日16:40 UTCから、us-westフリートの一部マシンが1台ずつ応答不能になった
- 個々のインスタンスは約10分ずつオフライン状態になった
- 障害はローリング方式で続いた
- 自動フェイルオーバーが行われず、手動フェイルオーバーが必要だった
- 20:53 UTCにはすべてのワークロードのフェイルオーバーが成功し、サービスが復旧した
- Railwayは調査の結果、GCPゲストのuserspace-to-kernelメモリ転送に関連する相互作用が、リソース圧迫時にまれにsoftlockを引き起こし得ると判断した
18か月にわたり蓄積したGoogle Cloudの問題
- Railwayは過去18か月間、Google Cloudに関連して複数の運用上の問題を経験した
-
ネットワークの不安定さ
- 2022年、Googleのクラウド製品で継続的なネットワーク断が発生した
- 何度もGoogleにエスカレーションした後、Railwayは独自のネットワークスタックを構築した
- 独自スタックはresilient eBPF/IPv6 Wireguardネットワークで、現在すべてのデプロイを支えている
- その後、ネットワーク問題は解消した
-
Artifact Registryのクォータ
- 2023年にGoogleがArtifact Registryのクォータを事実上ゼロに近い水準へ任意に削減した、とRailwayは述べている
- イメージ配布のスループットが大きく低下し、ビルドが遅延した
- その後、Railwayは独自のregistry製品を作り、レジストリのスループット問題も解消した
サポート対応とbare metal移行の決定
- RailwayはGoogle Cloudに年間数百万ドルを支払っていたが、Googleの措置がRailwayや他の顧客のワークロードに影響する状況で、十分な対応を受けられなかったと見ている
- 創業者が関連問題をXに投稿した後、Googleから連絡があり、RailwayはGoogleのVPたちと問題の原因について議論した
- Railwayによると、あるGoogleエンジニアがGCPクォータを任意に変更できたという
- GoogleのVPたちは、この問題が受け入れられないものであることに同意したという
- 6月以降もRailwayは、振り返り、公式回答、任意のクォータ変更を防ぐポリシーを継続して求めている
- この過程でGoogleは事前警告なしにToSを変更し、Railwayのコストが20%増加したとRailwayは述べている
- Googleはこの問題にも回答するとしていたが、Railwayはまだ回答を受け取っていないという
- Railwayは前四半期に、すべてのGoogle Cloudサービスを終了し、独自のbare metalインスタンスへ移行することを社内で決定した
- 最初のbare metalインスタンスは数週間前に立ち上がった
- 全インスタンスの移行は2024年に行われる予定
11月30日と12月1日の障害の推移
- 2023年11月30日21:41 UTCには、Googleがマシンを再起動したことで1台のボックスがオフラインになった
- Railwayにはこのような状況を検知し解決する自動システムがある
- 該当ボックスは正常にフェイルオーバーされ、ページは発生しなかった
- 2023年12月1日16:52 UTCには、1台のボックスがアクセス不能な状態でオフラインになった
- 自動フェイルオーバー後も正常に復旧しなかった
- 主要なオンコールエンジニアが呼び出され、調査中に別のボックスもオフラインになった後、復旧しなかった
- Railwayはボックス群を手動でフェイルオーバーし始めた
- 各ホストで約10分のダウンタイムが発生した
- まもなく約12台のボックスが影響を受け、会社の人員の約半数がランブックに従って対応した
- Google Cloudの自動live migrationに似たserial logパターンがあったため、当初はGoogleの日常的な再起動が失敗したものと判断した
- Google側の担当者にメールを送ったが、すぐに不在時の自動返信を受け取った
serial consoleログに見られた手がかり
- Railwayがまず確認したのはserial consoleログだった
- このログは仮想化されたserial deviceを通じてカーネルから直接出力される
- ログにはsoft-locked CPU coreと、ロックされたCPUのスタックトレースが現れていた
- 例としては
kvm_wait、__pv_queued_spin_lock_slowpathがある
- 例としては
- Railwayがこれに似たログと挙動を最後に見たのは、前年12月にGoogleが開始した再起動時だった
- その時も3台のボックスで同じ様相が発生した
- 追加調査で、GCPのnested kernel virtualizationとsoft lockupに関するスレッドと一致するカーネルエラーを見つけた
- Googleが関連バグを認めた事例としてKubernetesのissueコメントを挙げている
- 他ユーザーの不満事例としてStack Overflow事例1、Stack Overflow事例2を挙げている
- Railwayは該当ホストで独自の仮想化を使っていなかったため、
kvmとparavirtualization関連のメッセージを、GCPハイパーバイザーと相互作用するゲストカーネルコードの兆候と見なした - GCPは類似問題を再現不能として扱ったようだが、Railwayは今回の事故が同系列だと強く判断している
推定原因と緩和策
- Railwayは、GCPゲストのuserspace-to-kernelメモリ転送に潜在的に致命的な相互作用があり、まれなリソース圧迫時にsoftlockを引き起こすと見ている
- より具体的には、paravirtualized memory managementと、ハイパーバイザーでページがマッピング・再マッピングされる仕組みが、特定のリソース圧迫状況に関連していると判断した
- 類似報告のほぼ大半がGCPユーザーから出ている点も共通点だと見ている
- GoogleがMMIO命令の大半をuserspaceで処理している点も、Railwayの推測と合致している
- 関連資料としてGoogle CloudブログとYouTube動画を挙げている
- この判断が正しければ、CPU・メモリ・IOPSの観測指標上は上限より低い状態でも、公開されていない速度制限・しきい値・条件によってボックスがsoftlockする可能性がある
- 当時のマシンは、公開されていたリソース制限の約**50%**水準にあった
- Railwayは手動再起動後、影響を受けたインスタンスのリソース圧迫を下げるため一部の内部サービスを無効化し、その後インスタンスは安定した
ユーザーへの影響
- 手動フェイルオーバー中、各マシンにはホストあたり10分のダウンタイムが発生した
- 複数のユーザーがマルチサービスのワークロードを実行していたため、ボックスが連続してオフラインになることで、ダウンタイムが何度も累積する可能性があった
- Railwayはユーザーに謝罪し、より高い信頼性のために独自のbare metalへ移行中だと述べている
1件のコメント
Hacker Newsの意見
2人だけの小さなソフトウェア会社だが、うちも何年もの間 Google Adwords のせいでGoogleとは多くの問題があった。たとえば:
https://successfulsoftware.net/2015/03/04/google-bans-hyperl...
https://successfulsoftware.net/2016/12/05/google-cpa-bidding...
https://successfulsoftware.net/2020/08/21/google-ads-can-cha...
https://successfulsoftware.net/2021/05/04/wtf-google-ads/
Googleに多額を支払っている原文の著者に対してさえまともなサポートを提供する気がないのなら、うちのような小規模事業者にどんな望みがあるのかと思う
全体として、この数年で GCP は方向性を見失ったと思う。数年前までは、コンピューティング・ストレージ・帯域幅の価格性能比でAWSより意味のある優れた選択肢で、自分たちのワークロードについて詳細な性能テストとコストモデリングまで行って確認していた
当時のサポートも素晴らしかった。初期に出した曖昧なネットワーク問題のチケットはすぐにエスカレーションされ、複数地域のエンジニアが引き継いで解決し、最終的にはGCP側の変更がロールバックされた。営業担当者も社内リソースを素早くつないでくれて、全体として良い体験だった
今ではAWSがコスト性能比で明らかに追いつき、複数のマネージドサービスでは今も数年先を行っている。一方でGCPのサポートは大きく悪化し、ほとんどが外部委託のサポート業者に回っているようで、実際のGCPインフラに対する可視性もこちらと大して変わらないように見える
営業体験もはるかに悪くなり、現在の担当者は明らかにマイナス要因だ。GCPに大きく投資してきたが改善の兆しが見えないため、GCP支出を減らす作業を積極的に進めている。以前はGCPの支持者だったが、今では新しいプロジェクトをGCPに載せるよう勧めるのは難しい
どのクラウドプロバイダーにも問題があるのは確かだ。この2年間、仕事で Keyspaces、Amazon Aurora、App Runner に関する問題をいくつも見つけて報告したが、いずれも性能低下につながり、AWSサポートは見当違いの場所ばかり掘らせて時間を浪費させた
数週間エスカレーションしてようやくプロジェクト責任者たちが問題を認めた。その一部はすでに把握されていた問題だったのに、サポートチームに時間を無駄にさせられた形だった。今のところKeyspacesに縛られているが、これからはEC2、EBS、S3のような中核サービスでなければ使わないつもりだ。それ以外に出ると危険だ
会社がすべてのログにCloudWatchを使っているのを見ると、いくつもの代替手段を知らない経験不足のせいだろうと推測してしまう。それでもコンピューティングサービスは信頼できる
GCPでコンピューティングインスタンスが1つ落ちたからといって非難するのはおかしい。原文の著者もまれな出来事だと認めていたが、AWSではインスタンスが強制停止されたり、そもそも消えたりすることをよく経験した。99.95%の耐久性と 99.999% は大きく違う
同じアーキテクチャをAWSに載せていたら、経験上ずっと障害が起きていたはずだ。AWSのドキュメントと自分の経験からすると、AWSの基本構成要素はGCPよりはるかに安定性が低い
彼らはベアメタルへ移ろうとしているようだが、オンコールエンジニアに何とか直せと直接言えるという明確な利点がある
[0] https://aws.amazon.com/compute/sla/
[1] https://cloud.google.com/compute/sla
Google Cloud Supportとは、特にマネージドサービス関連で多くやり取りしてきたが、同規模のAWS利用環境でのサポート体験が常に素晴らしかったことに比べると、正直それほど印象的ではなかった
ただしGoogle Cloudで誰かが本当に助けてくれたなら、それを大いに称賛するとよい。そういうことは珍しいだけに、強いポジティブなフィードバックで報われるようにしてあげるのは大きな負担でもない。自分も本当に素晴らしかった経験が4回あり、そのたびにすぐTAMへメッセージを送った。そういう人たちが報われて昇進してほしい
GCPは10年ほどプロジェクトで断続的に使ってきたし、その上で成功した事業もいくつか作った。完璧ではなかったが、全体としては満足している
逆にCloud Foundryの初期ホスティング版を作っていたチームでAWSをかなり使ったが、戻りたいとは思わない。終わりのない騒動だった
GCPで非常にエンタープライズっぽい機能が壊れたことがあり、その機能がその時点まで一度も正しく動作していなかったことがはっきり露呈した。こっそり直そうとしてダウンタイムまで発生させ、GCPの担当者たちは原因を説明する通話で、全員が NDA の下にあることを繰り返し念押しするばかりだった
上記の事実を認めれば、規制産業にとっては悪夢になっていただろう
「12月1日午前8:52 PSTに1台のボックスがオフラインになり、アクセス不能になった。そしてフェイルオーバー後に自動で戻るはずだったが戻らなかった。メインのオンコールエンジニアが通知を受けて調査している間に、別のボックスもオフラインになり、戻らなかった」
これは筋が通らない。マシンが再起動したら壊滅的な障害になったって？ VMは時々再起動するものだ。なのにそのシナリオで構成全体が自壊するよう設計されているなら、AWSへ移ろうが、まして自前のコロケーションを使おうが、気に入らないだろう
そして本文のどこにも、これが「壊滅的な障害」だったとは書かれていない。Railway全体が落ちたわけではないが、Railwayはデプロイ会社なので、顧客アプリケーションをデプロイするためのコンピューティングリソースを再販売している。したがってVMが1台落ちて自動フェイルオーバーしなければ、そのマシンでサービスを動かしていた特定の顧客にはダウンタイムになる
本文にも「これらのマシンを手動でフェイルオーバーしている間、ホストごとに10分のダウンタイムがあった。多くのユーザーは複数サービスのワークロードを動かしているため、ボックスが順にオフラインになることで、このダウンタイムは何倍にも膨らみ得る。すべてのユーザーに深くお詫びする」と書かれている
興味深いことに、GCPには文書化されていないしきい値がかなり一般的にあるのではないかと思い始めている
Cloud Runでも似たことを経験した。ドキュメント上ではスケーリングを制御するとされるCPU使用率と同時リクエスト数の基準では説明できないスケーリングイベントがあった
有償サポートと長いやり取りをした末に、リクエスト継続時間に関連する追加基準があることを知ったが、当然ながら誰も詳しく説明できなかった
今はここに文書化されているようだ: https://cloud.google.com/run/quotas#cloud_run_bandwidth_limi...
https://hacks.mozilla.org/2022/02/retrospective-and-technica...
本当に苛立たしい経験に聞こえる。ただ、VMの中で仮想化を使っているわけではないのに、ネストされた仮想化がこの問題とどう関係するのかは少し混乱する。ソフトロックは一般に、進行していないことを示す包括的なシグナルだ
MMIO命令に関するコメントも同じように分かりにくい。命令エミュレーションの話なら、それがどこで起きるかがなぜ重要なのか分からない。いずれにせよ遅く、ユーザー空間に縛られるはずで、高速に動作すべきならゲストから抜けること自体がほとんどないはずだし、エミュレーションはなおさらないはずだ
筆者は苛立ちのあまり、最近の出来事について理解できる範囲で何でも手がかりにして原因を探そうとしているように感じる
「2022年にGoogle Cloud製品で継続的なネットワークの瞬断を経験した。Googleに何度もエスカレーションした後、疲れ果てて自前のネットワーキングスタック、つまりすべてのデプロイを駆動する弾力的なeBPF/IPv6 Wireguardネットワークを作った。すると突然ネットワーク問題が消えた」
私の理解では、VM向けネットワークはスイッチにプログラムされるVLANで、VPCを作るとおそらくVLANを作るのだろうが、基盤ネットワークが不安定なら、オーバーレイであるUDP/WireGuardがどうしてより安定し得るのか気になる
ついでに言うと、こういう顧客に対してAWSでこの問題の10分の1でも起きていたら、ソリューションアーキテクトの一団が隔週で会議室に張り付き、アーキテクチャをレビューし、サポートエンジニアを通話に参加させていただろう
古い資料だが、感覚をつかむには役に立つ: https://www.usenix.org/conference/nsdi18/presentation/dalton
自前のネットワークスタックを作ることでそうした最適化を迂回し、WireGuardは本質的に信頼できないUDPの上に構築されているため、断続的な障害をよりうまく扱えたのかもしれない