QoSとは何か

ネットワークには、同時にさまざまな通信が流れます。

• IP電話
• Web会議
• Webアクセス
• 基幹業務システム
• メール
• ファイル転送
• OSアップデート
• バックアップ

これらをすべて同じ条件で転送すると、 回線が空いているときには問題がなくても、 混雑時には重要な通信とそうでない通信が 同じように待たされる可能性があります。

QoSは帯域そのものを増やす技術ではない

100Mbpsの回線へQoSを設定しても、 回線が200Mbpsになるわけではありません。

QoSが行うのは、 100Mbpsという限られた資源を、どの通信へどのように使わせるか決めること です。

なぜQoSが必要なのか

例：100MbpsのWAN回線

本社と拠点が100MbpsのWAN回線で接続されているとします。

通常時は40Mbps程度しか使っていなくても、 バックアップが始まり、 大きなファイル転送とWeb会議が重なると、 一時的に100Mbpsを超える通信が発生するかもしれません。

その場合、ネットワーク機器はすべてのパケットを 同時には送信できません。 一部のパケットは待ち行列に入り、 待ちきれなければ廃棄されます。

通信によって「困る品質劣化」が違う

バックアップは多少遅くなっても、 処理時間が延びるだけで済む場合があります。

一方、音声通話は数秒止まるだけでも 利用者へ直接影響します。

通信品質を決める4つの指標

帯域だけ見ても通信品質は分からない

「100Mbpsあれば十分」という判断だけでは、 リアルタイム通信の品質を保証できません。

平均通信量が50Mbpsでも、 瞬間的な混雑によってキューが長くなれば、 音声通信の遅延やジッターが増えることがあります。

QoS処理の全体像

QoSは、1つの設定だけで完結するわけではありません。 基本的には次のような流れで考えます。

1. 通信を分類する 音声、Web会議、業務システム、バックアップなど、 パケットをポリシー上のクラスへ分類します。
2. 必要に応じてマーキングする DSCPなどを使って、 パケットへ転送上の扱いを判断するための情報を付けます。
3. キューへ振り分ける 出力インターフェースが混雑した場合に、 パケットを対応する待ち行列へ入れます。
4. 優先順位や帯域を決めて送信する 音声を優先したり、 業務通信へ一定の帯域を確保したりします。
5. 必要に応じて通信量を制御する シェーピングやポリシングによって、 特定クラスや回線全体の送信レートを調整します。

分類（Classification）

QoSを行うには、 最初に「何を優先するのか」を判別できなければなりません。

分類に使用できる情報の例

単純なポート番号だけでは難しいこともある

現代のアプリケーションでは、 HTTPSなど共通のポート番号を使う通信が多くあります。

そのため、TCP/UDPポート番号だけで すべてのアプリケーションを正確に識別できるとは限りません。

製品によっては、 アプリケーション識別機能やSD-WANのアプリケーション制御機能などを 組み合わせて分類します。

マーキングとDSCP

IPネットワークのQoSで代表的に使われる値が DSCP（Differentiated Services Code Point）です。

DSCPはIPヘッダー内のDSフィールドに含まれる 6ビットの値で、 ネットワーク機器がパケットをどのように扱うか判断するために利用できます。

代表的なDSCPの例

Trust Boundaryを決める

端末が設定したDSCP値を、 ネットワーク全体で無条件に信用するのは危険です。

たとえば、一般ユーザーの端末が すべての通信へ高優先度のマーキングを行えば、 QoSポリシーが機能しなくなる可能性があります。

そこで、 どこから先のマーキングを信頼するのか という境界を決めます。 これをTrust Boundaryと呼びます。

キューイングと優先制御

QoSで特に重要なのが、 混雑したときにどのパケットから送るか という考え方です。

回線が空いている場合

送信したいパケットが10Mbps分しかなく、 出力回線が100Mbpsあるなら、 基本的にはすぐ送信できます。

回線が混雑した場合

100Mbpsのインターフェースから 150Mbps分のパケットを同時に送りたい場合、 すべてを一度に送ることはできません。

そこで、送信待ちのパケットをキューへ入れ、 QoSポリシーに従って順番に取り出します。

Priority Queue

音声など、遅延に特に敏感な通信については、 優先度の高いキューを使用する設計があります。

ただし、 高優先キューへ大量の通信を入れすぎると、 他の通信へ帯域が回らなくなる可能性があります。

Bandwidth Guarantee

音声以外の重要通信については、 混雑時にも一定量の帯域を使えるようにする設計があります。

たとえば、業務システム用クラスへ 一定割合の帯域を割り当てることで、 バックアップが大量通信を発生させても 業務通信が完全に押し出されないようにします。

シェーピングとポリシング

QoSでは、優先順位だけでなく 通信速度を制御する機能も使われます。

Traffic Shaping

シェーピングは、 一時的なバースト通信をキューへ保持し、 設定した速度に合わせて送信する考え方です。

特に、物理インターフェース速度より 契約回線速度が低いWANなどで使われることがあります。

Traffic Policing

ポリシングは、 決められた通信レートを超えたトラフィックへ 廃棄や再マーキングなどの処理を行う考え方です。

たとえば、 低優先度の大量転送が一定量以上を占有しないよう、 上限を設定する場合などに利用できます。

QoSの基本設計例

要件

100Mbpsの拠点間WANで、 次の通信を利用しているとします。

最大値を単純に合計すると165Mbpsとなり、 100MbpsのWAN回線を超えます。

そこで、混雑時の扱いを決めます。

QoSクラス設計例

設計の考え方

1. リアルタイム通信を特定する 音声やWeb会議など、 遅延・ジッターの影響が大きい通信を把握します。
2. 業務重要通信を特定する 帯域競合によって業務停止や生産性低下につながる通信を確認します。
3. 遅くなってもよい通信を確認する バックアップや大容量転送など、 混雑時に優先順位を下げられる通信を特定します。
4. 必要な帯域を実測する 推測だけではなく、 現在の通信量、ピーク値、同時利用数を確認します。
5. マーキングとキューの対応を決める どのDSCPをどのキューへ入れるかを設計します。
6. 混雑状態で試験する QoSは回線が空いている状態だけ試験しても、 効果を確認できません。

QoS設計で確認するポイント

1．本当に混雑が発生しているか

QoS設定を始める前に、 まず現在の通信量を確認します。

• 平均帯域
• ピーク帯域
• 時間帯別通信量
• クラス別通信量
• インターフェースDrop
• キューDrop
• 遅延
• ジッター
• パケットロス

原因が回線混雑ではないのにQoSを設定しても、 問題は解決しません。

2．どこがボトルネックか

QoSは、特に帯域が狭くなるポイントで重要です。

この例では、WANの100Mbps部分が ボトルネックになる可能性があります。

3．双方向を考える

片方向だけQoSを設定しても、 反対方向の混雑が原因なら問題は解決しません。

上り・下りそれぞれの 通信量と制御可能な場所を確認します。

4．回線事業者側の扱いを確認する

自社ルーターでDSCPを付けても、 WANサービスやインターネットの途中で 同じ扱いが保証されるとは限りません。

閉域網サービスなどでQoSクラスが提供される場合は、 キャリア側のクラス仕様、 DSCPマッピング、 契約帯域などを確認します。

5．監視まで設計する

QoSは設定して終わりではありません。

運用開始後に次の情報を確認できるようにします。

• クラス別パケット数・バイト数
• クラス別Drop数
• 優先キュー利用量
• ポリシングDrop
• インターフェース使用率
• 遅延・ジッター・ロス

QoS設計でよくある失敗

顧客・上司へQoSをどう説明するか

技術に詳しくない相手へ、 DSCPやキューイングから説明を始める必要はありません。

まず、 業務への影響 から説明します。

道路にたとえる

QoSは高速道路の交通整理にたとえると説明しやすくなります。

道路そのものの車線数を増やすのが 「回線増速」だとすると、 QoSは混雑時に 「どの車両をどのレーンへ通すか」 を決める仕組みです。

QoSで使われる英語表現

ベンダードキュメントで使われる表現例

自分の言葉で説明する課題