ThousandEyes を導入する前に整理しておきたいこと – エージェント、テスト、コスト体系

エージェントの観測地点、テストの構造、コスト体系

クラウドサービスや SaaS の利用が増えると、利用者とサービスの間には、自社で直接管理できないネットワークが多く含まれるようになります。利用者から「遅い」「つながらない」と申告されても、原因が社内 LAN、WAN、ISP、DNS、クラウド事業者、SaaS のどこにあるのかは、手元のネットワーク機器やサーバーの死活監視だけでは分かりません。ネットワーク機器やサーバーが正常であっても、利用者がサービスを正常に使えるとは限らないためです。

ThousandEyes は、このような通信経路へテストトラフィックを送信し、サービスの到達性、応答時間、パケットロス、経路などを継続的に観測する製品です。ただし、導入を検討し始めると、Cloud Agent、Enterprise Agent、Endpoint Agent の違い、エージェントの配置、HTTP 監視とページロード監視の違い、BGP 監視の扱い、コストが増える要因など、単なる製品機能一覧では片付けにくい論点が出てきます。

これらは個別の製品仕様に見えますが、実際にはすべて、何を、どこから、どの粒度で観測するかという設計上の問題につながっています。最初に監視対象だけを決めるのではなく、観測地点、テスト種別、障害範囲、コスト軸を分けて整理しておくと、導入後に「見たい障害が見えない」「必要以上にテストを増やしてしまう」といったずれを減らせます。

設計軸	決めること	間違えやすい点
観測地点	Cloud Agent、Enterprise Agent、Endpoint Agent のどこから測るか	監視対象だけを決め、どこから測るかを後回しにする
テスト種別	HTTP Server、Page Load、Transaction、Network、DNS などをどう使い分けるか	URL が応答することと、利用者が業務操作を完了できることを混同する
障害範囲	拠点、ISP、VPN、端末、SaaS 側のどこまで切り分けたいか	Enterprise Agent 1 台で組織内の通信を代表できると考える
コスト軸	ユニット、Endpoint Agent ライセンス、BGP 監視の扱いを分ける	エージェント台数だけで費用を見積もる

ThousandEyes では「何を見るか」だけでなく「どこから見るか」を決める

一般的な監視設計では、最初にサーバー、ネットワーク機器、URL、IP アドレス、プロセス、インターフェースなどの監視対象を決めます。ThousandEyes でも監視対象は重要ですが、それと同じくらい、どこからその対象を測るかが重要です。

同じ Web サイトを測定しても、インターネット上の監視拠点から測る場合、社内ネットワークから測る場合、支店から測る場合、クラウド環境から測る場合、実際の利用者端末から測る場合では、通過する WAN、ISP、DNS、プロキシ、ファイアウォール、VPN が変わります。測定結果は同じ URL に対するものでも、観測している通信経路は同じではありません。

そのため、ThousandEyes のエージェントは単なる監視ソフトウェアではなく、ネットワーク上に設ける観測地点として考えると分かりやすくなります。Cisco のスタートアップ資料でも、ThousandEyes の主要な構成要素は「エージェント」「テスト」「データ」の 3 つに整理され、エージェントは戦略的な監視ポイントとして説明されています。

3 種類のエージェントは、観測する視点が異なる

ThousandEyes には、主に Cloud Agent、Enterprise Agent、Endpoint Agent の 3 種類のエージェントがあります。これは性能の上下を表した分類ではなく、それぞれが異なる場所からサービスを観測するための仕組みです。

エージェント	観測地点	主な用途
Cloud Agent	インターネット上	外部からサービスを見る
Enterprise Agent	拠点、データセンター、クラウド内部	組織内部からサービスを見る
Endpoint Agent	利用者の端末	実際のユーザー体験を見る

Cloud Agent：外部からサービスを見る

Cloud Agent は、ThousandEyes 側が世界各地に設置し、管理している観測地点です。利用者が自分でサーバーやエージェントを用意しなくても、異なる地域やネットワークからテストを実行できます。公開資料では「世界 200 都市以上」などと説明されることがありますが、具体的な都市数や国数は資料の更新時期によって変わるため、導入時には最新資料で確認する必要があります。

Cloud Agent は、公開 Web サイトが外部から利用できるか、地域や ISP によって性能に差がないか、DNS や CDN に問題がないか、インターネット上の経路に異常がないかを確認する用途に向いています。一方、Cloud Agent から正常に接続できても、社内ユーザーが同じように利用できるとは限りません。Cloud Agent の通信経路には、通常、自社の WAN、プロキシ、ファイアウォール、社内 DNS などが含まれないからです。

Cloud Agent が主に確認するのは、サービスが外部のインターネットから正常に見えているかという点です。公開サービスや外部利用者向けのサービス品質を確認するには有効ですが、社内利用者の体感品質を代表するものではありません。

Enterprise Agent：組織内部からサービスを見る

Enterprise Agent は、自社のネットワーク内に配置するエージェントです。本社、支店や営業所、データセンター、クラウドの VPC や VNet、WAN の接続拠点、インターネット回線の出口などに配置し、その地点から SaaS、クラウド、Web サービス、別拠点などへテストを実行できます。

Enterprise Agent を置くと、本社と支店の応答時間、拠点ごとの ISP の品質、WAN 経由とインターネット直接接続の違い、主回線とバックアップ回線の違い、拠点固有のパケットロス、プロキシやファイアウォールを含む経路の状態を比較できます。ここで重要なのは、Enterprise Agent を 1 台設置しても、組織内のすべての通信を測定したことにはならない点です。

データセンターに配置した Enterprise Agent が測定するのは、原則としてそのデータセンターを起点とした通信経路です。支店が別の ISP や別のインターネット出口を利用している場合、データセンターからの測定では支店利用者と同じ経路を通りません。Enterprise Agent が主に確認するのは、この拠点、この回線、このネットワークからサービスを正常に利用できるかという点です。

Endpoint Agent：実際の利用者端末から見る

Endpoint Agent は、利用者が使用する PC などへ導入するエージェントです。Enterprise Agent が拠点を代表する観測地点であるのに対し、Endpoint Agent は端末単位で利用状況を観測します。対象には、端末のネットワーク接続、Wi-Fi の状態、デフォルトゲートウェイまでの通信、VPN 接続、利用者側の ISP、SaaS や Web アプリケーションまでの経路、アプリケーションの応答や表示性能などが含まれます。

同じ拠点にいる利用者でも、接続しているアクセスポイント、端末の状態、VPN の有無によって体感品質は異なります。そのため、Enterprise Agent では異常が確認できないのに、特定の利用者だけが「遅い」と感じる場合があります。Endpoint Agent は、拠点を代表する監視では把握しにくい、利用者固有の経路や端末環境を確認するための観測地点です。

複数の観測地点を比較すると障害範囲が見えてくる

3 種類のエージェントは、どれか一つを選べばよいというものではありません。同じサービスを複数の場所から測ることで、問題の範囲を段階的に切り分けられます。

測定結果	考えられる問題の範囲
Cloud Agent も異常	SaaS、クラウド、DNS、CDN、広域のインターネット
Cloud Agent は正常、Enterprise Agent は異常	社内 WAN、ISP、プロキシ、ファイアウォール、社内 DNS
特定拠点の Enterprise Agent だけ異常	拠点回線、拠点設備、特定 ISP、特定経路
Enterprise Agent は正常、一部 Endpoint Agent だけ異常	端末、Wi-Fi、VPN、利用者側 ISP

たとえば、Cloud Agent では正常だが、ある支店の Enterprise Agent だけが異常であれば、サービス全体の停止よりも支店固有の通信経路を疑いやすくなります。さらに、支店の Enterprise Agent は正常だが一部の Endpoint Agent だけが異常であれば、Wi-Fi や VPN など、利用者側の問題へ範囲を絞れます。ThousandEyes の価値は、単に多くの情報を表示することではなく、異なる観測地点の結果を比較できることにあります。

Enterprise Agent の台数は、監視対象数ではなく観測地点の数で決まる

一つの Enterprise Agent から、複数の URL やサーバーを監視できます。そのため、監視対象が 10 個あるから Enterprise Agent も 10 台必要になるわけではありません。一方で、監視対象が 1 個しかなくても、本社と支店、複数の ISP、主回線とバックアップ回線、VPN 経由と直接接続、国内と海外、複数のクラウドリージョンの違いを区別したければ、複数の観測地点が必要になります。

つまり、Enterprise Agent の台数は、監視対象の数ではなく、区別したい通信経路と観測地点の数で決まります。もちろん、すべての拠点へ一律に配置する必要があるとは限りません。同じ構成、同じ回線、同じインターネット出口を使う拠点が多い場合は、代表地点を選ぶ方法もあります。重要なのは、「何台置くか」から考え始めるのではなく、どの違いを観測結果として区別したいかを先に決めることです。

Enterprise Agent には複数の導入方式がある

Enterprise Agent には、Linux パッケージ、Docker コンテナ、仮想アプライアンス、物理アプライアンス、クラウドイメージ、対応する Cisco ネットワーク機器上への導入など、複数の導入方式があります。Cisco の資料でも、Linux Package、Docker、IaaS Marketplace、仮想アプライアンス、Cisco Application Hosting など、複数の展開方式が示されています。

ただし、導入方式は、単に「どれが一番簡単か」だけで選ぶべきではありません。測りたい通信経路を実際に通るか、他システムの障害に巻き込まれないか、OS 更新や脆弱性対応を誰が行うか、障害時に再構築できるか、実行するテストに必要な性能があるか、その構成が正式なサポート対象か、複数拠点へ標準化して展開できるかを確認する必要があります。

観点	確認すること
観測地点	測りたい通信経路を実際に通るか
障害分離	他システムの障害に巻き込まれないか
OS 管理	更新や脆弱性対応を誰が行うか
再展開	障害時に容易に再構築できるか
リソース	実行するテストに必要な性能があるか
サポート	その構成が正式なサポート対象か
展開方法	複数拠点へ標準化して展開できるか

仮想化や集約は、運用上は便利です。しかし、エージェントを中央の仮想基盤へ集約した結果、測りたかった拠点固有の経路を通らなくなれば、観測設計としては目的を満たしません。Enterprise Agent の導入方式は、単なる実装方法ではなく、観測地点をどこに作るかという設計の一部です。

ThousandEyes のテストは階層構造になっている

ThousandEyes には、Network、Web、API、DNS、音声など、複数のテスト種別があります。これらは完全に独立したテストとして並んでいるわけではなく、上位のテストには下位レイヤーの測定が組み込まれます。

ネットワークテスト

• Agent-to-Server
• Agent-to-Agent
• パケットロス
• 遅延
• ジッター
• ネットワーク経路

Web・API テスト

• HTTP Server
• Page Load
• Transaction
• API

DNS テスト

• DNS Server
• DNS Trace
• DNSSEC

音声テスト

• SIP Server
• RTP Stream

たとえば、HTTP Server テストには、HTTP の可用性や応答時間だけでなく、Agent-to-Server のネットワーク測定と、対象プレフィックスに関する BGP の可視化が含まれます。Cisco のスタートアップ資料でも、Web、DNS、Network、Routing のテストが階層的に構成されることが示されています。

このため、Web サービスの応答が遅くなった場合に、単に「HTTP が遅い」という結果だけを見るのではなく、同じ時間帯の DNS 応答、TCP 接続、TLS 処理、HTTP 応答、パケットロス、ネットワーク遅延、ホップごとの経路、BGP 経路を関連付けられます。複数レイヤーの情報を同じ時間軸で確認できることが、単純な URL 監視との大きな違いです。

BGP 監視はエージェントが実行するテストではない

画面上では、HTTP、Network、BGP の情報が同じテストに関連付けて表示されます。そのため、Cloud Agent や Enterprise Agent が BGP も能動的に測定しているように見えますが、BGP 監視の仕組みは異なります。

BGP のルーティング情報は、Public BGP Monitor や Private BGP Monitor などから収集されます。Cloud Agent や Enterprise Agent が BGP パケットを送信して測定するわけではありません。サービス URL を指定したテストでは、その宛先に関係するプレフィックスの BGP 到達性や経路変更が、下位レイヤーとして関連付けて表示されます。

項目	測定・収集する主体
HTTP、DNS Server、Network など	Cloud Agent／Enterprise Agent
BGP 経路、到達性、アップデート	Public／Private BGP Monitor

上位テストに BGP 情報が表示されることと、エージェントが BGP テストを実行することは同じではありません。この違いは、テスト構成だけでなく、後述するコスト体系を理解する上でも重要です。

HTTP Server、Page Load、Transaction は目的が異なる

Web サービスを監視する場合も、どのテストを使うかによって見える範囲が異なります。HTTP Server テストで正常応答が得られても、利用者がサービスを正常に使えるとは限りません。ページ内の JavaScript、画像、外部 API、認証処理などが遅い可能性があります。また、ログイン画面が表示できても、その後の検索、登録、ファイル取得などが成功するとは限りません。

目的	適したテスト	確認する範囲
サーバーが HTTP 応答を返すかを見る	HTTP Server	HTTP の可用性、応答時間、レスポンス
ページ表示の体感を見る	Page Load	ページ全体と各オブジェクトの読み込み
一連の業務操作が完了するかを見る	Transaction	ログインや画面遷移を含む一連の操作

上位のテストほど、実際のユーザー操作に近い状態を再現できます。一方で、設定や保守、実行リソース、コストも大きくなる可能性があります。重要なサービスだからといって、すべての画面を Transaction テストにすればよいわけではありません。どの操作まで正常であることを確認したいのかを先に定義する必要があります。

コストはエージェントの台数だけでは決まらない

ThousandEyes のコスト体系は、単純な「エージェント 1 台につきいくら」という形ではありません。Cloud Agent や Enterprise Agent から実行するテストでは、主にユニットを消費します。テストによるユニット消費量は、テスト種別、実行間隔、テストを実行するエージェントの数、Cloud Agent か Enterprise Agent か、タイムアウト設定、一部のテスト固有の設定によって変わります。

増やすもの	主に影響するもの	設計上の意味
観測地点	同じテストを実行する組み合わせ	本社、支店、クラウド、利用者端末の差を見分けやすくなります
テスト種別	ユニット消費量、設定と保守の手間	HTTP 応答だけを見るのか、ページ表示や業務操作まで見るのかが変わります
実行間隔	一定期間内の実行回数	短時間の障害を拾いやすくなる一方、消費量も増えます
Endpoint Agent	端末ライセンスと端末管理	拠点代表ではなく、利用者ごとの体感品質を確認できます
独立した BGP テスト	BGP Monitor 側の監視構成	上位テストに付随する表示と、独立した経路監視を分けて扱えます

これは、これらの値を単純にすべて掛ければ算出できるという意味ではありません。テスト種別ごとに基本となる消費率があり、その設定内容によって最終的な消費量が変わります。したがって、設計段階では「何を増やすと観測精度が上がり、何を増やすと消費量が増えるのか」を分けて考える必要があります。

監視対象数だけではコストを見積もれない

たとえば、5 つの SaaS を監視する場合を考えます。1 か所の Enterprise Agent から 5 つの SaaS を測定する場合と、10 拠点の Enterprise Agent から同じ 5 つの SaaS を測定する場合では、測定の組み合わせが異なります。

監視対象	観測地点	概念上の測定組み合わせ
5 つの監視対象	1 つの観測地点	5 つの測定組み合わせ
5 つの監視対象	10 の観測地点	50 の測定組み合わせ

実際のユニット数は、さらにテスト種別、実行間隔、エージェント種別などの影響を受けます。したがって、「監視対象は 5 個です」という情報だけでは、必要なコストを見積もれません。少なくとも、何を測定するか、どこから測定するか、どのテストを使うか、どの間隔で測定するかを決める必要があります。

実行間隔を短くすると消費量は増える

同じテストでも、実行間隔が短いほど、一定期間内の実行回数が増えます。5 分間隔より 2 分間隔、2 分間隔より 1 分間隔の方が、多くのユニットを消費します。実行間隔を短くすると短時間の障害を検知しやすくなりますが、すべてのテストを最短間隔に設定すればよいとは限りません。

短時間の停止も見逃せないサービス、顧客影響が大きい公開サービス、障害を早期に検知したい重要経路については、短い間隔が適しています。一方、変化が少ない対象や補助的な監視は、長い間隔でも目的を満たせる可能性があります。実行間隔はコスト削減のつまみではなく、検知したい障害の時間幅に合わせて決める設計項目です。

Cloud Agent と Enterprise Agent では消費率が異なる

同じ種類のテストでも、Cloud Agent と Enterprise Agent ではユニットの消費率が異なります。Enterprise Agent は利用者側が実行基盤を用意し、管理します。一方、Cloud Agent は ThousandEyes 側が世界各地に用意した実行基盤を利用します。この違いから、同じテストであれば、Enterprise Agent から実行した方が Cloud Agent から実行するよりも少ないユニットで済む場合があります。

過去の国内資料では、Enterprise Agent によるテストを Cloud Agent の半分として計算する例も示されています。ただし、過去資料に記載された具体的な換算値、最低契約数、購入単位を、現在の契約条件としてそのまま利用すべきではありません。契約時には、最新の公式計算方法や販売パートナーの見積もりで確認する必要があります。

上位テストに含まれる下位テストは、別々には加算されない

HTTP Server テストには、Agent-to-Server のネットワーク測定と BGP 監視が含まれます。この構造だけを見ると、HTTP Server の費用に、Network テストの費用と BGP テストの費用を別々に足し込むように見えます。しかし、ネストされた下位テストは、別々のテストとしてユニットを追加消費するわけではありません。

HTTP Server テストを設定した場合は、HTTP Server テストとしてのユニットが消費されます。下位の Network や BGP 表示を無効化しても、HTTP Server テストの消費量が減るわけではありません。つまり、上位テストには下位レイヤーの可視化が含まれますが、下位テストの数を単純に足し合わせてコストを考える必要はありません。ただし、別途独立した Network テストや BGP テストを作成すれば、それは別のテスト構成として扱われます。

Endpoint Agent はユニットではなくライセンスで管理される

Endpoint Agent は、Cloud Agent や Enterprise Agent のテストとは異なる料金体系で扱われます。Cloud Agent と Enterprise Agent のテストは主にユニットを消費しますが、Endpoint Agent はライセンス単位で管理されます。Endpoint Agent には、機能の異なる Advantage と Essentials のライセンスがあります。

エージェントが登録される際に利用可能なライセンスを消費し、Advantage ライセンスがなければ Essentials を使用します。利用可能なライセンスがなければ、その後に登録されたエージェントはライセンスのない状態になります。したがって、Endpoint Agent については、単純に Cloud／Enterprise Agent のユニット計算へ含めるのではなく、導入する Endpoint Agent の数、ライセンス種別、端末交換や再登録時の管理、動的テストや定期テストの必要数、利用する機能とデータ保持条件を確認する必要があります。

コストを説明するときは、「ユーザー数課金」や「端末数課金」と単純化するより、Endpoint Agent ごとにライセンスを割り当てるモデルとして理解する方が安全です。

BGP 監視のコストもエージェント数だけで考えない

BGP 監視は、Cloud Agent や Enterprise Agent が実行するテストではなく、BGP Monitor から収集した情報を利用します。そのため、「BGP テストに Enterprise Agent の台数を掛ける」という考え方を、そのまま適用すべきではありません。

HTTP Server や Network テストにネストされた BGP 監視については、上位テストのユニットに含まれます。一方、特定プレフィックスを対象に独立した BGP テストを作成する場合は、そのテスト構成に応じた扱いを確認する必要があります。BGP が同じ画面に表示されるからといって、他のエージェントテストと同じ測定方式、同じ課金軸であるとは限りません。

コスト設計は、監視を減らす作業ではない

コストを抑えるだけなら、テスト数やエージェント数を減らし、実行間隔を長くすればよいです。しかし、それによって必要な障害を検知できなくなれば、監視を導入した意味が薄れます。重要なのは、すべての対象を一律に扱わないことです。

重要なサービスは短い間隔で測定し、補助的なサービスは長い間隔にする。全拠点から測る必要がある対象と、代表拠点だけでよい対象を分ける。外部視点が必要な対象だけ Cloud Agent を使い、Page Load や Transaction は必要な操作へ限定する。Network テストだけで目的を満たせる対象を分ける。このように、検知したい障害と観測地点を対応させて設計します。

コスト設計とは、単に監視項目を削ることではありません。どの障害を、どの場所から、どの粒度で、どれだけ早く検知する必要があるかという判断を、エージェント、テスト、実行間隔へ変換する作業です。

導入前に整理しておくべき項目

見積もりを依頼する場合も、単に「監視対象は 10 個」と伝えるだけでは不十分です。最低限、次の項目を整理しておくと、見積もりのためだけでなく、監視設計そのものの前提も明確になります。

項目	整理する内容
監視対象	URL、IP アドレス、DNS 名、サービス
観測地点	本社、支店、DC、Cloud Agent、利用者端末
テスト種別	HTTP、Page Load、Transaction、Network、DNS など
エージェント数	何か所からテストを実行するか
実行間隔	1 分、2 分、5 分など
タイムアウト	Web テストなどの待ち時間
Endpoint Agent	必要数とライセンス種別
BGP 監視	ネストされた監視か、独立テストか
追加機能	Internet Insights など
運用	アラート、レポート、設定変更、障害対応

この表を埋めることは、見積もりのためだけの作業ではありません。どの障害を検知したいのか、どの範囲まで切り分けたいのか、どの場所から観測しなければ意味がないのかを整理する作業でもあります。

まとめ

ThousandEyes の導入では、最初から製品の台数やライセンス数を考えるより、誰の通信を観測したいのか、どこからどこまでを測定したいのか、どの観測地点を区別したいのか、どのテストで利用状態を再現するのか、どの間隔で測定するのかを順番に整理した方がよいです。その結果として、必要なユニットやライセンスが見えてきます。

Cloud Agent、Enterprise Agent、Endpoint Agent は、単なる製品の種類ではありません。Cloud Agent は外部から見て、Enterprise Agent は組織内部から見て、Endpoint Agent は実際の利用者端末から見るという観測地点の違いです。また、ThousandEyes のコストは、単純な監視対象数やエージェント台数だけでは決まりません。テスト種別、観測地点、エージェント種別、実行間隔、タイムアウトなど、監視設計の結果として決まります。

したがって、導入設計とコスト設計は別々のものではありません。必要な観測地点とテストを決めた結果として、必要なコストが決まります。

参考資料

• ThousandEyes Documentation – Getting Started
• ThousandEyes Documentation – Enterprise Agents
• ThousandEyes Documentation – Tests