InMobi が ClickHouse で実現したクエリ20倍高速化と80%のコスト削減

多くの消費者と同じように、あなたもおそらくモバイルアプリを開き、広告を目にし、タップするかどうかを一瞬で判断し、そして次へと進んでいるでしょう。目に入らなければ、気にも留めない…。

しかしパブリッシャーにとって、その一瞬は決して忘れ去られるようなものではありません。それはデバイス、地域、そして数百万人のユーザーにわたって、自分たちのインベントリがどのようなパフォーマンスを発揮しているかを、毎日、毎分、リアルタイムで下される判定なのです。そして彼らは、InMobi のようなアドテクのリーダーに、単に広告を配信するだけでなく、その瞬間を信頼できる即時的なインサイトに変えてくれることを期待しています。

2007年にインドで設立されたInMobiは、30,000を超えるブランドおよびパブリッシャーを、150カ国以上の20億人を超える人々と接続し、毎日およそ2,500億件の広告リクエストと300億件のイベントを処理しています。プラットフォーム全体としては、1日あたり240 TBを超えるデータを取り込んでいます。

バンガロールで開催されたOpen House Roadshow において、InMobiのエンジニアであるAnand TirthgirikarとAmber Vaidが「Project Velocity」のストーリーを語ってくれました。これは、パブリッシャー向けのレポーティングを再設計し、リアルタイムな意思決定に十分なほど高速で、厳格なSLAを満たせるほど信頼性が高く、InMobiの成長に追従できるほどコスト効率に優れたものにするための取り組みです。

Anandの言葉を借りれば、「これは、私たちにとって最も重要なユースケースの一つに対し、高速で信頼性が高く、コスト効率の良いソリューションを構築するためにClickHouseをどのように採用したか、というストーリーです」。

旧システム:遅すぎてコストもかかる #

数千ものパブリッシャーにとって、InMobiのAPIは自社インベントリの状況を覗き見る窓です。Anandは次のように説明します。「彼らはOS、デバイスタイプ、地域などのさまざまなディメンションをまたいで、何件のインプレッションとクリックが発生しているのかをリアルタイムで知りたがっています」。

これらのAPIにはP99レイテンシ10秒以下というSLAが課せられています。しかし時間の経過とともに、その約束を守ることが難しくなってきました。「以前の構成では、ピーク時に1分を超えるという問題が発生していました」とAnandは語ります。

しかも負荷は決して小さくありません。システムは1日あたり40万件以上のリクエストを処理しており、クエリ量は時間帯によって毎分200から600クエリにのぼっていました。

さらにチームが「コスト問題」と呼ぶ課題もありました。InMobiの既存スタックは、ブロブストレージから直接読み込むサーバーレスウェアハウスに依存していました。「ライセンス費用は月額約4万ドルでした」とAnandは言います。「そしてコストモデル上、トラフィックが増えれば、コストも線形に増加する仕組みでした」。

ClickHouseでのPOC成功 #

何かを変えなければならないのは明らかでした。チームに必要だったのは、サブセカンドのパフォーマンス、コストを抑える方法、そしてInMobiの成長に追従できる分析プラットフォームでした。

そこで彼らはベイクオフを開催し、同じパブリッシャーレポーティングワークロードに対して複数のデータベースをテストし、クエリレイテンシ、圧縮率、インフラ要件で評価しました。

「私たちにとって最も良かったのがClickHouseでした」とAnandは語ります。ClickHouseは「既存の構成と比較して3倍速いクエリパフォーマンス」を実現し、さらに5:1の圧縮比を達成しました。「そして発行されるすべてのクエリにおいて、スキャン行数が70%減少することを観測しました」と彼は付け加えます。

インフラの比較も同様に印象的でした。旧サーバーレスウェアハウスは、稼働を維持するためだけに、56から448 vCPU、0.5から3.5 TB RAMへと頻繁にオートスケールしていました。ClickHouseは同じワークロードを、固定された60 vCPUと240 GB RAMで処理できました。

「これが80%のコスト削減を実現できた理由を物語っています」とAnandは語ります。

InMobiのClickHouseベースのアーキテクチャ #

新しいClickHouseベースの本番アーキテクチャでも、データはクラウドストレージから流れ、1時間ごとに更新されますが、取り込みは旧ウェアハウスではなくClickHouseに書き込むSparkジョブを経由するようになりました。

1時間ごとのSpark取り込みと、分離されたリーダー/ライターサービスを用いたInMobiのClickHouseベースのアーキテクチャ。

ClickHouseのマネージドインスタンスを使用し、読み取りと書き込みのために親子サービスパターンを採用しました。「リーダーサービスは、バックエンドがすべてのAPIリクエストを処理するための専用リソースとして用意しています」とAnandは説明します。「そしてライターサービスは、データ取り込みのために毎時起動して、終わったらシャットダウンする一時的なサービスです」。

両サービスは同じ分散ストレージを共有していますが、コンピュートはきれいに分離されています。「これにより、リーダーサービスは無事に保たれ、レイテンシの問題に直面することがありません」と彼は述べます。

ストレージに関しては、変化は劇的でした。非圧縮で10 TBを超えていたデータが、Parquetで2.5 TBに、そしてClickHouseではおよそ500 GBになりました。

本番稼働の課題と解決策 #

もちろん、有望なアーキテクチャ図を実戦投入できる本番システムへと仕上げるには、いくつかの難問を解決しなければなりませんでした。Amberが、チームが直面した最大の課題と、それらをどのように解決していったかを説明してくれました。

課題 #1 - 大規模なアトミック取り込み #

フォールトトレランスは素晴らしいものです…ただしデータ保証を破壊しない限り。Amberは次のように説明します。「Sparkはフォールトトレラントですが、いずれかのエグゼキューターが停止したりタスクが失敗すると、パイプラインが再トリガーされ、ターゲット層で重複が発生します」。パブリッシャー向けのメトリクスにおいて、これは許容できませんでした。

検証とパーティション移動によるアトミック取り込みを行うClickHouseのステージングから本番へのパイプライン。

そこでチームは、ステージング → 検証 → 本番のパターンを導入しました。Sparkは毎時のバッチをステージングテーブルに書き込み、システムは行数とKPIを期待値と照合して検証します。検証に合格した場合にのみ、ClickHouseの MOVE PARTITION コマンドを使用して本番テーブルへ昇格させます。何かが失敗すれば昇格は行われないため、本番ビューはクリーンかつアトミックに保たれます。

課題 #2 - 同時実行性と接続数の制限 #

POCの段階では、チームはClickHouseへのクエリに対してシンプルな「fire and forget」アプローチを採っていました。「POCの数値は非常に魅力的で良好で、このまま進められそうに見えました」とAmberは語ります。「しかし本番化したとき、小さな問題に直面しました。それがmax_concurrent_connectionsです」。

本番環境では、アプリケーション層がClickHouseとのセッションを開きっぱなしにしており、各セッションはそれぞれメモリオーバーヘッドを抱えていました。「そのメモリオーバーヘッドのせいで」と彼は説明します、「クラスタが詰まり、メモリ不足例外が発生しました」。

修正は、同時実行性の考え方を見直すことでした。チームは軽量な同時実行性のためにgevent with greenletsを採用し、サービングプラットフォームを正しい非同期パターンを使うように書き換え、接続あたりのフットプリントを削減しました。変更後、ピークトラフィック時でもP99レイテンシは6秒以下を維持しました。「そして、それ以来OOMの問題には一度も遭遇していません」とAmberは語ります。

課題 #3 - ダウンタイム時のフォールバック #

利害関係の大きさを考えると、InMobiのレポーティングAPIは盤石でなければなりません。「外部のパブリッシャーがこのテーブルにクエリを発行するため、ダウンタイムを発生させるわけにはいきません」とAmberは語ります。

フォールバックとして、チームはGrafanaのダッシュボードをClickHouseのサーバーメトリクスに接続し、シンプルなルールを定めました。「5分のウィンドウで2%を超える失敗を観測した場合、トラフィックを自動的にサーバーレスプラットフォームに戻します」と彼は説明します。「これが信頼性を提供する方法です」。

課題 #4 - ステップ関数型のコストスケーリング #

InMobiは、データ量が今後2年間で5倍に成長すると予測しています。彼らのストレステストでは、ClickHouseノードまたはレプリカを1つ追加するごとに30%多くのトラフィックを処理できることが示されました。

これにより、コストの成長は直線ではなくステップ関数となり、コストはクエリが少しずつ増えるたびに上がるのではなく、チームが意図的にキャパシティを追加したときにのみ増加するようになりました。Amberの言葉を借りれば、「レプリカを増やすだけで、時間とともに多くのトラフィックを処理できるのです」。

ClickHouseで20倍高速、80%安く #

取り込み、同時実行性、信頼性、コストのすべてが制御下に入り、システムは本格的な本番稼働の準備が整いました。そしてClickHouseは期待を上回る成果を出しました。

Amberはこう語ります。「以前は1分を超えていたP99レイテンシは、ピーク時でも3秒未満にまで短縮されました」。プラットフォームは現在、10 TBを超える非圧縮データ(ClickHouseでは圧縮しておよそ500 GB)に対して、1日40万件を超えるクエリを余裕で処理しています。

一方で月額コストは4万ドルから8000ドルへと80%削減されました。「これは私たちにとって大きな勝利でした」とAmberは語り、「サーバーレスプラットフォームのコストは指数関数的に増えていきましたが、今では今後2年間のコストがどうなるかがわかっています」と続けます。

信頼性も向上しました。アトミック取り込み、適切な接続管理、自動フォールバックにより、チームは火消しに追われることなくSLAを満たせるようになりました。そしてパブリッシャーは、より応答性の高いレポーティングAPIを通じて、より速くインサイトを得ています。

メリットは1つのワークロードを改善することにとどまりませんでした。Data PlatformチームはProject Velocityをパブリッシャーレポーティング向けの一回限りの修正として扱うのではなく、全社的な分析パターンへと発展させました。「私たちのメインの目標は、これらのAPIをInMobiのすべての開発者に提供し、できる限り汎用的にすることでした」とAmberは語ります。

チームは、クエリ履歴を分析し、インデックスオプションを含む最適化された CREATE TABLE 定義を提案するツールを構築しました。汎用的な取り込みパイプラインが、型変換 や、Deltaまたはブロブストレージからの ClickHouse への同期を処理します。ClickHouseの内部に精通していないInMobiの開発者にとって、Project Velocityは複雑さを抽象化し、新たな分析ユースケースのために実戦で鍛えられた既製の基盤を提供します。

学んだ教訓と今後の展望 #

これまでの歩みを振り返り、AnandとAmberは、現在InMobiでデータシステムを設計する際の指針となっているいくつかの教訓を挙げてくれました。

第一に、取り込みで重要なのは速度だけでなく正確性であるということ。Sparkのリトライと毎時バッチにより、部分書き込みや重複書き込みは避けられませんでした。ステージングと検証のモデルが、「私たちが顧客に報告しているデータは、すべて正確で検証されたもの」(Anand)であることを保証します。

次に、非同期の接続管理は「APIにとって不可欠」です。アプリケーションを高速なデータベースに向けるだけでは不十分です。同時実行モデル、そして接続が作成、再利用、クリーンアップされる方法こそが、信頼性とゼロ障害のプラットフォームを保証するのです。

チームはまた、予測可能性はパフォーマンスと同じくらい価値があることを学びました。ClickHouseで線形のコストカーブからステップ関数モデルへと移行したことで、トラフィック増加に応じた支出を予測できるようになりました。Anandの言葉を借りれば、「予測可能性はInMobi規模では金に等しい」のです。

最後に、ガードレール、つまり取り込み時の検証、セカンダリシステムへの自動フォールバック、モニタリングのエラー閾値は必須です。各レイヤーが、外部の顧客があなたのエンドポイントを叩く際の運用リスクを低減します。

最終的に、Project Velocityはシンプルなミッションから始まりました。それは、パブリッシャーレポーティングをより速く、より安くすることです。ClickHouseはそれを実現し、それ以上の成果をもたらしました。InMobiに対し、テラバイト規模で高速、信頼性が高く、経済的にも賢明な分析を構築するための基盤を与えてくれたのです。

「私たちはスピードを求めてClickHouseを採用しました」とAnandは語ります。「結果として、スピードだけでなく、コスト面でも高速・信頼性・予測可能性を兼ね備えたプラットフォームの構築につながりました。それがInMobiにおけるProject Velocityの意味です」。