何が起きたか

2022年6月21日にCloudflareサービスが大規模にダウンした。これによりDiscordやPixiv、Nortionなど多くのサービスが影響を受けたと報道されました。Cloudflareはサービスの性質上CDN/WAFとして利用されることが多く、ユーザ→Cloudflare→サービス提供者 とアクセスが流れる構成になっていることが多いためCloudflareのダウンはサービス提供者に直接影響が出るというメカニズムです。 詳細についてはCloudflare本家のブログを読んでいただければと思います。

実際にどのくらい影響が出たか

Cloudflareが公開した時系列と私が観測したデータを元に事実を列挙する。尚、筆者の環境は東京リージョンにおけるパブリッククラウドをCloudflareのバックエンドに利用し、Cloudflareのエンドポイントには全世界から外形監視を実施している条件となります。

• 15:27 [Cloudflareソース] 理論上、この時刻からサービス影響があったとしている
• 15:32 [筆者ソース] 全世界からの外形監視にてサービス影響を検知
• 15:32 [Cloudflareソース] 内部的にサービス影響を検知した時刻
• 15:58 [Cloudflareソース] Root cause(根本原因)を発見
• 16:12 [筆者ソース] サービス復旧（その後、複数回のフラップを観測）
• 16:42 [Cloudflareソース] 全ての設定の切り戻し完了
• 17:00 [Cloudflareソース] インシデントクローズ

よって、Cloudflareの東京POPの利用者は実質約40分＋α（回復時にフラップを観測したため）のサービス断と観測されました。

何を学んだか

• 構成変更のスコープについて
  • 自分の経験上、切り戻しリスクを考慮して同じ構成や単一リージョンという括りで構成変更を行うことが多かったが、Cloudflareでは異なる構成を持つ複数のPOPに対して同一工事で順次構成変更を実施していました。
    • 後日のブログでも言及があったが、複数のPOPを同時に変更するのではなく、順次構成変更を行う工事手順にて実施した模様。
    • 切り戻し判断が難しくなることを理解した上で実施、かつ、実際に問題が起きた際に迅速なRoot Causeの検出に成功している点で高度な運用が垣間見えます。
    • 一般的に構成変更のスコープは、変更速度とリスクのトレードオフになる場合が多い。Cloudflareでは同一日に、複数のリージョン（POP）の構成を変更できる運用体制が整っており、グローバルで利用しているユーザに対して迅速に新機能や改善を適用することが出来ることが伝わりました。
• 障害・回復検知について
  • サービス断検知からユーザ周知までの早さと正確性は、外部へ情報を展開するための承認プロセスも含めて、正確な正常性監視と並々ならぬ自動化が垣間見えました。
  • ネットワーク起因のサービス断による回復時のフラップを考慮した回復報もグローバルという規模を考慮すると経験値の高さを感じました。
    • 正確なサービスの正常性監視基盤があるということと同義かもしれません。
• 障害報告の早さと粒度の細かさ
  • 内部向けに練習が行われているのでは？と思うほど直ぐに詳細の報告がBlogという形で展開されるのは見習う点が多いと感じました。
    • 恐らく日々の作業の中で外部に公開するほどではないインシデントケースを用いて練習しているのでは？と感じます。
  • サンプルConfigを含めた詳細の内容は他社では中々見ることのできないものです。
    • Configを見れば、中で利用しているベンダーや内部構造が推測できたりするので通常はしないことの方が多いかと思います。