なぜ仮想ブリッジはホームサーバーのコンテナアプリを遅延させるのか？

仮想ブリッジは、パケットが物理インターフェースとアプリケーションソケットの間を直接移動しなくなるため、ホームサーバーのコンテナアプリを遅延させる可能性があります。パケットは仮想イーサネットペア、ソフトウェアブリッジ、ルーティングやファイアウォールのフック、アドレス変換、そしてコンテナが受信する前に2つ目の名前空間を通過するかもしれません。各ステップは小さいですが、リクエストが短く頻繁であったり、CPUスケジューリングがすでに厳しい場合、その経路は測定可能になります。

それがブリッジネットワークを本質的に遅くするわけではありません。健全なブリッジはしばしばDNS、TLS、ストレージ、またはアプリケーションの作業よりも遅延を少なくします。重要な問いは、ブリッジが通常のパケットごとのオーバーヘッドをもたらすのか、それともMTU、conntrack、フィルタリング、またはネストされた仮想化の問題などの誤設定を露呈し、小さな負荷を明らかな遅延に変えているのかということです。

簡単な技術的回答

Linuxブリッジはソフトウェアスイッチです。Red Hatのブリッジ概要では、ネットワーク名前空間に接続された仮想インターフェースを含む接続されたインターフェース間でパケットを転送するカーネルモジュールとして説明されています。したがって、コンテナのフレームはホストのネットワークスタックを使うプロセスが回避できる追加の転送判断が必要です。

ブリッジはルートの一部に過ぎません。公開されたコンテナポートは、受信時に宛先変換を、送信時に送信元変換を呼び出すことができ、ファイアウォールやコネクショントラッキングルールがフローを検査します。これらの作業はCPUサイクル、キャッシュアクセス、キューを使用し、負荷がかかるとこれらの短い操作が他のパケットの後ろで待機し、テールレイテンシを拡大することがあります。

リクエストが仮想ブリッジを越えると何が起こるのか？

パケットがコンテナ名前空間に入る

ほとんどのブリッジ接続されたコンテナは、ネットワーク名前空間内に仮想イーサネットペアの一端を持ち、対応するもう一方の端はホスト上にあります。アプリケーションにとって、コンテナ側のインターフェースは通常のNICのように振る舞います。ホスト側では、その対応端がブリッジに接続されているため、受信フレームはコンテナのTCPソケットに到達する前に名前空間の境界を越えます。

このハンドオフは物理的な再送信ではありませんが、それでもパケットはカーネルのネットワーク段階やスケジューリングコンテキストを通過します。小さなウェブレスポンスは、長い転送よりもその固定作業をより明確に示します。アプリ自体がミリ秒のごく一部しか必要としない場合、その前後に費やされる別のごく一部の時間が割合を大きく変えることがあります。

ブリッジはフレームを選択し転送する

ブリッジはどのMACアドレスがどのポートの背後にあるかを学習し、その転送情報を使って出口ポートを選択します。Dockerのブリッジドライバのドキュメントはブリッジネットワークを1台のホスト上のコンテナを接続するソフトウェアブリッジとして説明しています。この設計は有用な分離とサービス間接続を提供しますが、転送レイヤーを挿入します。

未知のユニキャスト、ブロードキャスト、マルチキャストトラフィックは学習済みユニキャストフレームとは異なる扱いを受けることがあります。多忙なホストは複数のブリッジ、多数の仮想ポート、または入れ子の仮想スイッチを持つこともあります。問題は単一のルックアップではなく、リクエストとそのレスポンスが通過しなければならない段階とキューの数です。

フィルタリング、NAT、および接続追跡は状態を追加する

コンテナポートの公開は一般的にファイアウォールとNATルールを作成し、ホストのアドレスとポートをコンテナ側に変換します。Dockerのパケットフィルタリングのドキュメントはブリッジネットワーク用のファイアウォールルールを作成し、外部アクセスにはマスカレードを使用すると説明しています。そのため、新しいフローはパケットが確立された経路に従う前にルール評価と接続状態の作成を必要とする場合があります。

大規模なルールセット、高い接続の入れ替わり、またはほぼ満杯のconntrackテーブルはその作業を増幅します。リバースプロキシはコンテナ間のもう一つの経路を追加することがあり、ブラウザのリクエストが公開ポートを通って入り、プロキシを経由し、さらにアプリケーションへと渡ることがあります。レスポンスは逆のルートをたどります。

通常のブリッジオーバーヘッドと実際のレイテンシ問題の違い

最初のテストは比例性です。ブリッジ接続とホストネットワークのリクエストがわずかにかつ一貫して異なり、スループットがほぼ同じであれば、その差は分離と変換の予想されるコストかもしれません。レイテンシが数十ミリ秒または数百ミリ秒跳ね上がったり、ダウンロードが崩壊したり、特定のペイロードサイズだけが失敗する場合、ブリッジのルックアップだけでは十分な説明になりません。

Dockerコミュニティの報告は、この区別が重要な理由を示しています。あるユーザーはブリッジ経由のダウンロードが劇的に遅くなる一方でアップロードの遅延は似ていることに気づき、調査ではMTUと周辺のHyper-Vパスを検討し、極端なパケットロスを通常のブリッジオーバーヘッドとは見なさなかったのです。最終的にホスト環境の再起動後に挙動が変わりました。

レイヤーごとに測定します。IPアドレスとホスト名、コンテナポートとアプリの直接名前空間アドレス、ブリッジモードとホストモード、単純な静的エンドポイントと実際のアプリケーションを比較します。ZimaSpaceのDNS遅延とアプリケーション時間の分離ガイドは、遅い最初のルックアップがブリッジのせいにされるのを防ぎます。

なぜHost、macvlan、またはipvlanのパスが速く感じられるのか

ホストネットワーキングはコンテナプロセスがホストのネットワーク名前空間を共有できるようにします。この方法はコンテナブリッジ、ポート公開、および関連するNATホップを回避します。現在のブリッジ対ホストのガイドでは、ホストモードは仮想ブリッジやポートマッピングがないとまとめられており、これが診断の基準として有用な理由です。

macvlanとipvlanは異なるアプローチを取ります：従来の公開ポート経路なしにコンテナにLAN到達可能なIDを与えることができます。翻訳を除去またはブリッジ処理を減らすかもしれませんが、独自のホスト到達性、スイッチング、アドレス管理、互換性の制約を導入します。パケット経路が短いことが必ずしも単純な運用モデルを意味するわけではありません。

有効な結論は、同じホスト、アプリケーション、クライアント、プロトコル、ペイロードでのA/Bテストから得られます。ホストモードで遅延がほとんど変わらなければ、ブリッジは主要なボトルネックではありません。結果が大きく変わる場合は、キャプチャとカウンターで、除去されたコストがNAT、フィルタリング、conntrack、MTU処理、または単に別の過負荷の仮想レイヤーかどうかを特定すべきです。

遅延の背後にある利点とコスト

分離とサービスポリシーは実際の利点

ブリッジネットワークはコンテナに別々のアドレスと名前空間を与え、複数のアプリケーションが同じ内部ポートをバインドでき、オペレーターが選択したポートのみを公開します。また、ユーザー定義ネットワーク上でのサービス名発見もサポートします。これらは運用上およびセキュリティ上の利点であり、偶発的なオーバーヘッドではありません。

実用的なDockerの議論では、ホストモードが複数サービス間のポート競合を引き起こす可能性がある一方、ブリッジ名前空間は各コンテナがリバースプロキシの背後で独自のポートを使えるようにします。ブリッジを取り除くことは、測定可能なマイクロ最適化と引き換えに、より難しい展開を招くことがあります。

余分な状態は故障面を増やす

コストとして、追加される境界ごとにアドレス、ルート、MTU、チェックサム、ファイアウォールポリシーの合意が必要です。仮想マシン内でコンテナを実行するホームサーバーは、コンテナブリッジをVMブリッジの上に、さらに物理LANの上に重ねることがあります。各レイヤーは単独で正しくても、組み合わさった経路で不一致が露呈することがあります。

状態にも容量が必要です。接続追跡、隣接テーブル、キュー、CPUのsoftirq処理は、バースト時に圧力点になることがあります。10フローで正常に動作するブリッジが、数千フローになると遅く見えるのは、基本設計が突然変わったのではなく、共有リソースの一つが閾値を超えたためです。

実際に重要な実用的な修正

タイミングの証拠から始めてください。繰り返しHTTPリクエストを使用してコールドとウォームの挙動を分離し、非重要なテストインスタンスで一時的にブリッジモードとホストモードを比較します。中央値および高パーセンタイルのレイテンシを記録し、一つの結果だけに頼らないでください。また、ネットワーク時間がアプリケーション処理と混同されないように、静的エンドポイントとデータベースバックのページも比較してください。

実際の経路を追跡してください。コンテナネットワーク、vethペア、ブリッジメンバーシップ、ルート、公開ポート、およびファイアウォールカウンターを検査します。可能な場合は物理インターフェース、ブリッジ、およびコンテナ側インターフェースでパケットをキャプチャしてください。重複再送、長いギャップ、または片側にしか現れないパケットは失敗しているステージを絞り込みます。

ネットワークモードを変更する前に偶発的な複雑さを減らしてください。密接に連携するサービスは同じユーザー定義ブリッジ上に配置し、コンテナ間の不要な公開ポートを避け、ファイアウォールルールを意図的に保ち、conntrackの利用状況を確認してください。カプセル化により使用可能なペイロードが減少する場合は、物理、VM、トンネル、ブリッジ、およびコンテナインターフェース間でMTUを揃えてください。

測定結果がトレードオフを正当化した場合にのみ、ホスト、macvlan、またはipvlanを選択してください。ホストモードは制御されたポートを持つレイテンシに敏感なサービスに適しているかもしれませんが、複数アプリの分離にはブリッジが依然としてより良いデフォルトである場合があります。目標はすべてのカーネルステージを除去することではなく、証拠が遅延の原因と示すステージを除去することです。

いつ心配すべきか？

相互作用やスループットに影響しない小さく安定した差異は通常、設計上のコストであり、欠陥ではありません。負荷に応じてレイテンシが変化する場合、一方向のみが遅くなる場合、特定のパケットサイズが失敗する場合、conntrackが容量に近づく場合、またはパケットキャプチャで仮想インターフェース間の損失が示される場合に注意してください。これらのパターンは制約されたまたは一貫性のないパスを示しています。

また、アプリがコンテナの直接アドレス経由では高速だが、公開されたホストポート経由では遅い場合も調査してください。その比較は、すべてのコンテナをホストモードに切り替えるよりも、翻訳、フィルタリング、およびプロキシ層をより効果的に分離します。DNSキャッシュヒットやウォームTLSセッションが結果を歪めないようにテスト条件を維持してください。

仮想ブリッジは、便利な転送、分離、およびポリシーステージを追加することでコンテナアプリの遅延を引き起こします。健全なホームサーバーでは、そのコストは制限されるべきです。遅延が大きい場合は、ブリッジをチェックポイントの地図として扱い、各境界を測定し、時間やパケットが消失するステージを特定し、証拠がそれを制限パスとして示す場合にのみネットワーク設計を変更してください。