機能一覧

サーバの外で起きている障害を、利用者と同じ回線から計測する

SpeedData が計測する範囲

多くの監視ツールが見ているのは、自社のサーバとアプリケーションの内側です。
しかし利用者は、ISP、モバイル回線、DNS、CDN、BGP経路を経由してサービスを利用しています。
サーバもクラウドも正常なのに利用者が使えないとき、問題はその経路のどこかで起きています。

SpeedData は、国内7都市の計測センターから、NTT/KDDIの光回線と4キャリアのモバイル回線という利用者と同じ回線を使って、この経路全体を計測します。
このページでは、機能を「何を計測するか」「どこから計測するか」「どうやって計測するか」の3つの軸で整理しています。

何を計測するか ― インターネットの層ごとの計測対象

利用者の端末からアプリケーションの内部まで、インターネットの層の順に並べています。
起きている症状から、該当する層の計測対象を選んでください。

経路・ネットワーク

BGP監視

「サーバは正常なのに、特定のネットワークから繋がらない」
自社ASの経路広告、ピアリングの状況、他のASからの経路の受け取り状況を監視し、経路ハイジャックやルートリークを検知します。

通信経路監視

「どの回線の、どの区間で遅延しているのか知りたい」
各都市の光回線と4キャリアのモバイル回線からTracerouteを実行し、経路ごとのレイテンシ、ホップ数、パケットロスを可視化します。

Transport監視

「任意のTCP/UDPサービスの応答性を監視したい」
任意のホストとポートにTCPまたはUDPで接続し、名前解決、接続、送信、応答待ち、受信の段階ごとに時間を計測します。

NTP監視

「時刻同期の精度を監視したい」
NTPサーバの応答時間、時刻のずれ（オフセット）、ストラタムを継続して監視します。金融取引や放送など、時刻の正確さが求められるシステム向けです。

名前解決・暗号化

DNS監視

「名前解決の遅延や失敗を、利用者側から捉えたい」
ISPやモバイルキャリアのリゾルバを経由した応答時間、DNSSECの検証、DKIMレコードの応答を、実回線から継続して監視します。

SSL/TLS監視

「証明書の期限切れによるサービス停止を防ぎたい」
証明書の有効期限、証明書チェーン、対応しているプロトコルと暗号スイート、OCSPの応答時間を監視し、失効前に通知します。

Web・API・配信

Web監視（単ページ）

「全国や海外の利用者から見た表示速度を知りたい」
ページの表示速度と可用性を計測し、自社のコンテンツとサードパーティーのコンテンツに分けて、どこが遅いのかを明らかにします。

Web監視（シナリオ計測）

「ログインや購入の手続きが、途中で失敗していないか確かめたい」
典型的な操作の流れをPlaywrightやPuppeteerのスクリプトで再現し、ページ遷移全体を計測します。

API監視

「API連携のエラーが、提供側と利用側のどちらの問題か切り分けたい」
APIの応答時間、可用性、エラー率を実回線から継続して計測します。

CDN計測

「CDNが、本当に利用者の近くで速く配信できているか確かめたい」
オリジンとCDNの速度を比べ、地域やISPごとの配信速度と、どの拠点から配信されているか（マッピング）を確認します。

埋め込みタグ監視

「自社のタグが、顧客のサイトを遅くしていないか知りたい」
広告タグ、分析タグ、チャットボットなどを計測用の空のページに埋め込み、顧客サイトの状況に左右されずにタグ単体の性能と可用性を計測します。

リアルタイム・ストリーミング・IoT

WebSocket監視

「会議が途切れる、チャットが届かない原因を知りたい」
WebSocketの接続確立時間、メッセージの往復遅延、接続の維持時間、切断の発生率を実回線から監視します。

ストリーミング監視

「配信の画質低下やバッファリングを検知したい」
HLS/DASHの再生開始時間、バッファリングの頻度、ビットレートの切り替え、接続断を、地域と回線ごとに計測します。

MQTT監視

「IoTデバイスからのメッセージが遅れていないか知りたい」
MQTTブローカーへの接続時間、Publish/Subscribeの配信時間、QoSレベルごとの到達性を実回線から監視します。

カスタムプロトコル監視

「独自プロトコルのサービス品質を計測したい」
TCP/UDP上で任意のデータを送り、応答時間と可用性を計測します。ゲームなどの独自の通信仕様にも対応します。

メール

SMTP監視

「メールが遅い原因を特定したい」
メール送信サーバや、Google Workspace・Microsoft 365からの実際の送信で、SMTPのコマンドごとの処理時間を計測します。

IMAP監視

「メールの受信が重い原因を特定したい」
IMAPのログイン、フォルダ一覧の取得、本文の取得の段階ごとに応答時間を計測し、サーバ側とネットワーク側のどちらの問題かを切り分けます。

社内利用・SaaS

エンドポイント監視

「在宅勤務の従業員だけ、社内システムやSaaSが重い原因を知りたい」
従業員のPCから、社内システムやSaaSへの接続品質、VPNやゼロトラスト環境での遅延、Wi-Fiの品質を計測します。PCのCPUやメモリの使用状況も計測するので、端末の問題かネットワークの問題かを切り分けられます。

SaaS監視

「利用している複数のSaaSへの接続品質を、まとめて把握したい」
Salesforce や Microsoft 365 などの複数のSaaSに対して、スクリプトのテンプレートを使って、Playwright／Puppeteer のシナリオ、API、カスタムの計測をまとめて設定・管理します。

アプリケーション内部

トレーシング

「マイクロサービスのどこがボトルネックなのか特定したい」
OpenTelemetryに準拠したトレーシングで、複数のサービスにまたがる処理時間を可視化します。インターネット側の計測と組み合わせることで、障害がサーバの内側と外側のどちらで起きているかを判断できます。

どこから計測するか ― 計測拠点

障害は、利用者のいる地域と回線で起きます。
SpeedData は、データセンターからではなく、利用者と同じ回線から計測します。

国内計測ノード

札幌、仙台、新潟、東京、名古屋、大阪、福岡の7都市に計測センターを自社で運用しています。
NTT/KDDIの光回線と、docomo、au、SoftBank、楽天モバイルの4キャリアの回線から計測します。
国内最大の可視化カバレッジを誇ります。

海外ブロードバンド計測ノード

Catchpoint が管理するブロードバンド計測ノードで、世界87か国、224都市、983のネットワークから計測できます。
世界最多の計測ノード数を誇ります。

海外モバイル計測ノード

Catchpoint が管理するモバイル計測ノードで、世界4か国、12都市、34のネットワークから計測できます。

ラストマイルノード

Catchpoint が管理するラストマイルノードで、世界20か国、81都市、115のネットワークから計測できます。
世界最多の計測ノード数を誇ります。

Enterpriseノード

社内のシステムやデータセンター内のシステムなど、各都市の計測ノードからは届かない場所を計測するためのノードです。
仮想マシンと物理マシンの両方に対応しています。

どうやって計測するか ― 計測方式

SpeedData の計測エンジンである Catchpoint は、Google、Microsoft、Amazon、Facebook、Oracle、SAP、TikTokなどの企業、CDNトップ10の内9社、各国の通信キャリアに採用されています。

合成監視（Synthetic Monitoring）

決まった拠点と回線から、利用者の操作を定期的に再現して計測する方式です。
利用者がいない時間帯でも計測が続くため、障害を利用者より先に検知できます。条件をそろえて計測するので、回線や地域どうしを比べられます。

リアルユーザーモニタリング

実際の利用者のブラウザで計測した表示速度を集計する方式です。
合成監視の結果を、実際の利用状況で裏付けます。

エンドポイントモニタリング

従業員のPCに計測エージェントを入れて、社内、在宅勤務、出張先からの通信状況を計測する方式です。
SWGやVPNを経由している場合も、その通信状況を可視化します。

WebPageTest

Webページの読み込み過程を詳細に分析し、表示速度を改善するための手がかりを得る方式です。

計測・監視データの提供

BGPモニタリング

世界各地に配置したプローブから、BGPの経路の状況を監視したデータを提供します。
世界最大のカバレッジを誇るBGP監視サービスです。

インターネットソナー

「自社の問題か、それとも外部の問題か」に素早く答えるために、インターネット上の主要なサービスの状況を監視したデータを提供します。

インターネットスタックマップ

自社のサービスが依存しているDNS、CDN、クラウド、サードパーティーのサービスを一つの図にまとめ、どこで問題が起きているかを即座に把握します。

既存の監視ツールとの連携

Datadog・New Relic・Slack との連携

SpeedData は、既存の監視ツールを置き換えるものではありません。
計測結果を Datadog や New Relic に送り、サーバ内部のデータと並べて見ることで、障害がサーバの内側と外側のどちらで起きているかを切り分けられます。