インタビューインターネット サービス企業 Cloudflare は昨日、慎重に狙いを定めて両砲弾を自社の足元に撃ち込み、インターネットの大部分をダウンさせた。
同社は、驚くべきオープンさで、障害の原因となった不正行為について、悲痛なほど詳細な事後分析を公開した。The Register紙はまた、苦境に立たされた同社のCTO、ジョン・グラハム＝カミング氏に、事態の経緯を理解するため、疲弊した様子でインタビューを行った。
今回は Verizon の仕業ではなく、Cloudflare が独自にこの障害を引き起こしたのです。
簡単に言うと、CloudflareがWebアプリケーションファイアウォール（WAF）にいくつかのルールを導入したのです。彼らはこれらのルールをテストモードでサーバーに導入しました。つまり、ルールは実行されますが、実際には何も実行されません。これは、実際の顧客トラフィックが通過した際に何が起こるかを測定するためです。
我々は、トラフィックを誘導できる隔離されたテスト環境は理にかなっていると主張しましたが、グラハム・カミング氏はこう言いました。「我々は常にこのようなことを行っています。物事を展開するには一定の手順があります。しかし、今回のケースではそれができませんでした。」
まるで「Who, Me?」の始まりのように聞こえます。
グラハム・カミング氏は、DevOps 愛好家全員が慌ててパイプラインを確認するような率直な告白で、次のように語った。「私たちは、内部で実行される自動テストスイートが、これが私たちのサービスに悪影響を及ぼすという事実をなぜ認識しなかったのかを解明しようと真剣に取り組んでいます。」
CTOはこう説明した。「何かを発表し、人間による承認を得て、テスト手順を経て、世界に発信されます。そしてどういうわけか、そのテスト手順の中で、これが事態を悪化させるだろうと気づかなかったのです。」
彼は、今後の進め方について説明を続けた。社内でドッグフーディングを行った後、アップデートは「私たちに対して少し生意気なところがあり」「ちょっと悪いことをする」少数の顧客にプッシュされ、その後、徐々に広く世界に展開されるという。
Cloudflareが倒産、インターネットでまたもBGPリーク発生、ウェブサイトが消滅
続きを読む
「そして今回はそうはならなかった。簡単に発見できたはずだ。」
残念ながら、2つの問題が発生しました。まず、悪質なインラインJavaScriptをブロックするために設計されたルールの1つに、CPU使用率を急上昇させる正規表現が含まれていました。次に、新しいルールが誤って一度にグローバルに展開されてしまいました。
その結果はどうなったか？「これらのルールの1つが、すべてのマシンのCPU使用率を100%まで急上昇させました。」Cloudflareの製品はすべてのサーバーに分散されているため、問題の正規表現が動作している間、すべてのサービスはCPU不足に陥っていました。
CPU使用率が100%に達するスパイクはUTC13:42に発生し、DNS over HTTPS（DoH）、コンテンツ配信ネットワーク（CDN）など、Cloudflareが提供するほぼすべてのサービスが停止しました。最悪の状況では、Cloudflareを通過するトラフィックが82%減少しました。お客様は、当社のVulture Centralなどのサイトを閲覧しようとした際に「502 Bad Gateway」エラーが表示されました。
ネットでは悲鳴が上がった。
一体何が起こったのかを突き止めるのに、同社は20分もかかりました。そして、障害発生から30分近く経ったUTC14時9分に、WAFマネージドルールセットに対して「グローバルキル」を実行し、状況を正常に戻しました。
どのシステムが問題を引き起こしているのかを特定する必要がありました。重大な問題があることはわかっていましたが、どの重大な問題なのかを特定する必要がありました。20分の間に、WAFが問題の原因であること、そして問題を引き起こしている具体的な変更点を特定しました。
同社が問題となっているプルリクエストを追跡し、特定のルールをロールバックした後、これらのルールセットが再度有効化されたのは、UTC 14:52 になってからでした。
DevOpsの実践
Cloudflare自体は、TeamCityやAtlassianスイートなど、ビルドとテストにかなり標準的なツールを使用しています。Graham-Cumming氏は、多くのDevOps実践者に馴染みのあるプロセスについて次のように説明しました。
「この問題が本番環境に導入される様子を社内システムで確認すると、個々のエンジニアがプルリクエストを作成し、そのプルリクエストが他の人によって承認され、TeamCity の自動ビルド システムにプッシュされ、ビルドが実行され、テスト スイートが実行され、そのシステムがデプロイしても問題ないと判断することがわかります。
「そして、それが重要な点だったのです。自動化されたシステムがその決定を下すことが許可されていたのです…そして、おそらくそうすべきではなかったのです。」
Cloudflareは新しいコマンドラインでサーバーレスに力を入れ、無料アカウント層で開発者を誘致
続きを読む
もちろん、今回の障害の影響を受けた顧客は、サービスレベル契約に基づき、障害による損失を補償される契約を結んでいる。しかし、30分のダウンタイムによる収益損失をカバーできる可能性は低い。グラハム＝カミング氏は、「営業部門のリーダー陣やチームの他のメンバーと、この問題への最善の対応策について協議中」と述べるにとどまり、Cloudflareは「この痛みを非常に深く感じている」と改めて述べた。
私たちみんなそうだったよ、ジョン。私たちみんなそうだったんだ。
機械が最終的にどのように台頭し、人類を絶滅させるのかをまとめるのは、スコット・ハンセルマンに任せましょう。®
宇宙は火で滅びたり消滅したりすることはありません。私たちすべてを破壊するのは、不適切に書かれた正規表現です。 https://t.co/zhORvHcx0t
— スコット・ハンセルマン (@shanselman) 2019年7月3日
®
開示: The Register は Cloudflare の顧客です。
