澤部 直太 三菱総合研究所 情報技術研究センター
メディア&ネットワークシステム部
ネットワーク増強だけではないボトルネック対策
トラフィック監視の大きな目的の一つは,ボトルネックの発見です。エンドユーザーから見ると,ネットワークの一部にボトルネックが生じているのか,あるいはブロードキャストなどのためにサブネット全体が遅くなっているのか,通常は区別がつきません。この二つの原因はトラフィック監視の立場から見ると,対処方法は異なります。
![]() |
写真1 MRTGでトラフィック推移を調べて異常を発見する 1台のホストでSNMPエージェントを動作させてトラフィックを計測したところ,決まって朝6時に大量の通信が起こることが判明した。さらにパケットを分析することで,相手のホストとアプリケーションの種類が分かる。 |
ユーザーのトラフィック特性を把握
トラフィックを監視していると,障害や日常的なトラフィック増ではなく,特定時間にトラフィックが増えることがあります。このような場合は,まず個別ユーザーによるアプリケーションの実行を疑います。あるネットワークで,定期的なトラフィック監視のためにサーバー機器の入出力通信量を観測していたことがあります。このときの例を紹介します。
このネットワークでは,各サーバーでSNMPエージェントを動かし,SNMP型ツールの「MRTG」を使って定期的にアクセス状況を調べていました。ある日,1台のサーバーで朝6時ころに大量の通信が毎日起こっていることに気がつきました(写真1[拡大表示])。UNIXサーバーだったので,ユーザーがcronジョブを仕掛けて何かしているのだろうと想像しました。ところが,調べてみても,そのサーバーでは特に問題となりそうなcronジョブは動いていませんでした。
そこで,ネットワーク監視ツールを使いパケットの内容を調べました。cronジョブを用い,朝6時少し前からネットワーク型監視ツールの「snoop」を起動し,どのホストからどのようなパケットが流れてくるのかを監視しました。すると,1台のホストからのNFSによる通信が大量に発生していることが分かりました。そのホストの利用者に聞いてみたところ,ファイルのバックアップを毎朝実施していました。
このケースでは,早朝でネットワーク,サーバーともに空いている時間帯だったので,そのままの利用を認めることにしました。ただし,今後この時間帯にほかのアプリケーションを使うニーズが生まれたり,ほかのユーザーが利用する例が増えた場合には,バックアップの運用を見直してもらうことにしました。
不要なトラフィックは削減する
ユーザー固有のトラフィックがほかの通信に影響を与える場合には,アプリケーションの使い方を変更してもらうことが,コストのかからない一時的な対策として有効な場合もあります。
![]() |
図3 ネットワーク・モニターでホスト間の通信を調べる ホスト間のトラフィックに関して統計をとったところ,あるホスト間のトラフィックが目立って多いことが分かる。次にアプリケーションを調べれば,該当ホストのユーザーと交渉するなどして問題解決につなげられる。 |
幸い,一方のホスト「A」は筆者の管理下のUNIXサーバーだったので,ホストAのsnoopを使い,ホストBとの通信を観察してみました。すると,X-Window通信が大多数を占めていることが分かりました。
ホストBの利用者は把握していたので,まずはそのユーザーのプロセスをホストAで調べてみました。すると,WWWブラウザのプロセスがCPUを占有した状態で動き続けています。ホストB利用者の席でWWWブラウザの画面を見ると,アニメーションGIFを含むページが表示されていました。
アニメーションGIFは,WindowsやMacintosh上でWWWブラウザを動作させる分にはネットワークにパケットを流しません。しかし,X-Windowで別ホストのWWWブラウザを表示する場合には,アニメーションが動くたびに多くの通信が発生してしまいます。このケースでは,ローカル・ホストのWWWブラウザを使用してもらうことにして問題を解決しました。