「スイッチは魔法の箱ではない」——ノンブロッキング設計とMppsの深淵を読み解く
ネットワークエンジニアとして現場を渡り歩いていると、ベンダーのカタログスペックに踊らされる若手をよく見かけます。「48ポートで100Gbps対応！」という謳い文句を鵜呑みにして、全ポートフル負荷のトラフィックを流した瞬間にパケットロスを発生させ、頭を抱える……。まさに古典的な悲劇です。
今日は、スイッチの「物理的な限界」であるバックプレーン容量とフォワーディングレート（Mpps）について、現場の視点から紐解いていきましょう。
1. Mppsの正体：なぜ「ビット」ではなく「パケット」なのか
多くのエンジニアは「Gbps」という帯域幅に注目しますが、L2スイッチのASIC（専用集積回路）が実際に処理しているのは、ビットの列ではなくパケットそのものです。
ここで重要なのが Mpps（Million packets per second）です。なぜなら、イーサネットの最小フレームサイズである64バイト（プリアンブルとIFGを含めると84バイト）を処理する場合と、ジャンボフレーム（9,000バイト超）を処理する場合では、ASICにかかる負荷が天と地ほど違うからです。
64バイト時の理論値算出式
理論上の最大性能を測るには、以下の式を使います。
$$ Mpps = \frac{ポート速度 \times ポート数}{ (フレームサイズ + IFG/プリアンブル) \times 8 } $$
例えば、10Gbpsのポート1つに対し、最小サイズ（84バイト）のパケットが押し寄せた場合、必要なフォワーディング能力は：
10,000,000,000 bps / (84 bytes * 8 bits) ≈ 14.88 Mpps
もし貴方のスイッチが48ポートの10GbEポートを持ち、すべてでノンブロッキング（全ポート全二重でロスなし）を謳うなら、ASICは 48 * 14.88 = 714.24 Mpps を安定して処理できなければなりません。カタログの数値がこれより低いなら、それは「特定のフレームサイズ以上でしか性能が出ない」という意味です。
2. ノンブロッキング設計を検証するPythonスクリプト
机上の空論で終わらせないために、擬似的にスイッチへの負荷をシミュレートする簡易的なトラフィック生成の概念コードを紹介します。実際の実務では Scapy などを使いますが、ここではロジックの理解にフォーカスします。
# スイッチのフォワーディング性能を検証する概念ロジック
def calculate_required_mpps(port_speed_gbps, num_ports, frame_size_bytes):
# イーサネット最小フレームサイズ（64B + 8Bプリアンブル + 12B IFG = 84B）
total_frame_size_bits = (frame_size_bytes + 20) * 8
pps_per_port = (port_speed_gbps * 1e9) / total_frame_size_bits
return pps_per_port * num_ports / 1e6
# 48ポートの10GbEスイッチで64バイトパケットを処理する場合
required = calculate_required_mpps(10, 48, 64)
print(f"必要な理論フォワーディング性能: {required:.2f} Mpps")
# この数値がASICのスペックシートを上回っていれば、
# 小さなパケットの洪水（DDoSや大量の小規模APIリクエスト）で
# パケットロスが発生するリスクが高いと判断する3. 実効値の評価：Web API開発者が知るべき「見えないロス」
Web APIの設計において、バックエンド側でマイクロサービス間の通信が頻発する場合、小さなパケット（SYNパケットやACKパケット）が大量に流れます。
ここで現場のトラブルシューティングとして役立つTipsが、curl を用いたインターフェース統計の確認です。スイッチのCLIにログインし、パケットドロップが発生していないか監視してください。
# Cisco Catalyst等のCLIでの確認例
# インターフェースのカウンタをクリアして一定時間計測する
clear counters Gi1/0/1
# 数秒後に再確認
show interfaces Gi1/0/1 | include drops
# もしここに数値が増えていれば、物理的なバックプレーンの飽和か、
# バッファ溢れ（マイクロバースト）が疑われます4. インフラアーキテクトからの助言
多くのクラウドネイティブな環境では、オーバーサブスクリプション（あえて帯域を束ねてコストを抑える設計）が推奨されますが、「どこがボトルネックになるか」を把握していることが重要です。
1. バースト耐性の確認: カタログの Mpps だけで安心せず、バッファサイズ（KB/MB単位）を確認してください。短時間の突発的なトラフィックには、ASICの処理能力よりもバッファの深さが効いてきます。
2. 可視化の徹底: SNMP や gRPC ストリーミングテレメトリを用いて、トラフィックのスパイクを秒単位で可視化してください。1分平均のグラフでは、一瞬のパケットロスは見えません。
ネットワークは生き物です。スペックシートの数字はあくまで「理想の姿」。泥臭い現場では、パケットの挙動を想像し、最悪のシナリオ（最小パケットサイズの洪水）を常に想定して設計する。この慎重さが、インフラエンジニアとしての真の価値を決めるのです。
次回は、この「バックプレーン」を通り抜けた先にある、L3ルーティングのテーブル爆発とTCAM（Ternary Content Addressable Memory）の最適化について深掘りしましょう。それでは、また現場で会いましょう。
コメント