高速で機能的なネットワーク構築のために
ネットワークの帯域幅要求を算出する方法
いつでも構成・再構成できるサーバとは異なり、帯域幅はネットワークを最初に構成する時点で最適化しておく必要がある。必要となる帯域幅は、どうやって求めればいいのだろうか。
帯域幅に対する要求はネットワークによって異なる。毎秒何ビットのデータがネットワーク上を行き交い、各アプリケーションがどれだけ帯域幅を使用するかを求めることは、高速で機能的なネットワークを構築・運用する上で不可欠だ。
多くのネットワーク管理者が言うように、ネットワーク帯域幅は機能的なLANまたはWANを設計・運用する上で最も重要なファクターの1つだ。ネットワークの運用期間を通じていつでも構成・再構成が可能なサーバとは異なり、帯域幅はネットワークを最初に構成する時点で最適化しておく必要のあるネットワーク設計要素の1つだ。ネットワークを設計する際に、将来必要となる帯域幅をどうやって求めればいいのだろうか。本稿ではこういった疑問に答えたい。
帯域幅とは、ネットワークコネクション、あるいはネットワークに接続するインタフェースがサポートするデータ転送速度を指す。通常はビット/秒(bps)で表されるが、バイト/秒(Bps)という単位が用いられることもある。ネットワーク帯域幅は、ネットワークコネクションの容量を表すが、理論上のスループットと実際の転送能力の違いを理解することが大切だ。例えば、1000BASE-T(UTPケーブルを使用)のギガビットイーサネット(GbE)ネットワークは理論上では1000Mビット/秒(Mbps)をサポートするが、実際にはハードウェアとシステムのオーバーヘッドがあるため、決してこのレベルを達成することはできない。帯域幅の計算が難しいのは、こういった問題があるからだ。
では、必要となる帯域幅はどうやって求めればいいのだろうか。このプロセスは正しい質問をすることから始まる――どのようなアプリケーションを運用するのか、これらのアプリケーションのパフォーマンスに関するSLA(Service Level Agreement)の内容はどうか、といった質問だ。筆者が知っているネットワーク管理者の中には、VLAN上のユーザー数だけを考慮すればいいという人もいる。本当に知らなければならないのは、ユーザーがネットワーク上で何をするのかだ。ユーザーが200人であっても、時代遅れのクライアント/サーバアプリケーションを利用してネットワークを酷使する3人のユーザーのグループよりもボトルネックになりにくいこともあり得る。
ネットワーク帯域幅を算出する
帯域幅を算出するための基本的な手順を以下に示す。
- 利用可能なネットワーク帯域幅を求める
- 特定のアプリケーションの平均利用率を求める
これらの数値はBps(バイト/秒)で表すこと。会社のネットワークがGbEであれば、その理論帯域幅は1億2500万Bpsとなる。これは、1000Mbps(ギガビットネットワークの帯域幅)、すなわち10億bpsを8で割ってバイトに換算した値だ。
ネットワークの帯域幅を算出したら、各アプリケーションがどれだけの帯域幅を使用しているかを算出する必要がある。ネットワークアナライザを使用し、アプリケーションがネットワークに送出しているデータ量(Bps)を測定する。これには、ネットワークアナライザの「累積バイト」フィールドを有効にする必要がある。次に、以下の手順を行う。
- アプリケーションを実行するテスト用ワークステーションを出入りするトラフィックを採集する
- 「デコードサマリー」ウィンドウ内でファイル転送の最初のパケットにマークを付ける
- 1秒後のタイムスタンプの位置で「累積バイト」フィールドの値を確認する
仮に、アプリケーションが20万Bpsの速度でデータを転送しているのであれば、1億2500万÷20万=625という計算が成り立つ。この場合、数百人の同時接続ユーザーがネットワークを利用していても大丈夫ということになる。しかし、ネットワークの帯域幅が100Mbpsだとしたらどうなるだろうか。この場合には、上記のアプリケーションを実行するユーザーを60人くらいしかサポートできないネットワークになるわけだ。このように、帯域幅というのは非常に重要な要素だ。
わたしは上記の計算を行う際には、10秒単位でデータを収集するようにしている。また、その数値がユーザー全体を代表していることを確認するために、複数のワークステーションでチェックするようにしている。予想される同時接続ユーザーの数も把握しておく必要がある。同時接続ユーザーが2人と20人では当然、必要な帯域幅が異なるからだ。
本稿筆者のケン・ミルバーグ氏はUnix-Linux Solutionsの創業者。ニューヨーク市で最も古いUNIXユーザーグループであるUnigroupの理事も務める。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した? 事例に学ぶ戦略立案&実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは -
市場調査・トレンド
[セコムトラストシステムズ株式会社] EDR導入を成功に導くロードマップ:選定/稟議/運用のつまずきを防ぐコツ -
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
3
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
4
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
5
クラウド資格コレクターは評価されない? 年収1000万を分ける“OSの理解度”
-
6
脱VMwareか、継続か? 仮想化ソフト主要6製品の機能とスペックを徹底比較
-
7
JSONをやめてPythonで送る トークン消費を約7割抑えるAIの設計
-
8
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
9
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
10
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー