現場の課題：「自分の環境では動く」というネットワークの幻想
ステージング環境ではすべてがスムーズに動作します。マイクロサービス間のgRPC呼び出しは1ミリ秒未満で完了し、Postgresクエリは2msで応答し、テストワーカーのパケットドロップはゼロと報告されます。しかし、エッジ拠点、ハイブリッドクラウドクラスタ、遠隔地のモバイルクライアントが混在する本番環境へデプロイした途端、状況は一変します。
レイテンシに敏感なワークフローが即座に劣化し始めます。リクエストは5,000msでタイムアウトし、スループットは激減し、ローカル検証では再現しない接続切断の調査にエンジニアは追われることになります。テストコンテナが快適な10 Gbpsループバックインターフェース経由で通信している限り、不安定なWAN回線や帯域飽和状態を再現することはほぼ不可能です。
多くのチームはソフトウェアモックに頼ったり、アプリケーションコード内にtime.Sleep(100ms)を散りばめたりしがちです。しかし、コードレベルでの遅延挿入ではカーネルの実挙動を再現できません。TCP再送タイマー、SACK（Selective Acknowledgement）のネゴシエーション、ソケットバッファの枯渇、経由ルーターのバッファブロート（Bufferbloat）といった低レイヤーの事象を完全に無視してしまうためです。
根本原因の分析：なぜカーネルレベルでのパケット制御が重要なのか
ネットワーク起因のトラブルは、アプリケーションコード単体から発生することは稀です。むしろ、過酷な実ネットワーク環境下でLinuxネットワークスタックが耐えきれなくなることで発生します。アップリンクが飽和したりフレームがドロップしたりすると、カーネルはキューイング規律（qdisc: queuing discipline）を用いて送信パケットのバッファリング、並べ替え、破棄を制御します。
デフォルト状態の最新Linuxディストリビューションでは、ネットワークインターフェースにfq_codelやpfifo_fastといったWork-Conserving（作業保存型）qdiscが割り当てられています。これらは通常負荷時の公平かつ低遅延なパケット配信に最適化されているため、テスト環境では本番特有の障害パターンが隠蔽されてしまいます。
- パケットドロップ制御の欠如: ローカル統合テストでは、TCP高速再送（Fast Retransmit）、テールドロップ、指数バックオフが決してトリガーされません。
- レイテンシジッターがゼロ: ローカルのping応答時間は0.05msと完全に安定しており、パケットの順序逆転による競合状態（レースコンディション）が表面化しません。
- 無制限な送信バースト: 1つの暴走したバックアップジョブが950 Mbpsの帯域を占有し、重要なRedisのハートビートやSSHセッションを帯域不足に陥らせます。
こうしたエッジケースを洗い出し、厳格なマルチテナント帯域保証を実現するには、パケットが物理NICのリングバッファに到達する前に、カーネル内でトラフィックシェーピングを行う必要があります。
ソリューション比較：アプリケーションモック vs IPTables vs Linux TC
ネットワーク劣化をシミュレートする手法として、エンジニアは主に3つのアプローチを用います。
1. アプリケーション層プロキシ（Toxiproxy、Chaos Mesh、独自インターセプター）
ユーザー空間でサービス間に常駐し、TCPストリームを切断したりペイロードを遅延させたりします。
- メリット: ルート単位の設定が容易で、Docker Composeでの統合テストに便利。
- デメリット: メモリやCPUのオーバーヘッドが大きい。Raw UDP/ICMPトラフィックをクリーンに検査できず、OSネイティブのソケットバッファをバイパスしてしまう。
2. Netfilter / IPTablesドロップルール
iptables -m statistic --mode random --probability 0.05 -j DROPのようにパケットをドロップさせて回線障害をシミュレートします。現代の環境ではIptablesを置き換えるモダンなファイアウォール設定としてNftablesが主流になりつつありますが、パケット破棄によるシミュレーションの考え方は共通です。
- メリット: 追加パッケージをインストールすることなく、Netfilter標準機能で利用可能。
- デメリット: 大雑把すぎる制御。パケットを即座に破棄することはできますが、送信遅延の挿入、ミリ秒単位のジッター再現、滑らかなトラフィックシェーピングは不可能です。
3. Linux Traffic Control (tc) + Netem / HTB
Linuxカーネルのネットワークスタック内に存在するネイティブサブシステムであり、送信パケットのスケジューリング、分類、レートシェーピングを一括管理します。
- メリット: ユーザー空間のオーバーヘッドがゼロ。全システムプロセスに対して透過的に機能し、統計的遅延曲線を正確に再現できるほか、キロビット単位でのマルチティア帯域制限が可能です。
- デメリット: コマンド構文が難解で学習コストが高い。
推奨アプローチ：NetemとHTBを活用した実践的Traffic Control
最も理想的なアプローチは、Traffic Control（tc）と2つの主要カーネルモジュールを組み合わせることです。悪条件の回線シミュレーションにはNetem（Network Emulator）を使用し、厳格な帯域割り当てにはHTB（Hierarchy Token Bucket）を使用します。
対象インターフェースの確認
まず、Linuxのネットワークボンディング環境などを含め、対象のプライマリインターフェース名を確認し、現在アクティブなqdiscを表示します。
ip link show
tc qdisc show dev eth0Netemによるネットワークジッター、遅延、パケットロスのシミュレーション
Netemを使用すると、混雑したモバイル回線や大西洋横断光ファイバー回線のような過酷な条件下で分散サービスを検証できます。
固定遅延の追加
eth0のすべての送信パケットに対して、ベースラインとして100msのラウンドトリップペナルティを付与します。
sudo tc qdisc add dev eth0 root netem delay 100msリアルなジッターと確率分布を伴う遅延の追加
現実のネットワーク接続は常に揺らいでいます。正規分布（ガウス分布）に従う±20msのジッターを含む100msの基準遅延をシミュレートします。
sudo tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normalパケットロスとパケット重複のシミュレーション
送信パケットの5%をランダムにドロップさせ、さらに重複排除ロジックをテストするために1%のフレームを重複させます。
sudo tc qdisc change dev eth0 root netem loss 5% duplicate 1%適用されたエミュレーションの確認
パケットカウンタとドロップされたフレームの統計をリアルタイムで確認します。カーネル内部のパケット処理や低レイヤーでの遅延要因をより詳細に追跡したい場合は、BCCとeBPFの実践によるトレーシングを組み合わせるのも有効です。
tc -s qdisc show dev eth0Netemルールのリセット
テスト完了後、root qdiscを削除してインターフェースをデフォルト設定に戻します。
sudo tc qdisc del dev eth0 rootHierarchy Token Bucket (HTB) による帯域制限
上限を設定していないバックグラウンドジョブは、容易に送信帯域を使い果たします。帯域制限のないS3データベースアップロードが100 Mbpsを消費すると、リアルタイムなRESTやGraphQLリクエストが即座に応答不能に陥ります。Cgroups v2とsystemd Sliceによるリソース制限がCPUやメモリの独占を防ぐのと同様に、HTBは帯域を親子階層のクラス構造に整理し、厳格なバースト上限と最低保証帯域を割り当てることで、このリソース枯渇を防止します。
Ubuntu 22.04 LTSインスタンスでのベンチマークでは、明示的なレート階層を構築したことで、夜間バックアップのピーク時におけるAPI応答のp99レイテンシが1,240msから42msへと劇的に改善しました。
ステップ1: ルートHTB Qdiscの作成
HTBをルートキューイング規律として設定し、未分類のトラフィックをフォールバッククラス1:20にルーティングします。
sudo tc qdisc add dev eth0 root handle 1: htb default 20ステップ2: ルート帯域プールの定義
利用可能な合計送信帯域の上限を宣言します。この例では、標準的な100 Mbpsのアップリンクを想定します。
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbitステップ3: 分割サブクラスの作成
100 Mbpsのプールを分割し、重要度の高いHTTPトラフィック用と低優先度の同期処理用の専用レーンを作成します。
# クラス 1:10 - 優先APIトラフィック（保証帯域: 80 Mbps、バースト上限: 100 Mbps、優先度: 1）
sudo tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80mbit ceil 100mbit prio 1
# クラス 1:20 - バックグラウンド同期ジョブ（保証帯域: 10 Mbps、絶対上限: 20 Mbps、優先度: 2）
sudo tc class add dev eth0 parent 1:1 classid 1:20 htb rate 10mbit ceil 20mbit prio 2ステップ4: フィルタを使用したトラフィックのルーティング
宛先ポートに基づいて送信パケットを特定のクラスに割り当てます。以下のフィルタは、標準的なWebトラフィック（ポート443および80）を優先クラス1:10に転送します。
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
match ip dport 443 0xffff flowid 1:10
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
match ip dport 80 0xffff flowid 1:10その他すべてのトラフィック（バッチS3バックアップ、ログ転送エージェント、ファイルエクスポートなど）はクラス1:20にルーティングされ、転送速度は最大20 Mbpsに制限されます。
アクティブトラフィックの確認とモニタリング
トークンの消費状況、パケットドロップ数、現在の転送レートをリアルタイムで監視します。
tc -s class show dev eth0curlによるAPI通信テストやiperf3 -c <target-ip> -p 5201を使ってスループットテストを実行すると、未分類の転送が20 Mbpsの制限に抑えられつつ、ポート443のWebトラフィックは100 Mbpsまでスムーズにバーストする様子を確認できます。
クリーンアップ
設定したすべてのクラス階層、トークンバケット、フィルタを破棄するには、ルートqdiscを削除します。
sudo tc qdisc del dev eth0 rootまとめチェックリスト
- カオスなネットワーク環境をシミュレートする場合:
tc qdisc add dev <interface> root netem delay 80ms 15ms loss 3%を実行し、遅延、ジッター、パケットドロップをカーネルスタック内で直接検証します。 - 送信リンクの飽和を防ぐ場合:
tc qdisc add dev <interface> root handle 1: htbを設定し、保証最低帯域と上限キャップを定義します。 - テスト完了時の対応: ステージングや本番環境に人工的なボトルネックを残さないよう、必ず
tc qdisc del dev <interface> rootを実行してクリーンアップします。
