ClickHouseでBigQueryとLookerのコスト削減 第1回

本記事は複数回にわたるシリーズの第1回で、セットアップ手順を論理的なパートに分けてお届けします。エコシステムや技術の複雑さから「if-then-else」的な条件分岐が多く絡んでくるため、記事全体が煩雑にならないよう、それぞれを別パートに分けて整理しました。第1回では主に理論面を解説し、第2回では基本的な実装に焦点を当てます。

まずご存じない方のために触れておくと、ClickHouseはBigQueryと競合するデータウェアハウスです。最大の特徴は、他のデータウェアハウスと比べて格段に高速に処理を実行できる、非常に高性能なデータストアであるという点です。そのため、LookerのようなBIツールなど、常時クエリを発行するworkloadsに対してデータを保存・配信する用途に最適です。

本記事は、DBaaS分野のリーディングプロバイダーでありマネージドClickHouseサービスを提供しているパートナーAivenの技術協力のもとで執筆しました。あわせて、独自のマネージドサービスを提供するClickHouse社の情報も併記します。

BigQueryは大規模分析やMLのworkloadsに優れたプラットフォームで、可視化やレポーティングのためにLookerなどのBIツールと連携されるケースも多く見られます。しかしこの種の用途でクエリを実行すると、リソース、あるいはコスト都合で課されたリソース制約によってパフォーマンス上の問題が起きがちです。さらに見過ごせないのが、BigQueryのクエリ単位の課金という、いわば「部屋の中の巨大なゴリラ」とも呼ぶべき存在です。

加えて、最近のクエリ単位の値上げによってBigQueryはさらに高額になりました。データを絶え間なくクエリするツールと連携している場合は特に顕著です。そのため、多くのお客様がworkloadsのコスト削減策を模索する中で、DoiT InternationalのCustomer Reliability Engineerが長年訴えてきた事実、すなわち「BIツールこそがBigQueryコストの最大級の要因のひとつであり、コスト最適化における最重要ターゲットのひとつである」という現実に行き着いています。

Google Next 2023での筆者のセッション(録画は残念ながら公開終了となりましたが、スライドは現在も閲覧可能です)では、多くのお客様が大きな成果を上げているコスト最適化のテーマを提案しました。それは、特に計算負荷の高い高コストworkloadsをBigQueryから切り離し、より安価で目的に適した別のツールへ移行するというアプローチです。

本記事ではその発想を直接的に発展させ、ClickHouseデータウェアハウスをBigQueryとLookerなどのBIツールの間に置き「キャッシュ兼配信」レイヤーとして活用する、データ提供の代替手法を提案します。これにより、レポーティングや可視化のworkloadsをBigQueryから、より安価で高性能なプラットフォームへ移すことができます。

重要な補足: ここではClickHouseを取り上げていますが、必要に応じて他のツールやデータベースでも同様のことは十分実現可能です。ClickHouseを採用しているのは、可視化ツールへ非常に高速にデータを配信する用途で抜群の性能を発揮し、実際の現場でもよく目にするため、本記事で取り上げる価値があると判断したからです。

最近、LinkedInなどで「ClickHouseはBigQueryより安い、あるいは速い」と謳う広告を目にする機会が増えたのではないでしょうか。あの広告キャンペーンを手掛けるブレーンたちは、本記事で提案するコンセプトの根幹をなす要素を巧みに突いています。DoiT Internationalのデータアーキテクトは、価格改定が非常に多くのGCPユーザーに与える影響を大規模な現場で目の当たりにしながら、コスト削減のための創意工夫を重ねてきました。

ClickHouseはBigQueryと「似た系統」のデータウェアハウスですが、両者を大きく分けるアーキテクチャ上の違いがあります。ClickHouseはよりモノリシックなアーキテクチャを採用し、内部で利用するユーザー定義の「モジュール」を中心に据えた設計により、パフォーマンスを大幅に引き上げられるのが特徴です。このモジュール式インフラのおかげで、多くのタスクにおいてBigQueryや他のデータウェアハウスソリューションを大きく上回る性能を発揮できます。

PostHogによる以下の引用がこの点を端的にまとめています。

「BigQueryとClickHouseのパフォーマンス差は非常に大きい。BigQueryではクエリ実行に数十秒かかることもある。一方、ClickHouseは適切にチューニングすれば、テラバイト級のデータに対して同じクエリをサブ秒で実行できる。」

「初歩的なことだよ、ワトソン君。コスト削減さ」 ―シャーロック・ホームズ(クラウド時代風アレンジ)

答えはコスト削減です。より正確に言えば、コスト削減の「可能性」です。

これは、クエリ利用量に対して課金されず定額制で提供されるデータウェアハウスにクエリを投げる形になるためです。利用量による課金がなく、リソースが許す限り好きなだけクエリを実行できます。

本記事では、価格の指標としてAivenのClickHouseマネージドサービスプランを取り上げます。これは筆者が本記事の検証に用いたサービスで、ClickHouseをはじめとする各種サービスをGCP環境へ簡単に接続できるよう設計されています。

Aivenのビジネスプランは、スタートアップ向けが月額約500ドルから、ビジネス向けが月額約2,000ドルからとなっており、お使いの環境で本アプローチが現実的かを判断する価格目安になります。

このソリューションがコスト面で意味を持つかどうかには、いくつかの損益分岐点があります。

BigQueryや可視化ツールに月500ドル未満しか支払っていない場合、コスト削減効果は得られない可能性が高い点にご注意ください。とはいえ反対に、パフォーマンスが大きく向上する可能性は十分にあります。

Aivenの500ドルおよび2,000ドルという価格帯を念頭に置くと、これはBigQueryのオンデマンド料金モデルにおける月間処理データ量1TiBおよび321TiB(320TiB+無料枠1TiB)に相当します。BIツールのジョブを実行しているプロジェクトに対して、こちらの[1]クエリを実行して確認することもできます。

比較対象として、ClickHouseもオートスケーリング機能とやや大きめのインスタンスを備えたプランをほぼ同等の価格帯で提供しています。サイジングや開発・本番要件次第では、こちらのほうが安価な選択肢となる場合もあります。

BigQuery Editionsについては、Editionsがオートスケーラー、つまり実質的にスライド式の価格スケールを採用しているため、損益分岐点を一概に示すことはできません。最も簡単な方法は、Lookerがクエリを実行しているプロジェクトに対して上記リンクの[1]クエリを実行し、Lookerのおおよそのコストを算出することです。

このクエリに関する注意点:

標準的でないLookerサービスアカウントを使っている場合や複数アカウントを利用している場合は、正確なコストを得るために正規表現を調整するか、Lookerサービスアカウント名で完全に置き換える必要があるかもしれません。

その値を算出すれば、上述の500ドルおよび2,000ドルというしきい値の上下どちらに位置するかを判断できます。さらに、パフォーマンスを重視するのであれば、Lookerダッシュボードでリアルタイムデータを表示するのに20秒も待たずに済むという観点だけでも、追加コストを払う価値は十分にあるでしょう。

本計画の狙いは、BigQueryとClickHouseの間でデータを「レプリケーション」し、重いクエリを発行するBIツールやその他の負荷の高いクエリツールをClickHouseに接続することです。理論上、これによりBigQueryのクエリ単位コストがなくなり、固定料金のリソースでクエリを処理できるようになるため、コストを大幅に削減できます。

また、リアルタイム性やより高速なクエリ性能が必要な場合にも有効です。ClickHouseは適切にチューニングすれば、はるかに高性能なクエリエンジンとして機能するからです。

大きなコスト削減につながる取り組みには必ず最初の一歩があり、本プロセスも例外ではありません。

まず確認すべきは、BIツールがBigQueryからどれだけのデータを読み込み、どのテーブルを参照しているかです。これは抽象的な問いで、BigQueryで簡単に解けるものではありませんが、これまでにもお見せしてきたとおり、ここでも解決の助けとなるクエリ[2]を用意しています。注意: このクエリは多額の費用が発生する可能性があるため、実行前にBigQuery UIで必ず見積もりを確認してください。

2つ目は、より踏み込んだ作業で、データ取り込みプロセスの調査です。何が「肝」になっているかを把握し、現在BigQueryへどのようにデータが取り込まれているかを理解する必要があります。これは、BigQueryと新たに作成するClickHouseインスタンスの両方にデータが行き渡るよう、取り込みプロセスを「分岐」させる形で改修するためです。

第1回の最後として、本シリーズ全体で使用するClickHouseインスタンスのサイズ選定と作成についてのガイダンスをお示しします。

BigQueryから他のデータベースシステムへの移行を何度も手掛けてきた中で、移行先データベースの適切なサイズをどう選ぶかという質問を頻繁にいただきます。残念ながら、絶対確実な方法は存在しないというのが、筆者の辿り着いた答えです。

クエリでBigQueryから取得したデータ量、キャッシュヒット件数、スロット使用量を分析するといった検討も重ねてきましたが、BigQueryは他の多くのデータベースとはあまりに仕組みが異なるため、同じ土俵での比較は困難です。これらの検討を通じて実現自体は可能だと分かりましたが、BigQueryはユニークなクエリデータ量や、スロットが消費したCPU・メモリといった必要なメトリクスの一部を出力していません。

とはいえ、これらの検討から1つはっきり見えてきたことがあります。それは、定期的に基本的なクエリを実行するデータベースであれば、まずは最低でも8GBのRAMから始めること。日中に重い計算クエリを発行するユーザーが10人を超える本格的な本番可視化用データベースであれば、16GBが最低ラインだということです。クエリの複雑さが増すにつれてCPU数を増やすのは有効ですが、ほとんどのクエリ性能においてCPUよりメモリのほうがはるかに重要なので、workloadsを問わずデュアルCPU構成が出発点として妥当です。

このガイダンスを踏まえると、Aivenのhobbyistティアやクリックハウスのdevelopmentインスタンスのようなごく小さなインスタンスでまずPoC(概念実証)を立ち上げ、動作を確認してから必要に応じてライトサイジングしていくアプローチをおすすめします。

UI変更によっていずれ古くなってしまう完全なウォークスルーをここに記す代わりに、Aivenのドキュメントへ直接リンクする形を取ります。

最初のステップは、こちらからAivenのアカウントを作成することです。

2番目のステップは、こちらに従ってAiven VPCを作成し、こちらに従ってGCP VPCとピアリングすることです。

次のステップは、こちらに従ってClickHouseサービスを作成することです。これには数分かかることがあるので、コーヒーかお茶でも淹れてお待ちください。

ピアリング済みVPC内のDockerコンテナまたはCLIツールを使って動作確認を行えば、利用開始の準備は完了です。

こちらも上記と同様、ここに記す内容は将来的に変更があれば古くなってしまうため、ベンダーのドキュメントへのリンクを示すにとどめます。

インスタンスの作成方法については、ベンダーのクイックスタートガイドをご覧ください。

ClickHouseインスタンスへの接続には、こちらに従ってGCP Private Service Connectをセットアップすることをおすすめします。これにより、最高レベルのセキュリティと、最小限の構成でインスタンスを利用できる環境を確保できます。

本パートはこの計画の概要をご紹介するにとどまりました。次回は、ClickHouseへのデータ取り込みと、ClickHouseとBigQuery間のレプリケーション設定について解説していきます。