このような記事を書くことになるとは夢にも思いませんでした。当社の主要なデータセンターの1つが停電してから5か月も経たないうちに、同一データセンターで停電が再発してしまいました。「なぜこのような施設を継続して使用するのか」という意見に対して、私たちには説明の余地がありません。この状況には同意せざるを得ません。しかし、この5か月間、このデータセンターにおける変化は不十分であったかもしれませんが、Cloudflareではで多くの変化がありました。そのため、5か月前の主要データセンターの停電が大きな影響を与えたのと比較して、今回の停電の影響ははるかに軽減されました。
本記事は、高可用性（HA）データセンターが5か月間で2回目の停電を起こしたときの内容について触れたものです。しかし本記事では、このこと以上に、重要なデータセンターの1つが停電してもなお、お客様に影響を与えないようにするために、当社のチームが行ってきた取り組みに関する内容をお伝えします。
2023年11月2日、オレゴン州ポートランドにある重要な施設の1つで、長時間にわたる停電が発生しました。この問題は、電力送電網プロバイダーの保守作業が原因と思われる一連の障害が連鎖して発生し、最終的に施設の漏電という一連の不運な出来事が施設の復旧を遅らせ、影響が悪化する事態となりました。
全容については、こちらからご覧いただけます。
データセンターで完全な電源損失が発生した場合の影響は大きなものですが、このような事態は想定されていました。残念ながら、この想定を超えた大規模な障害が発生しても製品が動作し続けることを保証する程の多くの要件は適用されていませんでした。
それは二度と起きない過ちでした。
コードオレンジ
この痛手を負ったインシデントから、当社はCode Orange（コードオレンジ）と呼ばれるものを宣言しました。これは、ビジネスの存続を脅かす脅威がある場合に「コードイエロー」または「コードレッド」を宣言するというGoogleからアイデアを借用したものです。当社のロゴはオレンジ色ですので、少し変更を加えました。
このコードオレンジに対する当社のコンセプトは、このインシデントを指揮した人物（今回の場合はテクニカルオペレーション担当シニアバイスプレジデントのJeremy Hartman氏）にチームのエンジニアに対する指示権限を与え、彼が最も優先度の高いプロジェクトと考えるものについて進められるようにするというものでした。（ただし、ハッキング事件が発生したため、実際には「コードレッド」を宣言しました。その場合、さらに高い優先順位が与えられます。ご興味をお持ちの方は、これについてはこちらでお読みいただけます）。
Jeremy氏はこの緊急のインシデントを切り抜けた後、主要なデータセンター施設で再び壊滅的な障害が発生した場合でも、高い可用性を確保するために行うべき対策の優先順位を決めました。チームはこの取り組みを開始しました。
何を進めたか？
準備していた対策をこれほど早く現実世界で実践することになる日が来ることは想定外でしたが、世の中何が起こるか分かりません。2024年3月26日火曜日、最初のインシデントからわずか5か月足らずで同一施設での大規模な停電が再発しました。以下では、今回の障害の原因について説明しますが、最も重要なのは、この機会が当社のチームがコードオレンジの下で行ってきた作業の完璧なテストとなったことです。その結果は？
まず、Cloudflareのポートランドデータセンターが提供する機能について改めて紹介します。 2023年11月2日の投稿で説明したように、Cloudflareのコントロールプレーンは、主にWebサイトやAPIを含むすべてのサービスに関するお客様向けインターフェースで構成されています。さらに、分析パイプラインとログパイプラインを提供する基盤となるサービスは、主にこれらの施設から提供されます。
2023年11月と同じように、PDX01データセンターへの接続が切断されたことが即座に警告されました。11月とは異なり、私たちはすぐに再びすべての電源が失われ、5か月前とまったく同じ状況に陥ったことを確信することができました。また、2月に実施した内部切断テストを基に、システムがどのように反応すべきかも把握していました。私たちは数か月を費やして膨大な数のシステムを更新し、膨大な量のネットワークとサーバー容量を稼働させてこの事態に備えました。この間、作業が意図した効果を発揮していることを証明するためのテスト（この場合は冗長設備への自動フェイルオーバー）も行いました。
当社のコントロールプレーンは数百の内部サービスで構成されているため、ポートランドにある3つの重要なデータセンターのうち1つが失われた場合も、残る2つの施設でこれらのサービスが通常どおりに稼働し、主にポートランドで事業を継続できるようにしています。ポートランドセンターが完全に利用できない場合に備えて、ヨーロッパのデータセンターへのフェイルオーバー機能も持ち合わせています。しかし、それは二次的な選択肢であり、すぐに追求するものではありません。
2024年3月26日14時58分UTC、PDX01の電源が失われ、システムが反応し始めました。15時05分UTCまでに、当社のAPIとダッシュボードは、すべて人為的な介入なしに、正常稼働を継続していました。ここ数か月間で当社が最も重視したのは、同様の障害が発生した場合でもお客様がCloudflareサービスを設定・運用できるようにすることでした。人為的な介入を必要とするいくつかの特定のサービスがあったため、復旧に若干の時間を要しましたが、主要なインターフェイスメカニズムは想定どおりの動作を継続していました。
詳しく説明すると、2023年11月2日のインシデントでは、以下のサービスで少なくとも6時間のコントロールプレーンのダウンタイムが発生し、そのうちのいくつかは数日間機能が低下しました。
APIとダッシュボードZero TrustMagic TransitSSLSSL for SaaSWorkersKV待機室負荷分散Zero TrustゲートウェイAccessPagesStreamImages
2024年3月26日のインシデントの間、これらのサービスはすべて、停電から数分以内に正常稼働を取り戻し、その多くがフェイルオーバーによる影響もありませんでした。
Cloudflareのお客様が世界300以上の都市にあるデータセンターを経由するトラフィックを処理するデータプレーンは影響を受けませんでした。
お客様のトラフィックを表示する当社の分析プラットフォームは影響を受け、その日の後半まで完全に復旧しませんでした。 分析プラットフォームはPDX01データセンターに依存しているため、これは想定された動作でした。コントロールプレーンの作業と同様に、2023年11月2日のインシデントの直後より、新しい分析能力の構築を開始しました。これについては作業の規模が大きいため、完成までにもう少し時間を要します。この依存関係を解消するため、急いで作業を続けており、近い将来、この作業を完了する予定です。
コントロールプレーンサービスの機能の検証を終えた後、私たちは再び直面した問題は、非常に大規模なデータセンターのコールドスタート問題でした。2023年11月ではコールドスタートが完了するまでに約72時間要しましたが、今回は約10時間で完了することができました。将来的これをさらに短時間化できる余地は残されているため、今後同様のインシデントが発生した場合に備えてこの手順の改善を継続して行います。
ここまでの道のり
前述のように、昨年11月の停電に起因して当社ではコードオレンジを導入しました。コードオレンジは、重大なイベントや危機が発生した場合に、エンジニアリングリソースのほとんどまたはすべてを、目前の問題に対処するためにシフトするプロセスです。この5か月間、当社は優先度の低いエンジニアリングの工数をすべて、コントロールプレーンの高い信頼性の確保に重点を置くことにシフトしました。
エンジニアリング部門のチームを結集し、将来同様の障害に直面した場合のシステムの復旧力の向上に取り組みました。2024年3月26日のインシデントは予期せぬものでしたが、それは想定内でした。
最も顕著な違いは、コントロールプレーンとAPIによるサービスの復旧速度です。人為的な介入なしに、PDX01が失われてから7分には、ログインしてCloudflareの設定を変更できるまでになりました。これは、すべての構成データベースを高可用性（HA）トポロジに移行し、容量損失を吸収できるように十分な容量を事前にプロビジョニングしたためです。影響を受けた施設の同時に停止した20以上の異なるデータベースクラスターにわたる100以上のデータベースが、サービスを自動的に復旧することができました。これは毎週、適切にフェイルオーバーすることをテストした、実に1年以上に及ぶ作業の集大成です。
もう1つの重要な改善は、Logpushインフラストラクチャの更新です。2023年11月、PDX01データセンターが喪失したため、ログをお客様にプッシュすることができなくなりました。コードオレンジの期間中、私たちはポートランドのログプッシュインフラの高可用性化（HA化）に投資し、さらにアムステルダムにアクティブフェイルオーバーオプションを作成しました。ログプッシュは、ポートランドの施設すべてにまたがる大規模に拡大したKubernetesクラスターを活用し、サービスオーナーがシームレスな方法でHA準拠のサービスをデプロイできるようにしました。実際、2月のカオス訓練でポートランドのHAのデプロイメントに欠陥が見つかりましたが、アムステルダムのログプッシュインフラストラクチャが正常に引き継ぐことができたため、お客様は影響を受けることはありませんでした。このイベントの間、それ以降行ってきた修正が機能し、ポートランド地域からログをプッシュすることができることがわかりました。
Stream製品とZero Trust製品でその他に数多くの改善を加えた結果、運用への影響はほとんどありませんでした。当社のStream製品は動画のトランスコーディングに多くの計算リソースを使用しますが、アムステルダムの施設にシームレスに引き継がれ、稼働を継続することができました。チームにはサービスの具体的な可用性目標が与えられ、それを達成するためのいくつかの選択肢を与えられました。Streamは、異なる耐障害性アーキテクチャを選択したサービスの良い例ですが、この障害中にシームレスにサービスを提供することができました。2023年11月にも影響を受けたZero Trustは、その後、機能の大部分を当社の数百のデータセンターに移行しており、このイベントの間、シームレスに機能し続けることができました。最終的にこれは、世界300以上の都市に広がるデータセンターで可能な限り最高レベルの可用性を提供するために、すべてのCloudflare製品に採用することを推し進めている戦略です。
データセンターの電源に何が起こったか？
2024年3月26日14時58分UTC、PDX01において、Flexential社が所有・運用するCloudflareのすべてのサーバーラックに電源を供給する4つのスイッチボードで同時に障害が発生したと報告された後、Cloudflareの物理的インフラの電源が完全に喪失しました。これはつまり、環境全体でプライマリ電源経路と冗長電源経路の両方が非アクティブ化されたということです。Flexential社が調査を行っている間、エンジニアは回線スイッチボード（CSB）と呼ばれる一連の機器に着目しました。CSBは電気パネルボードに例えられ、主要な入力回路ブレーカーと一連の小さな出力ブレーカーで構成されます。Flexentialのエンジニアは、CSBの上流のインフラ供給、発電機、UPS & PDU/変圧器に影響はなく、通常の動作を継続していると報告しました。同様に、リモート電源パネルや接続されたスイッチギガバイトなど、CSBの下流のインフラストラクチャには影響はありませんでした。これは、障害がCSB自体に分離されたことを意味します。
Flexential社のCSB障害の根本原因に関する初期評価では、1つの要因として、4つのCSB内のブレーカー調整設定が誤って設定されていることが指摘されました。過度に制限されたトリップ設定は、過電流保護に過度に敏感になり、デバイスのトリップを引き起こす可能性があります。当社の場合、4つのCSB内のFlexential社のブレーカー設定が、ダウンストリームのプロビジョニングされた電源容量に対して低すぎると報告されていました。これらのブレーカーの1つまたは複数が遮断されると、残りのアクティブなCSBボードにカスケード障害が発生し、共有インフラストラクチャ上のCloudflare社のケージと他のユーザーに提供される電源が完全に損失しました。 インシデントのトリアージ中に、Flexential社の施設チームが誤ったトリップ設定に気付き、CSBをリセットして想定される値に調整したことで、当社のチームが段階的に制御された方法でサーバーを稼働できるようになったと報告されました。これらの設定がいつ行われたかはわかりませんが、通常、これらはお客様の重要な負荷がインストールされる前に、データセンターの委託プロセスおよび/またはブレーカー調整の調査の一環として設定または調整されます。
今後の展開は？
最優先事項は、分析プラットフォームの災害復旧プログラムを完成させることです。分析は、ダッシュボード上を飾る単なる美しいグラフではありません。攻撃のステータス、ファイアウォールでブロックされているアクティビティ、さらにはCloudflare Tunnelのステータスを確認したい場合は、分析が必要になります。当社が採用する障害復旧パターンが期待通りに機能しているという証拠があるため、これは依然として私たちの主要な焦点であり、可能な限り迅速に進める予定です。
一部のサービスに、依然として適切に復旧するために人為的な介入が必要なサービスがありましたが、それぞれのデータとアクション項目を収集し、それ以上の人為的な介入が必要ないことを確認しました。これらの変更と強化によってお客様が期待する耐障害性を提供できることを証明するために、引き続き本番切断テストを使用していきます。
私たちはできる限りの範囲で、Flexential社とのフォローアップ活動を行い、同社の運用およびレビュー手順に関する理解をさらに深めていきます。今回のインシデントは1つの施設に限定されましたが、当社ではこの取り組みを、重要なデータセンター施設すべてに対して同様の視点を持つようにするプロセスに変えていきます。
繰り返しになりますが、この度のインシデント中は製品機能にアクセスできなくなり、Analytics Engineをご利用いただいているお客様に多大な影響を与えたことを深くお詫び申し上げます。この4か月間の当社の作業は期待通りの結果を得ることができました。Cloudflareは、引き続き残りの作業の完了に向けて全力を尽くす所存です。