【入門編】イーサネットスイッチにおけるキューイングアルゴリズム（Strict PriorityとWFQ） – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

こんにちは！ネットワークの世界へようこそ。インフラエンジニアの私です。

日頃何気なく使っているインターネットや社内ネットワークですが、実はルーターやスイッチという「交通整理のプロ」たちが、ものすごいスピードでデータをさばいてくれています。

ネットワークの世界に少し足を踏み入れると、「輻輳（ふくそう）」という言葉に出会います。これは要するに、道路で言うところの「大渋滞」のことですね。データがあふれかえり、スイッチの出口（出力ポート）で「通りたいけど通れない！」という大行列ができてしまう現象です。

この大渋滞が起きたとき、スイッチの中では「どのデータを先に行かせるか」を決める、非常に重要な交通整理が行われています。それが今回お話しするキューイングアルゴリズムです。

今回は、数ある方式の中から「Strict Priority（厳格優先キューイング：SPQ）」と「WFQ（重み付きフェアキューイング）」という代表的な2つの仕組みを取り上げます。難しいパケットの構造やビットの計算はいったん脇に置いて、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！

—

データの渋滞はどうして起きる？スイッチの中の「待合室」

まずは、スイッチの出力ポートで何が起きているのかをイメージしてみましょう。

ネットワークの世界では、音声通話（ZoomやTeamsなど）のデータ、YouTubeの動画データ、そして会社の重要なファイルサーバーへのアクセスなど、様々な性格のデータが同じ一本のケーブルを行き交っています。

ここで想像してみてください。
もし、あなたが「リアルタイムの音声通話」を楽しんでいる最中に、隣の人が「巨大な映画のファイル」のダウンロードを始めたとします。もしスイッチがデータを「来た順」にただ流すだけ（FIFO：First-In, First-Out）だったらどうなるでしょうか？

巨大なファイルのあとに並んでしまったあなたの音声データは、順番待ちのせいで「プツプツ……あれ、聞こえますか？」と途切れてしまいますよね。これは音声通話としては致命的です。

これを防ぐために、スイッチの出口には、データの種類ごとに「待合室（キュー）」が用意されています。重要度や性格ごとに待合室を分けておき、どの部屋から優先的にデータを送り出すかを決めるルールが「キューイングアルゴリズム」なのです。

—

1. 容赦ない実力主義！「Strict Priority（SPQ）」の世界

郵便局の「窓口」で例えてみよう

Strict Priority（厳格優先キューイング：以下SPQ）は、一言で言うと「完全なる優先順位制」です。

郵便局を想像してください。そこには「一般の窓口」と、お年寄りや妊婦さんのための「優先窓口」があります。SPQのルールはこうです。

「優先窓口に人が並んでいる間は、一般窓口の人は絶対に案内しない！」

ネットワークの世界でも全く同じです。SPQでは、一番優先度の高い待合室（高プライオリティ・キュー）にデータがある限り、中・低プライオリティの待合室にどれだけデータが溜まっていようとも、そちらには見向きもせず、優先データを送り続けます。

SPQのメリットと、現場で恐れられる「スタベーション（飢餓）」

このSPQ、音声データやIP電話（VoIP）のように「遅延が絶対に許されないリアルタイム通信」にとっては最強の味方です。何しろ、待たされることなく最優先で送り出してもらえるのですから。

しかし、現場のインフラエンジニアとして警告しておきたい恐ろしい副作用があります。それが「スタベーション（飢餓状態）」です。

もし、優先度の高いデータ（例えば、終わりのない巨大な監視カメラのライブ映像など）が延々と流れ込んできたらどうなるでしょうか？ SPQのルールに従うと、一般のデータ（Web閲覧やメールなど）の待合室にいる人たちは、いつまで経っても自分の番が回ってきません。これが「飢餓状態」です。一般通信が完全にフリーズしたように見えてしまう、現場泣かせのトラブル原因になります。

—

2. みんな仲良く、でも貢献度に応じて！「WFQ」の世界

レストランの「コース料理」で例えてみよう

SPQの「優先度の低いデータが一生流れない」という問題を解決するために生まれたのが、WFQ（Weighted Fair Queueing：重み付きフェアキューイング）です。

WFQをレストランのシステムに例えてみましょう。
お店にはたくさんの客席（データフロー）があります。完全な平等（フェア）であれば、全員が同じペースで料理を受け取りますが、それではVIP客や、たくさんお金を払っている団体客の満足度が下がってしまいますよね。

そこでWFQでは、客席ごとに「重み（ウェイト）」を付けます。

一般のお客さん（重み：1）
ちょっと良い席のお客さん（重み：2）
VIPルームのお客さん（重み：4）

店員さんは、完全にVIPだけを贔屓する（SPQの）ようなことはしません。すべての席に目を配りつつ、重みに応じた割合で、順番に料理を配っていきます。重みが「4」のVIPには4皿配る間に、一般客には1皿配る、といった具合です。

WFQの美しさ：大渋滞でも「完全な無視」は起きない

ネットワークにおけるWFQもこれと全く同じです。
あらかじめ設定された「重み（Weight）」や、データの流れ（フロー）ごとに、帯域（使える太さの割合）を分配します。

SPQのように「優先度の低い通信が完全に止まってしまう」という悲劇が起きないため、全体のバランスを取りながら上手に交通整理をしたい場合に非常に重宝されます。

—

比較表でスッキリ整理！SPQ vs WFQ

ここまでの特徴を、分かりやすく表で比較してみましょう。

—

実際のネットワーク機器（Cisco等のスイッチ）での設定イメージ

「理屈は分かったけれど、実際はどう設定するの？」という疑問にお答えするために、実務でよく使われるCisco IOS風のCLI設定サンプルを見てみましょう。

ネットワークの世界では、まずデータに「マーキング（目印）」をつけ、その目印（DSCP値など）を見て「どのキューに入れるか」を分類（Class-Map / Policy-Map）します。

設定例：音声にはSPQを、その他にはWFQ（または帯域保証）を割り当てる

以下の設定は、「音声データ（VoIP）」はSPQで最優先しつつ、「一般データ」には一定の帯域を割り当てる（WFQの思想に近いキューイング）実用的な設定の断片です。

! 1. 分類するデータの定義 (Class-Map)
! アクセスリスト等で音声トラフィックを指定します
ip access-list extended ACL_VOIP
 permit udp any any range 16384 32783  ! RTP音声パケットの一般的なポート範囲

class-map match-all CLASS_VOIP
 match access-group name ACL_VOIP

! 2. 実際の動作を決めるルール (Policy-Map)
policy-map QOS_POLICY_OUT
 class CLASS_VOIP
    ! 【Strict Priorityの適用】
    ! 音声データには迷わず優先権（priority）を与えます
    priority percent 30  
 class class-default
    ! 【WFQ / 公平な帯域割当の適用】
    ! 残りのデータに対しては、重みやフェアネスを考慮した帯域を割り当てます
    fair-queue
    bandwidth percent 70

! 3. 物理インターフェースへの適用
interface GigabitEthernet0/1
 description "社内ネットワークのアップリンク"
 service-policy output QOS_POLICY_OUT

設定のポイント

priority percent 30 という記述が、まさにSPQ（厳格優先）の挙動です。ポートの帯域の30%を上限として、音声データを問答無用で最優先させます。
fair-queue という指定により、残りのトラフィック間でWFQのアルゴリズムが働き、特定の端末だけが帯域を占有するのを防ぎます。

—

まとめ：現場でどう使い分けるべきか？

今回は、スイッチの出力ポートにおける「キューイングアルゴリズム」である、SPQとWFQについて解説しました。

SPQは、遅延を極限まで減らしたい「音声やライブ映像」の味方。ただし、使いすぎると他の通信が死んでしまう諸刃の剣。
WFQは、全体のバランスを取りながら、誰もがそこそこに快適な通信を行えるようにする「調停役」。

実際のインフラ現場では、これらの一つだけを極端に使うのではなく、「音声などの絶対死守したいデータにはSPQを使い、それ以外の通常データの間ではWFQを使って綺麗に帯域をシェアする」というように、いいとこ取りをした複合的な設計（LLQ: Low Latency Queueingなど）がよく使われます。

ネットワークの仕組みを知ることは、目に見えないパケットの流れを自分の頭の中で立体的に描けるようになるということです。トラブルシューティングの際にも、「いま、このスイッチの出口でどちらのキューがボトルネックになっているんだ？」と推論できるようになります。

ぜひ今回の例えを思い出しながら、ご自身のネットワーク環境や設計書を見直してみてくださいね。それではまた、次の深淵なネットワークの世界でお会いしましょう！