はじめに
こんにちは、エーピーコミュニケーションズ iTOC事業部 BzD部 0-WANの片桐です。
ZDX連載の第2回です。前回はWeb Probeを取り上げ、「アプリが応答しているか」を監視する方法を解説しました。
しかし実際の運用では、「応答が遅い」と分かったその先が問題です。ユーザーの自宅Wi-Fiが原因なのか、ISPなのか、ZscalerのService Edgeなのか、アプリケーション側なのか——Web Probeだけでは切り分けられません。
Cloud Path Probeは、ユーザーのデバイスからアプリケーションまでのネットワーク経路をホップ単位で可視化し、「どの区間で遅延やパケットロスが発生しているか」を特定する機能です。Web Probeと同様にZDX Standardライセンスから利用可能です。
前編の本記事では、Cloud Path Probeの仕組みと、ダッシュボード画面の読み方を解説します。
具体的な設定手順や、設定パラメータについては後編で取り上げます。
注意事項： 本記事は筆者個人の技術的な知見と検証に基づいた内容です。弊社の公式見解や性能保証を示すものではありません。正確な仕様や最新情報については、Zscaler公式ドキュメントをご確認ください。
1. Cloud Path Probeの仕組み
1-1. TTLインクリメントによるパスマッピング
Cloud Path Probeは、パケットのTTL（Time to Live）を段階的にインクリメントしながら送信することで経路をマッピングします。
ZCCがまずTTL=1のプローブパケットを送信すると、最初のルーターがTTLを0にデクリメントしてパケットを破棄し、「TTL expired」のエラーを返します。
ZCCはこの応答から1ホップ目の情報を記録します。同じTTL値でデフォルト5回プローブを繰り返して統計を取得したら、TTLを1つ増やして次のホップへ。これをアプリケーションに到達するまで繰り返します。
tracerouteと同じ原理ですが、各ホップで複数回プローブして統計を取るのがポイントです。
1回だけの計測では分からない「一時的な遅延なのか、恒常的な遅延なのか」を判断できます。
1-2. Adaptive Mode——プロトコルの自動選択
Cloud Path ProbeはICMP、TCP、UDPに対応しており、Zscalerが推奨するのはAdaptive Modeです。
Adaptive Modeでは、プローブを送信する際に3つのプロトコルを試行し、各ネットワーク区間で遅延とパケットロスが最も少ないプロトコルを自動選択します。
ネットワーク機器の設定やアンチウイルスソフトの有無によってはICMPをブロックするケースがありますが、Adaptive Modeなら自動的にTCPやUDPに切り替えて計測を継続できます。
なお、ZPA経由のプライベートアプリケーションではAdaptive Modeはサポートされません。
ZPA環境ではICMP、TCP、UDPのいずれかを明示的に指定する必要があります。
2. Cloud Pathダッシュボードの読み方
ここからが本記事のメインです。
「アプリが遅い」という報告を受けたとき、Cloud Pathダッシュボードのどこを見て、どう判断するかを順を追って解説します。
2-1. まずレイテンシのグラフで全体傾向を掴む
Cloud Pathダッシュボードを開くと、まずレイテンシの推移グラフが表示されます。
このグラフでは以下のようにセグメント別の遅延が色分けされています。
- End-to-End
- Client - Egress
- Egress - ZIA Public Service Edge
- ZIA PSE - Application
ここで見るべきは、どのセグメントの線が跳ねているかです。End-to-Endの遅延が増加しているとき、
どのセグメントの線がそれに連動しているかで、問題の区間を大まかに絞り込めます。
2-2. Hop Viewで問題のホップを特定する
レイテンシグラフで問題の時間帯を特定したら、その時刻のHop Viewを確認します。
Hop Viewは、経路をグラフィカルに表示するビューです。ユーザーのデバイスからアプリケーションまでの各ホップがアイコンで並び、ホップ間のレイテンシが数値で表示されます。
最も遅延が大きい区間はオレンジ色でハイライトされるため、ボトルネックが一目で分かります。
また、Z-Tunnel 1.0/2.0、GRE、IPSecなどのトンネル情報も可視化されます。Adaptive Mode使用時は、各区間で実際に選択されたプロトコル（例：「Protocol: ICMP」）も表示されるため、どのプロトコルで計測された結果なのかも把握できます。
各ホップにカーソルを合わせると、以下のような詳細情報が表示されます。
また、Differential Latencyを確認することで、「全体で100ms遅い」ではなく、「ISPとZscalerのどのホップで+60ms増えている」というレベルで特定できます。
2-3. Command Line Viewで数値を確認する
Hop Viewと同じデータを、テキストベースで確認できるのがCommand Line Viewです。
各ホップのIPアドレス、リージョン、ASN、パケットロス、レイテンシが一覧で表示されます。
画面一番右のStd Dev(Standard Deviation)は、文字通りレイテンシの標準偏差を示しています。
Command Line Viewのみに表示される数値で、レイテンシのばらつきがわかります。
この値が大きい場合、一時的なスパイクである可能性もあるので、トラブルシューティングの際にはぜひ有効活用いただければと思います。
普段からネットワーク機器をCLIで操作しているエンジニアにとっては、グラフィカルなHop Viewよりもこちらのほうが馴染みやすいかもしれません。
正確な数値を確認したいときや、サポートへスクリーンショットを送る際にも便利です。
2-4. 判断のフレームワーク
Cloud Pathを見るときの判断の流れを整理します。
デバイス → Gateway間で遅延が大きい場合：ユーザーのローカルネットワーク（自宅Wi-Fi、社内LAN等）に問題がある可能性が高いです。Device Healthダッシュボードと合わせてWi-Fi信号強度なども確認します。
Egress → ZIA PSE間で遅延が大きい場合：ISPの区間に問題がある可能性があります。同じ拠点の他のユーザーでも同様の傾向が出ていれば、ISP起因の可能性がさらに高まります。
ZDX Advanced Plusライセンスを利用されている方であれば、ISPの障害や以上を即座に確認できる方法があります。
詳しくは、以下の記事をご覧ください。
ZIA PSE → Application間で遅延が大きい場合：ZIA PSEからアプリケーションまでの区間、つまりアプリのホスティング先やCDNに問題がある可能性があります。他のアプリでは正常であれば、特定のアプリケーション固有の問題と判断できます。
3. ZIA / ZPAでの見え方の違い
Cloud Path Probeの結果は、通信経路によってセグメントの数が変わります。
ZIA経由の場合は「デバイス → Egress → ZIA PSE → アプリケーション」の3セグメントです。ISP区間とアプリ側の区間が分離されるため、切り分けがしやすい構成です。
ZPA経由の場合は「デバイス → Egress → ZPA PSE → Egress → App Connector → アプリケーション」と、ZPAトンネルを含むより多くのセグメントが表示されます。
App Connectorからアプリケーションまでの区間——つまり、通常はZPAトンネルの向こう側で見えにくいプライベートネットワーク内の遅延も把握できるのが特徴です。
4. まとめ
Cloud Path Probeは、「アプリが遅い」という漠然とした報告を、「ISPのこのホップで+60ms遅延している」というレベルの具体的な情報に変換する機能です。
読み方のポイントは3ステップです。
- レイテンシグラフでどのセグメントの線が跳ねているかを確認し、問題の区間を大まかに絞り込む
- Hop Viewでオレンジ色にハイライトされたホップを特定し、遅延の発生箇所を突き止める
- ホップの詳細から原因を特定する
この流れが身につくと、「とりあえずネットワークチームにエスカレーション」ではなく、最初から正しい担当先に問題を振り分けられるようになります。
次回の後編では、Web ProbeとCloud Path Probeを実際に設定する手順を、画面キャプチャを交えて解説します。
ここまでの前2回は「仕組み」と「読み方」の話でしたが、次回はいよいよ手を動かすフェーズです。
おわりに
私たち0-WANは、ゼロトラスト製品を中心とした、マルチベンダーでのご提案で、お客様の経営課題解決を支援しております。
「ゼロトラストってどうやるの？」「製品を導入したけれど使いこなせていない気がする」「ZDXを導入したいが、どこから手をつければいいか分からない」等々、どんな内容でも支援いたします。お気軽にご相談ください。
