LayerX、Langfuse 改善で ClickHouse 負荷低減
本文の状態
日本語全文を表示中
詳細モードで約7分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
LayerX Tech Blog
LayerX はバクラク事業部における Langfuse のトレース記録遅延問題を解決するため、取り込み処理を最適化し、ClickHouse の負荷と Redis メモリ使用率を大幅に低減した。
AI深層分析を開く2026年7月30日 04:16
AI深層分析
キーポイント
トレース記録遅延の発生要因
LLM 機能の増加に伴いピーク時にトレース反映が最大1日かかる状況となり、Redis メモリ使用率の上昇と滞留が確認された。
ボトルネック箇所の特定
Langfuse worker と ClickHouse の CPU 使用率が頭打ちになる一方で、EFS の読み取り IO が異常に増加する不自然な状況が発生していた。
処理フローの改善と結果
Langfuse worker のトレース取り込み処理を改善したことで、ストレージである ClickHouse の負荷が低減し、記録遅延の問題が解消された。
ClickHouse での SELECT クエリが負荷の要因
イベント取り込み時に特定レコードを検索するSELECTクエリが頻繁に発行され、ClickHouse の苦手とする処理により遅延が発生していた。
プロジェクト作成日による SELECT クエリのスキップ機能
環境変数で指定した日以降に作成されたプロジェクトについては、取り込みパイプライン内のSELECTクエリをスキップする機能が用意されている。
重要な引用
ピーク時はトレースの反映まで1日近くかかることもあり、プロンプト変更後のモニタリングや改善作業にも影響が出ている状況でした
当時の Redis メモリ使用率は次の通りで、アイテム数の急増に伴ってメモリ使用率が上昇しており、処理遅延に伴う滞留が確認できます
ClickHouse はカラム単位の大量データ集計やスキャンには強い一方で、特定1レコードの検索や読み取りを大量に繰り返す処理は苦手としています。
LANGFUSE_SKIP_INGESTION_CLICKHOUSE_READ_MIN_PROJECT_CREATE_DATE: z.string().date().optional(),
編集コメントを表示
編集コメント
この技術ブログは、LLMOps の実運用で直面する具体的なボトルネックと、その解決策を詳細に分析した貴重な事例である。特に Redis と ClickHouse の連携における非効率な IO パターンの特定は、同様のアーキテクチャを採用する開発者にとって示唆に富む内容だ。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
バクラク事業部 Platform Engineering 部 SRE グループの uehara です。
LayerX のバクラクでは、LLMOps プラットフォームとして Langfuse を採用しています。また、Langfuse のストレージには ClickHouse を使用しており、どちらもセルフホストで運用中です。詳細については、以下の記事も合わせてご覧ください。
バクラク内で LLM を活用した機能が増えるにつれ、Langfuse へのトレース記録に遅延が目立つようになりました。
お客様の利用に直接影響する事象ではありませんが、ピーク時にはトレースの反映まで約 1 日かかることもあり、プロンプト変更後のモニタリングや改善作業にも支障をきたす状況でした。
参考までに、トレースが取り込まれるまでの流れは以下の通りです。
- クライアントから Langfuse へトレースが送信される
- Langfuse はジョブを Redis キューへ積む
- Langfuse worker がジョブを取り出し、トレースを永続化する
当時の Redis メモリ使用率は次の通りで、アイテム数の急増に伴ってメモリ使用率が上昇しており、処理遅延による滞留が確認できます。
imageRedis メモリ使用率
キューを処理する Langfuse worker は CPU を使い切れておらず、流量が増える日中は 30% 台で頭打ちになりました。書き込み先ストレージである ClickHouse も CPU が 60% 前後で限界に達しています。
imageLangfuse worker CPU 使用率
imageClickHouse CPU 使用率
一方で、EFS の DataReadIOBytes が大幅に増加していることも判明しました。処理の内容はトレースの書き込みですが、EFS で読み取りが増えているのは少し不思議な状況です。
imageEFS DataReadIOBytes
Langfuse トレース取り込み処理の概要
まずは Langfuse の worker がトレースを取り込む処理を調査しました。記事の理解を容易にするため、ここでは用語を以下のように定義します。
- プロジェクト：トレースが保存される場所。バクラクでは製品や機能ごとに分割しています。
- トレース：LLM アプリケーションにおける 1 リクエストまたは 1 操作に対応する記録単位です。
- イベント：SDK から送信される、トレースの作成や更新などのデータです。「Observation」の種類である「Event」とは区別されます。
- レコード：ClickHouse に書き込まれる 1 行のデータ。同一トレースに対する複数のイベントをマージした結果が格納されます。
トレース取り込みの詳細な流れを確認すると、以下の処理が行われています。
- クライアント SDK からイベントが送信される
- イベント情報を S3 に保存し、worker が実行するジョブを Redis にキューイングする
- worker がジョブを受け取り、S3 から同一トレースの全イベント情報を取得してマージする
- ClickHouse を検索し、該当する既存レコードがあれば新イベント情報とマージする
- マージ結果を 1 レコードとして ClickHouse に書き込み、永続化する
トレース保存の際のポイントとなるのは、S3 のイベント情報や ClickHouse の既存レコードとのマージ処理です。特に 4 つ目のステップでは、ClickHouse に対して以下のクエリが実行されます。
SELECT *
FROM ${table}
WHERE project_id = {projectId: String}
AND id = {entityId: String}
${additionalFilters.whereCondition}
ORDER BY event_ts DESC
LIMIT 1 BY id, project_id SETTINGS use_query_cache = false;
これは特定の 1 レコードを検索する処理で、クエリキャッシュを無効化するオプションも付与されています。イベントが 1 件送られるたびにこのクエリが発行されるため、膨大な数の SELECT 実行が発生してしまいます。
ClickHouse はカラム単位での大量データ集計やスキャンには強い反面、特定の 1 レコードを検索・読み取る処理を大量に繰り返すことには苦手としています。今回の処理遅延の主な原因が、この SELECT クエリの増加によるものでした。
SELECT クエリのスキップによる負荷軽減
Langfuse worker では、この SELECT クエリを実行しないための環境変数 LANGFUSE_SKIP_INGESTION_CLICKHOUSE_READ_MIN_PROJECT_CREATE_DATE が用意されています。
// S3 が稼働し始めた日以降に作成されたプロジェクトについては、取り込みパイプライン内で ClickHouse への読み取りを行わないように設定します。
LANGFUSE_SKIP_INGESTION_CLICKHOUSE_READ_MIN_PROJECT_CREATE_DATE: z
.string()
.date()
.optional(),
https://github.com/langfuse/langfuse/blob/v3.119.0/worker/src/env.ts#L130-L135
この環境変数には YYYY-MM-DD 形式の日付を指定します。指定日以降に作成されたプロジェクトでは、ClickHouse からの SELECT クエリがスキップされる仕様です。
この設定が用意された背景には、Langfuse の v2 と v3 でトレースの取り込み処理が大きく異なる点があります。v2 ではイベント情報を PostgreSQL に直接書き込んでいましたが、v3 からは S3 を経由した非同期処理へと変更されました。
v2 から v3 へ移行した環境では、PostgreSQL 上のデータは ClickHouse へ移管されますが、S3 には v2 時代のイベント情報が残っていません。つまり、v2 時代に作成されたプロジェクトでトレースを更新する際、S3 のデータに加えて ClickHouse のレコードも合わせてマージする必要があります。
しかし、弊社では運用開始当初から v3 を利用しており、すべてのイベント情報が S3 に保存 *1 されています。そのため全プロジェクトで ClickHouse への SELECT クエリをスキップでき、環境変数には「Langfuse の運用開始日より前の日付」を設定しました。
設定変更後の効果
ClickHouse への SELECT クエリを停止したところ、すぐに効果が現れました。
Redis のメモリ使用率を確認すると、滞留していたアイテムが解消され、アイテム数が減少してメモリ使用率も急激に低下しています。
imageRedis メモリ使用率 (設定変更後)
後続処理の詰まりにより 30% 台で頭打ちになっていた Langfuse worker も、滞留したジョブを一気に消化した後は従来の半分以下の負荷に落ち着いています。
imageLangfuse worker CPU 使用率 (設定変更後)
ClickHouse の CPU 使用率も一桁台まで急減し、リソースに余裕が生まれました。この状態で安定的に運用できたため、その後はタスクのスケールダウンによりコストを最適化できています。
imageClickHouse の CPU 使用率（設定変更後）
EFS の DataReadIOBytes も、休日や深夜の閑散時と同程度の負荷に落ち着きました。
imageEFS の DataReadIOBytes（設定変更後）
まとめ
Langfuse でのトレース取り込み処理の遅延について調査した結果、ClickHouse への SELECT 処理をスキップすることで解消できました。
実施した変更は環境変数を 1 つ追加しただけですが、ClickHouse が苦手とするワークロードを取り除いたことで、取り込み処理を大幅に高速化できました。運用チューニングの事例として、少しでも参考になれば幸いです。
今回はセルフホストならではの深掘り事例でしたが、弊社では要件に応じてマネージドサービスも積極的に活用しています。
バクラク事業部の SRE チームでは、技術選定からパフォーマンス改善、開発プラットフォームの整備まで一緒に取り組める仲間を探しています。少しでもご興味のある方は、ぜひお話させてください！
AI カンファレンス「Bet AI Day 2026」を開催します！
AI は「使う」段階から「共に働く」段階へ。
2 回目となる「Bet AI Day 2026」は、"AI エージェントと働く未来に、Bet しよう"をテーマに、LayerX における AI エージェント活用の実践知などを余すことなく共有します。
昨年同様オンライン開催となりますので、全国どこからでも PC やスマートフォンで気軽にご視聴いただけます。AI エージェントと働く未来に興味のある方は、ぜひ「Bet AI Day 2026」にご参加ください！
「Bet AI Day 2026」開催概要
- 開催日：2026 年 9 月 3 日（木）12:00 開演
- 開催方法：オンライン配信
- 参加費：無料（事前申込制）
- お申し込み（connpass）：https://layerx.connpass.com/event/399169/
*1: 保存先バケットでオブジェクトを削除するライフサイクルルールは設定していません
AI算出
技術分析ainew評価高い
記事は Langfuse と ClickHouse を用いた LLM 運用基盤の性能問題（トレース遅延）を分析し、Redis キューやストレージ負荷の具体的な数値を示しながら技術的改善プロセスを詳述しており、実装知見としての価値が高い。LayerX という日本企業の事例であり、日本語で詳細な技術分析が提供されている点も評価される。
6つの評価軸を見る
- AI関連度
- 75
- 情報源の信頼性
- 100
- 新規性
- 50
- 調べる価値
- 75
- 重複の少なさ
- 100
- 日本での有用性
- 75
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み