CyberAgentが公開した高トラフィック向け分散トレーシング基盤の構築法

編集: グリットアーツ編集部

公開日：2026年9月28日

3行解説

ニュースの概要

CyberAgent Developers Blogは2026年9月10日、AJAのDSPチームで進めたオブザーバビリティ強化の取り組みを公開しました。記事では、内定者アルバイトとして参加した杉原充稀氏が、広告配信基盤のマイクロサービス群に対して分散トレーシングを導入した経緯と構成を説明しています。対象は、SSPからの入札リクエストを短時間で処理する高トラフィック環境です。

これまで同基盤では、メトリクスやログで個別の異常は追えても、1件のリクエストがどのサービスを通り、どこで遅れたかを一連で追跡できませんでした。そこで、OpenTelemetryによる計装と、OpenTelemetry Collectorを使ったTail-based Samplingを導入し、Traceの保存対象を制御する構成にしています。

何が新しいのか

新しい点は、単にトレーシングを入れたことではなく、高負荷前提で「受信」と「保持・判定」を分けたことです。DDOTは各ノードでSpanを受け取り、Trace IDを基準にCollectorへ振り分けます。一方で、Traceの保持とサンプリング判定は専用のCollector群が担います。これにより、同じTraceのSpanが別々のCollectorに分かれる問題を避けやすくしています。

もう一つの新しさは、サンプリング基準を単純なエラー判定に置かなかった点です。記事では、Span StatusがERRORかどうかだけでは調査価値を判断できず、処理結果や劣化状態を示すAttributeをアプリ側で付与したとしています。さらに、サンプリングポリシーは一時20個まで増え、条件ごとの評価方法がCPU負荷に影響したことも明かしています。

グリットアーツ編集部の分析

この事例で重要なのは、「見える化」そのものより、見える化のための基盤が本番負荷を増やす点です。記事では、CollectorがTrace保持によるメモリ使用と、ルール評価によるCPU使用に偏ると説明しています。つまり、トレーシングは導入すれば終わりではなく、どこで保持し、どこで判定し、どこで分離するかまで設計しないと、広告配信のような短時間応答系では逆に本体処理を圧迫する可能性があります。

また、Tail-based Samplingは調査価値の高いTraceを残しやすい一方、Trace完了まで保持するため、Collector側の設計難度は上がります。今回のように専用ノードプールへ分ける判断は、アプリケーションと観測基盤の資源競合を避けるうえで現実的です。高トラフィック環境では、可観測性の精度と運用コストを同時に見ないと、導入効果が見えにくくなると考えられます。

日本の現場で考えると

日本のKubernetes運用でこの構成を考えるなら、まず確認したいのは、既存のアプリケーションノードと観測基盤を同居させるかどうかです。記事のようにCollectorを専用ノードプールへ分ける設計は、業務処理の遅延を避けたい現場では有効ですが、ノード増設や運用分担が必要になります。

向いているのは、広告配信、金融取引、ECの決済前後、配車や予約のように、1件の遅延原因を後から追いたいシステムです。慎重に見るべきなのは、トラフィックが少なく、ログだけで十分に原因追跡できる環境です。その場合、Tail-based Samplingのための保持・判定コストが見合わない可能性があります。

また、記事では業務上の状態をAttributeで追加していました。日本企業の現場でも、HTTPステータスだけでは分からない「劣化」「フォールバック」「入力異常」をどう表現するかが重要です。計装を入れるだけでなく、アプリ側の状態定義を先に決めないと、後からTraceを見ても判断材料が足りないままになります。

導入・検討時に確認したいこと

• 毎秒どの程度のSpanをCollectorが受ける想定か。
• Trace完了までの保持に必要なメモリ量と上限。
• サンプリングポリシーを増やしたときのCPU負荷。
• 同一TraceのSpanを同じCollectorへ集める方法。
• アプリ側で追加するAttributeの設計と運用ルール。

現時点で分かっていないこと

記事からは、実際の処理性能や保存コストの削減幅は分かりません。また、Collector群の具体的な台数、ノードプールの規模、障害時の切り戻し手順も明示されていません。Tail-based Samplingの最終的な保持率や、運用後の調整頻度も未記載です。

高トラフィック環境では、可観測性の強化がそのまま運用コストと設計負荷に跳ね返ります。自社の基盤でどこまで計装し、どこを分離して守るべきかを整理したい場合は、構成の見直しから検討できます。

出典: CyberAgent Developers Blog