アプリケーションが遅い原因はサーバかネットワークか?応答時間を分解して確認する方法
業務アプリケーションを利用していると、「画面の表示が遅い」「処理に時間がかかる」「特定の拠点やユーザーだけ応答が悪い」といった問い合わせが発生することがあります。
しかし、アプリケーションの遅延は原因の切り分けが難しいことがあります。アプリケーションサーバの処理が遅いのか、ネットワーク遅延が発生しているのか、通信先サーバやデータベース側に問題があるのかを判断するには、複数の観点で確認する必要があります。
アプリケーションの遅延調査では、単に「アプリが重い」と捉えるのではなく、ユーザーが感じている応答時間を分解し、どこで時間がかかっているのかを確認することが重要です。
この記事のポイント
- アプリケーションが遅いときに考えられる主な原因を整理します。
- ユーザー応答時間をアプリケーション応答時間とネットワーク遅延時間に分けて確認する考え方を紹介します。
- uObserveを活用したアプリケーション遅延の切り分け方法を紹介します。
アプリケーションが遅い原因は1つとは限らない
アプリケーションの遅延には、さまざまな原因があります。たとえば、サーバ側の処理、ネットワーク、クライアント環境、通信先サービスなど、複数の要素が関係します。
代表的な原因としては、以下が挙げられます。
- アプリケーションサーバの処理に時間がかかっている
- データベースや外部サービスの応答が遅い
- ネットワーク遅延や再送が発生している
- 特定の拠点やクライアントからの通信だけ遅い
- 特定のサービスやポートで応答時間が悪化している
- 通信先サーバ側のレスポンスが遅い
- 一部のトランザクションだけ処理に時間がかかっている
このように、アプリケーションの遅延は、サーバ、ネットワーク、クライアント、通信先サービスのどこで発生しているかを切り分ける必要があります。
まずはユーザー応答時間を分解して考える
アプリケーションの遅延調査では、まずユーザーが感じている応答時間を分解して考えることが有効です。
uObserveでは、エンドユーザレスポンスタイムを、アプリケーションレスポンスタイムやネットワーク遅延時間などに分けて確認できます。

エンドユーザレスポンスタイム画面
たとえば、ユーザーの応答時間が長くなっている場合でも、実際には以下のように原因が異なる可能性があります。
- アプリケーションサーバの処理時間が長い
- ネットワーク遅延時間が大きい
- データ転送に時間がかかっている
- 特定のクライアントや拠点だけで遅延が発生している
- 特定の通信先サーバの応答が遅い
応答時間を分解することで、アプリケーション側を調査すべきか、ネットワーク側を調査すべきか、通信先サーバを確認すべきかを判断しやすくなります。
ユーザエクスペリエンスで拠点やクライアントごとの状態を確認する
アプリケーションの遅延が発生している場合、すべてのユーザーで同じように遅いのか、特定の拠点やクライアントだけで発生しているのかを確認することが重要です。
uObserveのユーザエクスペリエンスでは、あらかじめ登録したサイト内のクライアント通信をもとに、ネットワークラウンドトリップタイム、リトライ数、アプリケーション応答時間などを確認できます。
ユーザエクスペリエンスで確認できる主な情報
- サイト内のクライアントごとの通信状況
- ネットワークラウンドトリップタイム
- 受信リトライ数・送信リトライ数
- アプリケーションレスポンスタイム
- Conversation単位の通信詳細
- 通信相手やサービスごとの状態
拠点やクライアント単位で状態を確認することで、遅延が特定の利用者に限定されているのか、広範囲に発生しているのかを把握しやすくなります。
確認したいポイント
- 特定のサイトや拠点だけで遅延が発生していないか
- 特定のクライアントだけで応答時間が悪化していないか
- ネットワークラウンドトリップタイムが大きくなっていないか
- 受信リトライ数や送信リトライ数が増えていないか
- 特定のアプリケーションだけ応答時間が悪化していないか
アプリケーション応答時間とネットワーク遅延を比較する
アプリケーションが遅いと感じられる場合でも、実際にはアプリケーション側の処理が遅い場合と、ネットワーク側の遅延が大きい場合があります。
uObserveのユーザエクスペリエンスのアプリケーションタブでは、ネットワーク遅延時間とアプリケーションレスポンスタイムを積み上げグラフとして確認できます。

ユーザエクスペリエンス アプリケーションタブ
アプリケーションレスポンスタイムが大きい場合は、サーバ側の処理や通信先サービスの応答を確認します。一方で、ネットワーク遅延時間が大きい場合は、ネットワーク経路、拠点間通信、リトライ、パケットロスなどを確認する必要があります。
- アプリケーションレスポンスタイムが大きい場合:サーバ処理、データベース、外部サービスを確認
- ネットワーク遅延時間が大きい場合:ネットワーク経路や通信品質を確認
- 特定クライアントだけ遅い場合:端末、拠点、アクセス経路を確認
- 特定アプリケーションだけ遅い場合:対象サービスや通信先サーバを確認
Conversation単位で問題の通信を確認する
遅延の原因をさらに絞り込むには、どのクライアントとどのサーバ間の通信で問題が発生しているかを確認します。
uObserveのユーザエクスペリエンスでは、Conversation単位で詳細情報を確認できます。Conversationタブでは、サービス、ネットワーク、不良トランザクションなどの観点から通信を確認できます。

Conversation単位の詳細確認画面
Conversation単位で確認することで、遅延が発生している通信の組み合わせを把握しやすくなります。
アプリケーション通信全体から遅い通信を探す
個別のユーザーや拠点だけでなく、データセンター内で観測されているアプリケーション通信全体から問題を探したい場合もあります。
uObserveのアプリケーション解析では、監視している通信内で観測されたアプリケーション通信に着目し、複数の切り口から状態を確認できます。
アプリケーション解析で確認できる主な情報
- 依存するサービス:アプリケーション通信の依存関係を確認
- トポロジーマップ:ホスト、クラスタ、クラウド、ポートグループなどの単位で通信を整理
- テーブル:クライアント、サービス、仮想マシン、ホストなどの単位で通信情報を確認
- アラーム:アプリケーションパフォーマンスに関するアラームを確認
これらの情報を確認することで、どのアプリケーション通信で応答時間が悪化しているか、どのノード間の通信に問題がありそうかを確認しやすくなります。
特定のユーザーや拠点からの問い合わせだけでは原因が見えにくい場合でも、アプリケーション通信全体を確認することで、影響範囲や問題のある通信を把握しやすくなります。
依存関係マップで通信先との関係を確認する
アプリケーションの遅延は、対象サーバ単体ではなく、通信先のサーバや依存しているサービスの影響を受けることがあります。
uObserveのアプリケーション依存性マップでは、VMやパブリッククラウドインスタンス間のアプリケーション通信を可視化し、相互依存関係を確認できます。アプリケーションレスポンスタイムに問題がある場合は、ノードや矢印がヘルス状態に応じた色で表示されます。

アプリケーション依存性マップ
これにより、どの通信先とのやり取りで応答時間が悪化しているのか、どのアプリケーション通信が影響しているのかを把握しやすくなります。
サンキーダイアグラムで通信量とヘルス状態を確認する
アプリケーション遅延の調査では、通信の有無だけでなく、通信量やネットワークヘルス状態も確認する必要があります。
uObserveのカンバセーション サンキーダイアグラムでは、クライアント側ノード、サーバ側ノード、サービスやアプリケーションの関係を視覚的に確認できます。帯の太さはトラフィック量を示し、色はネットワークヘルス状態を示します。

カンバセーション サンキーダイアグラム
通信量が多い経路や、ネットワークヘルス状態が悪化している通信を確認できるため、調査対象の優先順位を決める際にも役立ちます。
トランザクション解析でリクエストやレスポンスを確認する
DNS、HTTP、データベース系プロトコルなど、対象プロトコルの詳細を確認したい場合は、トランザクション解析も有効です。
uObserveのトランザクション解析では、対象プロトコルごとに、リクエストやレスポンスの傾向、サーバごとのトランザクション数、関連するネットワーク統計などを確認できます。
トランザクション解析で確認できる主な情報
- レスポンスの種別ごとの発生状況
- クエリリクエストの種別ごとの発生状況
- サーバごとのトランザクション数
- クライアントごとのリクエスト数
- 各プロトコルのサーバごとのリクエスト数・レスポンス数・ネットワーク統計
- 個別トランザクションのリクエスト・レスポンス概要
たとえば、HTTPやデータベース通信の応答が遅い場合、どのサーバで、どのようなリクエストやレスポンスが発生しているかを確認することで、アプリケーション側の問題を絞り込みやすくなります。

トランザクション解析 Overviewタブ画面
不良トランザクションから具体的な遅延内容を確認する
アプリケーションレスポンスタイムが悪化している場合、どのリクエストに対する応答が遅かったのかを確認することも重要です。
uObserveのルートコーズビューでは、不良トランザクションとして、アプリケーションレスポンスタイムが大きいトランザクションのリクエストやレスポンスの概要を確認できます。

不良トランザクション確認画面
この情報により、どのクライアントから、いつ、どのようなリクエストに対して応答が遅かったのかを確認できます。遅延の発生箇所を具体的に把握しやすくなるため、サーバ側の処理やアプリケーション側の調査につなげやすくなります。
通信先サーバの応答も確認する
アプリケーションが遅い場合、解析対象の仮想マシン自体ではなく、通信先サーバの応答が遅いことが原因になっている場合もあります。
uObserveでは、問題の仮想マシンがクライアントとして通信しているサーバ群を、レスポンスが遅いものから順に確認できます。これにより、遅延の原因が対象仮想マシン側にあるのか、通信先サーバ側にあるのかを切り分けやすくなります。

通信先サーバの応答確認画面
通信先サーバの応答が遅い場合は、そのサーバで稼働しているアプリケーション、データベース、外部サービスなどの状態を確認する必要があります。
uObserveを使ったアプリケーション遅延調査の流れ
uObserveを活用したアプリケーション遅延調査の流れは、たとえば以下のようになります。
- ユーザエクスペリエンスで、どのサイトやクライアントで遅延が発生しているかを確認する
- アプリケーションタブで、アプリケーションレスポンスタイムとネットワーク遅延時間を比較する
- Conversation単位で、問題の通信を確認する
- アプリケーション依存性マップで、通信先や依存関係を確認する
- サンキーダイアグラムで、通信量やネットワークヘルス状態を確認する
- トランザクション解析で、リクエストやレスポンスの内容を確認する
- ルートコーズビューで、不良トランザクションや通信先サーバの応答を確認する
このように、ユーザー視点の応答時間から、アプリケーション通信、ネットワーク状態、トランザクション、通信先サーバまで順番に確認することで、原因候補を絞り込みやすくなります。
まとめ
アプリケーションが遅い場合、原因はアプリケーションサーバだけとは限りません。ネットワーク遅延、通信先サーバの応答、データベース処理、特定クライアントの通信状態など、さまざまな要素が関係します。
そのため、アプリケーション遅延の調査では、以下の観点で確認することが重要です。
- ユーザー応答時間を分解して確認する
- アプリケーションレスポンスタイムとネットワーク遅延時間を比較する
- 特定のサイト、クライアント、Conversationに問題がないか確認する
- アプリケーション通信の依存関係を確認する
- 通信量やネットワークヘルス状態を確認する
- 不良トランザクションから具体的なリクエストやレスポンスを確認する
- 通信先サーバの応答が遅くないか確認する
uObserveを活用することで、アプリケーション、ネットワーク、通信先サーバの状態を横断的に可視化し、アプリケーション遅延の原因切り分けを支援できます。
あわせて読みたい
VDI環境で遅延が発生した場合に、仮想基盤・ネットワーク・アプリケーションのどこに原因があるのかを切り分けるポイントについて、以下の記事で解説しています。
アプリケーションの遅延原因を可視化したい方へ
uObserveは、仮想基盤・ネットワーク・アプリケーションを横断して可視化し、 パフォーマンス問題の原因切り分けを支援する監視・管理ツールです。 uObserveの製品情報はこちらからご覧いただけます。
資料・無償評価版もご用意しています。アプリケーションやネットワークの遅延原因の切り分けに課題がある場合は、お気軽にご相談ください。