Cloudflare は、今月初めにシステムがダウンし、インターネットに大きな混乱をもたらした問題について、詳細かつ驚くほど正直なレポートを公開した。
翌日公開された短い概要と、同社CTOのジョン・グラハム・カミング氏へのインタビューから、30分間の世界的な障害は、同社が迅速なソフトウェア変更を推進するために使用しているシステムの1行のコードにおけるエラーによって引き起こされたことはすでにわかっていた。
この変更は事前にテスト済みであったにもかかわらず、このミスによりCloudflareのサーバーのCPUが限界に達し、世界中の顧客がCloudflareを利用するウェブサイトで502エラーを受信できるようになりました。この完全な事後分析では、何が問題だったのか、そしてCloudflareがこれまでどのような対策を講じ、再発防止に取り組んでいるのかを詳細に検証しています。
見出しは、小さなミスが連鎖して一つの大きな失態を引き起こした、というものです。ついつい「パーフェクトストーム」という流行語を使いたくなりますが、実際はそうではありませんでした。小さなミスと、Cloudflareの堅牢なプロセスに多くの欠陥があったことが、ミスをエスカレートさせたのです。
まずエラー自体についてですが、それは次のコードにありました。.*(?:.*=.*)原因の詳細な説明は記事でかなり詳しく書かれているのでここでは割愛しますが（コーディングオタク向けの金曜日のお楽しみです）、大まかに言うと、このコードはいわゆる「バックトラッキング」、つまり繰り返しループを頻繁に発生させていました。このバックトラッキングは、リクエストが複雑になるほど指数関数的に悪化し、あっという間に会社のCPUを限界まで使い果たしてしまいました。
そこで、3つの大きな疑問が浮かび上がります。なぜこの問題は実際に発生する前に気づかれなかったのでしょうか？なぜこれほど早く、これほど大きな影響が出たのでしょうか？そして、なぜCloudflareが修正にこれほど時間がかかったのでしょうか？
この記事は、それぞれの質問に詳細かつ明確に答えており、社内プロセスやソフトウェアに関して、ほとんどの組織が共有をためらうような情報も豊富に含まれています。Cloudflareの貢献は称賛に値します。しかし、これらの質問については…
CPUが見えています
影響は、テストスイートがCPU使用率を測定していなかったという単純な理由で、検知されませんでした。しかし、Cloudflareには1週間後の社内期限があるため、すぐに影響が明らかになるでしょう。
2つ目の問題は、CPUの過剰な消費を防ぐはずだったソフトウェア保護システムが、わずか1週間前に「誤って」削除されていたことです。この保護システムは明らかにロックダウンする必要があるにもかかわらず、現在は復活しています。
Cloudflareは昨日、インターネットの一部を30分間一時的に利用できないようにした。その方法とは？
続きを読む
コードを実行するために使用されたソフトウェア（エクスプレッションエンジン）にも、発生したようなバックトラッキングをチェックする機能がありません。Cloudflareは、そのような機能を備えたソフトウェアに移行すると述べています。
それで、それがチェックプロセスを通過したわけですが、それが全員に影響を及ぼすスピードはどうですか?
もう一つの重大なミスがありました。CloudflareはWebアプリケーションファイアウォール（WAF）の変更にあまりにも慣れすぎていたようです。WAFはCloudflareの顧客に迅速に保護を提供できるように設計されており、文字通り数秒でグローバルに変更を加えることができます。
Cloudflareは過去にもこの技術を有効活用してきました。投稿では、5月にSharePointのセキュリティホールが発見され、それに対する保護策を迅速に展開したことを指摘しています。セキュリティホールが公開された直後、Cloudflareは顧客のシステムへのハッキング攻撃を多数確認しましたが、WAFを通じてアップデートを適用することで、ほぼ瞬時に攻撃を阻止することができました。こうしたサービスこそが、Cloudflareの評判と顧客獲得の源です。絶え間なく発生するセキュリティ問題に、お客様が対処する必要がないように、Cloudflareが対応してくれるのです。
しかし、システムの使用頻度は高く、過去 60 日間の変更リクエストは 476 件、つまり 3 時間ごとに 1 件のリクエストが寄せられています。
問題を引き起こしたコードは、同社が特定した新たなクロスサイトスクリプティング（XSS）攻撃に対処するために設計されていましたが、（そしてここが重要な点ですが）その変更は緊急を要するものではありませんでした。そのため、Cloudflareはより緩やかなペースで変更を導入し、世界的な問題になる前に問題に気付くこともできたはずです。しかし、そうしませんでした。Cloudflareにはこれまで常に機能していた様々なテストプロセスがあり、そのため、他の多くの式と同様に、この式をグローバルシステムに組み込んでしまったのです。
Cloudflare は、毎年公開される CVE (共通脆弱性識別子) の数が増加していることを指摘してこれを正当化しています。
ウォーゲームの再来
しかし、その影響は瞬く間に世界規模の頭痛の種となりました。さらに、コード自体は完全なライブモードではなくシミュレーションモードで実行されていましたが、CPU消費が膨大だったため、そのモードであってもサーバーが処理負荷に対処できず、すべてがオフラインになってしまいました。
すべてがうまくいかなかったのはそこです。では、なぜCloudflareは修正にこれほど時間がかかったのでしょうか？なぜ数分以内にロールバックして、何が起こっているのかを解明するまでに問題を解決しなかったのでしょうか？
この投稿には、危機対応の経験がある人なら誰でもお馴染みの、興味深い詳細がいくつか記載されています。問題はアラートで発見され、全員が慌てて対応にあたりました。より多くのエンジニア、特に対応について大きな決定を下す権限を持つ上級エンジニアを動員するために、この問題はエスカレーションされる必要がありました。
ここで起きるミスはすべて人間によるものです。まず、画面の前、電話、チャットルームに他の人間を物理的に集めなければなりません。そして、迅速かつ効果的に調整しなければなりません。何が問題なのでしょうか？何が原因なのでしょうか？どうすればそれが正しいと確信できるのでしょうか？
人はプレッシャーを感じるとパニックに陥り、状況を読み間違えたり、誤解したり、間違った判断を下したりしがちです。真実を見極め、できるだけ早く解決策を見つけるには、冷静な判断が必要です。
Cloudflareの投稿から、このウェブビジネスはこの点で実にうまく対応していたことが窺えます。時系列データのおかげで、同社の説明にはある程度の信頼性があります。当初、何らかの外部攻撃を受けていると思われていたにもかかわらず、最初のアラート受信から15分以内にWAFが問題であると特定しました。このルール変更を誰も監視していなかったことを考えると、これは実に良好な対応時間と言えるでしょう。定期的なアップデートに不具合が発生したのです。
しかし、決定的な遅延がいくつかありました。まず、自動緊急アラートが届くまでに3分かかりました。Cloudflareは、この時間はもっと短くすべきだったと認めています。次に、問題の原因が特定されてから2分後に上級エンジニアがWAFのグローバルキルを決定したにもかかわらず、実際に処理するまでにさらに5分もかかりました。
