遅延切り分け

アプリ遅延の切り分け

 クラウド時代になり、ネットワークやサーバ構成が複雑になりました。その結果、トラブル時の切り分けが難しくなってきました。
 特に明確な故障(利用できない)ではなく、
・時々使えないことがありそうだ。
・遅延が生じて業務が行えない。 
のようなトラブルについては原因の究明がなかなかできません。

 本ページでは、1、2、3項で、WEB系のシステムにおいて、このような遅延のトラブルに関する切り分け方法について詳しく説明します。

4項では、WEB系のシステム以外の場合の遅延のトラブルに関する切り分け方法について説明します。

本ページで説明するシステム構成です。
遅延の切り分け

EEC(Ent-to-End Checker)


1.EECの基本機能を利用した切り分け

 次に示すグラフは、あるWEBサイトをEEC(End-to-End Checker)で調査した出力例です。Wget試験 2016.3.18
遅延の状況 Wget試験
遅延の閾値
凡例 青:速い、緑:少し遅い、紫:遅い、赤:timeout

(注)EECについては、こちらのページをご参照下さい。

 このお客さまは、WEBのアクセスが遅すぎると苦情になっています。
このような場合、
・ネットワークの帯域の要因
・サーバ等の機器の要因
の切り分けが必要になります。

 ネットワークの帯域の場合、キャリアやSIベンダに使用帯域を測定して貰う必要があります。
 EECを利用した場合は、帯域の測定をする代わりに、pingまたは使用ポートのレスポンスを見て、切り分けが可能です。

帯域の測定の場合、どの程度の帯域利用であれば良いのかどうか分かりませんが、レスポンスの測定は、よりお客さまの使い勝手を知る上で効果的です。


次に示すのは、同じ日の80ポート試験のEECの結果です。
遅延の状況 80ポート試験

サーバは、設置者のポリシーにより、ping試験を拒否している場合もありますが、WEB利用の場合は、80ポートは必ず利用していますので、80ポートの試験は可能となります。

 Wget試験と80ポート試験を比較します。
80ポート試験では、遅延が発生していませんので、ネットワークの帯域よりもそれ以外の要因の可能性が高いのが分ります。


2.パケットキャプチャによる解析

 EECは、試験の状況を簡単にパケットキャプチャを行うことができます。

 次に示す画面は、実際のパケットキャプチャの起動画面です。

パケットキャプチャの起動画面

図をクリックすると拡大します。


 Webサイトの場合、ipアドレスを指定することは稀です。アドレス名に対して複数のIPアドレスがある場合がありますので、そのアドレスを指定します。

 冗長化されたサーバの1つが時々不具合がある場合等の発見は難しいですが、このように複数のサーバを指定することにより他サーバとの比較ができ不具合の原因究明に役立ちます。

 次に示すのは取得したパケットキャプチャの検索の画面です。

パケットキャプチャの検索画面

図をクリックすると拡大します。


次に示すのは、実際の検索結果の例です。
IPアドレスは、xxx.yyy.zzz に変換しています。

パケットキャプチャの検索結果

図をクリックすると拡大します。

 次に、上記のパケットの遷移の赤枠で括った「45690」番の一連の処理を表示します。

パケットキャプチャ一連の処理

図をクリックすると拡大します。


 この図を見て分かるように、パケット遷移の16番目の処理に、1.28秒もかかっています。

 EECとサーバのやりとりを次に示します。

パケットのやりとり

httpsのパケットなので、データの中身については不明ですが、16番目のパケットの処理と言うことで、アプリケーションの動作に問題があることが分かります。


3.WEBアクセスの特殊な例

 WEBシステムは色々と拡張されてきておりますので、同じurlでも、トップと配下に置いてレスポンスが違うことがあります。


例えば、
 https://xxx.yyy.zzz/ へのアクセスと
 https://xxx.yyy.zzz/sampl/ へのアクセス
で表示レスポンスが次のようになりました。

10秒間隔で、30回の試験結果の比較
https://xxx.yyy.zzz/      1.349 秒
https://xxx.yyy.zzz/sampl/   0.452 秒

 必ずしも、階層の浅い方がレスポンスが速いと言うことではないことが分かります。

 試験の対象が、https://xxx.yyy.zzz/sampl/ の場合の試験は、EECの基本機能にはありません。

 この場合には、カスタマイズ試験として実施します。
カタマイズ試験の詳細は、カスタマイズ試験のページをご覧ください。

 お客さま環境により、できるだけ実環境に近い試験を行うため、今回のケースでは、

「EECより、直接、https://xxx.yyy.zzz/sampl/ のコマンドを発行します。」

 次に示すのは、、実際に、コマンドを発行し、ログ情報を蓄積した結果です。コマンドの処理の結果表示と、コマンドの所要時間(処理時間)を記録しています。

コマンドラインからの試験

図をクリックすると拡大します。


この試験を行っている時に、「2.」と同様にパケットのキャプチャをEECから実施します。

パケットキャプチャが実施できれば、どの処理に時間がかかっているかのパケット遷移の分析が可能となります。このようにして、WEBシステムの遅延に関する調査を実施することが可能です。


4.WEBでないシステムの遅延の切り分け

 通常の切り分けは、トータル監視により行うことができます。
詳細は、トータル監視による弊社の保守サービスの特徴のページをご覧ください。

 ブロードバンド化、クラウド化により、ITインフラは複雑になってきておりますので、どうしても不明な点が生じてきます。

このような場合には、利用されているアプリケーションの利用状態をそのままパケットキャプチャーする方法が有効です。

次に示しますのは、パケットキャプチャーをする構成例です。
パケットキャプチャ構成例



 通常は、ミラーリングサイトを設定し、パケットキャプチャを行いますが、タイムリーにかつ短時間で行えるように弊社では、ケーブルの繋ぎ変えにより実現しています。
 不便を感じておられるエンドユーザのケーブルをスイッチ経由に繋ぎ変えます。
 以前は、リピータハブの製品も多くありましたが、現状はスイッチィングハブがほとんどです。ポートミラーリングのあるスイッチを選んで下さい。

スイッチの写真

【参考】
 NETGEAR のGS105Eは、
小型で持ち運び易く、セッテイングも簡単でテンポラリィの試験設置で重宝しています。

NETGEAR のGS105Eへリンク




 次の示すのは、この試験環境にて、PCよりある気象サイトを検索し、そのパケットキャプチャをした例です。

あるサイトへのアクセス結果

図をクリックすると拡大します。

 この検索結果を見て分かるように、
  49517
  49518
  49519
 の3つの検索が並行して行われているのが分ります。

次に、それぞれの検索のパケットの遷移を示します。


【49517のパケット群】
一連の処理パケット(その2)

図をクリックすると拡大します。

【49518のパケット群】
一連の処理パケット(その2)

図をクリックすると拡大します。

【49519のパケット群】
一連処理パケット(その3)

図をクリックすると拡大します。

 このように実際に利用しているアプリケーションをパケットキャプチャすることにより、どのパケットの遷移で時間がかかっているかが分りますので、原因究明の貴重な情報となります。


5.まとめ

 本ページで説明したとおり、

(1)EECの基本機能試験をパケットキャプチャする。
(2)WEBアクセスの実態に沿った試験(コマンドラインからの試験(カスタマイズ試験に準拠)をパケットキャプチャする。
(3)人手により、実際のアプリケーションを動作した試験をパケットキャプチャする。

を実施ることにより、遅延に関する問題点の原因究明に必要な情報を提供することができます。

 パケットキャプチャーのページへ

 トータル監視のページへ

 保守サービス特徴のページへ

 ITサービスレコーダーのページへ

 お問合せのページへ

a:593 t:3 y:3

  

最新の更新 RSS  Valid XHTML 1.0 Transitional