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

Cloudflareは、以前の事故を教訓にデータセンターで発生した大規模停電の影響を最小限に抑えた。本稿では同社が公式ブログで紹介した内容を取り上げる。

[＠IT]

　Cloudflareは2024年4月8日（米国時間）、以前のトラブルから得た教訓を生かし、同社のデータセンターで発生した大規模停電に効果的な対策を実施した事例を公式ブログで紹介した。

　Cloudflareが運営するオレゴン州ポートランドのデータセンターで、2024年3月26日、大規模な停電が発生した。同データセンターは2023年11月2日にも停電が起こり、コントロールプレーンとAnalyticsサービスがダウンした。しかし、2024年3月には停電の影響はほとんど発生しなかった。2つの事故の概要と、2023年11月以降Cloudflareが実施した対策について同社は以下のように説明している。

データセンターで起きた大規模停電

　Cloudflareのポートランドデータセンターのコントロールプレーンは、主にWebサイトやAPIを含む顧客向けインタフェースや、AnalyticsおよびLoggingパイプラインなどのサービスを提供している。

　2024年3月26日に、「PDX01」データセンターへの接続が切断されたというアラートが発生した。これは2023年11月と同様の警告だった。停電が起きた11月以降5カ月の間に、Cloudflareは多くのシステムを更新し、（冗長化のために）大量のネットワーク／サーバ容量を投入して、この事態に備えていた。加えて、2024年2月に内部切断テストを実施しており、システムがどのように反応すべきかを把握していた。また、冗長設備への自動フェイルオーバーのテストも実施し、作業が意図した効果を発揮していることも証明していた。

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

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

• APIとダッシュボード
• Zero Trust
• Magic Transit
• SSL
• SSL for SaaS
• Workers
• KV
• 待機室
• 負荷分散
• Zero Trustゲートウェイ
• Access
• Pages
• Stream
• Images

　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も、機能の大部分を世界中の何百ものデータセンターに移行し、停電中もシームレスに動作を維持した。