【テクニカル・上級編】イーサネットにおける省電力イーサネット（EEE / Energy Efficient Ethernet / IEEE 802.3az） – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

EEE（IEEE 802.3az）の深淵：省電力という名の「パケットの沈黙」と、その代償

ネットワークエンジニアとして現場を渡り歩いていると、往々にして「なぜか特定の環境でだけパフォーマンスが不安定になる」という難解な事象に遭遇する。パケットロス率が極めて低いにもかかわらず、特定のアプリケーションのレイテンシがスパイクする。そんな時、多くのエンジニアがOSのTCPスタックやルーティングテーブル、あるいはファイアウォールのセッション管理を疑うが、実はその犯人が物理層の「省電力機構」だったというケースは、決して珍しくない。

今回は、データセンターやエンタープライズ環境で密かに暗躍する「Energy Efficient Ethernet（EEE / IEEE 802.3az）」の深層に切り込みたいと思う。

EEE：Low Power Idle (LPI) の物理的挙動

EEEの核心は、データの送信がないアイドル期間において、PHY（物理層）の送信機を一時的にシャットダウンする「Low Power Idle (LPI)」モードにある。

通常、イーサネットのリンクは常にアイドル信号（IDLEシンボル）を送り続けることで同期を保っている。しかし、EEEが有効な場合、一定期間パケットがないと、PHYは「眠り」に就く。この時、リンクは完全に切れるわけではなく、定期的なリフレッシュ信号を送ることで同期を維持するが、いざデータが到着した際には「ウェイクアップ時間」が必要となる。

このわずか数マイクロ秒のウェイクアップ時間が、高負荷なマイクロサービス間通信において、TCPの輻輳制御アルゴリズムや、TLSハンドシェイクのRTT計算に微妙な「ゆらぎ」をもたらすのだ。

パフォーマンスへの影：TCPバッファとレイテンシの相関

もし君がハイパフォーマンスなデータ転送を設計しているなら、EEEの存在を無視することはできない。特に、TCP_NODELAYを有効にし、小パケットを頻繁に投げるようなリアルタイム性の高いアプリケーションでは、LPIからの復帰に伴うレイテンシが、バッファリングのオーバーヘッドと重なり、期待したスループットを下回る原因となる。

Linuxカーネルレベルでこの挙動を制御・観測するには、ethtoolが不可欠だ。

# 特定のインターフェースでEEEの状態を確認する
ethtool --show-eee eth0

# もしレイテンシがシビアな環境なら、EEEを無効化して検証する
# デフォルトで有効なNICが多いが、パフォーマンスボトルネックが疑われる場合は断つ
sudo ethtool --set-eee eth0 eee off

セキュリティとネットワークアーキテクチャの視点

セキュリティの観点からEEEを見ると、さらなる興味深い事実がある。LPIモード中はPHYの状態が変化するため、サイドチャネル攻撃の標的となる可能性や、トラフィックのバースト性を利用したタイミング攻撃の解析精度に影響を与えるリスクを考慮する必要がある。

また、高密度なスパイン・リーフ構成のデータセンターにおいて、全ポートでEEEが有効になっていると、突発的なトラフィックバーストが発生した際、全PHYが一斉にウェイクアップを開始する。この「ウェイクアップ・ストーム」とも呼ぶべき事象が、スイッチのASICの内部処理に負荷を与え、輻輳制御のアルゴリズムに悪影響を及ぼす可能性がある。

実践的な最適化の指針

我々インフラアーキテクトが取るべきスタンスは、「汎用的な省電力設定を疑い、用途に合わせて物理層をチューニングする」ことだ。

1. サーバー側の最適化

高負荷な計算ノードやストレージサーバーでは、潔くEEEを無効化する。systemd-networkdやnetplanなどで管理している場合、起動時に自動適用されるように設定しておく。

# /etc/netplan/01-netcfg.yaml の例
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      # 物理層の特性をスクリプトで無効化するフックを入れる
      nameservers:
        addresses: [8.8.8.8]

2. TLSハンドシェイクとRTT削減

EEEを無効化できない環境（物理的な電力制限がある場合など）では、アプリケーションレイヤーでのRTT削減が重要になる。TLS 1.3の活用はもちろん、0-RTTの採用を検討すべきだ。これにより、物理層がLPIから復帰する僅かな時間を、暗号化ハンドシェイクの最適化で隠蔽（隠蔽）することが可能になる。

3. バッファチューニングの再考

EEEの影響を受ける環境では、デフォルトのTCPバッファサイズでは足りないことがある。

# sysctl.conf でバッファを広げ、LPIによる微小な遅延を吸収させる
# デフォルト値を引き上げ、輻輳によるウィンドウ縮小を緩和する
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

結びに代えて

EEEは、現代のデータセンターにおける消費電力削減の切り札であることは間違いない。しかし、プロトコルの深淵を覗くエンジニアにとって、それは「隠れたレイテンシの発生源」でもある。

「省電力」という正義を無批判に受け入れるのではなく、自らのネットワーク環境が「低電力」を必要としているのか、それとも「極限の低レイテンシ」を必要としているのかを明確にすること。これが、プロトコルスペシャリストとしての矜持であり、真のパフォーマンスを引き出すための鍵となる。

パケットは嘘をつかない。たとえその背後に、物理層の眠りという小さな隠蔽があろうとも。君たちのネットワークに流れるパケットの行く末に、常に最適化の光があらんことを。