ClickHouseを導入する前に知っておきたかったこと：SaaSのネットワーク制約とセルフホストの勘所
この記事は、freee Developers Advent Calendar 2025 の 16日目の記事となります。
フリー Platform Engineerのyuriaです。
昨日のpon さんのアドベントカレンダー記事「LangfuseバージョンアップのためにClickHouseを社内初導入した話 」でLangfuseとClickHouseの関係性やClickHouseの特徴について書いてもらいました。今回はClickHouseのサーバーとしての側面に注目して、以下の三つについて書いていこうと思います。
- ClickHouseがどのようなコンポーネントで構成されているか
- AWSでClickHouseをホストするときどのような選択肢があるか
- ClickHouseを実際立ててみてはまったポイント
ClickHouseがどのようなコンポーネントで構成されているか
Langfuse v3は、v2のPostgresのみに依存する構成から、Postgres, ClickHouse, S3 / Blob Storage, redis という多くのストレージコンポーネントに依存するようになりました。特にClickHouseがLangfuse内でどのような役割をしているかについてはponさんの記事 にお任せするとしてまずClickHouseの中の構成についてお話ししていきます。
まず知っておくべきClickHouseの「中身」
ClickHouseをLangfuseのリリースを見て知った方もいると思いますので、中身のアーキテクチャーについて軽く説明します。ClickHouseは１つのコンポーネントで完結するようなシステムではなく複数のClickHouseと複数のClickHouse Keeperというコンポーネントに大きく分かれています。それぞれのコンポーネントが他のノードに通信を行うことで非同期マルチマスターなDBを実現しています。
本体とKeeperの役割分担
ClickHouseは分析タスクを得意とするDBです。また、非同期マルチマスターなアーキテクチャーを採用しているDBでもあるため、非同期で他のレプリカにinsertされたdataを取ってくるmerge 作業の際の一貫性の保証を効率よく行うためにClickHouse Keeperが存在します。
ホスティング方針：3つの選択肢
ClickHouseをAWSで利用するとき大きく分けて３つの方針があります。
- EKSにたてる
- ECSにたてる
- AWS marketplace からSaaS版を購入
EKS・ECSは目立って大きな差は出ませんでした。どちらかというと、Fargate vs EC2やEBS/EFS/S3 のどれにするかがむしろ運用・コストの両面で差が出てくるだろうなという肌感です。
ECSをTerraformで運用するときの手間や、ClickHouseの通信設計をECSで実現する時の手間を鑑みると、フリーではECSよりEKSのナレッジの方が社内に蓄積されていることも踏まえてセルフホストなら、EKSを選んだだろうなと思います。
セルフホスト/ SaaS の比較
※SaaSはEnterpriseプラン
| 項目\ 方法 | セルフホスト | SaaS |
|---|---|---|
| 垂直スケール | 大きいサイズで水平スケールしてから小さいサイズのものを削除 | ユーザー定義の範囲内で自動的に変動 |
| 水平スケール | レプリカ数を増やして設定 | レプリカ数を増やすと数分で完了 |
| バージョンアップ | Cluster / ClickHouse両方必要 | SaaS側で自動的に実施 |
ClickHouseを実際立ててみてはまったポイント
SaaS導入時にはまったポイント
SAML設定どこ...問題
SAML SSO setup | ClickHouse Docs
フリーでは、社内の権限管理をSAMLによって行っています。ClickHouse Enterprise プランではSAML SSO設定ができるためこちらの設定を行いました。SAML設定のための Identity provider SSO URLやX.509 certificateを入力するフォームがあるのかと期待するかと思います。入力フォームはなく、ClickHouseのサポートチケットでSAML設定の依頼を行うようなフローになっていました。
「同一VPC内で制御しきれない？」AWS Private DNSの制約詳細
ClickHouseを利用するにあたって、必要ないサーバーからClickHouseにアクセスできないよう制御する必要がありました。これは複数台たてる時も目的のClickHouseサーバー以外に繋げないことも含めています。SaaS版ではVPCとClickHouse間はAWS PrivateLinkで接続します。VPC Endpoint にはSecurity Groupがattachできるため通信制御はSecurity Groupで行うことができます。ClickHouseを複数台たてるときは、立てたClickHouse毎にVPC Endpointを作れば、Security Groupで個別に通信制御ができて解決！
...そう思っていた日が私にもありました。
※ 図はイメージです。実際にはEC2の部分はEKSのpodだったりします。
確かに、VPC Endpoint 自体は1つのVPCに複数個たてることができました。しかし、実際に疎通確認をしてみると上手くいかない。原因を調べるとどうやら名前解決がうまくいっていない模様。どうやら、VPC Endpointに紐づけられたDNS名が1つでないために起こったようです。実際に、Manage DNS names for VPC endpoint services では以下のように記載されています。
An endpoint service can have only one private DNS name.
ClickHouseを使うサービス毎にVPCを分ければそもそもこの問題は起こらないのですが、RDSのノリで作ろうとするとPrivate DNSの制約に引っかかるので配置にはお気をつけください。
EKSでセルフホストする場合のハマりポイント
マニフェスト作るの手間問題
EKSでセルフホストする場合、helmその他の方法でマニフェストを作る必要があります。ClickHouseとLangfuseを同じクラスタ上でホストしても良いのケースでは、Langfuse公式Helm Chartがimage以外の点で使い勝手が良くおすすめです。マニフェスト上のclickhouse.image.repository の値をclickhouse/clickhouse-server のものに差し替えるくらいの変更で手軽に動かすことができます。一方で、ClickHouse単体となるとちょうど良いマニフェストファイルがない状態です。そのため、公式チュートリアル等で使用されているdocker-composeやClickstack・Langfuseに同梱されているClickHouseのChartを参考にして、helm chartを自作する必要があります。
Langfuse公式Helmチャートの注意事項
Langfuse公式Helm Chartは、ClickHouseのイメージがbitnami のものを使っているためライセンスに関しては注意が必要です。また、keeperのデフォルトがClickHouse KeeperではなくZookeeperな点も留意する必要があるかもしれません。
おわりに
フリーでは最終的にSaaSのスケールしやすさ、Helmファイル等のメンテコストを考え、SaaSを利用することにしました。
ECSの構築、とりわけタスク間通信の設計においては、先行事例としてLayerX uehara様の記事を多大に参考にさせていただきました。 この記事で共有されている知見があったからこそ、迷いなく検証を進めることができ、設計の大きな助けとなりました。また、自分もこのブログのように役立つ記事を書けたらなと思い記事を書くきっかけにもなりました。
ClickHouseの導入にあたり、ClickHouse Inc.のサポート、セキュリティチーム、SRE（特にDBRE）チームをはじめ、多くの方々にご尽力いただきました。
とりわけAWS PrivateLinkとDNS周りの検証においては、11月に設立されたばかりのClickHouse日本法人の皆様に手厚くサポートいただきました。ご協力いただいた皆様に、改めて深く感謝申し上げます。
明日はossoさんからAI時代のPdM / EMについての記事が公開されます。お楽しみに！
