今回やりたいこと
特定画面のレスポンスの悪さに関する問合せが多く、
品質向上の１つとして、潜在化している遅延処理を洗い出してほしいと依頼がありました。
なので今回はDatadogを使って該当箇所を探す取組みについて
自分はインフラ担当では無いので、調べながらこの記事を書くことにしました。
Datadogとは
インフラ監視、アプリケーションのモニタリング、ログ管理などによって
システム運用のトラブル調査、最適化するためのサービスのこと
遅い処理を判断する機能があるか
Datadogの公式Doc「遅いトレースやエンドポイントを調査する」
本番環境においてアプリケーションのパフォーマンスに問題がある場合、 分散型トレーシングとプロファイリングによるコードスタックトレースのベンチマークを統合することで、 パフォーマンスのボトルネックを特定する強力な方法となります。 APM分散型トレーシングと Continuous Profiler の両方が有効になっているアプリケーションプロセスは、 自動的にリンクされます。
claudeに解説してもらう
分散型トレーシング：アプリケーション内のリクエストの流れを追跡します。
プロファイリング：コードの各部分の実行時間を測定します。
これらを組み合わせると、パフォーマンスの問題がどこにあるかを正確に特定できます。
Datadogでは、APM（アプリケーションパフォーマンスモニタリング）の分散型トレーシングと
Continuous Profilerを有効にすると、自動的にこれらのデータがリンクされます。この方法を使うことで、開発者はアプリケーションの遅い部分を素早く見つけ出し、
効率的に改善できるようになります。
要するに、
リクエストの流れの追跡と、実行時間の計測を、
DatadogのAPM分散型トレーシングと、Continuous Profilerを有効にすることで可視化できて
遅い処理を判断できるんだと思います（理解度30%）
実際にやってみる
APMのトレーシング？は既にAPM→Tracesから見れるようでした
（設定方法調べに来た人居たら申し訳ない…）
対象はAPIとSQL、外部API連携箇所
Durationを見ると１時間でかなりの数がありました。
claudeにリスト化を依頼
API名が、80万件あるテーブル名を含んでいるものが多いので、
ここで挙げたAPIの中で、該当テーブルを参照するSQLのチューニングをやるべきだと考えました。
DB側での対応は難易度高いので一旦無し…（自分の技術力の低さ😇）
SQLでも同じく、時間の掛かっているものを一覧化します。
SQLはループで実行時間が遅くなる可能性もあるので、duration１秒以上を対象にします。
まとめ
APIとSQLともに同じようなものが遅くなっている様子です。
なので、今回はデータが非常に多いテーブルに対しての操作が時間掛かっていると想定して
該当API、該当SQLの調査・修正に入りたいと思います。
SQLチューニングであまり変わらない場合は、
画面側のデータの取得方法を変えたりなど検討します。
ちなみに、「Continuous Profilerを有効にする」について、有効になっていなかったのですが
トレーシングで、ある程度洗い出しできたので今回はやりませんでした。
