iFoodがClickHouse Cloud上にエージェンティックセキュリティプラットフォームを構築した方法

iFood は、ラテンアメリカを代表するフードデリバリープラットフォームです。2011年に設立され、ブラジルのフードデリバリー市場で80%以上のシェアを占めており、食料品、薬品、ペット用品、金融サービスなど、他の分野にも事業を拡大しています。

Jesus Santos氏は、同社のセキュリティインシデントレスポンスチームを率いており、これは全ビジネスユニットにサービスを提供する約100名のサイバーセキュリティ組織の一部です。

iFoodのClickHouse導入経緯について、Jesus氏に詳しく話を伺いました。iFoodのLakehouseの基盤としてDatabricksは引き続き利用されていますが、セキュリティインシデントレスポンスチームは、そのアーキテクチャに統合でき、彼らの要件を満たすエンジンとしてClickHouseを見出しました。要件とは、大量のログ取り込み、長期保持、そして最も重要な、インシデントに迅速に対応するためのデータへの高速アクセスです。

AWS上のClickHouse Cloudが、なぜ大規模環境で必要な速度とコスト効率を実現し、これまで不可能だったエージェント型脅威ハンティングワークフローを可能にする最適解となったのか、その理由をご紹介します。

コストの上限にぶつかる #

iFoodのサイバーセキュリティチームが結成された当初、彼らはパッケージ化されたSIEMを購入するのではなく、社内で既に運用されていたDatabricksを中心に独自に構築する道を選びました。

Jesus氏は、iFoodのセキュリティには大量のログ、長期の保持、そしてインシデント発生時に数か月分の履歴を素早く取り出せる能力が必要だと説明します。運用規模が130 TBを超えるにつれ、これらのニーズを満たすためのスケーリングコストが高騰していきました。

支出を管理するため、会社の経営陣とプラットフォーム管理者はクエリタイムアウトを導入し、最初はクエリを20分に制限し、その後10分に短縮しました。新しい検知ルールを構築するために3〜6か月分のログをスキャンする必要があったJesus氏のチームにとって、これらのタイムアウトは業務をほぼ不可能にしました。「iFoodが規模と範囲を拡大するにつれ、そのパラメータ内で仕事をすることができなくなりました」と彼は語ります。

予算の制約はさらなる制限を生み出しました。「支出できる金額に定められた予算上限があり、作成できるアラート数が制限されていました」とJesus氏は言います。「そのため、プラットフォームのコストが原因で、目標が停滞していました。」

彼らが必要としていたのは、セキュリティチームの要件を満たし、コストが上限にならないプラットフォームでした。「そこでClickHouseの出番となりました」と彼は語ります。

ClickHouse Cloudでより安く、より速く #

ClickHouseはiFoodにとって初めての技術ではなく、オープンソースのClickHouseを使ったアドホッククエリでログファイルを取得した経験がありました。

セキュリティインシデントレスポンスチームにとって、ClickHouse Cloud は自然な選択でした。彼らは1か月分の実運用データを使って、ClickHouseとDatabricksの両方でPOCを実施しました。「できるだけ公平になるように努め、両方のソリューションに同じスキーマとほぼ同じクエリを与えました」とJesus氏は述べています。

「ClickHouseのパフォーマンス対価格比は驚異的です。従来ソリューションの半分のコストで、9〜16倍のパフォーマンス向上を実現しました。」

— Jesus Santos氏、iFood セキュリティインシデントレスポンスチームリード

これが決まると、Jesus氏とチームはセキュリティツールの再構築を開始しました。スケジューリングやアラート発報から、重複排除、相関分析、オンコールエスカレーションまで含みます。「私たちが学んだこと、直面した問題をすべて取り入れ、私たちにとってより良いツールを作りました」と彼は語ります。

ClickHouse Cloudにより、iFoodはコストを40〜50%削減しつつ、より高速なパフォーマンスを得られる見込みです。データの鮮度も向上し、以前はほとんどのデータが1時間ごとにバッチ処理されていたのが、今ではほぼリアルタイムで到着するため、調査がはるかに迅速に進みます。「全体がより速く、よりスムーズに動作しています」と彼は語ります。「今の状態にとても満足しています。」

iFoodの新しいClickHouseベースのアーキテクチャ #

iFoodのセキュリティプラットフォームでは、ログはあらゆる場所から集まります。インフラストラクチャやファイルシステム、Kubernetesワークロード、クラウド管理コンソールなどです。「監査データを生成する場所ならどこでも、おそらくそのデータが必要になります」とJesus氏は語ります。それらはすべてAWS S3に格納され、ClickHouse Cloudのネイティブな取り込みレイヤーである ClickPipes を介してClickHouseに取り込まれます。その結果、エンドツーエンドの鮮度は2〜10分で実現され、Jesus氏によれば、ClickPipesが提供する信頼性と使いやすさを考えれば、それは十分に速く、価値があるとのことです。もし1分未満の鮮度が必要になった場合でも、Kafkaは選択肢として残っており、他の多くのデータソースと同様にClickPipesでサポートされています。

iFoodのセキュリティプラットフォーム向けログ取り込みパイプラインアーキテクチャ

クエリについては、チームは常にSQLで作業しています(これはClickHouseを最初に選んだ理由の一つでもあります)。調査面では、アナリストはDatabricks上のノートブックに慣れており、そこでは調査が進むにつれてセルを追加し、アナリストがいつ何を見たかの継続的な記録を保持できました。そのワークフローを維持するため、チームはオープンソースのノートブックプラットフォームである Querybook を採用し、その上に独自の調査ツールを構築しています。これは、会社全体で全チームに推進しているAIワークフローとより密接に統合されています。

UIについては、チームはClickHouseの可観測性スタックである ClickStack を立ち上げています。Jesus氏はこれを、運用KPIを可視化する主要な手段にしたいと考えています。生成するアラート数、取り込むログ数、調査に発展した数、インシデントに至った数などです。「単一のガラスペイン(統合ダッシュボード)」として、誰でも運用状況を確認できるようにしたい、と彼は表現しています。

ClickHouseとLangfuseによるエージェント型脅威ハンティング #

移行以降、ClickHouse CloudはiFoodのサイバーセキュリティチームがAIを活用して構築を進める中核となっています。Jesus氏の言葉を借りれば、「ClickHouseは、私たちのCSIRT全体のAI戦略の中核です」。

その好例がエージェント型脅威ハンティングです。過去6か月間、チームは脅威ハンティングを自動的に実行するツールを構築してきました。アナリストが仮説を立てる(例:「AWSインフラ側で侵害されているか?」)と、AIエージェントがログ全体をスイープして、それを裏付けるか除外するかを判断します。以前はアナリストが約1週間かかっていた作業が、今ではおよそ2時間で完了します。

Jesus氏は、エンドポイント検出・応答(EDR)ログだけでも1日あたり1.6 TBの生データが生成されると指摘します。単一のハンティングでは通常1か月以上のデータを見るため、一度に50 TB以上を扱うことになります。目標のログ保持期間は6か月から1年で、これはClickHouseでしか実現できません。

ハンティングの初期段階では、チームは10〜15の仮説を生成し、複数を並行して調査します。サブエージェントを5つずつ立ち上げ、各エージェントが独自のクエリを実行します。ClickHouseは高速かつコスト効率の良いクエリを提供するため、これらのエージェントは自由に反復処理でき、より強力な結果を生み出せます。初期テストは有望で、以前はアナリストが手動で1週間かけていた脅威ハンティングが、今ではClickHouse上のAIエージェントワークフローで約2時間で完了できるようになりました。

「ClickHouseにセキュリティデータを保存することで、エージェントは数か月分の履歴コンテキストを活用でき、クエリが非常に高速なので、複数の仮説を大規模かつ迅速に検証できます。」

— Jesus Santos氏、iFood セキュリティインシデントレスポンスチームリード

エージェントが何をしているかを理解し、より良いハンティングができるよう改善するため、チームは Langfuse を使用しています。これはオープンソースのAI可観測性・評価プラットフォームで、ClickHouseが2026年に買収 しました。これを使って、各分析がどこで成功し、どこで不十分なのかを確認し、エージェントを適切に調整しています。「Langfuseは、分析側で何が起きているかを詳しく理解し、より良い分析を行うためにエージェントをどう調整するかを知る上で、私たちにとって重要です」とJesus氏は語ります。導入はセキュリティにとどまらず、iFoodは全社的にエージェントのテレメトリと分析のため、Langfuseに関する研修を500人以上に実施しています。

より迅速な検知、そして広がるプラットフォーム #

Jesus 氏のチームにとって、ClickHouse のインパクトは平均検知時間などの KPI に明確に表れています。「以前は 1 時間に 1 回しか実行できなかったアラートを、今では平均 10 分ごとに実行できます。アラートの実行が数秒で済むようになったからです」と彼は語ります。データの鮮度が上がり、クエリも高速になったことで、平均対応時間も改善しています。

今後、チームは CDN と API のログを OpenSearch から ClickHouse へ移行し、保持期間を 7 日間から 6 か月に延ばしつつ、コストを 4 分の 1 に抑える計画です。「API ログの移行が完了すれば、以前は夢にも思わなかった分析ができるようになります」と Jesus 氏は語ります。インシデントの発端は 1 週間以上前にさかのぼることが多く、疑わしい挙動がチームに連携される 1 か月以上前から始まっていたケースもあったといいます。目指すのは、iFood アプリケーションへのすべてのリクエストを捕捉することです。

Jesus 氏はこう見ています。「私たちがここで成し遂げたことは、ClickHouse がいずれ全社にもたらしうるポテンシャル、コスト削減、そしてパフォーマンスを示しています」