Web APIが突発的な高負荷で沈む前に：レイヤー2から見直すIEEE 802.3x「PAUSEフレーム」の真実
「APIサーバーのCPU負荷は余裕があるのに、なぜか特定の時間帯だけパケットロスが多発し、クライアント側でタイムアウトが連鎖する……」
インフラエンジニアやバックエンドエンジニアとして数年の経験を積んだ人なら、一度や二度はこうした悪夢のようなインシデントに直面したことがあるはずです。アプリケーション層やロードバランサーのログをいくら漁っても原因が掴めず、最終的にスイッチのポート統計（ifInDiscards や ifOutDiscards）を覗いて初めて、「あ、リンク層でバッファが溢れてやがる」と気づく。
Web APIの設計やコンテナ基盤のチューニングにおいて、私たちはどうしてもHTTPステータスコードやJSONのペイロードサイズ、あるいはデータベースのコネクションプール数といった上位レイヤーに意識を奪われがちです。しかし、どれほど洗練されたAPIを設計しようとも、それを支える物理・データリンク層の足元がグラついていれば、システム全体の信頼性は砂上の楼閣となります。
今回は、全二重イーサネットの隠れた守護神でありながら、時としてパフォーマンスのボトルネックにも化けるIEEE 802.3x「PAUSEフレーム」を取り上げます。OSI参照モデルの第2層（データリンク層）で何が起きているのか、その泥臭いメカニズムと実務での向き合い方を、現場の視点から徹底的に解説していきましょう。
—
1. なぜレイヤー2で「待て」が必要なのか？（TCP/IPとの違い）
私たちが普段アプリケーション層で意識するフロー制御といえば、何と言ってもTCPの「ウィンドウ制御（スライディングウィンドウ）」や「輻輳制御」でしょう。受信側のバッファ残量（Receive Window）をTCPヘッダーに載せて送信側に伝え、送りすぎを防ぐ仕組みです。
では、なぜOSIモデルのはるか下層であるデータリンク層（レイヤー2）にも、わざわざフロー制御の仕組みが必要なのでしょうか？
ソフトウェアとハードウェアの処理速度の絶望的なギャップ
TCPのフロー制御は、あくまでエンドツーエンドのOS（カーネル）やアプリケーションが処理するレイヤーの話です。しかし、現代のデータセンターやオンプレミスのサーバーラックでは、ネットワークスイッチやNIC（Network Interface Card）のASIC（専用集積回路）が、毎秒数ギガビット、あるいは100Gbpsといった怪物的なスピードでパケットをルーティング・転送しています。
もし、スイッチのアップリンクから10Gbpsで流れ込んできたトラフィックを、特定のサーバーの1GbpsのNICや、仮想化基盤のソフトウェアスイッチ（vSwitch）が受け止めきれなくなったとしましょう。
OSのTCPバッファに到達するはるか手前、NICのハードウェアリングバッファ（Ring Buffer）やスイッチの出力ポートのキュー（Queue）が一瞬で埋まり、パケットは容赦なくドロップされます。
TCPはパケットロスを検知して再送制御を行いますが、ロスが発生するたびにスループットは急降下し、往復遅延時間（RTT）が増大します。この「上位レイヤーの再送地獄」が始まる前に、物理的なリンクの足元で「ちょっと待て、こっちはもう処理しきれない！」と相手の送信足をピタッと止めさせる仕組み。それが、IEEE 802.3xで規定されたPAUSEフレームです。
—
2. IEEE 802.3x PAUSEフレームの仕組みと通信フロー
IEEE 802.3x規格におけるフロー制御は、全二重（Full-Duplex）通信環境下において、MACコントロール・フレームを用いて実現されます。
PAUSEフレームの正体とMACアドレス
PAUSEフレームは、通常のイーサネットフレームとは異なり、宛先MACアドレスにマルチキャストアドレスである 01:80:C2:00:00:01 を使用します。このアドレス宛てのフレームは、IEEE 802.1Dに準拠したブリッジやスイッチによって同一セグメント内でのみ処理され、ルーターを越えて外部に転送されることはありません。
フレームの中身（ペイロード）には、以下の極めてシンプルな情報が含まれています。
- Opcode（オペコード）:
0x0001（PAUSE要求であることを示す） - Pause Time（一時停止時間）:
0x0000から0xFFFFまでの量子化された時間（スロットタイム単位）
通信シーケンス：何が起きているのか？
受信用バッファの残量が危険水域（High Watermark）に達したデバイスは、相手側デバイスに対して即座にPAUSEフレームを送信します。
[サーバー A (送信側)] [スイッチ / サーバー B (受信側)]
| |
| -------- (1) 10Gbps爆速データ送信 -------> | --> バッファ残量が限界に！
| |
| <------- (2) PAUSEフレーム (Time: 0xFFFF) -| --> 「ちょっと待て！」
| |
| (3) 送信を一時停止 (Timer起動) |
| ・この間、新規パケットを一切出さない |
| |
| -------- (4) PAUSEフレーム (Time: 0x0000)-> | または Timer満了
| ※再開要求 (必要に応じて) |
| |
| -------- (5) データ送信を再開 -----------> |
v v1. データ洪水: サーバーAからスイッチ（またはサーバーB）へ向け、NICの処理能力を超えるトラフィックが流し込まれます。
2. PAUSE発動: 受信側のバッファが溢れる寸前（High Watermark到達）で、受信側は 01:80:C2:00:00:01 宛てのPAUSEフレームを逆方向に射出します。
3. 送信停止: PAUSEフレームを受け取った送信側は、指定された Pause Time の間、新たなデータフレームの送信をぴたりと止めます。この期間中に受信側は溜まったバッファの消化（処理）を進めます。
4. 再開またはタイムアウト: 指定時間が経過するか、Pause Time に 0x0000（再開を意味する）が設定されたフレームを受け取ると、送信側はデータの送出を再開します。
—
3. 実務における光と影：PAUSEフレームのジレンマ
「バッファ溢れを防いでパケットロスを無くす万能の魔法」に見えるPAUSEフレームですが、実際のインフラ運用やWeb APIの設計現場では、「諸刃の剣」として恐れられています。ここに、シニアエンジニアとしての実務的な知見をいくつか共有しておきましょう。
メリット：マイクロバーストの吸収
Kubernetesクラスターなどで、多数のポッドが一斉にログを送信したり、外部APIから巨大なレスポンスが一気に返ってきたりする現象（マイクロバースト）が発生した際、瞬間的なバッファ溢れを防ぎ、再送によるレイテンシーの悪化を最小限に抑えられます。
デメリット：ヘッド・オブ・ライン・ブロッキング（HOLブロッキング）の波及
これが最悪のシナリオです。
全二重リンクでPAUSEがかかると、その物理リンク全体（あるいは特定のプライオリティキュー）の送信が止まります。つまり、「ある特定の重いAPIのレスポンス処理遅延が原因で、同じNICを通っている他の重要度の高いAPIトラフィックまで巻き込んで全て足止めを食らう」という現象が起きます。
マイクロサービスアーキテクチャにおいて、ひとつの非同期バッチ処理の遅延が、同期的なユーザー認証APIの応答遅延にまで波及する原因が、実は下層のPAUSEフレームにあった、というトラブルは現場で本当によくある話です。
—
4. 現場での設定・確認・デバッグの実践
ここからは、実務でどのようにPAUSEフレームの状態を確認し、必要に応じて制御するのかをコマンドや設定ファイルの例を交えて解説します。
1. Linux環境でのNICのFlow Control確認と設定（ethtool）
Linuxサーバー（Ubuntu / RHEL系）において、NICがPAUSEフレーム（Flow Control）をサポートしているか、また現在有効になっているかを確認・変更するには ethtool コマンドを使用します。
# 現在のNIC (例: eth0) のフロー制御設定を確認する
$ sudo ethtool -a eth0
# 出力例:
# Settings for eth0:
# Supports pause parameters: Symmetric
# Adaptive (rx/tx): off
# Rx pause: on <-- 受信側のPAUSE要求を受け入れるか
# Tx pause: on <-- 送信側にPAUSE要求を送信するか
#-Auto-negotiation: onもし、特定のサーバーが原因でネットワーク全体のパフォーマンスが落ちている疑いがあり、PAUSEフレームを無効化（Disable）して挙動をテストしたい場合は、以下のように設定します。
# eth0 の送受信におけるフロー制御（Pause）を強制的に無効化する
$ sudo ethtool -s eth0 autoneg off rx off tx off
# 設定が反映されたことを確認
$ sudo ethtool -a eth0*インフラ運用のTips*: 本番環境で安易に ethtool -s で設定変更を行うと、OS再起動時に消えてしまいます。永続化する場合は、/etc/network/interfaces や NetworkManager の設定、あるいは systemd-networkd の設定ファイルに記述してください。
2. スイッチ側（Cisco IOS / Catalyst / Nexus）での設定例
ネットワークスイッチ側でも、接続されるサーバーのNICに合わせてフロー制御（Flow Control）を適切に構成する必要があります。
! Ciscoスイッチのインターフェイス設定例 (GigabitEthernet 0/1)
interface GigabitEthernet0/1
description API-Server-01 Primary NIC
switchport access vlan 100
! 送受信ともにフロー制御（PAUSE）を有効化する場合
flowcontrol receive on
flowcontrol send onストレージトラフィック（iSCSIやFCoE）が混在する環境や、ロスレスイーサネット（RoCEv2など）を構築する環境では、通常のIEEE 802.3x（Global Pause）に加え、プライオリティごとに止められる PFC（Priority Flow Control: IEEE 802.1Qbb） の設計が必須となります。Web API基盤のネットワーク設計を行う際も、トラフィックの性質（同期API vs 大規模データ転送）に応じてポートのキューイングポリシーを分離することを強く推奨します。
—
5. まとめ：レイヤー2の挙動を理解した上でWeb API設計に挑む
今回は、OSI参照モデルの第2層におけるデータリンク層のフロー制御、IEEE 802.3xのPAUSEフレームの仕組みと実務での影響について解説しました。
- PAUSEフレームは、ハードウェアのバッファ溢れを防ぐ最後の砦である。
- しかし、全二重リンク全体を止めてしまうため、ヘッド・オブ・ライン・ブロッキングを引き起こし、無関係なAPIのレイテンシー悪化を招くリスクがある。
ethtoolやスイッチのflowcontrol設定を適切に把握・制御し、システムの特性（ロスレスを優先するか、スループットの低下を防ぐか）に合わせてチューニングする必要がある。
「なぜかAPIのレイテンシーがスパイクする」「パケットロスはないのに通信が詰まる」。そんな謎の現象にぶぶ当たったときは、上位のアプリケーションコードやデータベースのクエリだけでなく、視線をグッと下げて、パケットが流れる物理・データリンク層の足元に目を向けてみてください。そこには、今回解説したPAUSEフレームが静かに唸りを上げているかもしれません。
シニアエンジニアとしての引き出しを一つ増やし、堅牢で予測可能なインフラストラクチャを構築していきましょう。
コメント