- Lago は ClickHouse Cloud を活用して大量の利用イベントを取り込み・保存・クエリし、大企業向けのリアルタイムな従量課金や複雑なマネタイズを実現しています
- ClickHouse Cloud と ClickPipes への移行により、Lago は毎秒1万イベントの規模から、毎秒100万イベントというエンタープライズ規模のワークロードへとスケールしました。
- ClickHouse により、Lago は自社でデータ基盤を構築・運用することなく、より大規模で複雑な顧客に対して、正確かつ低レイテンシーな課金処理を提供できるようになりました。
まとめ
ビリングの基盤を築く #
Lago のチームには、こんな言い回しがあります。「友達には、ビリングシステムを自作させない」と。
2010年代後半、このフランスのスタートアップの創業者たちは、ヨーロッパで急成長を遂げていたフィンテック企業 Qonto で働いていました。多くのプロダクトチームと同じく、彼らもビリングはサイドプロジェクト程度のもの——さっと片付けて次に進める類のものだと考えていました。ところが実際には、新しい料金モデル、新しい顧客要件、新しいエッジケースが次々と現れ、複雑さは一気に積み上がっていきました。当初はわずかなスクリプトの集まりだったものが、10〜15 名のフルタイムエンジニアで支える巨大な社内プラットフォームに膨れ上がっていったのです。彼らが学んだのは、ビリングは重要なインフラであり、プロダクト、地域、顧客が増えるほど難しさが増していくということでした。
2021 年に Lago を立ち上げたとき、彼らの目標は単なる新しいビリングツールを作ることではありませんでした。ビリングの作り方そのものを変えること——ブラックボックスでも、マイクロサービスの寄せ集めでもない形を実現することでした。オープンソースは、その理念の中核にあり、哲学的な理由と同じくらい実務的な理由からも重要でした。ビリングが企業の収益の屋台骨である以上、それは透明であり、拡張可能であり、プライバシー・コンプライアンス・セキュリティを最大限に実現できるものでなければなりません。Lago は、開発者がコードを検査し、自社のシステムに合わせて適応させ、硬直したブラックボックス的なワークフローに縛られずに済むように設計されました。
それは同時に、彼らが市場で目にしていた状況への反応でもありました。彼らの言葉を借りれば、「他の多くのビリングベンダーは顧客を囲い込んだり、柔軟性が限定的だったりするため、顧客が結局ビリングロジックの多くを自社内で構築する羽目になっている」のです。スケールしてくると、そのモデルは綻び始めます。Lago の Head of Growth である Lisa Bardet はこう語ります。「企業はある程度の規模と複雑性に達すると、多くの回避策を作らざるを得なくなります。そうなるタイミングでお客様が私たちのドアを叩いてくれることが多いんです。」
Lago は最初から複雑なビリングのために作られました。つまり、従量課金、サブスクリプション、クレジット、そしてほぼあらゆる価格モデル(あるいはそれらのハイブリッド)をサポートしています。AI 駆動のプロダクトや API ファーストのビジネスがソフトウェアの売り方を一変させるなかで、その判断はますます意味を持つようになっています。すべてのリクエスト、すべてのトークン、すべての機能利用が課金対象イベントになるのです。Lisa は言います。「だからこそ、取り込めるイベント数をスケールできることが極めて重要なのです。それによって私たちは、いかなる時点でも顧客のマージンを最も正確に提示できるようになります。」
なぜ Lago は ClickHouse Cloud に行き着いたのか #
Lago のプラットフォームが成熟するにつれ、提供先となる企業の顔ぶれも変わってきました。当初は急成長中のスタートアップ向けのソリューションだったものが、PayPal、CoreWeave、Mistral といった、より大規模で複雑、かつ要求の厳しいエンタープライズに採用されるケースが増えています。そして上位市場へのシフトとともに、データ量も爆発的に増加します。ある時点を境に、ビリングはアプリケーションの問題ではなく、データの問題になるのです。
その新たな現実を支えるためには、Lago のインフラを根本から見直す必要がありました。チームに必要だったのは、膨大な使用イベントのストリームをリアルタイムに取り込み、効率的にクエリし、顧客のニーズの変化に合わせて進化できるシステム——しかも、Lago を硬直的・プロプライエタリな制約に押し込めることのないシステムでした。「オープンソース企業として、特定のソリューションに縛られたくなかったんです」と Engineering Lead の Jérémy Denquin は言います。
チームは代表的な候補をいくつも評価しました。Redshift、Timescale、DuckDB、そして Postgres ベースのアプローチなど。それぞれを実際のワークロードでテスト・ベンチマークし、限界まで負荷をかけてみました。あるものは取り込みで詰まり、あるものは構成が重く、運用面でスケールさせるには複雑すぎました。「本当にいろいろなデータベースを試しました」と Jérémy は語ります。「本当にうまく動いて、しかも理解しやすかったのは ClickHouse だけでした。」
当時、毎秒100万イベント規模のワークロードはまだ少し先の話でした。Lago の当初の目標は毎秒1万〜2万イベント程度——それでも、既存システムが快適にさばけるレベルをすでに大きく超えていました。そのレベルでも ClickHouse は際立っていました。導入直後から高速で、書き込み量の多さを難なくこなし、何かを動かすために何週間ものチューニングを必要としませんでした。ドキュメントは明快で、エコシステムは活発で、柔軟性とコントロールを保てるという点でチームのオープンソース哲学にもフィットしていました。
ClickHouse を選ぶことが一つの決断だとすれば、それをどう運用するかはもう一つの決断でした。Jérémy はインフラ面では実質的に一人で運用しており、チームとしてもデータベース運用者になるつもりは毛頭ありませんでした。「時間がなかったんです」と彼は言います。「私にとっては、ClickHouse Cloud を使うほうがはるかに簡単でした。」マネージドサービスがスケーリング、アップグレード、メンテナンスの負担を肩代わりしてくれることで、チームはインフラではなくビリングソリューションに集中できるようになりました。
ClickHouse Cloud は Lago の既存パイプラインにも自然に収まりました。チームは使用イベントのストリーミングに Kafka と Redpanda を多用しています。ClickHouse Cloud のネイティブな取り込みサービスである ClickPipes のおかげで、独自コネクタを構築・保守することなくデータを ClickHouse に流し込めるようになりました。プライベートネットワーキング、ネイティブな統合、明快な運用モデルを備えた ClickHouse Cloud は、インフラを「もう一つの仕事」にすることなく、Jérémy とチームに必要なパフォーマンスと信頼性をもたらしました。
ClickHouse ベースの Lago のビリングエンジン #
現在、ClickHouse は Lago のビリングインフラの中心に位置しています。プラットフォームは ClickHouse を 3 つのコアワークロードに利用しています。大量の課金イベント取り込み、利用データに対する高速な分析クエリ、そしてプロダクト全体にわたるアクティビティ/監査ログです。
このうち最大規模なのが課金イベントのパイプラインです。Lago の顧客のアプリケーションで課金対象のアクション——API 呼び出し、機能の利用、消費されたコンピュートユニットなど——が発生するたびに、そのイベントは Kafka または Redpanda を経由してストリーミングされ、ClickPipes 経由で ClickHouse に取り込まれます。多くの顧客では、毎秒数万件のイベントが常時システムを流れることになります。そして一部の顧客では、それをはるかに上回ります。
たとえばあるラージカスタマーでは、Lago に毎秒約 100 万件のイベントの取り込みをサポートすることを求めてきました。「私たちはそれを成し遂げ、成功させました」と Jérémy は言います。このワークロードの規模は、より大規模なエンタープライズが消費ベースのモデルを採用するなかで、従量課金がどこへ向かっているのかを示しています。「ビリングサイドで毎秒100万件のイベント取り込みを提供できるのは、市場で私たちだけです」と彼は付け加えます。「ClickHouse なしでは不可能でした。」
Lago は、その使用状況をリアルタイムにクエリするためにも ClickHouse を利用しています。プラットフォームは消費量を計算し、価格ロジックを適用し、正確な使用データを最小限のレイテンシで顧客に提供する必要があります。ClickHouse のカラムナストレージとクエリ性能のおかげで、データ量が増え続けてもなお、事前集計や複雑なパイプラインなしに生のイベントデータに対して直接これらの分析ワークロードを実行できます。
最近追加されたのが、アクティビティ/監査ログです。Lago に対するすべての API 呼び出しは ClickHouse に記録され、プラットフォーム全体で何が起きているかについて、完全で検索可能な履歴をチームに提供します。このデータは社内でデバッグと可観測性のために、社外では顧客に自分たちのアクティビティを可視化するために利用されています。これもまた、最初は小さく始まっても急速にスケールするタイプのワークロードであり、パフォーマンスと信頼性が重要になるもう一つの領域です。
Lago と ClickHouse のこれから #
Lago が上位市場への進出を続けるなかで、ClickHouse の役割はますます大きくなっています。チームはすでにコアの課金イベントとログを超えて利用範囲を拡大し、リアルタイムの利用トラッキング、集計、分析へとさらに踏み込んでいます。目指すのは、自社プロダクトがどう使われ、その利用がどう収益に転換されているかを、顧客にこれまで以上に明確かつ即時に見せることです。「これからもますます使うことになるでしょう」と Jérémy は ClickHouse について語ります。
この拡大は、Lago がサービスを提供する顧客層と密接に結びついています。彼らは最高水準の課金精度、パフォーマンス、信頼性を要求します。「私たちはどんどん大きな組織にサービスを提供する方向に進んでいます」と Lisa は言います。「そのレベルでスケールしながらパフォーマンスを維持するうえで、ClickHouse は大きな役割を果たしています。私たちのインフラの中核コンポーネントです。」
時間が経つにつれ、ClickHouse は Lago のデータワークロードのさらに大きな部分を担うようになるとチームは見ています。現在も一部の分析やイベントストレージは Postgres 上で動いていますが、長期的な方向性は明確です。「いずれ本番環境では、イベントストアとしての Postgres を取り除くことになるでしょう」と Jérémy は語ります。目指すのは、生の取り込みからリアルタイム分析まですべてを扱える、単一の高性能な基盤に集約しつつ、運用をシンプルに保つことです。
Lago が成長し、より大規模で複雑な組織を迎え入れていく中で、その基盤の重要性はかつてないほど高まっています。複雑なビリングをシンプルに感じさせるというビジョンから始まった企業にとって、ClickHouse は最も困難な部分をボンネットの内側にしっかり収めておくための鍵となっているのです。



