ネットワークトラブルを解決する

特集：ネットワークトラブルを解決する

レスポンスの悪いネットワークシステム
どう検証し、解決していくか？

西村稔
ネットマークス
2000/9/14

　5. トラフィックの評価・検証方法（2）

■Point-3　ネットワークを「レスポンス」で評価

　ルータ間や端末間のレスポンスを統計的に測定することで、ネットワーク上のどの箇所で遅延が発生しているかを特定することが容易になる。

　アプリケーションのレスポンス低下が検出される状況とは、「最近レスポンスが遅くなってきた」「朝一番はサーバの応答が遅い」といったように、ユーザーが自分の操作環境において感じるものであり、しかもその表現は一般的にあいまいなものである。ネットワークをレスポンスで評価することは、ユーザが感じるレスポンス低下の状況を定量的に数値化し、その原因箇所を特定するのに有効な手段である。例えば、ルータ間のレスポンスは低下していないにもかかわらず、端末間のアプリケーションのレスポンスが遅くなってきたとすれば、この原因は端末が接続されているローカルのネットワークか、もしくは端末の内部処理に原因があるものと容易に推測できる。

　また、レスポンスの傾向を中長期の統計として評価しておけば、レスポンス低下の予兆を検出し、ユーザーがレスポンス低下を感じる前に対策を打つ、といったサービスレベルの維持にも有効な手段になる。

図8　ポイント間でのレスポンスを測定する

　ネットワーク監視装置からのレスポンス測定では、ネットワーク監視装置を設置したポイントを基準にしたレスポンスしか測定することしかできない。すなわち、実際にレスポンスが知りたいルータ同士や、端末～サーバ間といったネットワーク上の任意のポイント間（End to End）の測定が実現できないことになる。このため、レスポンスの評価を実施するにあたっては、レスポンス測定を実施するエージェント機能をルータや端末に実装し、この結果をネットワーク監視装置で統計処理するという手法がとられる。

　ルータの機種によっては、ルータ自身からICMPエコー（ping）やTCPフレームを任意の対象に定期的に送信し、そのレスポンスを測定する機能を持つものがある。また、端末やサーバに実装するエージェントソフトでは、ルータと同様に定期的にフレームを送信してレスポンスを測定したり、WWWやNotesといったより上位層のレスポンスの統計を測定する機能を持つものがある。これらのエージェント機能によって測定されたレスポンスを、ネットワーク監視装置で吸い上げてグラフ化するなどの処理が行われる。

■Point-4　アプリケーションの通信形態を検証

　アプリケーションのレスポンスは、ネットワークの性能と共にその通信形態やデータ量に大きく依存するものである。特にネットワークの帯域が小さいWAN回線等においては、非効率な通信形態は大きな遅延を生む原因となる。

　例として、合計32KBという同じデータ量を、サーバ～端末間の通信形態を変えてWAN回線上で転送した場合を想定してみる（図9）。通信形態1では、32Byteのデータ送信ごとにAckを待つものであり、通信形態2は32Byteのデータをまとめて10個送信しAckを待つ。さらに、通信形態3は1400Byteのデータをまとめて10個送信してAckを待つものである。まとめてデータを転送できるという観点から、通信形態1よりも通信形態2が、さらに通信形態2よりも通信形態3の方が効率のよいものとなっている。

図9 同じサイズのデータを異なる3つの通信形態で転送した場合の通信効率

　このような3つの通信形態について、ネットワークシミュレーションによってレスポンス時間を検証した結果を図10のグラフに示す。合計32KBという同じデータ量を転送するのにも、通信形態1では22秒、通信形態2では約12秒、通信形態3では約2秒という大きな差が生じる結果となった。また、これら3つの通信形態を10Mbpsのイーサネット上で実施した場合のレスポンスについてもグラフに示してあるが、いずれの通信形態においても1秒とかからずに転送は完了している。

図10　イーサネットにおける差はわずかだが、低速なWAN回線においては大きな差となる

　このように、アプリケーションの通信形態とネットワークの帯域によってネットワーク上の遅延時間は大きく差が出てくるものなのである。なお、このシミュレーション結果はサーバやクライアントの遅延は考慮していないため、実際にユーザーが待たされるレスポンス時間はこれよりも長いものになると考えられる。

　ここで注目しなくてはならないのは、通信形態1のようなアプリケーションをイーサネット上で開発したとすると、開発環境ではユーザーが満足するレスポンスが得られてしまうかもしれない点である。開発環境では何の問題もなく動作するアプリケーションが、WAN回線経由で使い始めたとたんに数十秒、あるいは数分間も待たされることになり、実際の運用には耐えられない代物になってしまうのである。このことからも、ライフサイクルにおいてトラフィックの評価／検証が重要であることがうかがい知れる。

　また、アプリケーションの通信形態やそのデータ量を検証することは、特にアプリケーションを大規模に導入する場合の事前評価以外にも、あるアプリケーションに特化したレスポンス低下の切り分けに有効である。通信形態を把握してその遅延の割合を分析することにより、ネットワークを改善すればよいのか、サーバやクライアントを改善すればよいのかが、おのずと見えてくるであろう。

　なお、このようなアプリケーションの通信形態を検証するためには、アプリケーションが発生する生のトラフィックデータを収集して分析する必要があるため、アナライザに相当する専用装置やソフトウェアを利用することになる。なお、通信フレームが数百、数千になるようなアプリケーション通信であれば、これを人間が1フレームずつ分析することは現実的ではない。このような場合には、アプリケーションのセッション単位で発生トラフィックのフレーム数やフレームサイズ等の統計を分析したり、遅延の割合を解析できるようなアナライザや解析用のソフトウェアを利用することが必要になる。

　ネットワークはその存在自体が目的ではなく、その上で稼動するアプリケーションが「快適」に稼動してこそ、その存在意義がある。いくら高速なネットワークでも、数年前のように離れた場所と単に通信できるだけで満足する利用者はもういないであろう。そして、「快適」な利用環境を実現し維持していこうとすれば、ネットワークシステムの運営というライフサイクルの中で、トラフィックやレスポンスの評価・検証の重要性は自然に高まってきているのである。

Index
特集：ネットワークトラブルを解決する
	1. ネットワークのライフサイクル
	2. ネットワーク構築の失敗事例　事例1：耐えられないレスポンス　事例2：改善されないレスポンス
	3. 遅延の構成要素
	4. トラフィックの評価・検証方法（1）　-トラフィックを「量」で評価　-トラフィックを「質」で評価
	5. トラフィックの評価・検証方法（2）　-ネットワークを「レスポンス」で評価　-アプリケーションの通信形態を検証

「Master of IP Network総合インデックス」

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疑似デバイスの作成も可能だ。