こんにちは！ネットワークの深淵へようこそ。プロトコルの鼓動をこよなく愛する、当メディア主筆のネットワークアーキテクトです。
インフラエンジニアの道を歩み始めた皆さんが、最初にぶつかる大きな壁の一つ。それが「QoS（Quality of Service：通信品質の制御）」の世界です。特に「パケットが詰まった時にどう捌くか？」という、いわばネットワークの交通整理の話は、理屈だけ追うと非常に難解に見えます。
今日は、数ある制御アルゴリズムの中でも、現場で最もよく耳にする「WRR（Weighted Round Robin）」と「WFQ（Weighted Fair Queuing）」について、郵便局の窓口や道路の渋滞に例えながら、その「心」を解き明かしていきましょう。
—
1. なぜ「交通整理」が必要なのか？
ネットワークの世界では、ルーターやスイッチという「交差点」に、秒間何百万というパケット（データの小包）が押し寄せます。
もし、出口の道路（帯域）が広ければ問題ありません。しかし、大きなファイルのダウンロード（太いトラック）と、Web会議の音声（小さなバイク）が同時にやってきて、出口が狭くなっていたらどうでしょう？
何も工夫をしないと、先に着いた大きなトラックが道を塞ぎ、一刻も早く届けたい音声パケットが後ろで大渋滞に巻き込まれてしまいます。これが、Web会議の音が途切れたり、動画が止まったりする原因です。
この渋滞を解消するために、「どのパケットを優先して通すか？」を決める仕組みが、今回ご紹介する「キューイング」なのです。
—
2. WRR（Weighted Round Robin）：順番待ちの「重み付け」
まずはWRR（重み付きラウンドロビン）です。これは非常にシンプルで力強い仕組みです。
仕組みをイメージしてみよう
郵便局に3つの窓口（キュー）があると想像してください。
- 窓口A（特急）： 優先度が高い荷物
- 窓口B（普通）： 一般の荷物
- 窓口C（低速）： 急がない荷物
WRRは、この窓口を「順番に」回って荷物を集荷していきます。ただし、「重み（ウェイト）」に応じて一度に持っていく荷物の量を変えます。
例えば、重みを A:5, B:3, C:2 と設定したとしましょう。
1. まず、窓口Aから5個荷物を出す。
2. 次に、窓口Bから3個荷物を出す。
3. 最後に、窓口Cから2個荷物を出す。
4. また窓口Aに戻る……。
これなら、優先度の低い窓口Cも「全く通れない」ということはありません。「みんなに順番は回ってくるけれど、大事なところにはたくさん枠をあげるよ」という、非常に公平かつ効率的な仕組みですね。
実務でのポイント
WRRは計算が単純なので、スイッチのハードウェア（ASIC）で高速に処理できるのがメリットです。ただし、パケットの「サイズ」までは考慮しないことが多いため、大きなパケットばかりの列があると、予定より帯域を占有されてしまうこともあります。
—
3. WFQ（Weighted Fair Queuing）：真の「公平さ」を追求する
次に、もう少し賢いWFQ（重み付き公平キューイング）を見てみましょう。これはCiscoのルーターなどで古くから愛されている、非常に「賢い」アルゴリズムです。
仕組みをイメージしてみよう
WFQの最大の特徴は、「通信の流れ（フロー）」を自動で見分けて、小さなパケットを優遇する点にあります。
想像してみてください。
- 巨大なコンテナを運ぶトラック（大容量ダウンロード）
- 書類を運ぶ小さなバイク（音声通信やDNS問い合わせ）
普通の順番待ちだと、トラックが1台通る間にバイクは何台も待たされます。WFQは、「パケットのサイズ」と「重み」を計算して、あたかも「細いパケットが先に終わる」ようにスケジュールを組むのです。
たとえ重いダウンロードが走っていても、ひょいっと横から小さな音声パケットを先に通してくれる。まさに「弱きを助け、強きを（適度に）制す」、ネットワーク界の親分のようなアルゴリズムです。
—
4. 現場で使える設定サンプル（Cisco IOS風）
では、これらの概念が実際のネットワーク機器でどう設定されるのか、チラリと覗いてみましょう。ここでは、実務でよく使われる「クラスベース」の設定例を紹介します。
概念としては、「パケットにラベルを貼り、そのラベルごとに重みを割り当てる」という流れです。
! --- 手順1: 通信の種類（クラス）を定義する ---
class-map match-any VOICE-TRAFFIC
match dscp ef ! 音声パケット（非常に重要）を識別
class-map match-any BUSINESS-DATA
match dscp af31 ! 業務アプリなどの重要なデータを識別
! --- 手順2: どのクラスにどれだけの「重み」を与えるか決める ---
policy-map MY-QOS-POLICY
class VOICE-TRAFFIC
priority percent 10 ! 音声は最優先（Low Latency Queuing）
class BUSINESS-DATA
bandwidth remaining percent 60 ! 残りの帯域の60%を割り当て（WRRに近い挙動）
class class-default
fair-queue ! それ以外はWFQで公平に分配する
! --- 手順3: 物理ポート（出口）に適用する ---
interface GigabitEthernet0/1
service-policy output MY-QOS-POLICYパラメータチューニングのコツ
priority：これは「絶対優先」です。Web会議の音声など、遅延が許されないものに使います。ただし、ここに設定しすぎると他の通信が死んでしまうので、必要最小限（帯域の10〜33%程度）にするのがセオリーです。bandwidth：これがWRR/WFQの「重み」に相当します。パーセントで指定するのが、リンク速度が変わっても計算し直さなくて良いので現場では好まれます。
—
5. まとめ：パケットの気持ちに寄り添う
WRRもWFQも、根底にあるのは「限られた資源（帯域）を、いかに喧嘩させずに分け合うか」という哲学です。
- WRRは、決まった比率で順番に回る「律儀な交代制」。
- WFQは、パケットの大きさを計算して小さいものをスッと通す「気の利いた差配」。
もしあなたが運用しているネットワークで「特定の時間だけ通信がカクつく」といった相談が来たら、それはキューの中でパケットたちが押し合いへし合いをしているサインかもしれません。そんな時は、今回学んだ「重み付け」を思い出して、彼らの交通整理をしてあげてください。
一歩ずつ、パケットの挙動を理解していけば、いつの間にかあなたもプロトコルの深淵を読み解くエキスパートになっているはずです。
ネットワークの世界は、知れば知るほど面白いですよ。また次の記事でお会いしましょう！
コメント