- 日本市場ナンバーワンのニュースアプリを提供するSmartNewsがClickHouseを採用し、数千もの広告主が使用する広告パフォーマンスダッシュボードのリアルタイム化に成功。
- RedshiftからClickHouseへの移行により、かつては数時間かかっていたクエリが、わずか数秒で結果をユーザーに表示するまでに進化。
- 現在は1時間で300万件のクエリと6万件のインサート処理が可能。読み取りは大半が100ミリ秒未満で完了。
Summary
2012年創業のSmartNewsは、ダウンロード数5,000万以上まで拡大した日本市場ナンバーワンのニュースアプリを提供しています。SmartNewsのビジネスモデルは大部分が広告に依存しており、アプリと対話するユーザー向けに広告主が広告を配信し、そこで得た収入の一部を、4,500を超えるメディアパートナーにシェアしています。「それがモチベーションとなり、より質の高いコンテンツをメディアに届けてもらって、SmartNewsのユーザーに配信しています。」とエンジニアリングマネージャーの竜 清風氏は言います。
しかし、このサイクルを維持するために、広告主はフィードバックをタイムリーに収集する必要があります。竜氏が2020年に入社した頃は、広告のパフォーマンスデータの入手に何時間もかかることがあったため、まずそれを修正することからプロジェクトを開始しました。現在では同じデータが数秒足らずで入手できると言います。
ClickHouseが2025年4月に開催した東京ミートアップで、竜氏はSmartNewsがClickHouseを導入して分析パイプラインを再構築した事例を紹介し、速度の遅いバッチ主導のシステムを高速なストリーミングエンジンに置き換えることで、1時間に数百万ものクエリ実行を可能にしたと説明しています。
バッチ処理からリアルタイム表示へ #
ClickHouseを導入する前、SmartNewsのパイプラインでは複数の手順を実行する必要がありました。広告の配信ログはAmazon S3に15分間隔で書き込まれ、1時間ごとに実行されるバッチ処理を経て、Amazon Redshiftに読み込まれた後に集計処理されます。その結果がAmazon RDSにエクスポートされ、SmartNewsの広告マネージャーのダッシュボードからクエリ可能になります。
「このエンドツーエンドの処理全体でおよそ2-3時間かかっており、遅いと言われていました」(竜氏)
(図)ClickHouse導入前、2021年頃のSmartNewsのパイプライン: バッチベース、低速、脆弱
2021年、同社はこのシステムを完全に入れ替えます。現在のシステムでは、広告配信データがKafkaを使用してストリーミングされ、ClickHouseにインサートされます。Flinkも使用しますが、社内の技術的な要件を満たすためにデータをコピーしているだけで、特別なことは何もしていないと竜氏は言います。「ビジネスロジックと集計ロジックはすべてClickHouseで処理しています」(竜氏)
(図)SmartNewsの現在のClickHouseベースパイプライン: ストリーミング、リアルタイム、スケーラブル
新しくシンプルなアーキテクチャとなり、エンドユーザー側のパフォーマンスも改善されました。「エンドツーエンドの処理時間は最速で2-3秒くらいです。」と竜氏は言います。「広告マネージャーに接続し、広告主にリアルタイムな集計結果を見せています。」
数百万件のクエリを1時間で処理 #
SmartNewsの広告マネージャーダッシュボードには、各キャンペーンで消費した予算、インプレッション数、クリック数、クリックスルー率などのメトリクスが広告主に表示されます。「ここにリアルタイムでデータを送っているので、最新のデータをClickHouseでいつでも確認できます」(竜氏)
1時間におよそ6万件のインサートクエリが実行され(約1,000件/秒)、およそ20GBのデータがインサートされています。このように継続的にインサートを行い、広告主が最新の結果を最小限のタイムラグで確認できるようにしています。
読み取り側では、何千という広告主アカウント全体で、1時間におよそ300万件(約100件/秒)のSELECTクエリが処理されます。「かなり速いです」と竜氏が言うように、ほとんどのクエリが100ミリ秒未満で実行されます。
EC2からKubernetesへの移行 #
同社がClickHouseを最初に構築した際には、シャードを2つ、レプリカをシャードごとに2つという、ベーシックな4つのノードによるAWS EC2にClickHouseが展開されました。各ノードにローカルテーブルを配置し、その上に分散テーブル層を作成して、マテリアライズドビューを使用することで集計を実行しました。
(図)EC2展開のClickHouse: 2つのシャードにそれぞれ2つのレプリカーシンプルかつ信頼性が向上
非常にシンプルで信頼性の高い構成でしたが、データの容量が増えるにつれ、柔軟性の高い構成に変えることが必要になりました。「最近、弊社のインフラはどんどん進化しています」と竜氏は言います。
「将来の拡張性と柔軟性」を実現するため、同社はすべてをKubernetesに移行します。4つのノードはそのまま残し、シャードを3つ、レプリカをシャードごとに2つ用意し、平行処理と負荷分散がより効率良く行われるようにしました。
(図)Kubernetes展開のClickHouse: 3つのシャードにそれぞれ2つのレプリカ—柔軟性と拡張性を向上
ClickHouseのアーキテクチャにより、このような拡張をシンプルに実現できました。ノードごとにローカルテーブルを配置する点は同じですが、分散テーブルがクラスター全体をカバーするように変更し、また、集計の実行結果を別のサマリーテーブルに書き込むことで、クエリの速度と効率を維持することに成功しました。
クリーンで効率的なパイプライン #
竜氏が大学生の頃、学生同士でよく次のように言ったそうです。「話すよりもコードで見せてくれ。」その言葉のとおり、竜氏は東京ミートアップでSmartNewsのリアルタイムレポートパイプラインの構造を、コードを交えながら詳しく説明しています。
アーキテクチャは意図的にシンプルに作られています。Flinkが広告イベントを受け取り、ClickHouseに小バッチで書き込んで、「一度に数百から数千もの行」をインサートします。これらのレコードが処理前の「広告アクション」テーブルに書き込まれ、各行にログタイプ(クリックまたはインプレッション)、キャンペーンID、その他のメタデータが追加されます。
(図)SmartNewsの広告イベントパイプライン: FlinkからClickHouse、そしてマテリアライズドビューへ
そのデータをマテリアライズドビューが受け取ります。このビューが処理前の行を集計し、インプレッション数とクリック数を、キャンペーンごと、および時間枠ごとに「広告レポート」テーブルに入れてグループ分けします。このシンプルなロジックで、ログタイプがインプレッションであればインプレッション数を増分し、クリックであればクリック数を増分します。ClickHouseのReplicatedSummingMergeTreeエンジンを使用することで、インジェストの際に値を効率良く集計しています。
データが移動中にあらかじめ集計されるため、処理前の莫大な量のイベントデータをクエリ時に走査する必要がありません。「これにより、データ量を大幅に減らすことができ、ダッシュボードに出すクエリがかなり軽くなります。」と竜氏は説明します。
このようにクリーンで効率的なパイプラインにより、処理前のイベントを受け取って、集計結果をリアルタイムで出力しています。ほとんどのレポーティングを、このシンプルな仕組みで的確に処理することができます。
広告リーチをリアルタイムに計算 #
このデータパイプライン自体はシンプルに作られていますが、広告へのリーチ、つまり広告を参照した一意のユーザー数を計算する処理の部分は、技術的に難易度がかなり高くなります。
インプレッション数やクリック数であれば、シンプルなロジックでリアルタイムに集計できますが、リーチの場合は、大規模な複数のデータセットを動的かつ予測不能な時間枠で処理し、一意のユーザー数をカウントする必要があります。「これは実際なかなか難しいです。というのは、期間とかが固定じゃないからです。この期間の一意のカウントを計算したいときに、事前にデータを集計または圧縮しておくことはなかなかできません。」(竜氏)
そこでSmartNewsはClickHouseのuniqCombinedファンクションを使用し、HyperLogLogアルゴリズムの変数(竜氏曰く、「魔法のようなアルゴリズム」)を実装します。すると、すべての一意のユーザーIDを追跡するのではなく、「リーチステート」という中間データが圧縮および格納されます。このステート自体にはあまり意味がなく、クエリ時に一意のカウントをメモリ効率の良い方法で、高速に予測するために使用されます。
このロジックは広範なアーキテクチャにぴったりとはまります。新しい広告イベントが処理前のアクションテーブルに流れてくると、マテリアライズドビューがClickHouseの集計関数を使用してリーチステートを更新します。クエリの際に、一意のカウントの予測値が、キャンペーンと時間枠でグループ化した状態でレポートテーブルから返されます。これにより、SmartNewsは関数に組み込まれたパラメーターを調整しながら使用し、パフォーマンスと正確性のバランスを保つことができます。
この結果の正確性を調べるため、同社は一連のテストを実施し、一意のユーザーが最大500人までのキャンペーンについては、カウントが100%正確であることを確認しました。ユーザー数が40,000人のキャンペーンでは、約2%のわずかなエラーが発生しましたが、その割合はユーザーが数百万人に増えた場合でも変わりませんでした。このアルゴリズムは、レコードの合計数に関わらずエラーの比率が一定に保たれるよう作られているため、広告へのリーチなどカーディナリティの高いメトリクスの予測に非常に適しています。
クエリの速度もデータ量にそれほど影響されません。1週間分のデータで調べた場合、P95のレイテンシは1.2秒でした。1か月分のデータでは3秒で、3か月分になると約5秒になりました。「これはユーザー体験で耐えられる結果です」と竜氏が言うように、圧縮された大容量データからダッシュボードでリアルタイムに予測をクエリした結果としては十分な速度でした。
高速で、拡張性が高く、しかもシンプル #
SmartNewsはClickHouseを導入し、別次元の速度、拡張性、および簡潔性を手に入れました。バッチベースの低速なレポートシステムを、リアルタイムの分析プラットフォームに再構築し、価値の高いパフォーマンス分析データを広告主に数秒で届けることに成功しました。
以前は複数のツールに依存していたコアのロジックも、ClickHouseだけですべて実行されるようになりました。マテリアライズドビュー、効率的なテーブルエンジン、近似集計のロジックにより、大容量データのダッシュボード処理から高度なキャンペーン分析まで、何でもパワフルにこなすことができます。
ClickHouseにより、クエリが高速化しただけでなく、ビジネスの成長に合わせて基盤を柔軟に拡張することも可能になりました。SmartNewsはイノベーションを継続し、プラットフォームを拡張して、日本中の広告主をサポートできるという自信をClickHouseから得たのです。



