Cloudflareのコントロールプレーンおよび分析システム停止に関する事後分析
(blog.cloudflare.com)- 2023年11月2日 11:43 UTCからCloudflareのコントロールプレーンと分析サービスが停止し、ダッシュボード/APIの変更、ログ・分析機能に影響が出た
- 障害の発端はFlexentialが運営するオレゴンのPDX-04電源障害で、この施設には最大の分析クラスターと高可用性クラスター機器の3分の1以上があった
- utility feed、generator、UPS、回路遮断器の復旧が連鎖的に揺らぎ、PDX-04専用のKafka・ClickHouse依存関係が高可用性設計を崩した
- 11月2日 13:40 UTCに欧州の災害復旧サイトへのfailoverを決定し、17:57 UTCには顧客影響の大半が軽減されたが、ログ処理・一部のbespoke API・Magic WANの手動設定・Streamアップロードはより長く影響を受けた
- CloudflareはGA製品の高可用性要件、検証済みの災害復旧計画、中核データセンター全体の除去を含むchaos testing、ログ損失防止計画をCode Orangeで推進する
障害範囲と顧客影響
- 2023年11月2日 11:43 UTCからCloudflareのコントロールプレーンと分析サービスで障害が発生した
- コントロールプレーンはWebサイトとAPIを含む顧客向けインターフェースを意味する
- 分析サービスにはロギングと分析レポートが含まれる
- 事故全体は11月2日 11:44 UTCから11月4日 04:25 UTCまで続いた
- 11月2日 17:57 UTCに災害復旧施設でコントロールプレーンの大半が復旧した
- 災害復旧施設がオンラインになった後は、大半の製品で多くの顧客が問題を経験しなかった可能性がある
- 一部サービスは復旧により長くかかり、それらのサービスを使う顧客は完全解決まで問題を見る可能性があった
- 生ログサービスは事故期間の大半で、ほとんどの顧客に提供されなかった
- Cloudflareのネットワークとセキュリティサービスは事故の全期間を通じて想定通りに動作した
- 顧客がそれらのサービスを変更できない期間はあった
- Cloudflareネットワークを通過するトラフィックは影響を受けなかった
元の設計: Oregon 3つのデータセンターを基盤とした高可用性
- Cloudflareのコントロールプレーンと分析システムは、主にOregon州Hillsboro周辺の3つのデータセンターのサーバーで動作していた
- 3つのデータセンターは互いに独立しており、それぞれ複数のutility power feedと複数の冗長・独立したネットワーク接続を持つ
- 施設は自然災害が同時に影響しにくいように離しつつ、active-active冗長データクラスターを運用できる程度には近い場所として選定されていた
- 3施設は継続的にデータを同期する
- 設計上、1施設がオフラインになっても残りの施設が継続運用できるはずだった
- この高可用性設計は4年前から実装が始まっていた
- 大半の中核コントロールプレーンシステムは高可用性クラスターへ移行済みだった
- 一部の新製品サービスはまだ高可用性クラスターに含まれていなかった
- ロギングシステムは意図的に高可用性クラスターへ含められていなかった
- ログはネットワークedgeでキューに積まれた後、Oregon coreまたは地域ロギング施設へ送信される分散問題として扱われていた
- ロギング施設がオフラインなら分析ログはedgeで待機し、分析遅延は許容可能と判断されていた
PDX-04電源障害の始まり
- 3つのOregon施設のうち最大のものは、Flexentialが運営するPDX-04だった
- Cloudflareはここに最大の分析クラスターを置いていた
- 高可用性クラスター機器の3分の1以上もこの施設にあった
- 高可用性クラスターへオンボーディングされていないサービスの既定配置先でもあった
- Cloudflareはこの施設全体容量の約10%を使用する比較的大口の顧客だった
- 11月2日 08:50 UTCに、PDX-04へ給電するPortland General Electric(PGE)の独立した電力feedの1つで計画外の保守イベントが発生した
- このイベントによりPDX-04へ入るfeedの1つが停止した
- Flexentialは停止したfeedを補うためにgeneratorを起動した
- FlexentialはCloudflareにgenerator電源へfailoverした事実を通知しなかった
- Cloudflareの観測ツールは電源供給元が切り替わった事実を検知できなかった
- 事前通知があればCloudflareは施設を綿密に監視し、その施設に依存するコントロールプレーンサービスを他へ移せたはずだった
- Flexentialが残るutility feedとgeneratorを同時運用した点も異例だった
- Flexentialは冗長機を含め10台のgeneratorを運用しており、施設全体の負荷を賄えた
- 残るutility feedだけで施設を運用することも可能だった
- CloudflareはFlexentialがutility powerとgenerator powerを併用した理由について明確な回答を得られなかった
確認されていない原因とgenerator停止
- その後の事象の根本原因と一部の意思決定は、Flexentialから明確に確認されていない
- 可能性の1つとして、FlexentialがPGEのDSGプログラムに参加していた可能性が残っている
- DSGは地域電力会社がデータセンターgeneratorを活用して電力網へ追加電力を供給できるようにするプログラムである
- その見返りに電力会社はgenerator保守と燃料供給を支援する
- CloudflareはFlexentialがDSGプログラムを通知した記録を見つけられなかった
- 事故当時にDSGが有効化されていたかについても回答を得られなかった
- 11:40 UTCごろ、PDX-04のPGE transformerでground faultが発生した
- Cloudflareは、このtransformerがデータセンターへ入っていた2本目のfeedの電圧を下げる装置だったとみているが、確認は取れていない
- このground faultが、最初のfeedに影響したPGEの計画外保守に起因するかも確認されていない
- 12,470Vの高電圧ラインにおけるground faultでは、損傷防止のため電気システムが素早く遮断されるよう設計されている
- この保護措置によりPDX-04の全generatorも停止した
- 結果としてutility lineと10台のgeneratorがすべてオフラインになった
- PDX-04には施設を約10分維持できるとされるUPSバッテリーバンクがあった
- この時間は電源障害とgenerator自動再起動の間を埋めるためのものだった
- Cloudflareの機器障害観測基準では、バッテリーは4分で失敗し始めた
- Flexentialがgeneratorを復旧するには10分をはるかに超える時間がかかった
電力復旧遅延と最初の通知
- Cloudflareは公式確認を受けていないが、Flexentialの担当者からgenerator復旧を妨げた3つの要因を聞いた
- ground faultで回路がtripした方式のため、generatorへ物理的に接近して手動再起動する必要があった
- Flexentialの入退室制御システムはバッテリーバックアップ電源を受けておらず、オフラインだった
- 夜勤要員には経験ある運用または電気の専門家がおらず、警備要員と入社1週間の単独対応不可の技術者しかいなかった
- 11:44〜12:01 UTCの間、generatorが完全再起動できないままUPSバッテリーが放電し、データセンターの全顧客が電力を失った
- Flexentialはこの過程でCloudflareに施設問題を知らせなかった
- Cloudflareは11:44 UTCに外部と施設を結ぶルーター2台がオフラインになり、データセンター問題を初めて認識した
- ルーターへ直接またはout-of-band managementでアクセスできなかったためFlexentialへ連絡し、現地チームを施設へ向かわせた
- FlexentialがCloudflareへ最初に送った障害メッセージは12:28 UTCだった
- メッセージには、PDX-04の電源問題が12:00 UTCごろに始まり、エンジニアが復旧中で、30分ごとに進捗を知らせるという内容が含まれていた
高可用性設計で露呈した依存関係の問題
- PDX-04は建設前にTier III認証設計を受け、高可用性SLAを提供すると期待されていたが、Cloudflareはこの施設がオフラインになる可能性も計画していた
- 想定していた影響は、分析停止、edgeでのログキュー滞留と遅延、高可用性クラスターに統合されていない低優先度サービスの一時停止だった
- 他の2つのデータセンターが高可用性クラスターを担い、中核サービスをオンラインに保つ動作は概ね計画通りに機能した
- 問題は、高可用性クラスターにあるべき一部サービスがPDX-04でしか動かないサービスに依存していた点だった
- ログ処理と分析を担うKafkaとClickHouseがPDX-04でしか提供されていなかった
- 高可用性クラスター上で動く一部サービスがこれらに依存していた
- この依存関係はもっと疎結合であるべきで、より優雅に失敗すべきであり、事前に発見されるべきだった
- Cloudflareは高可用性クラスターテストで、他の2施設それぞれと両方を完全オフラインにしたことがある
- PDX-04の高可用性部分をオフラインにするテストも実施した
- しかしPDX-04施設全体を完全オフラインにするテストは行っていなかった
- 新製品と関連データベースが高可用性クラスターへ統合されることを求める基準も緩すぎた
- 製品チームごとにalpha段階へ進む経路が異なっていた
- 時間の経過とともにバックエンドをベストプラクティスへ移行する方式だったが、GA宣言前の正式要件ではなかった
- その結果、製品ごとに冗長保護の効き方が一貫していなかった
災害復旧サイトへの切り替え
- 12:48 UTCにFlexentialはgeneratorを再起動し、施設の一部に電力が戻った
- データセンターの電力復旧は通常、1回路ずつ段階的に進む
- Cloudflare回路を再投入しようとした時点で、回路遮断器が故障していることが判明した
- これらの遮断器がground faultやsurgeで故障したのか、以前から問題があったのかは不明である
- Flexentialは故障した遮断器の交換を開始した
- 施設内保有分より多くの遮断器が故障し、新しい遮断器を調達する必要があった
- Cloudflareは想定以上に多くのサービスがオフラインで、Flexentialが復旧時間を提示できなかったため、13:40 UTCに欧州の災害復旧サイトへfailoverすることを決定した
- failoverが必要だったのはコントロールプレーン全体のうち小さな割合だけだった
- 大半のサービスは残る2つのcoreデータセンターの高可用性システムで継続稼働していた
- 13:43 UTCに災害復旧サイトで最初のサービスを起動した
- このサイトは災害発生時に中核コントロールプレーンサービスを提供するよう設計されていた
- 一部のログ処理サービスはサポートしていなかった
- サービス起動後、失敗していたAPI呼び出しが殺到し、thundering herd問題が発生した
- Cloudflareはリクエスト量を制御するためrate limitを適用した
- この期間、大半の製品顧客はダッシュボードやAPIで変更を行う際に断続的なエラーを見る可能性があった
- 17:57 UTCまでに災害復旧サイトへ移されたサービスは安定化し、大半の顧客への直接影響は軽減された
- Magic WANなど一部システムは依然として手動設定が必要だった
- ログ処理と一部のbespoke API関連サービスはPDX-04復旧まで利用できなかった
一部製品の遅延復旧とPDX-04再起動
- 一部製品は災害復旧サイトで正常に稼働しなかった
- 主に災害復旧手順が完全に実装・テストされていない新製品だった
- 新しい動画アップロード向けのStreamサービスや、いくつかの他サービスが含まれる
- Cloudflareチームは2つの経路を同時に進めた
- 災害復旧サイトでそれらのサービスを再実装した
- 高可用性クラスターへ移行した
- Flexentialは故障した回路遮断器を交換し、2本のutility feedを復旧させ、22:48 UTCに安定した電力を確認した
- Cloudflareは、チームが終日緊急対応を行っていたため、大半の人員を休ませ、翌朝にPDX-04への復帰作業を始めることを決定した
- この判断は完全復旧を遅らせたが、追加ミスの可能性を減らすためのものだった
- 11月3日朝からPDX-04サービスの復旧が始まった
- ネットワーク機器を物理的に起動した
- 数千台のサーバーを起動してサービスを復旧した
- 事故中に複数回の電源サイクルが発生した可能性があり、データセンター内サービスの状態は不明だった
- 安全な復旧手順は施設全体の完全なbootstrapに従うことだった
- 構成管理サーバーを手動でオンライン化し、再構築に3時間かかった
- その後、残りのサーバーをbootstrap方式で再構築した
- 各サーバーの再構築には10分から2時間かかった
- 複数サーバーで並列実行したが、サービス間依存のため一部は順次復旧が必要だった
- すべてのサービスは2023年11月4日 04:25 UTCに完全復旧した
- ほとんどの顧客では、分析データが欧州coreデータセンターにも保存されているため、ダッシュボードとAPIの大半の分析でデータ損失はないと見込まれる
- EUへ複製されていない一部データセットには恒久的な欠落が残る
- Logpush利用顧客は事故期間の大半でログが処理されず、受け取れなかったログは復旧されない
Code Orangeと改善計画
- CloudflareにはFlexentialから回答を得るべき疑問が多く残っているが、データセンター全体の障害も想定すべきだと判断した
- GoogleのCode Yellow・Code Redに似た形で、重大事件や危機の際にエンジニアリングリソースを問題解決へ集中させる独自プロセスとしてCode Orangeを導入した
- 非中核のエンジニアリング機能は、コントロールプレーンの高い信頼性を保証する作業へ振り向けられる
- 計画されている変更は次の通り
- すべてのサービスのコントロールプレーン構成からcoreデータセンター依存を除去し、可能な場合はCloudflareの分散ネットワークが先に動くよう移行する
- すべてのcoreデータセンターがオフラインでも、ネットワーク上で動作するコントロールプレーンが機能し続けることを保証する
- coreデータセンターに依存するGA製品と機能には、特定施設へのソフトウェア依存なしで高可用性クラスターに依存することを求める
- GA製品と機能には、テスト済みで信頼できる災害復旧計画を持つことを求める
- システム障害のblast radiusをテストし、障害影響を受けるサービス数を最小化する
- 各coreデータセンター施設の完全除去を含め、すべてのデータセンター機能についてより厳格なchaos testingを実装する
- すべてのcoreデータセンターを徹底監査し、標準準拠を保証するための再監査計画を立てる
- すべてのcore施設障害時でもログが失われないよう、ロギングと分析の災害復旧計画を策定する
- Cloudflareは、必要なシステムと手順を備えていても、それに従い、未知の依存関係をテストするよう強制する厳格さが不足していたと総括した
1件のコメント
Hacker Newsの意見
記事の大半を、特定のサプライヤー名を挙げて責任を向け、根本原因を推測することに費やしているのは奇妙な選択だと思う
施設内の大口顧客であることを公表し、サプライヤーが Confidential と表示した電気系統図まで事後分析に入れたのも、かなり不適切に見える
インシデントのきっかけとなった要因や文脈を説明するのは理解できるが、事後分析の焦点はサプライヤーではなく Cloudflare の障害であるべきだ
Flexential も独自の事後分析を行うべきだろうが、Cloudflare が代わりに推測して公にやる必要はない
誰かが先に物語を作る前に、Cloudflare が先手を打って説明しようとする目的もあるのかもしれない
3者と複数の相互接続されたシステムが絡む状況で、Cloudflare が今後こうした複合的な障害モードを設計に反映するには、最後まで何が起きたのか知りたいと考えるのは合理的だ
個人的には Cloudflare が共有した情報に感謝している
責任の99%は、中核業務を果たせなかった Cloudflare にある
第三者をここまで深掘りするのは、むしろこの件が Cloudflare にとってどれほど気まずいものかを示している
ブレーカー点検もまともにしていなかったように見えるし、比較的新しい施設なのに、発電機のバッテリーを充電する10時間の半分も確保できていなかった
このメンテナンス中は完全に発電機へ切り替えるべきだったし、おそらく PGE を支援していたためにそれができなかった可能性が高い
Cloudflare CEO は正しいと思う。データセンターサービスには完全冗長化を期待して対価を払うもので、この場所には18MWあるというが、見たところフィードが2つだけなのかも不明だ
片方のフィードが落ちたら 2N 構成が入るべきだし、発電機があるなら問題ないはずだ
ならば、これまで把握した初期イベントの説明が含まれるのも妥当だ
続報の分析が出る可能性は高そうだ
https://twitter.com/eastdakota/status/1720688383607861442?t=...
引用された内容を見ると、障害の根本原因は単一データセンターへの依存だった
中核的なコントロールプレーンシステムの多くは高可用性クラスターへ移したが、一部の新製品はまだそうではなく、高可用性クラスターにあるべきサービスの一部が PDX-04 でしか動かないサービスに依存しており、一部の製品は災害復旧サイトに適切に載っていなかったという
インターネットの重要な部分を支える Cloudflare のような企業としては、かなり恥ずかしいことだ
Cloudflare が複数チームの迅速なイノベーションを許容した結果、製品は初期アルファまでそれぞれ異なる経路を取り、時間がたてばベストプラクティスへ移行するとしていたが、一般提供前の必須条件としては求めていなかったという
これは完全な管理の失敗だ。顧客には Cloudflare 内部基準ではアルファ品質のソフトウェアが売られていた、ということではないのか？
https://news.ycombinator.com/item?id=38113503
自己認識が足りないように見える
これはアマチュアレベルで、特に新サービスが高可用性なしでリリースされた点が深刻だ
この障害の影響を多少受けた立場として、この事後分析は不十分だと思う
75%は PDX-04 の電力障害と Flexential の責任を扱っており、文章だけ見るとそこで起きたことは災害に近かったようなので、それは理解できる
しかし11月2日UTC時点で電力は完全に復旧しており、その後も Cloudflare が完全復旧するまでさらに約30時間かかったとされている
障害より復旧の方が長かったのに、記事はあまりに多くのサービスが相互依存していたとだけ述べている。全体の運用復旧になぜそこまで時間がかかったのか、もっと詳しく知りたい
復旧プロセス自体から得た教訓はなかったのか？ それとも本当に、エッジから「頭脳」へデータを再同期するだけでその時間がかかったのか？
もう一つ欠けているのは、特にエンタープライズ顧客とのコミュニケーション不足だ。Cloudflare サポートはステータスページを除けば事実上沈黙しており、現実的にできることが多くなかったとしても、コミュニケーションを試みる必要はあった
事後分析で Flexential のコミュニケーション不足を責めた後なら、なおさらそうだ。Cloudflare の製品は好きだが、今回の件からもっと多くの結論を引き出すべきだと思う
ただ、これを事後分析と呼ぶのは少しずれている。完全な事後分析なら、上で述べたレベルの詳細があるべきだ
ロギングが落ちると、具体的にどのサービスが失敗するのか？ 意図せずそう作られたのか？ なぜ誰も気づかなかったのか？
Cloudflare の事後分析が徹底している点は良い
率直で透明性のある説明は、ほぼすべての他社の曖昧なコミュニケーション戦略と比べると新鮮
私たちも影響を受けたが、こういう記事があるからむしろ離れたくなくなる。誰でもミスをするし、悪い日もある。違いを生むのは、その後どう対応するかだ
電源障害は1段落で十分で、その後は Cloudflare 側の話に移るべきだった。データセンター障害は起こり得る
本当に学ぶべき点は、その状況を適切に考慮して復旧できなかった Cloudflare の対応にある
私たちは CloudFlare Images に大きく依存しているが、直近30日で67時間以上ダウンしていた
10月9日に22時間、11月2〜4日に42時間、その間にも約1時間の障害がいくつかあり、先月の可用性は90.6%だった
透明性は 99.9% の可用性の範囲で競うプロバイダー同士では優れた差別化要因だが、9 が1桁すらかろうじて超える程度なら、ほとんど意味がない
行動を改善するうえで大きな助けにはならず、インセンティブをさらに悪化させる可能性がある
ここでのプロセス上の誤りを修正しようとしている点は高く評価する。ただし、速く動くことと確実にやることの間には緊張関係がある
こういうものはたいてい天気のように扱われ、雨に濡れた後でレインコートを買うような形で管理されがち
プロセスに開発が縛られないまま、信頼性を文化の一部にする方法が気になる
ソフトウェアでシステムをモデル化し、トラフィック分析でそのモデルを検証することもできる。仮想実験で 信頼性実験のコストを下げられるなら、リリース前にもっと多くを見つけられるかもしれない
この記事を読んで、むしろ Cloudflare への信頼が下がったのは妙だ
Flexential がプロらしくない振る舞いをしたと強く非難していて、実際そうだった可能性はある
しかし、人々が依存しているシステム全体が落ちたという事実は、Cloudflare 側の巨大な 冗長化の失敗だ。こういうデータセンター1つくらい失ってもサービスは維持されるべき
特に、意図した設計が「Cloudflare のコントロールプレーンと分析システムは主に Oregon Hillsboro 近郊の3つのデータセンターのサーバーで動く」から始まっている点が気になる
世界中の人が使うコントロールプレーンなら、はるかに広い 地理的分散が必要だ。これは欠陥のある実装ではなく、意図した設計段階の話だという点がさらに驚き
新製品を消費者に提供するなら、冗長設計が最優先であるべきではないのか？ 選択肢扱いだったこと自体が意外
私も一部のシステムで Cloudflare を使っているが、こういう事態が起きても優れたフェイルオーバーがあると信じていたからだ。今では Cloudflare Workers がこうした設計判断から本当に安全なのか、考え直すようになった
災害復旧サイトを立ち上げたときに失敗していた API 呼び出しが殺到してサービスが圧倒されたという点も、結局 Cloudflare の中核設計が十分に冗長化されていなかったからだと思う
Flexential に責任を押しつけようとするこの記事には失望した。顧客の立場からすれば、Flexential が明日地震で消えても Cloudflare には優雅に処理してほしいと期待する
これほど重要なクラスター全体を、既知の 地震・津波リスク地域に置くのは良い考えなのか？
欧州の災害復旧もきちんと機能していなかったようだ
「PDX-04 施設全体を完全にオフラインにするテストはしたことがなかった」というのは痛い教訓
しかし、データセンターの電源を物理的に切るか、少なくとも外の世界とのネットワークを遮断してみなければ、本当の災害をテストしたことにはならない
施設運営者を責めることはできるが、最終的にはデータセンター1つが完全にオフラインになり、永遠に戻ってこなくても復旧できなければならない
自然災害がその施設を地球上から消し去ることもあり得る
「チームが総動員されて一日中緊急対応をしていたため、大半が休み、朝になってから PDX-04 へ戻す作業を始めようと決めた。この判断は完全復旧を遅らせたが、追加のミスが重なる可能性は減らしたと考えている」という部分は良かった
こうした報告書では 人間の疲労がしばしば過小評価される。極度に疲れた状態で大規模障害を直そうとすると、避けられるミスが増えるだけ
Cloudflare 規模の組織でどう機能するかは分からないが、私たちも大きな障害が起きたときは、スタッフが交代で働き、眠る計画を持っている
問題は、目を覚ましたり接続してきたりした新しい人員に、現在の障害状況を引き継ぐ方法が必要だということ
Mike Tyson の言葉どおり、顔面に一発もらうまでは誰にでも計画がある
文章構成がかなり驚き。ブログの75%を第三者の話で埋め、その後 Cloudflare 自身の復旧努力ははるかに少ない段落で扱っている
今後の道筋を示したのは前向きだが、なぜ今は失敗と状況だけを認め、後でほとぼりが冷めてから推測のない完全な 事後分析を出さなかったのか気になる
投資家はこの記事や要約だけを見て、数か月の手直しと数百万ドルの費用が必要な深い問題というより、単なる サプライヤー問題として流せる
文書があまり良くない
3つのデータセンターによる高可用性構成があったのに、完全に失敗した
なぜ文書の前半をデータセンター運営者のせいで埋めるのか？ データセンター施設の管理は Cloudflare の制御外だ
Cloudflare が制御できる 高可用性構成のテストをきちんと行わなくても問題ないだろうと賭けたのだ
データセンター運用の問題は運営者と議論すべきだが、それは双方の間の話であって、この事後分析に入れる内容ではない
重要な部分を本当に奥深くに埋めている。かなりスクロールしてようやくこんな文が出てくる
「高可用性クラスタにあるべきサービスの一部が、PDX-04 でしか稼働していないサービスに依存していた」
まさにこれが核心
「災害」サイトを作るなら、何らかの方法でテスト手段を見つける必要があると思う
サービスが立ち上がると、失敗していた API 呼び出しが殺到する雷の群れ問題が発生し、リクエスト量を制御するためにレート制限を実装したという
しかしこの内容は、記事末尾の項目からは抜けているようだ
いま気になるのは、システムが準安定障害[1]を起こすほど複雑で、実トラフィックでテストする余裕がない場合に、コールドフェイルオーバーをどう設計するのかという点
実装に使う手法は想像できるが、その手法が実際の状況で動作すると確認するための設計とテストが問題になる
もう一つ完全に抜けているように思えるのは、11月2日 11:43 UTC に障害が始まったのに、欧州の災害復旧サイトへ切り替えると決めたのが 13:40 UTC だったという点
なぜ決定にそれほど時間がかかったのか？ 軽々しく下せる決定ではないのは分かるが、ほとんどの時間、電力がすぐ復旧すると期待していたとしても、2時間はためらい過ぎに見える
どんな約束があったとしても、スイッチを押すべき事前の基準点があるべきだ。その基準は本当にそこまで遠くに設定されていたのか？
[1] http://charap.co/metastable-failures-in-distributed-systems/
障害を引き起こすのは、しばしば冗長システムそのものだ