障害事象

A社において、ある月曜日の午前中、インターネットへのアクセスが非常に遅い事象が発生し、全社のユーザが影響を受けました。事象は勤務時間開始後から午前中いっぱい継続し、午後には通常の状態に復旧しました。

A社ネットワーク環境

A社のネットワーク構成は事例1と同様です。インターネット通信のトラフィックは、本社内に設置されたProxyサーバを経由して、インターネットGWからインターネットに流れています。オフィス外のリモートユーザはVPNゲートウェイ経由で本社のネットワークに収容されています。(図1)

Proxyサーバは4台設置され通信内容によってトラフィックが振り分けられています。一般のwebアクセストラフィックはProxy1、Proxy2で処理され、メールやweb会議を含むMicrosoft365トラフィックはProxy3、Proxy4にバイパスされ負荷分散が行われています。インターネットGWの回線速度は100Mbpsで、ユーザ600名のインターネット通信を収容しています。

原因調査

MRTGツールでインターネットGWのトラフィック統計を確認したところ、その日の午前中の下り(インターネットからA社)のトラフィックが午前中いっぱいほぼ帯域上限(100Mbps)に達した状態が継続していました。(図2の青の折れ線グラフ)

サーバスイッチのミラーポートに接続されたNetEyez (図1) でProxyサーバ経由のインターネットトラフィックの傾向を確認したところ、同様の傾向が観測されました。(図3のグリーンの折れ線グラフ)

また、その日のホスト別のトラフィック順位を見ると、全社のweb通信を収容するProxyサーバを抑え、特定のユーザ端末Host Aが最も多くのトラフィックを発生させていました。(図4)

Host Aの通信相手を確認したところ、ほとんどがProxyサーバ経由のインターネットトラフィックでした。(図5)

Host AのProxyサーバ経由の通信先を確認するため、NetEyezのWEBエンドツーエンド解析画面を確認したところ、Host Aがインターネット上のオンラインストレージに大量のHTTPコマンドを発行していることが判明しました。(図6)

ソリューション

原因：事象の発生要因は大量データのダウンロード

IT部門の担当者がHost Aのユーザに当日の業務についてヒアリングを行ったところ、当日の午前中にインターネット上のオンラインストレージから大量のデータのダウンロードを行っていたとのことでした。A社は通常、休日明けの月曜の午前中は通信量が多い傾向がありますが、そこに今回のユーザのアクティビティが重なりネットワークの輻輳を引き起こすことにつながりました。

対策：ユーザへの依頼

A社ではインターネット接続の帯域の拡張を計画中でしたが、Host Aのユーザには当面は今回のような大量のデータ通信を伴う作業は、なるべく一般社員の業務に影響しない時間帯に行うよう依頼しました。

事例紹介に関するお問い合わせ

phone03-3245-1250