え、APM と分散トレースは同じじゃないですよ？

## はじめに
こんにちは、Datadog Japan で Sales Engineer をしている [**AoTo**](https://qiita.com/AoTo0330) です。

この投稿は **[<font color="#6495ED">AoTo Advent Calendar 2024</font>](https://qiita.com/advent-calendar/2024/aoto) 14日目**の記事です。

みなさんは **Application Performance Management/Monitoring(APM)** と聞いて何を思い浮かべますか？「はいはい、**分散トレース**のことね」と思われた方、素直に手をあげてください🤟

残念ながら、APM=分散トレースではありません。本ブログではこれらの言葉の定義からその関係性を解説します。

## 結論から
 - **Application Performance Management/Monitoring(APM)** は**分散トレース**の技術が生まれる前から存在する包括的なアプリケーション監視の概念
     - **分散トレース**は **APM** を**実現する手法の一つ**
     - **分散トレース**以外にも**シングルトレース**・**データベースパフォーマンス監視**・**合成監視**・**アプリケーションログ監視**などが **APM** の監視手法として当てはまる
     - つまり、**APM** はマイクロサービスではないアプリケーションにも親和性のあるソリューション
 - **Management/Monitoring** のどちらとなるかは**ベンダーによって異なる**が、どちらも概ね同じものを指す
     - IT 用語の標準化に影響力のある Gartner 社は、[Magic Quadrant](https://www.gartner.com/en/documents/4500499) などで **APM = Application Performance Monitoring** を採用している
     - 従来から APM ソリューションを提供しているベンダーは **APM = Application Performance Management** を採用していることが多い
 - 近年は**分散トレース**が **APM** を代表する監視手法で、「分散トレース=APM」として説明されることがある
     - そしてそのように誤解して説明をしてしまうことも多い

## そもそもなんだっけ
ではここからは、それぞれの言葉の定義を探っていきましょう。

[**Datadog Knowledge Center**](https://www.datadoghq.com/knowledge-center/) はサービスやソリューションに関わらない一般的な知見・用語・概念の解説をしている Datadog の公式リソースです。今回はこちらから説明を引用します。

### Application Performance Management/Monitoring(APM)
APM とは「組織がアプリケーションの可用性を確保し、顧客の期待に応え得ることを可能にするツールとプロセスの集合」です。つまり、エンドユーザーが存在するアプリケーションの可用性を可視化し原因分析ができれば、その手法は問いません。

https://www.datadoghq.com/knowledge-center/application-performance-management/

これらの概念は1990年代後半から2000年代にかけて醸成されました。このアプローチはそれぞれソリューション毎に異なりましたが、目的は当時から現在まで概ね同じものです。

2011年には Gartner 社から「[Gartner's 5 Dimensions of APM](https://www.apmdigest.com/gartners-5-dimensions-of-apm)」が提唱されました。[^1]
[^1]: Gartner は「[Analytics vs. APM](https://www.apmdigest.com/gartner-analytics-vs-application-performance-management-1)」「[Monitoring vs. Management](https://www.apmdigest.com/apm-convergence-monitoring-vs-management)」で APM の解説がされています。

この内容を翻訳しまとめると、以下の5つの側面があるとされています
 - エンドユーザーエクスペリエンス(UX)監視
 - インフラストラクチャの検出・モデリング・表示
 - ユーザー定義トランザクションのプロファイリング
 - アプリケーション要素の詳細分析
 - 分析

当時はこれらの側面は単一の監視手法によって賄えるものではなく、複数の監視手法や製品を導入する可能性が示唆されています。これは現在もそれほど変わっていませんが、導入コストを下げることで複数の監視手法を導入できるような工夫がされています。

近年はこれらの監視手法として、**分散トレース・サービスインベントリ・コードプロファイリング・エラートラッキング・データベース監視・デジタルエクスペリエンスモニタリング(DEM)** などが多く採用されています。

### 分散トレース(Distributed Tracing/Trace)
分散トレースとは「フロントエンドデバイスからバックエンドサービスやデータベースに流れるアプリケーションリクエストを追跡する方法」です。エンドツーエンドでアプリケーションのリクエストを介して、パフォーマンス・状態の追跡を行う監視手法です。

https://www.datadoghq.com/knowledge-center/distributed-tracing/

分散トレースは、個々のアプリケーション処理を追跡する必要があるため、アプリケーションに監視用のモジュールを実装する必要があります。この実装は、アプリケーション言語によって方法が異なりますが、大きく分けるとアプリケーションコードへ実装を追記する手動計装と、言語の仕様を活用してコードの変更を行わずに実装する自動計装があります。

この計装の他にも、転送・分析と可視化の手法それぞれが必要となります。何故なら計装されたアプリケーションがやりとりする別のアプリケーションやデータベース、クライアントデバイスで取得された監視データと紐づけて可視化・分析することが前提となるためです。

![Distributed_Tracing_Component.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/70c7bc6d-4fb4-616d-8770-ea52635555ca.png)

## APM 支える監視手法
分散トレースとそのほかの APM を支える監視手法も確認しておきましょう。

### 分散トレース
前述の通り、分散トレースはアプリケーションリクエストを追跡する監視手法です。アプリケーションに対する計装を経て、トレースデータ(スパンデータ)は転送され監視基盤で可視化されます。

分散トレースで重要なのは、分散システム(マイクロサービス)のサービス間のリクエストを繋げることです。トレースコンテキストを HTTP ヘッダーに挿入することで HTTP/REST API でやり取りをするサービス間で一意の識別子を共有し、可視化時点でこれらを繋げることができます。

トレースデータは専用のグラフ・ビューで可視化されます。
Datadog ではフレームグラフがメインのビューとして採用されていますが、その他にもウォーターフォールグラフやトレースマップなどが一般的です。

『[分散トレースを理解する！Trace Context 解体新書](https://speakerdeck.com/aoto/understanding-distributed-tracing-trace-context-tabul-anatomic)』でも説明をしているので、是非ご覧ください。

https://speakerdeck.com/aoto/understanding-distributed-tracing-trace-context-tabul-anatomic?slide=14

### データベース監視
分散トレースが確立される前の主要なアプリケーションパフォーマンスの測定方法の一つに、データベース監視があります。特にデータベース監視は、RDBMS が記録する監視情報を参照し、クエリをはじめとする DB オペレーションのパフォーマンスを監視します。

これらの監視は RDBMS に依存し、MySQL の Performance Schema, PostgreSQL の `pg_stat_statements` などの情報を参照します。これらに加え、標準化されたクエリとその実行計画を収集することで、操作構文の構造を確認しながら DB 内部のアクセス・計算方法が想定の通り実行されているかを確認し、パフォーマンスチューニングを実現できます。

### 合成監視(Synthetic Monitoring)
合成監視は内部への実装を必要としない、一貫性のあるサンドボックス環境から自動化ツールを使用して、ページの性能をモニタリングする監視手法です。合成監視は実際のユーザーが体験したパフォーマンスデータを取得するのではなく、無作為にスケジューリング実行された環境から得られた合成データによってパフォーマンスを測定します。

この監視手法は、ユーザーの体験をそのまま取得する手法が確立されたものです。対象の環境に依存せず、ブラックボックス方式でテストした内容に対する出力(レスポンス)のみでパフォーマンスを評価します。そのため、アプリケーションパフォーマンスを監視する最も単純な方法でありながら、環境に依存せず測定できる有用な方法です。

分散トレースやデータベース監視で監視対象とできていない、ネットワークをはじめとするその他の要素を含むアプリケーションパフォーマンスを測定できるため、実働環境で有効な監視手法として現在も頻繁に活用されています。

### リアルユーザー監視(Real User Monitoring, RUM)
リアルユーザー監視は、フロントエンド・クライアントデバイス上で動作する SDK により、実際のユーザーの体験した様々な情報を取得する監視手法です。合成監視とは異なり、実際のユーザーの動作を記録するため、フロントエンドへの組み込みと多少のオーバーヘッドを考慮する必要があります。

一方で、ユーザーの体験したアプリケーションのパフォーマンスだけではなく、ユーザーの動向分析にも活用できる点が大きな特徴です。システム・アプリケーション監視以外に、ビジネス分析の文脈で活用されることも多く、多くのステークホルダーを抱える to C サービスに相性が良い監視手法です。

## おわりに
混同されがちな APM と分散トレース、皆さんも違いを理解いただけましたか？

Datadog でも、APM(Application Performance Monitoring) に分散トレースや Database Monitoring(データベース監視) をはじめとする様々なソリューションが内包されています。

一方で合成監視やリアルユーザー監視を分類する概念として、デジタルエクスペリエンス監視(Digital Experiance Monitoring)というカテゴリも登場しています。
標準化の要因としても挙げた Gartner でも、2024年より [Digital Experience Monitoring 領域の Magic Quadrant](https://www.gartner.com/en/documents/5855079) を発表しています。

このように、アプリケーションのパフォーマンスを監視する手法は様々で、目的によって必要なソリューションは異なります。監視対象のシステム・アプリケーションが何に困っていて、どういったものが必要かを整理して最適な APM ソリューションを利用しましょう🐶