Trench を採用する前に見ておく: Kafka と ClickHouse を1つの Docker イメージに畳んだイベント基盤
Trench — Open-Source Analytics Infrastructure. A single production-ready Docker image built on ClickHouse, Kafka, and Node.js for tracking events. Easily build product analytics dashboards, LLM RAGs, observability platforms, or any other analytics product.
ひと目でわかる
- これは何？
- Trench は Segment 互換の Track / Identify / Group を受け取り、Kafka 経由で ClickHouse に書き込むセルフホスト型のイベント追跡基盤である。単一イメージで完結する代わりに、スキーマと保持期間の設計責任は利用者側に残る。
- 誰に向いている？
- 採用を検討すべきなのは、Segment 互換の API でイベントを受け取り、その先を ClickHouse の SQL で自分で組み立てたいチームである。Grafana や Metabase を ClickHouse に直接つなぐ前提が許容できるなら、Trench はその中間層として素直に収まる。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 162 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Trench が埋めるのは「イベント収集」と「分析」の間の空洞
プロダクト分析を自前で作ろうとすると、最初にぶつかるのは可視化ではなく取り込み口の設計である。Segment 互換の Track / Identify / Group を受け取る HTTP エンドポイントを立て、書き込み先を時系列に強いカラムナ DB に置き、その上にクエリ層を載せる。この3層を毎回作り直すのは無駄が大きい。Trench はこの部分を1つの Docker イメージにまとめて配布する。README は「Trench is an event tracking system built on top of Apache Kafka and ClickHouse」と説明しており、対象読者はイベント基盤を自前で持ちたいが、PostHog のような完成品の UI までは要らない、あるいは UI を自分で作る前提のエンジニアである。Frigade 社内のリアルタイム追跡パイプラインをスケールさせるために作られた、という由来も README に書かれている。
イベントは HTTP で入り、Kafka を経て ClickHouse に落ちる
データの流れは README の記述から読み取れる範囲でシンプルである。クライアントは /events に POST し、ペイロードは events 配列を持つ JSON で、各要素に userId、type、event、properties が入る。type は track などの Segment 互換の種別である。受け取ったイベントは Kafka に流し込まれ、そこから ClickHouse に書き込まれる。読み出しは2系統ある。1つは /events で、event 名などの条件で JSON を返す。もう1つは /queries で、ClickHouse の SQL 文字列をそのまま投げる。README の例では SELECT COUNT(*) FROM events WHERE userId = '...' という生の SQL が使われている。つまり Trench は分析用の抽象化レイヤを提供しておらず、ClickHouse のテーブル設計と SQL がそのまま利用者の作業対象になる。Kafka を挟む利点は書き込みのバッファリングと、ClickHouse 以外への fan-out の余地である。README は webhook による他 destination への接続にも触れている。
起動は docker-compose 3行と .env のコピーから
セルフホスト版の前提は Docker と Docker Compose のみである。README の quickstart は次の手順を示す。git clone https://github.com/frigadehq/trench.git の後、cd trench/apps/trench に移動し、cp .env.example .env で設定ファイルを用意する。起動コマンドは docker-compose -f docker-compose.yml -f docker-compose.dev.yml up --build --force-recreate --renew-anon-volumes で、dev 用の override ファイルを重ねる形になっている。これで ClickHouse と Kafka のローカルインスタンスを含むサーバが localhost:4000 で立ち上がり、ブラウザで開くと Trench server is running と表示される。README は本番環境なら 4GB の RAM と 4 CPU コア以上を推奨している。API キーは .env に既定の公開キーと私有キーがあり、curl の例では Authorization: Bearer public-... を送信に、private-... を読み出しに使っている。Kafka 側の接続は環境変数で調整でき、KAFKA_SSL_ENABLED、KAFKA_SSL_REJECT_UNAUTHORIZED、KAFKA_SSL_CA、KAFKA_SSL_CERT、KAFKA_SSL_KEY、KAFKA_SASL_MECHANISM（plain / scram-sha-256 / scram-sha-512）、KAFKA_SASL_USERNAME、KAFKA_SASL_PASSWORD が用意されている。証明書は PEM の中身をそのまま変数に渡す形式である。
公開キーで SQL が撃てる構成は、そのまま公開しない
README の SQL 実行例は public- で始まる公開キーを Authorization ヘッダに載せている。イベント送信用のはずのキーが /queries にも通る設計だと読める。これはクライアントサイドに埋め込む前提のキーとしては危険で、任意の SELECT を外部から実行できる状態を作りうる。README はこの点について権限分離の説明をしていない。同じく ClickHouse のテーブルスキーマ、TTL、パーティション設計についても、README には記述がない。イベント量が増えたときの保持期間の切り方や、properties をどうカラムに展開するかは利用者が自分で決めることになる。つまり Trench は「取り込みと保存の配管」を渡すが、「何をどれだけ持つか」は渡さない。ここを設計しないまま本番投入すると、ディスクが先に悲鳴を上げる。
PostHog や Plausible との差は抽象化の高さにある
同じ領域の選択肢として PostHog と Plausible が README のトピックにも挙がっている。PostHog はイベント取り込みからファネル、セッションリプレイ、フィーチャーフラグまでを1つの製品として提供し、利用者は SQL を書かずに UI で分析を組み立てる。Plausible は Web サイト解析に絞り、軽量なスクリプトと集計済みの指標を売りにする。Trench はどちらとも方向が違う。生のイベントを ClickHouse に溜め、SQL と /queries を入口として渡す。ダッシュボードが必要なら Grafana や Metabase を ClickHouse に接続して作る、という前提である。README のデモも Grafana と組み合わせて簡易版 Google Analytics を作る内容になっている。抽象化が高いほど早く答えが出るが、指標の定義を製品側に決められる。低いほど自由だが、SQL を書ける人が必要になる。Trench は後者に振り切っている。
イベント量の主張と、検証されていない部分
README は「Process thousands of events per second on a single node」とうたっている。ただしこれはプロジェクト側の記述であり、ノードのスペック、イベントのサイズ、バッチの条件は示されていない。採用判断の根拠にするなら、自分のイベント形状で /events に負荷をかけて ClickHouse の書き込みとクエリのレイテンシを測る必要がある。もう1つ確認できないのは、Kafka や ClickHouse のバージョン追従である。docker-compose.yml が固定しているイメージタグは README からは分からない。リリースは trench-js@0.0.17 などクライアント SDK 側が中心で、2024年12月以降の更新が README からは確認できない。サーバ本体のリリースサイクルがどうなっているかは、リポジトリのタグを直接見ないと判断できない。
ライセンスと運用コストの見積もり
ライセンスは MIT で、README も「Open-source and MIT Licensed」と明記している。フォークして改変し、自社サービスに組み込むことも MIT の条件の範囲で可能である。ただし Trench Cloud という別のマネージド提供が同じ README で案内されており、セルフホスト版とクラウド版でどこまで機能差があるかは README からは読み取れない。運用コストの面では、Trench 自身のアップグレードに加えて、同梱される Kafka と ClickHouse のアップグレードを自分で追う必要がある。ClickHouse はバージョン間の互換性で注意が要る箇所があり、Kafka も broker と client のバージョン整合を取る必要がある。マネージドの Kafka や ClickHouse を外部に置く構成も、KAFKA_SSL_* と KAFKA_SASL_* の環境変数が用意されていることから想定されていると読める。この場合、Trench のイメージはアプリケーション層だけを担う。
編集部の結論
採用を検討すべきなのは、Segment 互換の API でイベントを受け取り、その先を ClickHouse の SQL で自分で組み立てたいチームである。Grafana や Metabase を ClickHouse に直接つなぐ前提が許容できるなら、Trench はその中間層として素直に収まる。逆に、非エンジニアが画面だけでファネルやリテンションを組み立てる製品を期待している場合、Trench はその手前で止まる。導入前に確認すべきは、apps/trench 配下の .env.example に並ぶ PUBLIC_API_KEY と PRIVATE_API_KEY の運用方法、そして /queries エンドポイントに公開キーで到達できる構成になっていないかである。公開キーはイベント送信用、私有キーは読み出し用という切り分けが崩れると、SQL 実行が誰にでも開く。
コミュニティノート