特集:ネットワークトラブルを解決する
レスポンスの悪いネットワークシステム
どう検証し、解決していくか?
西村 稔
ネットマークス
2000/9/14
4. トラフィックの評価・検証方法(1) |
前章で示したように、アプリケーションレスポンスの遅延割合を把握して、これを前提にネットワークの増強を行うことは、レスポンスの改善に向けて非常に効果的なものではある。しかしながら、実際のネットワーク上には様々なアプリケーションが、様々な端末同士で通信を行っており、これら全てのアプリケーション通信について遅延分析を行うとことは、作業量から考えても現実的なものではない。
このため本章では、ネットワーク改善の指針となるようなデータを把握するための、トラフィックの評価・検証方法についていくつか説明を行っていく。
■Point-1 トラフィックを「量」で評価
ネットワーク機器が送受信するトラフィック「量」を把握することによって、ネットワークのどこにトラフィックが集中しているか、どのような時間帯にトラフィックが増加するのかといった、ネットワークトラフィックの全体像を分析することが可能になる。また、中・長期的にこれらのトラフィックデータを分析すれば、トラフィックの増加傾向から、利用率が高くなってアプリケーションのレスポンスに影響が出る前に、ネットワーク改善の検討を開始するといった性能障害の早期予防も可能になる。
一般的に、トラフィック量を把握するためには管理プロトコルであるSNMP(Simple Network Management Protocol)が利用される。SNMP対応のネットワーク機器は、インターフェイスの送受信量やエラー量、また機器によってはCPU利用率やバッファの利用状況等の情報をMIB(Management Information Base)と呼ばれるデータベースに保持している。ネットワーク監視装置(SNMPマネージャ)は、各ネットワーク機器にSNMPポーリングを行い、ネットワーク機器が保持するこれらの情報を吸い上げてデータを表示させたりレポートを作成したりする。
図6 WAN回線、ルータ(R)、スイッチ(SW)、それぞれの箇所でのトラフィックを収集する |
SNMPを利用したトラフィックの評価は、ネットワーク機器がSNMP対応であればマネージャを導入することで比較的容易に実現できる。しかし、その運用方法については事前に十分な検討を行っておかなければ、運用負担が大きくなる可能性があるので注意が必要である。例えば、トラフィック量をグラフ化したレポートをネットワーク機器のインターフェイスごとに毎日1枚作成する運用を想定する。ここで、監視するネットワークがある程度の規模であり、インターフェイスの数が仮に合計200程度あったとしよう。この場合、1ヶ月に作成されるレポートは6,000枚にもなってしまうのである。
200インターフェイス × 30日 = 6000枚
|
もしも、SNMPマネージャが自動的にレポートを作成してくれたとしても、1日200枚、1ヶ月6000枚のレポートを評価する運用管理者の負担はとても大きなものになってしまうであろう。また、トラフィック量とエラー量の推移を比較して評価したい、といった場合にも、これが簡単に実現できないSNMPマネージャであれば、運用管理者の負担はさらに大きくなるだろう。実際に、SNMPマネージャを導入してトラフィック監視を開始したものの、その運用負荷に耐えられずに監視をあきらめている管理者は以外に多いのである。
このような状況を避けるためには、トラフィック監視の運用に割けるリソースを考慮した上で、事前に表1のような項目について十分検討しておく必要がある。
|
||||||||
表1 事前検討項目の例 |
■Point-2 トラフィックを「質」で評価
前述のように、トラフィックを「量」で評価した場合には、例えばあるセグメントの利用率が高いことが分かっても、どの端末同士の通信が多いのか、また、どのようなプロトコルが流れているのか、といったトラフィックの詳細は把握できない。これは、一般的なネットワーク機器はこのようなトラフィックの詳細情報までは保持していないからである。
このため、トラフィックの詳細情報、すなわちトラフィックの「質」を評価するためには、Probeと呼ばれるトラフィック情報を収集するための専用装置や、ネットワークアナライザを利用して実現することになる。専用の機器を必要とする性質上、「質」の評価はサーバセグメントや基幹WAN回線等、主要部分にターゲットを絞って行われるのが一般的である。
トラフィックを「質」で評価する目的としては、トラフィックの構成要素を把握することにより、より最適なネットワーク構成を導き出したり、通信の優先順位を決定する元データにすることがあげられる。
例えば図7において、WAN回線トラフィックの利用率が高くなり、A地区とB地区間でのアプリケーションのレスポンスが遅くなってきたとしよう。ここで、単にWAN回線の帯域をアップさせることも1つの解決策ではあるが、場合によっては単にWAN回線を増強しただけでは、期待するようなレスポンスの改善が行われないこともある。もし、WWW(http)やFTPのような通信が業務アプリケーションの通信を圧迫していたとすると、WAN回線の速度を上げても、今までWAN回線がボトルネックとなっていたWWWやFTPがより多く流れることになり、やはり業務アプリケーションは圧迫され続けることもあるからである。
ここで、WAN回線上のトラフィックを「質」で捉え、トラフィックの流れや構成要素を分析することにより、より効果的な改善策が見えてくることになる。
図7 トラフィックの内容を分析し、どのアプリケーションがWAN回線を圧迫しているのかを把握する |
もしも、WAN回線を流れるトラフィックの多くがA地区からインターネットへ向かう通信であることが判明すれば、A地区にインターネットへの出口を作ることによって、これらのトラフィックをWAN回線から取り除くことが可能になる(もちろん、インターネット接続を行う際のセキュリティポリシーや、WAN回線増強コスト、インターネット接続コスト等について検討を行う必要はあるが)。
また、A地区とB地区間の業務アプリケーションのレスポンスが低下した状況で、WAN回線のトラフィックを分析したところ、トラフィックの多くがWWWやFTPで占められていたとする。この場合、業務アプリケーションの通信が他の通信に圧迫されていることが考えられるため、ルータの優先制御機能や帯域制御装置によって、業務アプリケーションの通信をWAN回線上で優先する措置を行うことが有効であると判断できる。
このように、トラフィックを「質」で捉えることにより、ネットワーク構成を変更して最適な通信経路を確保したり、トラフィックの内容によって優先制御を実施する等の、いわゆるトラフィックの“交通整理”が行えることになる。
Index | |
特集:ネットワークトラブルを解決する | |
1. ネットワークのライフサイクル | |
2.
ネットワーク構築の失敗事例 事例1:耐えられないレスポンス 事例2:改善されないレスポンス |
|
3. 遅延の構成要素 | |
4. トラフィックの評価・検証方法(1) -トラフィックを「量」で評価 -トラフィックを「質」で評価 |
|
5.
トラフィックの評価・検証方法(2) -ネットワークを「レスポンス」で評価 -アプリケーションの通信形態を検証 |
|
「Master of IP Network総合インデックス」 |
- 完全HTTPS化のメリットと極意を大規模Webサービス――ピクシブ、クックパッド、ヤフーの事例から探る (2017/7/13)
2017年6月21日、ピクシブのオフィスで、同社主催の「大規模HTTPS導入Night」が開催された。大規模Webサービスで完全HTTPS化を行うに当たっての技術的、および非技術的な悩みや成果をテーマに、ヤフー、クックパッド、ピクシブの3社が、それぞれの事例について語り合った - ソラコムは、あなたの気が付かないうちに、少しずつ「次」へ進んでいる (2017/7/6)
ソラコムは、「トランスポート技術への非依存」度を高めている。当初はIoT用格安SIMというイメージもあったが、徐々に脱皮しようとしている。パブリッククラウドと同様、付加サービスでユーザーをつかんでいるからだ - Cisco SystemsのIntent-based Networkingは、どうネットワークエンジニアの仕事を変えるか (2017/7/4)
Cisco Systemsは2017年6月、同社イベントCisco Live 2017で、「THE NETWORK. INTUITIVE.」あるいは「Intent-based Networking」といった言葉を使い、ネットワークの構築・運用、そしてネットワークエンジニアの仕事を変えていくと説明した。これはどういうことなのだろうか - ifconfig 〜(IP)ネットワーク環境の確認/設定を行う (2017/7/3)
ifconfigは、LinuxやmacOSなど、主にUNIX系OSで用いるネットワーク環境の状態確認、設定のためのコマンドだ。IPアドレスやサブネットマスク、ブロードキャストアドレスなどの基本的な設定ができる他、イーサネットフレームの最大転送サイズ(MTU)の変更や、VLAN疑似デバイスの作成も可能だ。
|
|