Cisco TalosがClickHouse Cloudで脅威リサーチャーを支援し、TCOを75%削減した方法

Cisco Talos は、専門の研究者、アナリスト、インシデントレスポンダー、エンジニアで構成される、世界で最も信頼されているサイバーセキュリティ脅威インテリジェンスチームの一つです。同チームは Cisco の顧客を保護し、進化する脅威への認識をサイバーセキュリティコミュニティ全体で高めながら、世界中の産業界や政府機関と連携しています。

Senay Goitom 氏は、そのミッションを支える一元化されたデータレイクとエンリッチメントを提供する少人数のエンジニアリングチームに所属しています。同チームが提供する最も重要な機能の一つが、膨大なハッシュデータセット上に構築されたレピュテーションサービスです。このサービスは、Talos が検出したすべてのファイルアーティファクトの性質を分類し、Cisco 製品のテレメトリから収集された個々のファイルハッシュに対する判定結果を保持しています。

「当社の脅威リサーチャーは、無害なハッシュに対する誤検知を防ぐガードレールとしてこのデータを使用しており、脅威ハンターはマルウェアキャンペーンの兆候となる可能性のある出現頻度の低いハッシュを探すために利用しています。いずれの場合も、彼ら、ひいては当社の顧客は、迅速かつ正確な回答を必要としています」 — Cisco ソフトウェアエンジニア、Senay Goitom 氏

しかし、そうした回答を提供することは、Senay 氏が言うように「干し草の山から針を探す」ようなものです。本番環境において、このデータセットは 2 兆行近くを保持しており、毎日 270 億行の新しいデータが取り込まれています。ディスク上では、圧縮データで約 192 TB、非圧縮では約 2 PB に相当します。これらのシステムは Cisco の顧客向け脅威インテリジェンスサービスを支えているため、レイテンシと精度が同社のセキュリティ製品に直接影響を及ぼします。

2026 Open House SF ユーザーカンファレンス において Senay 氏は、自身とチームがこのワークロードを OSS ClickHouse から AWS 上の ClickHouse Cloud へ移行した方法と、ダウンタイムゼロで Cisco のコストを大幅に削減できた経緯を紹介しました。

従来のアーキテクチャの限界 #

従来の設計では、データは S3 に Parquet ファイルとして保存されている Databricks Delta テーブルから生成されていました。カスタムのイベント駆動型サーバーレス取り込みパイプラインがセルフマネージドの Kubernetes (EKS) クラスターにデータを供給し、そこでステージングテーブルが API エンドポイントの背後にある集計テーブルへとロールアップされていました。以前の保持ポリシーでは、チームは約 1 PB の圧縮・レプリケーション済みデータを 32 台の高性能コンピュートノード (各ノードに 7 つの EBS ボリュームを接続) で運用していました。

Cisco Talos の従来のセルフマネージドアーキテクチャ: カスタムの取り込みパイプラインが EKS クラスターにデータを供給し、データはステージングテーブルから API エンドポイントの背後にある集計テーブルへと流れます。

「機能はしていました」と Senay 氏は言います。「しかし、いくつかの課題が生じ始めました」。脅威リサーチ組織内の少人数チームである彼らにとって、その規模のクラスターを運用することは本来のミッションから遠ざかる要因となっていました。「脅威リサーチャー向けの新プロダクトを開発する代わりに、アップグレード、バックアップ、トラブルシューティングに時間を取られていました」と同氏は説明します。

また、そのセットアップではチームのストレージとコンピュートが高コストな形で結びついていました。「クエリパフォーマンスの要件上、増え続けるストレージのニーズを高価なコンピュートノードと結びつけざるを得ませんでした」と Senay 氏は述べています。「トラフィックに応じたスケールアップやスケールダウンは高コストなプロセスであり、利用者へのサービス中断のリスクもありました。顧客の信頼を確保しなければならないため、最終的にはオーバープロビジョニングを行わざるを得ませんでした」

同氏は、運用面とコスト面の負担に加えて、さらに 2 つの課題を挙げています。1 つ目は SOC 2 コンプライアンスでした。「脆弱性管理には常に気を配らなければなりませんでした」と Senay 氏は述べ、これがすでに少人数のチームにとってさらなるオーバーヘッドになっていたと指摘します。もう 1 つはアーキテクチャの複雑さでした。カスタムの取り込み、カスタムの集計、カスタムの最適化によって構築されたシステムは「保守が難しく、進化させるのはさらに困難」であり、「保守やインシデント対応のために追加のエンジニア工数」が必要となっていました。

脅威リサーチャーを支える最適なリアルタイムデータプラットフォームの選定 #

より優れたソリューションを模索する中で、チームは3つの選択肢を検討しました。まず Snowflake は、ストレージコストとそれに伴うアーキテクチャの複雑さから、すぐに除外されました。Senay 氏は次のように述べています。「私たちが求めるクエリレイテンシを実現しようとすると、ClickHouse を採用する場合よりもはるかに複雑なアーキテクチャを組まざるを得ませんでした」

MongoDB も検討されましたが、そのドキュメントモデルは「当社の集約ワークロードには適しておらず、私たちが運用していたスケールではコストパフォーマンスにも見合いませんでした」と Senay 氏は振り返ります。

残った選択肢は1つだけでした。「ClickHouse Cloud は当然の選択でした」と Senay 氏は言います。チームはすでにこの技術を熟知しており、その列指向ストレージモデルは「ハッシュのルックアップパターンにぴったりでした」。ストレージとコンピュートの分離によってストレージコストを大幅に削減できる見込みが立ち、ClickHouse のソリューションアーキテクトとの対話を通じて、自社で保守していた環境よりもはるかにシンプルなアーキテクチャに落ち着けるという確信も得られました。

ClickHouse Cloud を軸にした再構築 #

Senay 氏とチームは、移行を4つのフェーズで進めました。第1フェーズで基盤を構築しました。ClickHouse サービス、ClickPipes、データベースリソース用の再利用可能な Terraform モジュールを整備し、SSO/SAML 連携を設定したうえで、開発用と本番用の両サービスをデプロイしました。続く第2フェーズではデータパイプラインを構築し、新しい取り込みフローを立ち上げ、シャード化された ClickPipes を使って過去12か月分のデータをバックフィルしました。

パイプラインが整ったところで、チームはシャドウトラフィックのフェーズへと移行しました。本番クエリを両方のバックエンドに並行してルーティングし、初期のデータ検証とパフォーマンステストを実施したのです。第4フェーズとなる最終段階がカットオーバーでした。大規模な実データを用いてソースとの詳細な比較検証を行い、ステークホルダーの承認を得たうえで本番の切り替えを完了しました。

その結果、アーキテクチャは劇的にシンプルになりました。新しい設計でも Databricks Delta テーブルをソースとして維持していますが、自作の取り込みコードはマネージドな構成要素に置き換えられています。Amazon EventBridge が S3 に届いた新規オブジェクトを検知して SQS キューにルーティングし、ClickPipes が ClickHouse Cloud への取り込みを担います。「カスタムコードも、オーケストレーションの仕組みも、すべて不要になりました」と Senay 氏は語ります。

ClickHouse Cloud 上に構築された Cisco Talos の新アーキテクチャ: ClickPipes がカスタムコードなしでデータ取り込みを処理し、ステージングテーブルへ供給。API エンドポイントの背後から AWS PrivateLink 経由でクエリに応答する。

ClickHouse Cloud の内部では、オブジェクトストレージにデータを保持し ClickHouse が完全に管理する SharedMergeTree テーブルエンジンを採用しています。クエリをバックエンドにルーティングする Lambda 関数は AWS PrivateLink 経由で接続されるため、トラフィックがパブリックインターネットを経由することはありません。さらに Senay 氏は、適切なパーティショニング戦略のおかげで「バックエンドを大幅に簡素化でき」、クラスター側で事前集約することなくクエリ実行時に集約処理を行えるようになったと付け加えています。

よりシンプルでコストパフォーマンスに優れたバックエンドへ #

「運用の観点から見ても、結果は明白でした」と Senay 氏は言います。本番稼働から1か月で、新しいパイプラインは1日あたり約 3,000 ファイルをデータ欠損ゼロで取り込みました。ファイルが S3 に配置されてから ClickHouse Cloud でクエリ可能になるまでのキューの遅延時間は1分未満に収まっています。ランダムに抽出した 1,000 件以上のハッシュを用いて新旧バックエンドの API レスポンスを比較したところ、一致率は 100% でした。これらの検証はすべて、利用者への影響もダウンタイムも一切生じることなく行われました。

「そして、コスト面での効果も同様に劇的でした」と Senay 氏は続けます。ストレージと高価なコンピュートの依存関係を切り離し、自作の取り込みパイプラインと以前のセルフマネージド構成に伴っていた SOC 2 の維持運用オーバーヘッドを解消したことで、ストレージコストは約 90% 削減され、コンピュート、ストレージ、エンジニア工数を合わせた総所有コスト (TCO) は約 75% 削減されました。

「ClickHouse Cloud への移行により、TCO を 75% 大幅に削減でき、年間 300 時間を超えるエンジニア工数を節約できました。この時間は、脅威インテリジェンスチーム向けの新しいプロダクト開発に充てることができます」 — Senay Goitom 氏、Cisco ソフトウェアエンジニア

世界最大規模の脅威インテリジェンスプロバイダーの一角を担う少人数チームにとって、インフラの維持管理からその上での価値構築へとシフトできたことは、最終的に脅威を追跡するリサーチャーと、彼らに信頼を寄せる Cisco の顧客への大きな貢献となっています。