Japan Datadog User Group Meetup#21@東京に、「全リクエストのレイテンシを保存する方針の検討」というテーマで LT 登壇しました

こんにちは、CSIG (Cyber Security Innovation Group) 所属の市川です。普段は脆弱性管理サービスの FutureVuls の開発・運用を担当しており、最近はパフォーマンス改善のリーディングをしています。

2026年8月26日(水)に開催された Japan Datadog User Group Meetup#21@東京 で、5 分間の LT をしてきたので、発表内容を軽くまとめておこうと思います。前回の #14@福岡 に続いて 2 回目の登壇です。

発表内容

「全リクエストのレイテンシを保存する方針の検討」というテーマについて話しました。実際に導入した話ではなく、検討段階での共有及び相談という形で発表させていただきました。

やりたかったこと

「画面と API の両方を含む全リクエストのレイテンシを集計して、時間がかかっているリクエストについて分析をしたい」というのが出発点でした。この集計において、外せない要件が 2 つありました。

1. 複数のリクエストをまとめて 1 セッションとみなし、そのセッション全体の所要時間を計測したい
2. エンドポイントに付与されたパラメータ（例: page など）も一緒に取得して、フィルタ単位で集計したい

この 2 つを Datadog の中だけ (例: ダッシュボードでの集計や、Endpoint 機能を利用したエンドポイント単位のレイテンシ集計など) で完結させるのは困難と考えました。特に要件1については、一度どこかにレイテンシの情報を保存したうえで、それらをまとめる集計ロジックを自前で組み、CI やローカルなど別の場所で実行するのが現実的です。

集計ロジックを自前で組む前提で考えた場合、これらの要件を実現するためには、自前のロジックでレイテンシを集計する際に情報を引っ張ってこられるよう、フィルタ情報を含めてレイテンシを一旦すべて保存できる場所 が必要でした。

考えられる実現方法

Datadog に集約する前提で考えると、やり方は大きく 2 つあると思っています。

1. APM をフル活用する
2. Flex Logs に集約する

順番に説明します。

案① APM をフル活用する

保存については、次の 3 つを実施することで概ね全スパンを保持できます。

• ingestion rate と trace sample rate を 100% にする
• トップスパンの retention rate を 100% にする
• 保存したいパラメータの情報 (例: page など) を、トップスパンの attribute に加える

パラメータが URL のクエリストリングに含まれている場合は勝手にスパンに付与されます。リクエストボディに入ってくる場合はアプリケーションのコード内でタグを付与する必要がありますが、いずれにせよスパンにフィルタ情報を持たせること自体は可能です。

以下のように、集計と検索用の API が用意されているため、保存した情報は API を通じて引っ張ってくることが可能です。

# 集計用
curl -X POST "api.datadoghq.com/api/v2/spans/analytics/aggregate"
# 検索用
curl -X POST "api.datadoghq.com/api/v2/spans/events/search"

この案のメリットは、すでに APM を導入しているのであれば、その延長線上で始められる、ということです。

案② Flex Logs に集約する

2 つ目は、Flex Logs に構造化ログとして全件保存する方法です。

Flex Logs は、大量にあるが参照頻度は低いログ向けのティアで、今回のユースケースにもっとも合致するティアでした。詳しくは公式ブログをご覧ください。

補足: Standard Logs と Flex Logs の違いについて

Standard Logs はホットストレージで全機能が使える代わりに高価で、短期のトラブルシュート向けです。特に意識せずにログを保存した場合は、このティアに振り分けられます。

一方 Flex Logs は、コールド寄りのストレージとオンデマンド計算の組み合わせで、リアルタイム系の機能が使えない代わりに、安く長期保持でき、かつ高速な検索が可能です。

使い分けとしては、以下の画像のようなイメージです。

保存の手順は、Flex Logs を有効化し、Flex Logs 用の Index を作成したうえで、その Index に振り分けられる attribute をログに付与する、という流れです。

検索のエンドポイントは Standard Logs と共通で、filter.storage_tier に flex を指定すると Flex ティアを検索できます。aggregate と search の両方に対応しているので、ログ取得の流れは案①とまったく同じです。

# 集計用
curl -X POST "api.datadoghq.com/api/v2/logs/analytics/aggregate"
# 検索用
curl -X POST "api.datadoghq.com/api/v2/logs/events/search"

2 案の比較

2 案を並べると、こうなります。

一番の争点は保持期間だと思います。1 か月以上情報を残したいのであれば Flex Logs の方が適しています。逆に、保持期間が短くて良いのであれば、APM を使用する形でも大きな問題はないと思われます。他の項目についても、Flex Logs の方が若干優れてはいますが、どちらでも問題ない範疇かと思います。

個人的には、以下の 3 つの理由より Flex Logs の方が今回のユースケースに適していると考えています。

• APM への副作用や、それに付随して発生するコストについて考慮しなくてよい
• 「ログに集約させる」方が直感的で分かりやすい（あくまで主観ですが）
• 今回のユースケースにおいては、Flex Logs にするデメリットがあまりない

おわりに

自分以外の方の発表だと、ALB ログとトレースを繋げる方法や、Datadog Cloud Cost Management による Datadog 自身のコスト分析の話が、特に興味深かったです。自社でも必要になるタイミングが来る可能性もあると感じたため、必要になったら導入したいです。当日の発表内容一覧は、JDDUG のブログ記事 から確認できます。

懇親会では、同じくアプリケーションのパフォーマンス改善を推進されている方と、優先度付けの方法などについても議論でき、実りの多い時間となりました。運営の皆様、会場を提供いただいた Wantedly 様、参加者の皆様、ありがとうございました。

また機会があれば、実際に Flex Logs を導入した後の話や、全然別のパフォーマンスの話も出来ればと思います。