この記事は アソビュー！ Advent Calendar 2025の14日目（表面）です。
はじめに
こんにちは、アソビューのバックエンド、佐藤です。
白湯が沁みる季節ですね。
当社のアソビューのサービスでは、ユーザーの利便性向上のため複数の決済手段を提供しており、それに応じてバックエンドの決済処理ロジックも複雑化しています。
今回、特定の決済手段を用いた場合の処理時間にボトルネックが存在しないかを詳細に分析し、ユーザー体験を損なわないよう改善を行う必要がありました。
特に、エンドポイントが共通しているため、標準的なAPMのメトリクスだけでは決済方法ごとのパフォーマンスの違いを把握できず、迅速な対応が困難な状況でした。
Datadogを活用した計測への試行錯誤
以下にDatadog初心者の私が試したことを紹介します。 何もわからないところからのスタートなので、やさしい気持ちで見ていただけると助かります。
Datadogの基本的な用語は以下で確認できますのであわせて確認してみてください。 https://docs.datadoghq.com/ja/tracing/glossary/
ひとつのエンドポイントを決済方法ごとに分ける方法として、リソースを分ける、タグをつけるの2つの案がすぐメンバーからでました。 ただリソースを分けてしまうと実務においてTraceの追跡がしづらいのでは？という懸念があったため、まずはタグ設定でできないかどうかから検証していきました。
1.カスタムタグを設定する
カスタムタグを設定してフィルタリングすれば、決済方法ごとに計測できるのでは？というところからスタートしました。 タグでのフィルタリングであればリソースを分ける必要もないと考えました。
ここではアプリケーションでタグをセットするようにして、画像のようにSpanにタグを設定しました。
そしてこのタグを使ってメトリクスをフィルタリングをすればOK！と思っていたのですが、いざMetrics Explorerの画面でフィルタリングしようとしたのですがなぜかNo suggestionsとなりました...。
改めてドキュメントを読み直してみると トレースメトリクスにはカスタムタグを使えないことがしっかりと記載されていました...。
Trace metrics tags, possible tags are: env, service, version, resource, http.status_code, http.status_class, and Datadog Agent tags (including the host and second primary tag). Note: Other tags set on spans are not available as tags on traces metrics.
トレースメトリクスの情報はDatadog Agentで集計・生成しているようで、どうやらカスタムタグは使うことができないとのことでした。
->この方法は不採用。
2.Spanを元にカスタムのメトリクスをつくる
次にドキュメントを読んでいるとSpanからメトリクスを生成する方法を見つけました。
これを使えば、設定したタグを使ってフィルタリングできるのではと思い試してみました。 アプリケーションでタグを設定することで、画像のように決済方法でフィルタリングしてメトリクスを作成することができそうです。
この方法もタグを使っているためリソースを増やすことなくいけそうではあったものの、データを確認していたところどうもデータが少ないことに気づきました。
これは私の知識不足なことが原因だったのですが、そもそもSpanデータはサンプリングされているため正確なデータではないようです。
以下のDatadogドキュメント記載の図がわかりやすいのですが、Spanからメトリクスを作る場合はサンプリングされたデータをもとにつくっているようです。
タグを使ってフィルタリングできるのはよいのですが、サンプリングされた正確なデータではないためこちらの方法は見送ることになりました。
->この方法は不採用。
3.リソース名を書き換える
この方法はトレースメトリクスを利用します。
当初からこの方法はうまくいくと予想はしていましたが、リソースを分割することでTraceの追跡が面倒になるのでは？という懸念がありました。
トレースメトリクスの特徴は以下です。
Spanからメトリクスをつくるのとは違い正確なデータに基づいて計測できそうです。
トレース取り込みサンプリングの構成に関係なく、アプリケーションのトラフィックの 100% に基づいて計算されます。
インスツルメンテーションされたアプリケーションから Agent に送信されたトレースに基づいて、Datadog Agent で計算されます。
ドキュメントの画像がわかりやすいので引用させていただきますが、アプリケーションから送られたデータをサンプリングすることなくメトリクスを生成しています。前述の「2.Spanを元にカスタムのメトリクスをつくる」の項の画像と比較してみてください。このトレースメトリクスはIngestion Sampling rulesが適用されていません。
こちらは冒頭にも書いた通りまず最初に思いついた案で、問題なく分けることができました。以下の画像のように決済方法ごとにリソースを分けました。
リクエスト数やLatencyを決済方法ごとに確認することができます。
リソース画面がそれぞれ分かれてしまうことでTraceを追跡するのが面倒になるのでは？という懸念に対しては、タグを設定することで対応してみました。
具体的には画像のようにオリジナルのエンドポイント名をタグとして設定しました。Traceはカスタムタグを使ってフィルタリングをすることが可能です。これで以前と変わらずに単一のエンドポイントのようにTraceを確認することができました。
->この方法を採用。
まとめ
結論：リソース名を書き換えることで決済手段ごとの処理時間を正確に計測できます。
検証の結果、以下の理由から「3. リソース名を書き換える」方式を採用し、課題を解決しました。
| 試行した方法 | メリット | デメリット |
|---|---|---|
| 1. カスタムタグを設定する | ー | Trace metrics にはカスタムタグが使えない |
| 2. Spanを元にカスタムのメトリクスをつくる | カスタムタグでフィルタリング可能 | Spanデータはサンプリングされているため、正確性に欠ける |
| 3. リソース名を書き換える | トレースメトリクスとして100%のトラフィックに基づき計測可能 | リソースが増えるため、Traceの追跡時に工夫が必要。 ※オリジナルのエンドポイントをタグとして設定することでTraceをまとめて検索できるように対応した。 |
Datadog計測の学び
今回の試行錯誤から、DatadogのAPMにおける重要な学びを得られました。
- Trace Metricsの正確性: エンドポイント全体のパフォーマンスを正確に把握し、ボトルネックを特定するためには、サンプリングの影響を受けないトレースメトリクス（Datadog Agentで計算されるメトリクス）を利用すべきである。
- Span Metricsの用途: Spanからカスタムメトリクスを作成する機能は、詳細な内訳の傾向把握や、サンプリングを許容できる特定ロジックの実行回数計測などに適しているが、厳密なパフォーマンス計測には不向きである。
- タグとリソースの使い分け: Datadogにおいて、メトリクスとして利用したいディメンション（今回で言えば決済手段）は、Trace Metrics Tagsとして利用可能なリソース名などとして設定する必要がある。単なるカスタムタグはSpanの詳細情報追跡に役立つが、Trace Metricsのフィルタリングには利用できない。
今回の改善により、決済手段ごとのパフォーマンスボトルネックを明確に可視化することが可能になり、ユーザー体験を損なう要因の迅速な特定と改善に取り組める状態になりました。
Datadogに詳しい人にとっては当たり前な話だったかもしれませんが、実際に検証することで私自身理解も深まりました。
現在アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています！
ご興味がありましたら、ぜひご気軽にご応募ください！
