図1　A社はADSLを導入したところセンター側の回線がボトルネックになってレスポンスが極端に低下
ADSL導入によりセキュリティが甘くなったため，パソコン起動時にセンターのサーバーからソフト情報をダウンロードするようにした。ところがパケット廃棄が頻発し，レスポンスが極端に低下した。

一斉ダウンロードでレスポンス低下

　ところがシステム変更早々，各拠点から「レスポンスが悪い」，「センターにアクセスできない」といったクレームが殺到。クレームは，各拠点が業務を開始する午前9時以降に集中して発生していた（図1[拡大表示]）。

　午前9時の業務開始時の通信状況を解析すると，TCPの再送が多発していることが判明。センターから拠点方向でパケット・ロスが多発していた。

　理由はすぐに分かった。朝，拠点のパソコンを起動した時点で，ソフトのバージョン情報など大量のデータがセンターからダウンロードされるためだ。センターと接続しているインターネット接続事業者（プロバイダ）の回線容量を超えるトラフィックが発生したため，「ルーターがパケットを廃棄，サーバーがパケットを再送」という悪循環に陥っていた。

図2　A社は帯域管理装置およびグループウエアのAPIを変更することでレスポンス低下を解決
最初に帯域管理装置を導入。スループットは改善したが，グループウエア・クライアントのレスポンスは悪いままだった。そこでグループウエアのAPIをMAPIからWebアクセスに変更した。
　そこでA社は，センター拠点に帯域管理装置を導入することを決定。まず，プロバイダにつながる回線のスループットを測定し，帯域管理装置に測定したスループットを設定。センターからプロバイダに向かうトラフィックを，スループットに合わせた（図2[拡大表示]）。これにより，業務開始直後の極端なレスポンス低下は解消された。

グループウエアのAPIも変更

　ただ，グループウエアのクライアントだけは，「通常業務中でもレスポンスが悪い」という苦情が続いた。A社のグループウエアは，LANでの使用を前提に設定されていた。

　グループウエアのクライアントは，MAPIを使っていた。MAPIは小さなパケットでやり取りするため，総パケット量が多くなる。各パケットはそれぞれ，網内遅延分だけ遅れて相手に到達。トータルの応答時間が極端に増えてしまっていたのだ（図2[拡大表示]）。

　A社のグループウエアでは，MAPI以外に「汎用POP/IMAP」，「Webアクセス」を利用できる。A社は，MAPIの使用を中止し，サーバーの設定を「Webアクセス」に変更。クライアントにはWebブラウザを使うようにした。

　これにより，レスポンスに対するクレームは完全になくなった。