トラフィック計測で見直すネットワーク構成基礎から学ぶネットワーク構築(5)

» 2001年05月19日 00時00分 公開
[篠原光太郎@IT]

 本特集のPart1〜4では、ネットワークの構成図を作図し、ネットワークの配線や基本的な構成を確認しました。Part5以降では、さらに、「ネットワークの使われ方」を調査することで、「最適なネットワークを構築する」ことを主題に話を進めていきたいと思います。

ネットワークトラフィックを理解する

 皆さんのネットワークは、どのような目的で使用されているでしょうか。ファイル共有やインターネット接続、もしくは、業務用アプリケーションのサーバ/クライアント環境など、多種多様な目的で使用されていることでしょう。

 ネットワークは一度構築してしまえば、このようにいろいろな目的で使用することが可能であるため、「便利だ」と感じることも多いはずです。この4?5年でLANやWANの導入が急速に進んだのも、この便利さが理由として挙げられるでしょう。そして、いまとなっては、便利さを通り越して、「なくては業務にならない」必須のシステム機能として位置付けされていることと思います。

 ところが、一度ネットワークで問題が発生すると、これが逆にあだになることも多いのではないでしょうか。例えば、「パフォーマンスが悪い」とユーザーからクレームがあがったとします。Part1?4で紹介したような方法で物理的な接続を確認しても、特に問題は見つかりません。そうなると、本当に何らかの理由でネットワーク回線が混雑している可能性があります。ただし、「何」が理由でネットワークがそんなに利用されているのかは、調査しないと分かりません。調査をするためには、ある程度ネットワークに精通している必要があります。「ネットワークの混雑原因の調査」といっても、どこからどう手を出してよいのか分からない、という管理者の方も多いのではないでしょうか。

 ネットワークを伝わる情報量を、「トラフィック」と呼びます。「トラフィックが多い」といえば、ネットワークを伝わる情報量が多いことを表します。ネットワークを伝わる情報量の考え方は、道路の交通量の考え方と似ていることから、トラフィックという名称で呼ばれています。

 では、ネットワークのトラフィック特性を理解し、ネットワークの正しい構成を見つけ出す、という手順で「ネットワークのパフォーマンスが悪い」という問題の解決方法を考えていきましょう。

ネットワークトラフィックとは?

 それでは、トラフィックにはどのような種類があるのかを考えてみましょう。ネットワークを伝わる情報には大きく分けて、1対1のトラフィックと、1対多のトラフィックの2つに分類できます。1対1のトラフィックとは、送信する側が受信する側を特定できている場合に発生します。通常のデータ転送時は基本的に、1対1のトラフィックになるはずです。例えば、PCからサーバへのファイル転送などがこれに当たります。

図10 1対1と1対多の通信。1対1の通信では、特定の1つの端末だけにデータが届くが、1対多の通信では、同じセグメント内に存在するすべての端末にデータが届く 図10 1対1と1対多の通信。1対1の通信では、特定の1つの端末だけにデータが届くが、1対多の通信では、同じセグメント内に存在するすべての端末にデータが届く

 一方、1対多のトラフィックは、大きく分けると2つの場合で発生します。制御用のトラフィックと、マルチキャストと呼ばれる通信手段によるトラフィックです。制御用のトラフィックは特に、1対1の通信を開始する前に、通信する相手が特定できていない場合に発生します。例えば、通信を最初に実施する場合は、通信する相手のネットワーク上での名称(例えば、SalesFSなどのサーバ名称などがこれに相当します)は分かっているが、物理的なアドレス(MACアドレスなど)は分かっていないことがほとんどでしょう。このような場合は、幾つかの段階は経ますが、最終的に通信する相手の物理的なアドレスを取得するために、ネットワークに接続されているすべての機器に対してブロードキャストを発信し、該当する機器が応答するのを待つ、という仕組みになっています。このとき発生するブロードキャストは、データ転送には関係はないが制御用に必要になる1対多の通信の1つですね。

 もう1つの1対多の通信は、マルチキャストと呼ばれる通信手段によるトラフィックです。例えば、映像サーバから映像をリアルタイムで取得して表示させるアプリケーションは、1対1で通信すると非効率なため、映像が必要な端末に対して映像のデータを同報することでデータを送信します。テレビは電波によって連続的に送信されている信号をテレビが受信して、必要なチャンネルのデータを選り分けて表示させる、という仕組みですね。マルチキャストは、このテレビの方式と似ています。

 業務用に構築されているLANの環境で、マルチキャストによるアプリケーションを構築しているところはまだそう多くはないと思いますし、制御用の1対多のトラフィックは通常、トラフィック量としては多くはないため、ここでは特に、「1対1」のトラフィックに注目して話を進めたいと思います。

トラフィックのパターンを理解する

 実際に、どのようなトラフィックが発生するのでしょうか。トラフィックを理解するためには、まず、机上でどのようなトラフィックが発生し得るかを理解しておくことが大切です。

 トラフィックはデータの情報量ですので、どのくらいの頻度で、どのくらいの量が転送されるのかを把握することで、大まかなトラフィック総量を求めることができます。

  では、Part3で紹介したSalesNetを例にとって、トラフィックパターンを列挙してみましょう。

例1 SalesNetのネットワーク構成図(図面をクリックすると拡大表示します) 例1 SalesNetのネットワーク構成図(図面をクリックすると拡大表示します
タイプ 開始点 終了点 頻度
ファイル転送 PC1〜10 SalesServer1 1回/5分 100Kbytes
ファイル転送 PC31〜40 SalesServer2 1回/5分 100Kbytes
ファイル転送 PC61〜70 SalesServer3 1回/5分 100Kbytes
ファイル転送 PC1〜70 SalesFS 1回/60分 100Kbytes
ファイル転送 営業部外 SalesFS 1回/60分 100Kbytes
プリント出力 PC1〜10 SalesServer1 1回/30分 500Kbytes
プリント出力 PC31〜40 SalesServer2 1回/30分 500Kbytes
プリント出力 PC61〜70 SalesServer3 1回/30分 500Kbytes
メール受信 PC1〜70 SalesMail 1回/5分 5Kbytes
メール送信 PC1〜70 SalesMail 1回/30分 1Kbytes
Webアクセス PC1〜70 SalesRT2 1回/30分 1Mbytes
Webアクセス PC1〜70 SalesWeb2 1回/30分 500Kbytes

 実際には、さらに多くのトラフィックを列挙することができるでしょう。

 ここで、例えば、10%のファイル転送と10%のプリント出力が仮に同時に発生したときが最大値と考え、そのときのレスポンスタイム(転送を開始してから終了するまでの時間)を3秒以内とすると、SalesNetに必要な帯域は次のとおり計算することができます。

【ファイル転送に必要な帯域】
[転送量]
=30(台)×10%×100(Kbytes)=300(Kbytes)
[帯域幅] =300(Kbytes)×8(bits)÷3(秒)=800(Kbits/s)

【プリント出力に必要な帯域】
[転送量]
=30(台)×10%×500(Kbytes)=1500(Kbytes)
[帯域幅] =1500(Kbytes)×8(bits)÷3(秒)=4000(Kbits/s)

【最大時に必要な帯域】
800(Kbits/s)+4000(Kbits/s)=4800(Kbits/s)=4.8Mbits/s

 SalesNetで使用しているイーサネット 10BASE-Tは、規格上の帯域幅は10Mbits/sですが、実際にデータを転送できる帯域幅としては6M?7Mbits/sです。イーサネットでデータが転送されるときは、パケットと呼ばれるデータの転送単位に区切られて送信されます。パケットには、あて先のアドレスなど、実際のデータとは関係のない制御用のデータも含まれるためです。

図11 パケットの仕組み。パケットに分解されたデータはネットワーク上に送出される前に、各種の制御用情報が付加されていく 図11 パケットの仕組み。パケットに分解されたデータはネットワーク上に送出される前に、各種の制御用情報が付加されていく

 これらのイーサネットの実際の帯域を考慮してみても、上記の試算ではSalesNetにはイーサネット 10BASE-Tの帯域で足りている、という結果を導き出すことができますね。

 上記のSalesNetの例では、最大時のトラフィック量を「ファイル転送とプリンタ出力が10%の同時利用率のとき最大」という仮定をおきました。最大時のトラフィックをどう見積もるかは、経験則に頼らざるを得ないところがあります。試算のときに用いた仮定を実際の値に近づけるためには、実際に計ったトラフィック量と照らし合わせて、試算のロジックが正しいかどうかを見極めて、必要に応じて見直していくことがポイントとなります。

イーサネットでは「フレーム」と呼ばれますが、簡便化のためパケットとします



Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。