セキュリティインサイトのスケーリング：グローバルスキャン能力を10倍に向上させた方法

Security Insights は、すべての Cloudflare アカウントに対して実行可能なセキュリティ推奨事項を提供します。これらのインサイトを見つけるために、私たちはすべてのアカウント、ゾーン、DNS レコードに対して定期的なスキャンを実行し、潜在的なセキュリティリスクや設定ミスを調査しています。 しかし、2 つの主要な課題が浮上しました。第一に、私たちのスキャン頻度が低すぎました。スキャンは週に 1 回または 2 回しか実施されておらず、その結果、新たに導入されたセキュリティリスクが最大で 2 週間検出されないままである可能性があります。第二に、多くの無料プランアカウントでは自動スキャンがオプトイン方式でした – つまり、多くのアカウントは一切スキャンされていない状態でした。 頻度が低い、あるいは存在しないスキャンのリスクは高まっています。自動化された攻撃が加速する中、セキュリティ設定ミスを検出するための時間的余裕は縮小しています。すべての顧客に対してこれらの問題を発見できていることを確認することは、誰もがより良いインターネットを構築するという私たちの目標にとって不可欠です。 スキャン頻度を高め、すべてのアカウントで自動スキャンを有効化するためには、平均してスキャン処理能力を約 10 倍に増やす必要があると計算しました – 1 秒あたり 10 スキャンから 100 スキャンへ。しかし、私たちのシステムはすでに負荷に苦しんでいました：数百万のイベントがバックログを埋め尽くし処理待ちの状態となり、API は頻繁にタイムアウトし、プロセスはクラッシュしていました。私たちはシステムを修正する必要があり、それをスケールさせる必要がありました。 これは、Security Insights のスキャン処理量を 10 倍以上に増強し、数百万人の顧客にセキュリティインサイトの提供を可能にし、全顧客のスキャン頻度を倍にしたという物語です。これらの改善をどのように達成したかについては、以下をご覧ください。 セキュリティインサートを得るためのスキャン方法 高レベルでは、自動セキュリティスキャンはスケジューラによってトリガーされます。アカウントまたはゾーンがスキャンの期限を迎えると、スケジューラは Apache Kafka（オープンソースの分散イベントストリーミングプラットフォーム）にメッセージ（または複数のメッセージ）を公開します。これらのメッセージは、特定の資産や構成を検査する専用の Go マイクロサービスである多数のチェッカーへと展開されます。 各メッセージに対して、各チェッカーはその結果（発見されたセキュリティインサイト）を内部 API に送信し、API がこれを Postgres データベースに永続化します。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1vJ2DRjdopX1LgymReyped/dbb20abb364acdd4904aba746d7921a6/BLOG-3307_image2.jpg) スケーラビリティの実現 Kafka のスケール Apache Kafka は厳密にはキューではなく、パーティション化されたイベントストリームです（ただし最近ではキューのセマンティクスも獲得しました）。1 つのパーティション内では、メッセージは順序通りに消費され処理される必要があります。これは、メッセージが順序通りに消費されることはあっても並列に処理される一般的なキューとは異なります。その結果、コンシューマーグループ内では 1 つのパーティションに対してアクティブなコンシューマーを 1 つしか持つことができません。 これにより、私たちに生じる影響は 2 つあります。 - 処理に時間がかかるメッセージが、コンシューマーが次のメッセージに進むのをブロックする - 各チェッカーについては、パーティション数と同じ数のコンシューマーしか持てない（各チェッカーには独自のコンシューマーグループが存在する） ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1Ml4yjhq4PIuDDNFPfCyKA/e22911321b38e48cd9dabc7fe33dba8c/unnamed.jpg) パーティション数を増やすことでスケーリングを試みることもできました。しかし、これにより多くの他のサービスと共有されている Kafka ブローカー自体のリソース使用量が増加してしまいます。そのため、これは最終手段として温存し、まずはコードとアーキテクチャの改善を目指すことにしました。 並列処理の導入 メッセージは順序通りにしか消費できませんが、同時に複数のメッセージを消費することに何ら制限はありません。 チェック処理をバッチ方式に変更し、各メッセージを個別のゴルーチンで処理するようにしました。その代償として、バッチ処理中にプロセスがクラッシュした場合に再処理する作業量が増え、メモリ使用量がわずかに増加します。しかし、私たちのケースではこれらはどちらも許容範囲内でした。 ヘッド・オブ・ライン（先頭行）ブロッキングの回避 一部のチェックャーが処理するメッセージの中には、他のメッセージに比べて非常に時間がかかるものがあります。例えば、あるアカウント/ゾーンは別のアカウント/ゾーンよりもはるかに多くのアセットを持っている場合があります。最悪の場合、これらのメッセージの処理には平均的なケースである数秒や数ミリ秒と比較して、数分あるいは数時間を要することがあります。 私たちは非常にシンプルなアプローチを採用しました：コンシューマーグループとチェックャーを「スローレーン」と「ファストレーン」の 2 つに分割することです。メッセージが処理に時間がかかるかどうかなどを素早く判断できます。「ファストレーン」のチェックャーが遅いメッセージを検出した場合、それをスキップします。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3jdSAU8FpBOHMIeWFUoWTP/a77806cbdf564dbe32be617135e8e2e9/BLOG-3307_image9.jpg) この解決策により問題が解消されました：遅いメッセージには専用のリソースと時間が割り当てられ、最小限の遅延で処理できるようになり、速いメッセージは通常の高速ペースで進行できるようになりました。 データベースクエリの最適化 発見したすべてのインサイトは、Postgres データベースに書き込まれます。これは、チェックャーがインサイトのリストを指定して呼び出す単一の API エンドポイントによって処理されます。実装は以下のようになりました。 for _, issue := range issues { _, err = tx.Exec(ctx, `INSERT INTO table ... VALUES ($1, $2, ...) ON CONFLICT DO UPDATE ...`, ...) if err != nil { return err } } 鋭い読者ならお気づきでしょうが、大量のインサイトに対してこのコードは、各インサイトごとにデータベースへの往復（round trip）を実行しています。最大で観測されたサイズが 500,000 の場合、これは単一の API コール内で 50 万回の往復、クエリ、トランザクションを意味します。 当初は、Postgres におけるバッチ挿入のゴールドスタンダードである、一時的なテーブルへの COPY を試みました。しかし、このアプローチが Postgres のシステムテーブルに肥大化（bloat）を引き起こすことが判明しました。 そこで私たちはハイブリッドアプローチを採用することにしました。 問題数が閾値未満の場合は UNNEST を使用し、 問題数が閾値を超えた場合は COPY を使用する これにより、両方の利点を享受できる結果となりました。つまり、大量のインセットに対しては秒単位で比較的高速に挿入でき、少量のインサイトに対してもミリ秒単位でさらに高速に挿入できるようになりました。 API タイムアウトの調査 スケーリングを試みる中で、内部 API でいくつかの奇妙な挙動が観測されました。 多数のリクエストがクライアント側のタイムアウトを引き起こしていた 多くのチェックャーが処理時間の 20〜90% を単一の API コールに費やしていた 大量のスキャンをトリガーすると、スループットは当初高い状態から徐々に低下し始めます これらすべての問題には同じ根本原因がありました：レイテンシです。 私たちの主要なデータベースはオレゴン州ポートランドに位置しています。一方、API はポートランドとアムステルダムの両方でアクティブ・アクティブ構成で稼働していました。光速であっても、ポートランドとアムステルダムの間の往復遅延（レイテンシ）は 50 ミリ秒になります。 このレイテンシの結果、アムステルダム側の API インスタンスからのデータベースクエリに非常に時間がかかり、クライアントサイドの接続プールから保持された接続が解放されなくなりました。API に対して大量のリクエストを送信しているため、接続プールはすぐに枯渇し、空き接続を待つ間にタイムアウトが発生しました。ポートランドでの平均的な API コール完了時間は 10 ミリ秒でしたが、アムステルダムではほぼ 3 秒にも達していました！ しかし、メッセージのスループットが低下した理由は何か？各チェッカープロセスには、消費する Kafka ストリームのパーティションのセットが割り当てられています。私たちの API はロードバランシングされています。プロセスのライフサイクルを通じて接続を保持しているため、一部のプロセスはアムステルダム側の API への接続を持ち、他のプロセスはポートランド側の API への接続を持っていました。ポートランドにリンクされたパーティションは迅速に処理されましたが、アムステルダム方面のプロセスによって消費されるパーティションは遅れをとっていました： ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4BDdHHlIGPZBTjFRR85tNk/f484c397ed3708395affb6c9f1d68294/BLOG-3307_image7.png) 単一のコンシューマーグループ内で処理待ちとなっているメッセージ数であるKafkaラグ（Kafka lag）を、パーティションごとに示したものです。この場合、パーティションは合計30あります。そのうちちょうど15のパーティションが、遅延していることが確認できます（これは、約03/10 03:00よりも後にゼロに達するかそれに近づくラインです）。これは、ロードバランサーがトラフィックをAPIエンドポイント間で均等に分割するためです。 これは簡単な修正でした：APIをアクティブ・パッシブ構成に変更し、アクティブなAPIがプライマリデータベースに従うようにしました。その結果、翌朝にはレイテンシの問題はすべて解消されました。 スケジューラーの再考 Kafkaのスケーリングを行い、データベースクエリの最適化を完了し、APIも修正しました。しかし、依然として問題が残っていました：スキャンが時間軸上でほぼ均等に分散されていることを確実にする必要があるのです。Kafkaトピックは時間ベースの保持ポリシーを採用しているため、すべてのスキャンを同時にキューに積むことは現実的ではありません。そうすればスキャンがKafkaに蓄積され、処理される前に最終的に削除されてしまうからです。 当社のスケジューラーは、スキャンを均等に分散させるのが不得意でした。特定の時刻にトリガーされるスキャン数はスパイク状であり、予測不可能でした。週の間のある時点では、数百万件のスキャンが数分ごとに連続してトリガーされていました。いったい何が起きていたのでしょうか？ スケジューラーは固定された再帰期間にスキャンをトリガーします。擬似コードでは、スケジューラーは以下のようになりました: Loop forever: Find accounts where last_scheduled_at + scanning frequency <= now For each account: Trigger scan for account Trigger scan for all zones in the account Update last_scheduled_at = now 私たちはすぐに、データベース内の多数のアカウントで last_scheduled_at が類似していることに気づきました。これが不均衡の一部の原因となっていました。 しかし、スキャン頻度を完璧に均等に分布させたとしても、スキャン頻度を上げればこの問題はさらに悪化します。例えば、スキャン頻度を 15 日ごとから 7 日ごとに短縮すると、アカウントの 53% が突然スキャン対象となることになります。 このロジックにはさらなる問題がありました。一部のアカウントは非常に多くのゾーンを持っています。これらのアカウントがスケジュールされると、すべてのゾーンに対して一連のスキャンがトリガーされ、Kafka パーティション (Kafka partitions) を飽和させ、より小さなアカウントのスキャンに遅延を引き起こしていました。 これらの問題を解決するために、私たちは 3 つの重要な変更を行いました: 1. アカウントとは独立してゾーンをスケジュールする：各ゾーンは独自の last_scheduled_at フィールドを持ちます。 2. 既存のアカウントとゾーンの last_scheduled_at 時間をランダム化する。 3. スキャンスケジューリングに適応型レート制限 (adaptive rate limiting) を導入する。 大規模アカウントの問題を解決するための明白な方法は、ゾーンを独立してスケジュールすることでした。last_scheduled_at 時刻をランダム化し（このプロセス中にスキャンが遅延しないように確保する）ことで、データベース内の既存の偏りを修正できました。 適応型レート制限は、やや興味深いものです。レート制限により、スキャン頻度を変更した際に発生するスキャンの急増という問題を解決できます。例えば、スキャン頻度を 7 日ごとにすることにし、5000 万アカウントを抱えている場合、約 83 スキャン/秒のレート制限を設定すれば、それらが 7 日間にわたって均等に分散されることを保証できます。 しかし、さらに 1000 万アカウントを追加したらどうなるでしょうか？その場合、このレート制限では全アカウントをスキャンするのに 8 日かかることになります。ここで適応型の要素が重要になります：レート制限は、保有するアカウント数とゾーンの総数、およびスキャン頻度に基づいて非同期で半時間ごとに再計算されます。これにより、数千または数百万の追加アカウントやゾーンを導入しても、スキャンを予定通りに継続して実行できます。 func computeRate(free, pro, biz, ent int64) rate.Limit { r := float64(free)/freeScanInterval.Seconds() + float64(pro)/proScanInterval.Seconds() + float64(biz)/bizScanInterval.Seconds() + float64(ent)/entScanInterval.Seconds() // 0 カウントに対するガード。常に少なくとも 1 秒に 1 スケジュールのスキャンをスケジュールしたい。 if r < 1 { r = 1 } // '完璧' な値を超えてレート制限を引き上げ、ダウンタイムや負荷の急増に備えたバッファを確保する // r *= rateLimitBufferFactor return rate.Limit(r) } 現在の状況 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3oPTkpvD7RduPU29VMMdyw/bdbe895a975b7c8184d6031fabe153ed/BLOG-3307_image8.png) これらの修正により、チェックャーごとの 7 日間の移動平均スループットは時間経過とともに 10 倍以上に向上しました。 これらの改善以前、私たちは 1 秒あたり約 10 スキャンを実行していました。この数値と目標である 1 秒あたり 100 スキャンというスループットの差は非常に大きく見えました。問題解決のためにリソースを投入する、Kafka トピックにパーティションを追加する、あるいはアーキテクチャそのものを根本から作り変えるといった議論もなされました。 しかし、私たちの行った修正が劇的な違いを生みました。現在、Security Insights はピーク時のスケジューリング時に 1 秒あたり 120 スキャンを超えるスループットを維持しており、10 倍の改善目標を達成しています。内部 API のタイムアウトは解消され、Kafka のラグ（遅延）メトリクスもはるかに健全な状態になっています。これらのスケーラビリティ向上により、すべての無料アカウントとゾーンで自動スキャン機能を有効化し、全顧客のスキャン頻度を増加させることが可能になりました： 無料プラン：7 日ごと Pro および Business プラン：3 日ごと Enterprise プラン：毎日 システムの安定性が向上したことで、以前は作成に制約があった新機能の開発に自信を持つことができました。粒度の細かいオンデマンドスキャンを実行する機能を追加しました。これにより、Cloudflare アカウント、ゾーン、インサイト、またはインサイトタイプを手動で再スキャンできるようになりました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6ZRp56v6QZiTEnNtf6d1Am/27a58f22fb2db0c482664076638386cc/BLOG-3307_image3.png) Cloudflare ダッシュボードのセキュリティ概要ページから、粒度の細かいオンデマンドスキャンを開始する様子 私たちが学んだ教訓は、何かを捨て去る前に既存システムを深く理解することが極めて重要だということです。コード、SQL クエリ、ログ、そして何よりもメトリクス（特にメトリクス！）を注意深く分析したおかげで、単にポッドやパーティションを増やすことなく、キャパシティを大幅に向上させることができました。前提条件に疑問を投げかけ、不自然に見えるメトリクスを掘り下げ、簡単な近道（例えば API のクライアントサイドタイムアウトの延長など）に頼らない姿勢を貫いた結果、より安定し、回復力のあるシステムを構築することができました。 問題に対してリソースを追加投入することが解決策となる場合もありますが、Cloudflare では、エンジニアリングによって問題を解決すること信じています。 セキュリティインサイトスキャンは、すべての Cloudflare プランでデフォルトで有効になっています。今日すぐに Cloudflare ダッシュボードにログインして、セキュリティインサイトをレビューおよび管理してください。

セキュリティインサイトのスケーリング：グローバルスキャン能力を10倍に向上させた方法

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

調べる

選ぶ

サイト