特集：ネットワークトラブルを解決する
レスポンスの悪いネットワークシステム
どう検証し、解決していくか？
西村 稔
ネットマークス
2000/9/14
| 2. ネットワーク構築の失敗事例 |
では、ライフサイクルにおいてトラフィックやレスポンスに関する検討が行なわれなかった場合、実際にはどのような問題に直面するのだろうか？
ここでは、ネットワークトラフィックを十分に検討していなかったために、ネットワークを増強したもののレスポンスが改善されない、あるいは期待したレスポンスが得られない、といった失敗事例を紹介していく。
■事例 1：耐えられないレスポンス
本社にサーバを集中配置したクライアント／サーバ方式の新規アプリケーションシステムの全社的な導入を計画していたある企業では、開発環境における機能テスト、および応答性のテストを無事完了し、実ネットワーク環境へのインストール作業を開始した。しかし、開発環境では数秒以内には返ってきていたサーバからのレスポンスが、拠点に設置されたクライアントからは数分、場合によっては数十分もかかってしまうという問題が発生した。もちろん、ユーザーとしてはクライアントの画面上で数分も待たされることは運用上許容できるものではなく、この新規アプリケーションは使い物にならない代物になってしまったのである。
 |
| 図2 本番環境に移行したとたんレスポンスが低下した例 |
このレスポンス低下の原因は、クライアント〜サーバ間で多量の小さなフレームのやり取りが行なわれていたため、WAN回線やルータの遅延が累積されることにより、全体として非常に大きな遅延になってしまったものであった。ただし、この遅延は開発環境であるイーサネット上では無視できる程度であったため、開発やテスト段階では全く気が付かなかったのである。また、拠点によってはWAN回線を既存トラフィックが圧迫しており、ネットワーク上の遅延がより大きなものとなっていた。
このような問題は、アプリケーションの発生トラフィックの検証、もしくはWAN回線という狭い帯域を想定した応答性のテストや、現状トラフィックの評価作業がライフサイクルの中で考慮されていれば避けられたと考えられる。もちろん、これらの評価を行うためにはそれだけの手間、すなわちコストを伴うものである。しかし、実環境で問題が発生してから原因を切り分け、さらに導入スケジュールを立て直す、といった手間と、問題が発生すれば当然利用者からの信頼を失う、ということを考えれば、事前評価のコストは決して高いものではないのである。
■事例 2：改善されないレスポンス
ある企業のIT部門では、最近ネットワークの利用者からサーバのレスポンスが遅くなってきたというクレームを受ける機会が増えてきた。このためIT部門としては、サーバのレスポンス改善を目的にネットワーク増強について検討を開始した。
まず、最近クライアントが増設されたこと、また、クライアント〜サーバ間で転送されるデータ量が増加傾向にあるというユーザーからのヒアリング結果から、ネットワーク上のトラフィックが増加しているものと判断した。さらに、クライアント〜サーバ間のトラフィックが増えた場合には、ネットワークの構成上、トラフィックが集中するサーバ・セグメントがボトルネックとなっているだろうという予測を立てた。このため、サーバへの帯域確保を目的に、現在利用している10Mイーサネットのルータを100Mイーサネットに対応したレイヤ3スイッチにリプレースして、100Mbpsの帯域がサーバで専有できる構成にリプレースを行った（図3）。しかしながら、ネットワークのリプレース後にもサーバのレスポンスは全く改善されず、利用者からのクレームはいっこうに減ることはなかった。
 |
| 図3 ボトルネックの場所を誤って判断した例 |
これは、レスポンス低下を招いていた原因が、ネットワークではなくサーバの処理性能にあったためである。サーバが処理するデータが増えたためにサーバ自身の負荷が高まりクライアントに対するレスポンスが低下していたのだった。実際にネットワークの帯域にはまだまだ余裕があったのである。
これも、現状のトラフィックの評価がライフサイクルの中で行われていれば、定量的な測定結果からネットワーク帯域には余裕があることが判り、遅延の原因はネットワーク以外にあることは容易に想像できただろう。特に改善を目的とするネットワークリプレースにおいては、問題の原因を的確に（可能な限り定量的に）把握しておかなければ、問題の見極めを誤り期待通りの結果が得られないという状況も充分にあり得るのである。
なお、IT部門としては、最終的に原因を特定してサーバの増強や分散によりユーザーのレスポンスを改善でき、増設されたネットワーク帯域やレイヤ3スイッチを有効に活用できたことが唯一の救いであった。
| 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疑似デバイスの作成も可能だ。
 |
|
|
|
|
注目のテーマ
Master of IP Network 記事ランキング
転職／派遣情報を探す
