データセンターの大規模停電、Cloudflareはどう対処したか？：データベースのHA化で障害時にもサービスの継続性を確保

　3月26日9時58分にPDX01が電力を失うと、システムが反応し始め、10時5分までには、APIとダッシュボードが、人手を介することなく全て正常に稼働した。過去数カ月間、同社が最も注力してきたのは、停電が発生した場合でも顧客がCloudflareのサービスを設定、運用できるようにすることだった。人為的な介入を必要とする特定のサービスが幾つかあり、そのため復旧に少し時間がかかったが、主要なインタフェース機構は期待通りに稼働していた。

　11月の停電では、以下のサービスで少なくとも6時間コントロールプレーンが停止し、幾つかは数日間にわたり機能低下した。

　3月の停電では、これらのサービスは全て数分以内に稼働し、その多くはフェイルオーバー中に影響を受けなかった。また、世界の300以上あるデータセンターを通過するトラフィック処理を担うデータプレーンへの影響もなかった。

　顧客のトラフィックに関する情報を提供するAnalyticsプラットフォームはPDX01データセンターに依存しているため、深夜まで完全には復旧しなかった。コントロールプレーンと同様、Analyticsプラットフォームも11月のインシデント発生直後から新たに構築していたが、作業規模が大きいため、完了までには至っていなかった。

　さらに、11月には約72時間を要した規模の大きいデータセンターのコールドスタートも、3月は約10時間で完了した。

Cloudflareが取った対策

　Googleは、自社のビジネス脅威に気付いたときに「コードイエロー」または「コードレッド」を宣言する。Cloudflareはそれにならい、自社カラーのオレンジを使って、11月の停電後「コードオレンジ」を宣言した。エンジニアリングリソースの多くをコントロールプレーンの高い信頼性を確保することに集中させた。

　2つの停電における最も顕著な違いは、コントロールプレーンとAPIによるサービスの復旧速度だ。人為的に介入することなく、PDX01が失われてから7分後には、ログインしてCloudflareの設定を変更できるまでになった。Cloudflareは全てのコンフィギュレーションデータベースをHA（Highly Available）トポロジーに移行し、キャパシティーロスを吸収できるだけのキャパシティーを事前にプロビジョニングしており、早期の復旧につながった。20以上の異なるデータベースクラスタにまたがる100以上のデータベースが、影響を受けた施設から同時にフェイルアウトし、サービスが自動的に復旧した。Cloudflareは1年以上、適切にフェイルオーバーすることを毎週テストしてインシデントに備えていた。

　もう一つの大きな改善は、Logpushインフラの更新だ。11月にPDX01データセンターが失われ、ログを顧客に送信できなくなったため、コードオレンジの期間中、ポートランドのLogpushインフラを高可用性化（HA化）し、アムステルダムでアクティブフェイルオーバーオプションを作成した。Logpushは、ポートランドの全施設にまたがる大規模に拡張されたKubernetesクラスタを活用し、サービス所有者が耐障害性を備えたHA準拠サービスをシームレスに展開できる方法を提供した。Cloudflareが2024年2月に実施したカオスエンジニアリング訓練では、ポートランドのHAデプロイメントに欠陥が見つかった。しかしながら、アムステルダムのLogpushインフラがそれを正常に引き継いだため、顧客への影響はなかった。3月の停電では、それ以降に追加した修正が機能し、ポートランドからのログを送信できた。

　また、StreamとZero Trustを改善したことにより、運用への影響はほとんどなかった。Streamは、ビデオのトランスコードに多くのコンピューティングリソースを使用するが、アムステルダムの施設にシームレスに引き継いで運用を継続できた。11月に影響を受けたZero Trustも、機能の大部分を世界中の何百ものデータセンターに移行し、停電中もシームレスに動作を維持した。