徹底比較:「分散トレーシングはAPMの主要機能」という勘違いはなぜ生まれる?実はそれぞれ異なるレベル、異なるアプローチで機能する

TechTargetは2025年3月18日、「アプリケーションパフォーマンス監視と分散トレーシングの違い」に関する記事を公開した。アプリケーションパフォーマンス監視と分散トレーシングはそれぞれ異なるが、互いに補完する形で、パフォーマンス問題を特定するのに役立つ。

» 2025年05月02日 08時00分 公開
[Donald FarmerTechTarget]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 TechTargetは2025年3月18日(米国時間)、「アプリケーションパフォーマンス監視と分散トレーシングの違い」に関する記事を公開した。

画像 APMと分散トレーシングの違い(TechTarget)

 オンラインストアで商品を選び、カートに入れ、配送先や支払い情報を入力した後、延々と待たされた揚げ句に取引が失敗する。こうしたことは誰もが一度は経験したことがあるだろう。こうしたパフォーマンス問題のトラブルシューティングは、オンラインストアやその他のアプリケーションを支える運用システムの技術チームにとっても、同様に困難な作業だ。

 今日の多くのシステムは、複数のマイクロサービスが相互に接続された複雑なネットワークを形成している。こうしたアーキテクチャにおいては、アプリケーションのパフォーマンスに影響を及ぼす問題や、取引の完了を妨げる問題のデバッグは特に難しい。こうした問題を運用チームや開発チームがスムーズに把握、修正するための技術的手法がアプリケーションパフォーマンス監視(APM)と分散トレーシングだ。

 APMと分散トレーシングは、それぞれ異なるレベル、異なるアプローチで機能する。本稿では、その違いを詳しく解説し、両者をどのように併用できるかについても紹介する。

APMと分散トレーシングの主な違い

 APMは、アプリケーション全体のパフォーマンスを俯瞰(ふかん)する手法で、ビジネスサービスの状態監視に使われることもある。例えば、Webサイトでの顧客体験(画像の表示速度など)が通常より遅くなっていないかどうか、アプリケーションが停止して収益に悪影響を与えていないかどうか、といった疑問に答える役割を果たす。

 分散トレーシングを使えば、アプリケーション開発者は、個々のユーザーリクエストや顧客取引が複数のマイクロサービスやシステムを通過する様子を詳細に追跡できる。各ステップは記録されているため、運用チームや開発チームは、アプリケーション障害やボトルネックが発生している正確な箇所を特定できる。

 APMと分散トレーシングの最も重要な違いは、APMが単一アプリケーション(サービス)内のパフォーマンスを監視するのに対し、分散トレーシングは異なるアプリケーション間を跨いでユーザーリクエストやアプリケーション間通信を追跡する点にある。この基本的な違いから、他のさまざまな相違点も生じている。両者の違いを明確にするため、それぞれの手法を詳しく見ていこう。

画像,APMと分散トレーシングの比較図

APMの仕組み

 APMは、主に単一アプリケーションのさまざまな部分からメトリクス(指標)やアクティビティー記録を収集する。このデータには、応答時間(レスポンスタイム)、エラー件数、リソース使用量などが含まれる。収集されたデータは集約、分析され、ダッシュボードに表示される。ダッシュボードでは、アプリケーションのリアルタイムパフォーマンス状態に加え、傾向分析のための過去データも表示される。

 先に触れたオンラインショッピング取引失敗の例では、APMによる計測(インストルメンテーション)は次のように機能する。

1.フロントエンドUX(ユーザーエクスペリエンス)監視

 ユーザーの製品選択からチェックアウトまでの操作を記録し、ページ読み込み時間の測定や、支払い処理中にUI(ユーザーインタフェース)がフリーズするタイミングの特定を行う。

2.バックエンドサービス監視

 「金融取引を処理するサーバへの接続に時間がかかっているため、支払い処理サービスがタイムアウトしている」といった状況を明らかにする。

3.データベース監視

 「データベースにおけるトランザクション競合防止のためのロックが、在庫更新処理をブロックしている」といったことを判別する。

4.アプリケーションの信頼性に関するエラーの追跡

 「サードパーティーの決済ゲートウェイがエラーコードを返してプロセスを停止している」といったことを特定する。

 これらの監視結果を参考に、アプリケーション開発者はアプリケーションのパフォーマンス低下の根本原因を特定し、業務への影響に応じて優先順位を付けて修正に取り組むことができる。

 他にも、APMツールの多くは次のような機能を提供する。

  • リアルタイムパフォーマンスデータに基づく「カスタマイズ可能なアラート機能」
  • アプリケーション動作とITインフラの指標(ネットワークパフォーマンスなど)との「相関分析機能」
  • アプリケーションパフォーマンス問題が組織の顧客に与える影響を評価する「ビジネストランザクション監視機能」

分散トレーシングの仕組み

 分散トレーシングは、ユーザーリクエストが分散システム内をどのように移動するかを追跡する手法だ。ユーザーリクエストには、データの取得、レコードの更新、関数の実行メッセージなどが含まれる。この複雑な経路の記録を「トレース」と呼ぶ。1つのリクエストが複数のマイクロサービス間をどのように移動したかを構造的に可視化し、レイテンシ(遅延)、依存関係、障害発生箇所などを示す。

 分散トレーシングツールは各トレースを「スパン」という単位に分割する。スパンは、サービス間で発生する個々の作業単位だ。それぞれのスパンは開始と終了の時刻に加え、エラー情報や使用されたマイクロサービスに関するメタデータを記録する。同じトレースIDを持つ全てのスパンは結合され、リクエストが分散システム内を通過した完全な経路を再構成できる。

 分散トレーシングプロセスの例として、金融サービスのWebアプリケーションにユーザーがログインし、自分のダッシュボードを表示するリクエストを送信したケースを考えてみよう。要求がマイクロサービス間を移動する方法は、次のようなワークフローでトレースされる。

  • APIゲートウェイで「ルートスパン」(root span)リクエストが始まる
  • リクエストがユーザー認証を処理するマイクロサービスに転送される(子スパン1)
  • 別のマイクロサービスが顧客データベースに最近の取引情報を問い合わせる(子スパン2)
  • 株式市場指標の最新データを取得するために、3つ目のマイクロサービスが外部サービスのAPIを呼び出す(子スパン3)

 トレーシングツールは、アプリケーション全体のユーザーに関わる類似トレースの結果を相関させ、開発チーム向けにデータを可視化する。例えば、収集したタイムスタンプデータを基に、各スパンの平均応答時間を表示したり、潜在的なパフォーマンス問題を抱えるスパンをハイライト表示したりする。この例はトレースとして単純なものだ。実際のアプリケーションでは多くのスパンが関係する可能性がある。

画像 分散トレーシングは、ユーザーリクエストがシステム内を移動する際のパフォーマンスを追跡する手法であり、個々の作業単位を表す「スパン」の連なりとして記録する

APMと分散トレーシングの対象範囲と主なユースケースの違い

 APMは、アプリケーション全体のパフォーマンスと健全性を長期的に監視するのに最適な手法だ。多くのユーザーに影響を与える広範な問題を検出するのに適している。例えば、APMは、アプリケーション全体の動作を遅くするメモリリークを特定したり、エラー率の増加を分析して問題の所在を絞り込んだりするのに役立つ。また、単一アプリケーション内でソースコードやデータベースクエリを最適化し、パフォーマンスを向上させたい場合にも、APMは最適なツールだ。

 分散トレーシングは、その名の通り、分散システムにおけるパフォーマンス問題の原因究明において特に有効だ。例えば、クラウドネイティブアーキテクチャにおけるマイクロサービス環境は、1件のユーザーリクエストが複数のサービス間で数十回もの呼び出しを引き起こすことがある。このようなシナリオでは、パフォーマンスボトルネックや障害箇所をデバッグするのに分散トレーシングが優れた効果を発揮する。

APMと分散トレーシングは併用可能か

 APMと分散トレーシングは異なる特徴を持つものの、包括的なパフォーマンス監視戦略においては併用されることが多い。これら2つの技術は次第に統合されつつあるのが実情だ。多くのAPMプラットフォームは、分散トレーシング機能を取り込み、複数サービス間のトランザクションに関するインサイト(洞察)を提供できるようになっている。こうした統合型のサービスで、分散トレーシングはAPMの構成要素のような役割を果たす。同様に、一部の分散トレーシングツールも、APMに似たダッシュボード機能を提供するようになっている。

 従って、APMと分散トレーシングは補完関係にあり、併用できる。APMはアプリケーション全体のパフォーマンスを俯瞰的に把握するトップダウンの視点を提供し、分散トレーシングは特定のトランザクションやユーザーリクエストが複数サービスをどのように通過するかを詳細に把握するボトムアップの視点を提供する。

 APMと分散トレーシングを併用することで、次のような疑問の答えを見つけることができる。

  • 顧客がオンライン決済の遅延や取引の失敗を経験している場合、アプリケーション内の多数の接続サービスのうち、どれが遅延の原因となっているのか
  • パフォーマンス問題は全ての顧客か、それとも特定の顧客セグメントか
  • アプリケーションのパフォーマンス向上のため、どのマイクロサービスを優先的に開発、更新すべきか

 多くの開発チームでは、まずAPMでパフォーマンスを分析し、その後、分散トレーシングを使用して原因を掘り下げるというワークフローが採用されている。APMツールによって、レイテンシやエラー率といったアプリケーションパフォーマンスの主要指標を監視し、異常があればアラートを出す。問題の通知を受けた開発者は、分散トレーシングデータを活用してその原因を調査する。例えば、APMダッシュボードが午後3時にページロード時間の急上昇を示した場合、開発者はその時刻のトレースデータを参照し、ユーザーリクエストの経路を確認して、動作が遅かったサービスやAPI呼び出しを特定する。

 この作業は、詳細なトレーシングをサポートするAPMツールであれば、そのツール内で完結する。そうでなければ、スタンドアロンの分散トレーシングツールを利用する必要がある。かつては別々のツールを使い、結果を手動で突き合わせなければならなかったが、現在のツールはよりシームレスに統合されている。ただし、基本的なパターンは変わらず、APMは「問題が起きていること」を知らせ、分散トレーシングは「どこで、なぜ起きているか」を明らかにする役割を果たす。

APMと分散トレーシングによる“可観測性”サポート

 「オブザーバビリティ」(可観測性)は、従来の監視の枠を超え、パフォーマンスとステータスを統合的に分析する、より広範なITプラクティスとして近年注目を集めている。オブザーバビリティは、あらかじめ定義されたダッシュボードの使用に頼るのではなく、探索的な分析を重視する。これによって、運用チームや開発チームはシステムに関して新たな問いを立てたり、パフォーマンス監視プロセスの設計段階では想定していなかった予期しない挙動を調査したりできるようになる。

 APMと分散トレーシングは、いずれもオブザーバビリティ施策に活用できる。収集される指標とトレースは、ログと併せて「オブザーバビリティの三本柱」とされている。オブザーバビリティのプラクティスでは、これら3つ全てを組み合わせて活用することが推奨されている。最新のオブザーバビリティプラットフォームでは、指標、トレース、ログを自動的に相関させ、開発者がパフォーマンス問題の根本原因にたどり着きやすいようにしている。

 ただし、オブザーバビリティは単なるインシデント対応のためのものではない。システムの信頼性とパフォーマンスを継続的に向上させるためにも役立つ。APMと分散トレーシングを組み合わせることで、実効性のある洞察をもたらすオブザーバビリティのフィードバックループが形成される。これによって、運用チームや開発チームは問題をより迅速に検出し、ユーザーに影響が及ぶ前に解決する必要がある。その結果、システムの稼働時間が向上し、ユーザーの満足度が上がる。

 APMと分散トレーシングそれぞれの特性を取り入れた強力なオブザーバビリティ戦略は、ITシステムの高い信頼性を実現する(つまり、決済ボタンをクリックしたときに取引が失敗し、顧客がイライラする可能性も下がる)と言える。

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

4AI by @IT - AIを作り、動かし、守り、生かす
Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。