パケットキャプチャーはネットワークトラブルを解決する切り札になる。現在はフリーソフトで安価にパケットをキャプチャーできる。パケットキャプチャーの実現方法と留意点を説明する。

 企業ネットワークのトラブル解決には「パケットキャプチャー」を用いることが多い。ネットワーク上を流れるトラフィックをイーサネットフレーム単位でキャプチャー(採取/蓄積)し、これらを解析・可視化して問題解決の糸口を見いだすわけだ。今回はパケットキャプチャーを使ってトラブルを解決した事例と、パケットキャプチャー利用時の留意点を解説する。

レスポンスの悪化でログイン不可に

 A社は社内向けWebシステムを更改したところ、直後に不特定のユーザーが不定期にログイン不可となるトラブルが発生した。Webサーバーの手前に配置するロードバランサー(負荷分散装置)も更改対象だったため、当初は機器更改に伴うネットワーク障害を疑った。だが、ロードバランサーのログやステータスを確認しても、動作上の問題は見つからなかった。Webサーバー側にもエラーは発生しておらず、解決は難航しそうだった。

図 A社で発生したトラブルの例
Webシステム更改後に不特定のユーザーがログインできなくなった
[画像のクリックで拡大表示]

 トラブルの解決には、ロードバランサーに備わっていたパケットキャプチャー機能が役立った。障害発生時のパケットデータを採取した結果、2点の事実を確認できた。

 1つ目は、ロードバランサーからWebサーバーに一定間隔で定期送信するヘルスチェックパケットが正常に機能していたことだ。ロードバランサーは、レイヤー7(HTTPベース)のヘルスチェックパケットをWebサーバーに送信していた。Webサーバーはヘルスチェックパケットに対して、ミリ秒単位で応答を返し続けていた。

 2つ目は、ユーザー端末上のWebアプリケーション(Webクライアント)からWebサーバーへの通信(HTTPベース)の遅延である。パケットキャプチャーで確認すると、トラブル発生の前後でWebサーバーからの応答時間が遅くなり、最終的にレスポンスが秒単位まで悪化していた。

 Webサーバーは処理が遅れながらも応答パケットを返送していたため、エラーにはならなかった。しかし、アプリケーション側は許容できる応答遅延(1秒以内)を超過し、ログイン処理が失敗したと判断していたことが分かった。更改前のシステムではレスポンスが悪化したことは無く、Webサーバーとアプリケーションの挙動の差異が見逃されていた。

 これらの解析結果を踏まえ、Webサーバーをさらに調査した結果、ユーザー情報を管理するデータベースで更改後のデータ構造に不備が見つかった。ログイン中のユーザー数が増大した際、走査時間が極端に悪化する不具合が判明したのだ。

 このように想定外のトラブルに遭遇しても、パケットキャプチャーを活用することで、客観的なエビデンスに基づいた障害調査が可能となる。

レイヤー7▼
OSI参照モデルのレイヤー7(アプリケーション層)のこと。

この先は有料会員の登録が必要です。「日経コンピュータ」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら