クラウドフレアがインターネットの半分をダウンさせるが、詳細な事後分析を共有

こんにちは、プラグマティック・エンジニア・ニュースレターのボーナス無料号をお届けするゲルゲリーです。毎号、私はシニアエンジニアとエンジニアリングリーダーの視点を通じて、ビッグテックとスタートアップを取り上げています。今日は、今週の「The Pulse」号の5つのトピックのうちの1つを取り上げます。フル購読者は以下の記事を7日前に受け取りました。このような記事を毎週メールボックスで受け取りたい方は、こちらから購読してください。 多くの購読者は、このニュースレターを学習・開発予算から経費処理しています。そのような予算をお持ちの方は、マネージャーに送信できるメールの例をこちらでご確認いただけます。 始める前に、新しいお知らせを共有できることを嬉しく思います：The Pragmatic Summitです。 4年前、The Pragmatic Engineerは小さなニュースレターとして始まりました。私がビッグテックやスタートアップのエンジニアやエンジニアリングリーダーに関連するトピックを書くというものでした。時は流れ、今日ではニュースレターの読者は100万人を突破し、出版物はポッドキャストにも拡大しました。 常に欠けていたものが一つありました：直接会うことです。エンジニア、リーダー、創業者 – このコミュニティで他の人と会い、互いに学びたい人々。それが今、実現します： Statsigとのパートナーシップにより、初めてのPragmatic Summitを主催します。席数には限りがあり、チケットは会場費、食事、運営費をカバーする499ドルで設定されています – このイベントから利益を得ることは目的としていません。 サミットへの参加を申し込む 多くの方々に会場でお会いできることを楽しみにしています！ Cloudflareがインターネットの半分をダウンさせる – しかし素晴らしい事後分析を共有 火曜日、数千のサイトが完全または部分的にオフラインとなる6時間に及ぶ障害が発生し、インターネットのどれだけがCloudflareのコンテンツデリバリーネットワーク（CDN）に依存しているかが再認識されました。より注目を集めた被害者の一部は以下の通りです： ChatGPTとClaude Canva、Dropbox、Spotify Uber、Coinbase、Zoom 別件ですが、最近AWSが引き起こした別の障害の際、イーロン・マスクが自身のウェブサイトXで、AWSはSignalにとって強固な依存関係であり、AWSの障害はいつでもこの安全なメッセージングサービスをダウンさせうると指摘したことを覚えている方もいらっしゃるかもしれません。それに対し、ある開発者が、XもCloudflareに対して同じ状況であると指摘しました – そして今週初め、XがCloudflareの障害によって壊れたことで、それが証明されました。 あのAWS障害は同社のus-east-1リージョンで発生し、先月インターネットの大部分をダウンさせました。AWSは3日後にインシデントの詳細を公開しました – このeコマース大手としては異例の速さでした – ただし、その事後分析は高レベルなもので、AWSのDNS Enactorサービスが遅くなり、障害を引き起こした予期せぬ競合状態を引き起こした正確な原因は結局明らかになりませんでした。 今回はCloudflareで何が起こったのでしょうか？ 障害を緩和してから数時間以内に、CloudflareのCEOマシュー・プリンセスは、何が正確に間違っていたのかについて、異例に詳細な報告を共有しました。根本原因は、設定ファイルをCloudflareのBot Managementモジュールに伝播させることに関連していました。そのファイルがBot Managementをクラッシュさせ、それがCloudflareのプロキシ機能をオフラインにしました。 以下は、Cloudflareのプロキシレイヤーが高レベルでどのように機能するかの簡単な概要です。これは顧客の「オリジン」リソースを保護するレイヤーであり、悪意のあるリクエストをブロックし、静的リソースをCloudflareのCDNにキャッシュすることで、それらへのネットワークトラフィックを最小限に抑えます： インシデントは以下のように展開しました： ClickHouseでのデータベース権限変更が事の始まりでした。権限が変更される前、機能メタデータ（Bot Managementモジュールによって使用される）を取得するすべてのクエリは、Clickhouseの分散テーブル上でのみ実行され、60の機能を含む「default」というデータベースに対して行われていました。 これまで、これらのクエリは共有システムアカウントを使用して実行されていました。Cloudflareのエンジニアリングチームは、システムのセキュリティと信頼性を向上させ、この共有システムアカウントから個々のユーザーアカウントに移行したいと考えていました。ユーザーアカウントはすでに「r0」という別のデータベースへのアクセス権を持っていたため、チームはr0へのアクセス権を明示的ではなく暗黙的にするデータベース権限変更を行いました。 これの副作用として、Bot Managementに渡される機能を収集する同じクエリがr0データベースからの取得を開始し、予想よりもはるかに多くの機能を返すようになりました： Bot Managementモジュールは200を超える機能の読み込みを許可しません。この制限は、本番環境で使用されている60を大幅に上回っており、パフォーマンス上の理由で設定されていました：Bot Managementモジュールは最大200機能分のメモリを事前に割り当てており、この数を超えると動作しません。 誤った機能ファイルが配信されたマシンでシステムパニックが発生しました。Cloudflareは親切にも、このパニックを引き起こした正確なコードを共有してくれました。それはこのunwrap()関数です： おそらく起こったこと： append_with_names()関数はおそらく200機能の制限をチェックした 200を超える機能を確認した場合、おそらくエラーを返した … そしてコードを書いたとき、append_with_names()がエラーを返すことは想定されていなかった… … そのため、.unwrap()がパニックを起こし、システムをクラッシュさせた！ エッジノードが、一見ランダムに、次々とクラッシュし始めました。機能ファイルは5分ごとに生成され、エッジノードに段階的にロールアウトされていました。そのため、最初はほんの数ノードがクラッシュし、時間の経過とともに、より多くのノードが応答不能になりました。ある時点では、良い設定ファイルと悪い設定ファイルの両方が配布されており、良い設定ファイルを受け取った故障ノードが一時的に動作を開始することもありました！ なぜ根本原因の特定にそんなに時間がかかったのか？ Cloudflareのエンジニアは、これらすべてを理解し、エッジサーバーに伝播する誤った設定ファイルが彼らのプロキシダウンの原因であると突き止めるのに、異例の長さ – 2.5時間！ – を要しました。どうやら、無関係な障害が、Cloudflareチームに、彼らが協調的なボットネット攻撃を受けているのではないかと疑わせたようです。なぜなら、いくつかのエッジノードがオフラインになり始めたとき、同社のステータスページもダウンしたからです： チームは攻撃の詳細を収集しようとしましたが、攻撃は存在せず、つまり彼らは間違った場所を探すことに時間を浪費したことになります。実際には、ステータスページのダウンは偶然の一致であり、障害とは無関係でした。しかし、彼らの最初の反応が分散型サービス拒否（DDoS）攻撃があるかどうかを確認することだったのは容易に理解できます。 前述の通り、最終的に誤った設定ファイルを障害の原因と特定するのに2.5時間かかり、新しいファイルの伝播を停止し、新しく正しいファイルを作成してデプロイするのにさらに1時間かかりました。これはインシデント開始から3.5時間後のことでした。クリーンアップにさらに2.5時間を要し、UTC 17:06に障害は解決されました。開始から約6時間後です。 Cloudflareはインシデントと学びの詳細なレビューを共有しており、こちらで読むことができます。 なぜ事後分析がそんなに速くできたのか？ Cloudflareについて驚き続けていることの一つは、インシデント解決後24時間以内に非常に詳細な事後分析を公開する点です。共同創業者兼CEOのマシュー・プリンセスは、これがどのように可能だったかを説明しました： マシューは障害対応コールに参加していた。 障害が解決された後、彼は自宅でインシデントレビューの最初のバージョンを書いた。マシューはリスボン、Cloudflareの欧州本社にいたので、これは夕方早い時間だった。 チームはこの最初の草案と、レビューが必要な質問を含むGoogle Docを回覧した。 数時間以内に、すべての質問に回答された。 マシュー：「私たちの誰も（このインシデントについて）満足していませんでした – 起こったことを恥じていました – しかし、私たちは（事後分析を）真実で正確であると宣言しました。 草案をSFチームに送り、彼らがもう一度チェックを行い、投稿した。 上場企業でありながら、スタートアップのスピードで動くとはこのことです！ このインシデントから学ぶべきことは多くあります、例えば： エラーを発生させるときは、それをログに明示的に記録すること！Cloudflareはおそらく、エラーを返したコード行がそのエラーもログに記録し、かつCloudflareがそのノードで特定のエラーが急増したときにアラートを設定していれば、このエラーの根本原因をはるかに速く特定できたでしょう。それは確かに緩和にかかった時間を1時間か2時間短縮できたはずです。 もちろん、エラーをスローする前にログに記録することは追加の作業ですが、監視と組み合わせて行うことで

クラウドフレアがインターネットの半分をダウンさせるが、詳細な事後分析を共有

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト