MikroTik帯域幅管理: キューとPCQ

要約 MikroTikの帯域幅管理は3つのツールで成り立ちます。クライアントごとに素早く上限を設けるシンプルキュー、階層と優先度を扱うキューツリー、そして多数のユーザーにキューを個別に作らず公平に分配するPCQです。キューツリーはファイアウォールのmangleマークと組み合わせ、最低保証・上限・優先度を提供します。本ガイドでは、それぞれをいつ使うか、RouterOSコマンド、そして複数ルーターのフリート全体で同じポリシーを一貫して保つ方法を解説します。

MikroTikにおける帯域幅管理とは？

MikroTikにおける帯域幅管理とは、各顧客・サブネット・トラフィッククラスがリンクをどれだけ消費できるかを制御するためにRouterOSのキューを使うことです — レートを制限し、最低速度を保証し、リンクが満杯になったときに誰が譲るかを決めます。RouterOSはキューをHierarchical Token Bucket（HTB）スケジューラで実装しており、2つの形で提供されます。順番に適用される順序付きリストであるシンプルキューと、インターフェースまたはファイアウォールのmangle機能によるパケットマークに紐づく階層であるキューツリーです（MikroTikドキュメント — Queues）。

この違いが、設計をどこまでスケールできるかを決めます。シンプルキューは「この顧客を50 Mbpsで制限する」に答えます。キューツリーは「この500 Mbpsの上位回線は300加入者で共有され、VoIPが最優先で、誰も枯渇せず、大量ダウンロードする人が夜間を台無しにしない」に答えます。すべてのISPはいずれ2つ目の答えを必要とします。

ステップ1 — シンプルキューで1台のクライアントを制限する

シンプルキューは、問題から解決までの最短経路です。IP・サブネット・インターフェースを対象に指定し、上限を設定すれば完了です。

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

max-limitはルーター視点でupload/downloadの形式で記述します。ルールは順番に評価され最初に一致したものが優先されます — そのため、前方にある大まかなルールが、後から追加した具体的なルールを黙って飲み込んでしまいます。この順序こそ、誰かが上位にルールを追加した後に「動いていた」キューが動かなくなる最も一般的な原因です（MikroTikドキュメント — Queues）。

シンプルキューは加入者認証とも組み合わせられます。PPPoEプロファイルのrate-limitフィールドはセッションごとに動的なシンプルキューを作成するため、プランはIPではなくユーザーに追従します。プロファイル側についてはISP向けMikroTik PPPoEサーバーガイドで解説しています。

ステップ2 — ファイアウォールのmangleでトラフィックをマークする

キューツリーは「VoIP」や「顧客101」を認識できません。認識するのはパケットマークです。mangleでマークを作成し、先に接続を、次にパケットをマークします。これはすべてのパケットを再検査するより低コストです。

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

マークの分類は小さく安定的に保ちましょう。マークはキューが話す語彙であり、フリートに場当たり的なマーク名が3世代分たまると、どのルーターがどのポリシーを適用しているのか誰にもわからなくなります。ここでMKControllerの設定監査と履歴機能が真価を発揮します。全ルーターのmangleとキューの状態を確認し、意図したポリシーと差分を取り、変更が届かなかった1台を探すために30個のWinboxセッションを開く代わりに、修正済みのルールをフリート全体に一斉展開できます。

ステップ3 — キューツリーの階層を構築する

キューツリーには、リンクの実容量を保持する1つの親と、それを分割する子があります。

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

3つのフィールドが働きます。limit-atは、リンクが飽和しているときでも子が受け取れる最低保証です。max-limitは、容量に空きがあるときに到達できる上限です。priority — 1が最高、8が最低 — はどの子が余った帯域を最初に得るかを決め、limit-atとmax-limitの間でのみ適用されます（MikroTikドキュメント — Queues）。親のmax-limitは契約上の値ではなくリンクが実際に届ける値に設定してください。さもないとキューがボトルネックにならず、何もシェーピングしません。

ステップ4 — 公平分配のためにPCQを追加する

Per Connection Queue（PCQ）は、ユーザーごとのキューリストが管理不能になるほどの加入者数にMikroTikがスケールできる理由です。PCQキュータイプはアドレスフィールドでトラフィックを分類し、異なる値ごとに動的なサブキューを作成して、それぞれに同じレートを適用します（MikroTikドキュメント — PCQ example）。

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=10M pcq-classifier=src-address

顧客のダウンロードトラフィックを運ぶ子のqueueとしてpcq-downを割り当てると、すべての顧客が自動的に割り当てられる最大20 Mbpsを得ます。pcq-rate=0に設定すると、PCQは親の帯域幅をアクティブな相手すべてに均等に分割します — 定番の「誰も枯渇しない」構成です。1つのキュータイプが、手書きの何百ものエントリを置き換えます。

同じ均等化ロジックは共有WiFiにも当てはまります。プランのレート制限とPCQの親を組み合わせることで、1人のゲストが会場の上位回線を占有するのを防げます — 認証情報側についてはMikroTik HotSpot利用券設定ガイドをご覧ください。

ステップ5 — limit-at・max-limit・バースト・優先度を調整する

壊れたQoSの大半は、間違ったツールではなく間違った数値が原因です。すべての子のlimit-atの合計を親のmax-limit以下に保ってください。保証がリンクを超過契約すると、HTBはそれを守れず、優先度も期待どおりに動かなくなります。priority=1はレイテンシに敏感なトラフィック — VoIP、ゲーム、DNS — に予約し、バルク転送は余裕のある上限とともに8に置きましょう。

バーストには注意が必要です。burst-limit・burst-threshold・burst-timeは、平均が低く保たれている間、クライアントが一時的にmax-limitを超えることを許します — スピードテストには最適ですが、超過契約されたリンクには不向きです。すべてがアイドルな午前3時ではなく、リンクに負荷がかかっているときに/queue simple print statsやキューツリーのカウンターで測定しましょう。ピーク時にカウンターを読むのが現実的でない場合、MKControllerのInternet Linkビューが同じ状況を継続的に映し出します — 契約速度に対する使用率、平均・最大・P95のレイテンシ、そして各リンクが90%を超えて過ごした時間 — 幸運なスナップショットではなく履歴に対して調整できます。

容量も変動します。デュアルWANフェイルオーバー構成では、光回線向けに調整した親のmax-limitは、トラフィックがLTEバックアップに移った瞬間に絵空事になります — 2つ目のポリシーを用意しましょう。

ステップ6 — フリート全体にポリシーを展開する

ルーター1台は設定ですが、100台は運用です。ポリシーは今やすべての機器で同一でなければならず、顧客の上限を「一時的に」引き上げた技術者がいても残り、タワーのルーターがnetinstallされても復元可能でなければなりません。RouterOSにはそれを代わりに行う機能はありません。

MKControllerにはあります。キュータイプ・レート制限プロファイル・ファイアウォールルールのフリート全体への一斉展開、いつ上限が変わったかを確認しワンクリックで以前のバージョンに復元できる設定履歴、変更前の自動バックアップ、そしてCGNATの背後やStarlink上のルーターへの、パブリックIPもポートフォワーディングも不要な安全なアウトバウンドリモートアクセス — CGNAT環境でのMikroTikリモート管理で解説しているアプローチです。さらにInternet Link監視が、あなたが今シェーピングしたまさにその上位回線を見守ります — 契約速度に対するソースごとの使用率、P95付きのレイテンシ、そしてルーターあたり最大4つのWANソースにわたる75%と90%の帯を越える消費量 — 飽和に近づきつつあるリンクが、加入者が電話してくる前にダッシュボードに、そして（Telegramアラートと組み合わせれば）通知に浮かび上がります。MikroTikを大規模に運用するISPやWISPは、帯域ポリシーが100の判断ではなく1つの判断であり続けるようにこれを使っています。

ヒント

• トラフィックがルーターを出ていくインターフェースでシェーピングしましょう。キューは出力（egress）を制御するため、ダウンロードはLAN側で、アップロードはWAN側でシェーピングされます。
• 数十加入者を超えたら、何百ものシンプルキューよりも1つのPCQキュータイプを選びましょう。
• mark-packetルールでのpassthrough=noは、残りのmangleルールの不要な走査を省きます。
• 本番エッジでキューを触る前は必ずバックアップを取り、一度に1つの変数だけを変更しましょう。

帯域幅の行方を推測するのはやめよう

キューは、プランを売ることと、それを届けることの違いです。シンプルキューはクライアントを制限し、キューツリーは構造と優先度を与え、PCQは公平性を自動化します — そしてMKControllerはこの3つを、一度適用すればどこでも強制できるポリシーに変えます。中央集権的なフリート管理、全ルーターへのレート制限とファイアウォールの一斉展開、ワンクリック復元付きの設定履歴、パブリックIP不要のリモートアクセス、そして顧客より先に契約速度に対して飽和しつつあるリンクを検知するInternet Link監視です。

MKControllerの無料トライアルを開始する