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

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

クラウドサービスや SaaS の利用が増えると、利用者とサービスの間には、自社で直接管理できないネットワークが多く含まれるようになります。

利用者から「遅い」「つながらない」と申告されても、原因が社内 LAN、WAN、ISP、DNS、クラウド事業者、SaaS のどこにあるのか分かりません。ネットワーク機器やサーバーが正常であっても、利用者がサービスを正常に使えるとは限りません。

ThousandEyes は、このような通信経路へテストトラフィックを送信し、サービスの到達性、応答時間、パケットロス、経路などを継続的に観測する製品です。

ただし、導入を検討し始めると、次のような疑問が出てきます。

• Cloud Agent、Enterprise Agent、Endpoint Agent は何が違うのか
• エージェントはどこに置けばよいのか
• Enterprise Agent は何台必要なのか
• HTTP 監視とページロード監視は何が違うのか
• BGP もエージェントが測定しているのか
• 何を増やすとコストが増えるのか

これらは個別の製品仕様に見えますが、実際にはすべて、何を、どこから、どの粒度で観測するかという設計上の問題につながっています。

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

一般的な監視設計では、最初に監視対象を決めます。

• サーバー
• ネットワーク機器
• URL
• IP アドレス
• プロセス
• インターフェース

ThousandEyes でも監視対象は重要だが、それと同じくらい、どこからその対象を測るかが重要になる。

同じ Web サイトを測定しても、次の結果は同じ意味を持ちません。

• インターネット上の監視拠点から測る
• 社内ネットワークから測る
• 支店から測る
• クラウド環境から測る
• 実際の利用者端末から測る

測定場所が変われば、通過する WAN、ISP、DNS、プロキシ、ファイアウォール、VPN も変わります。

そのため、ThousandEyes のエージェントは単なる監視ソフトウェアではなく、ネットワーク上に設ける観測地点として考えると分かりやすくなります。

Cisco のスタートアップ資料でも、ThousandEyes の主要な構成要素は「エージェント」「テスト」「データ」の 3 つに整理され、エージェントは戦略的な監視ポイントとして説明されています。

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

ThousandEyes には、主に次の 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 の接続拠点
• インターネット回線の出口

Enterprise Agent を配置すると、その地点から SaaS、クラウド、Web サービス、別拠点などへテストを実行できます。

これにより、次のような違いを確認できます。

• 本社と支店の応答時間
• 拠点ごとの 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 管理	更新や脆弱性対応を誰が行うか
再展開	障害時に容易に再構築できるか
リソース	実行するテストに必要な性能があるか
サポート	その構成が正式なサポート対象か
展開方法	複数拠点へ標準化して展開できるか

仮想化や集約は、運用上は便利です。

しかし、エージェントを中央の仮想基盤へ集約した結果、測りたかった拠点固有の経路を通らなくなれば、観測設計としては目的を満たさない。

Enterprise Agent の導入方式は、単なる実装方法ではありません。

観測地点をどこに作るかという設計の一部です。

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

ThousandEyes には、複数のテスト種別があります。

代表的なものを整理すると、次のようになります。

ネットワークテスト

• 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	HTTP の可用性、応答時間、レスポンス
Page Load	ページ全体と各オブジェクトの読み込み
Transaction	ログインや画面遷移を含む一連の操作

HTTP Server テストで正常応答が得られても、利用者がサービスを正常に使えるとは限りません。

ページ内の JavaScript、画像、外部 API、認証処理などが遅い可能性があるからです。

また、ログイン画面が表示できても、その後の検索、登録、ファイル取得などが成功するとは限りません。

そのため、目的に応じてテストを使い分ける必要があります。

• サーバーが HTTP 応答を返すかを見る

→ HTTP Server

• ページ表示の体感を見る

→ Page Load

• 一連の業務操作が完了するかを見る

→ Transaction

上位のテストほど、実際のユーザー操作に近い状態を再現できます。一方で、設定や保守、実行リソース、コストも大きくなる可能性があります。

重要なサービスだからといって、すべての画面を Transaction テストにすればよいわけではありません。

どの操作まで正常であることを確認したいのかを先に定義する必要があります。

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

ThousandEyes のコスト体系は、単純な「エージェント 1 台につきいくら」という形ではありません。

Cloud Agent や Enterprise Agent から実行するテストでは、主にユニットを消費します。

テストによるユニット消費量は、主に次の要因で決まります。

• テスト種別
• 実行間隔
• テストを実行するエージェントの数
• Cloud Agent か Enterprise Agent か
• タイムアウト設定
• 一部のテスト固有の設定

これは、これらの値を単純にすべて掛ければ算出できる、という意味ではありません。

テスト種別ごとに基本となる消費率があり、その設定内容によって最終的な消費量が変わります。

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

たとえば、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 の数
• Advantage と Essentials のどちらを使うか
• 端末交換や再登録時のライセンス管理
• 動的テストや定期テストの必要数
• 利用する機能とデータ保持条件

コストを説明するときは、「ユーザー数課金」や「端末数課金」と単純化するより、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 の導入では、最初から製品の台数やライセンス数を考えるより、次の順番で整理した方がよいです。

1. 誰の通信を観測したいのか
2. どこからどこまでを測定したいのか
3. どの観測地点を区別したいのか
4. どのテストで利用状態を再現するのか
5. どの間隔で測定するのか
6. その構成がどれだけのユニットやライセンスを必要とするのか

Cloud Agent、Enterprise Agent、Endpoint Agent は、単なる製品の種類ではありません。

• Cloud Agent は外部から見る
• Enterprise Agent は組織内部から見る
• Endpoint Agent は実際の利用者端末から見る

という観測地点の違いです。

また、ThousandEyes のコストは、単純な監視対象数やエージェント台数だけでは決まらない。

テスト種別、観測地点、エージェント種別、実行間隔、タイムアウトなど、監視設計の結果として決まります。

したがって、導入設計とコスト設計は別々のものではありません。

必要な観測地点とテストを決めた結果として、必要なコストが決まります。

参考資料

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