この記事の要点
- APMの視界は自社アプリの内側で完結する
- 利用者の体験劣化の多くは持たない経路（ISP・SASE・クラウド内部）で起きる
- 観測点を経路側に分散させ、自分側か事業者側かを証拠付きで切り分ける
前回、製品を思想の地図として整理した。本稿では、その地図に載っていない領域を扱う。アプリの性能を中心に組まれた比較記事が、構造として落としてしまう視点、すなわち自分の管理下にない経路をどう観測するか、という問いだ。
APM中心の比較が完結してしまう範囲
アプリ性能の監視を出自とする製品は、自分のアプリやインフラの中をよく見せる。リクエストがどのサービスを通り、どこで時間を使ったかを追える。だが、なぜその視界が境界の内側で完結するのか。理由は、観測点をどこに置くかにある。APMは、観測の仕組みを自社アプリの内側に常駐させる。だから見えるのは、その内側だけになる。
構成図にすると、見落としの構造がはっきりする。利用者からアプリに届くまでの経路は、Wi-Fi、ISP、SASEやクラウドの内部という持たない網を通る。APMの観測点はそのいずれにも無い。だから、利用者が遅いと感じる原因がこの暗い区間にあっても、APMの画面には何も映らない。アプリの中だけを見て、すべて正常と表示されることすら起きる。
アプリ性能中心の比較は、この右端のアプリの中で完結している。現場でいちばん困る、持たない区間で起きる劣化に、構造として届かない。
Gartnerの別カテゴリ：Digital Experience Monitoring
この視界の差は、Gartnerの分類にも表れている。アプリやインフラを見る観測プラットフォームと、利用者から見た体験や持たない経路を見る領域は、別のカテゴリとして評価される。後者はDigital Experience Monitoringと呼ばれる。
| カテゴリ | 守備範囲 | 代表 |
|---|---|---|
| Observability Platforms | 自分のアプリ・インフラのテレメトリ | Datadog、Dynatrace ほか |
| Digital Experience Monitoring | 持たない経路を含む、利用者から見た体験 | Cisco ThousandEyes、Catchpoint |
アプリ性能中心の記事は、前者のカテゴリの中だけで完結し、後者へ渡らない。だからSASEのような持たない経路の問題は、観測ツールの比較から構造として抜け落ちる。カテゴリが分かれていること自体が、見落としの原因になっている。
持たない経路の可視化 — 観測点を全区間に分散する
持たない区間は、自分のサーバにエージェントを入れて見るわけにはいかない。そこで発想を変える。観測点をアプリの内側に置くのではなく、経路の全区間に分散して配置する。
利用者の端末側に置いた観測点から宛先までを測り、加えて世界各地に分散した観測点から各区間の遅延や損失をホップ単位でたどる。経路情報と相関させ、どの区間で何が起きているかを示す。最初の構成図で暗かった区間に、観測点が入る。これにより、利用者が遅いと感じたとき、その劣化がどの区間で起きているかを切り分けられる。自分の区間なら手を打つ。持たない区間なら、証拠を添えて事業者にエスカレーションする。
自分側か事業者側かを切り分ける
この切り分けは、技術だけでなく関係者の調整にも効く。障害が起きると、ネットワークのせいにされることもあれば、アプリのせいにされることもあり、責任の押し付け合いになりやすい。
| 切り分けが無いとき | 切り分けがあるとき |
|---|---|
| どこが原因か分からず人手で総当たり | 劣化した区間を即座に特定 |
| 責任の押し付け合いになる | 事実に基づき担当を割り当てられる |
| 自分の管轄外でも疑われ続ける | 持たない区間だと証拠付きで示せる |
経路を区間ごとに可視化できれば、劣化はこの区間で、ここは事業者側だ、と証拠付きで示せる。全部チェックしろという要求に網羅で応えるのではなく、起きた事象がどこにあるかを即座に指し示す。これが、前提が崩れた後のプロの応答になる。
ネットワークとアプリの相関
最も効くのは、この経路の観測と、アプリの観測を相関させたときだ。利用者の体験、その背後のアプリの内部、それらをつなぐ持つ網と持たない網。三つを一つの文脈で見られると、どこで問題が起きても精度の高い切り分けができる。近年は、経路を測る製品とアプリを観測する製品の統合も進んでいる。アプリ性能中心の比較の外に、もう一つの軸があることを知っておくと、選定の視野が変わる。
まとめ
アプリ性能中心の比較は、自分の境界の内側で完結する。だが現場でいちばん困るのは、持たない経路で起きる劣化だ。これはGartnerでも別カテゴリとして扱われ、観測プラットフォームの比較からは抜け落ちる。両方の軸をまたいで、自分の現場の問いに答えるのはどの領域か、と考える。それが既存の比較が踏まない橋になる。総論はo11y（オブザーバビリティ）とは何か、最近のAIの動きはAIエージェント時代のオブザーバビリティで扱う。
よくある質問
APMを入れているのに利用者の「遅い」が見えないのはなぜですか
APMの観測点が自社アプリの内側にあるためです。利用者からアプリまでのWi-Fi・ISP・SASE・クラウド内部という持たない経路には観測点がなく、そこで起きる劣化は画面に映りません。
自分の管理下にない経路はどう観測しますか
観測点を経路の全区間に分散配置し、端末側から宛先までをホップ単位で測って経路情報と相関させます。この領域はDigital Experience Monitoringと呼ばれ、Cisco ThousandEyesやCatchpointが代表です。
経路の切り分けは何の役に立ちますか
劣化が自分の区間か事業者の区間かを証拠付きで示せます。責任の押し付け合いを避け、事業者へのエスカレーションが事実ベースになります。
