Docker ネットワークモード選択実践：bridge、host、overlay の決定ガイド

ある実際の障害から始めよう

深夜 2 時、本番環境の API サービスが突然タイムアウトした。

コンテナは確かに起動している。docker ps は running を表示し、ファイアウォールも停止し、ポートマッピングも明確に設定されている。コンテナログにもエラーがない。30 分間トラブルシューティングして、もう限界だ。最後にわかったのは、Docker のネットワークモードが間違っていたということ。デフォルトの bridge を使用していたが、サービスは別のノードのデータベースにクロスホストでアクセスする必要があった。bridge は単一ホスト通信のみで、ホストを跨げない。

このケースは、かなり一般的な問題を浮き彫りにしている。多くの開発者は Docker に bridge、host、overlay の3つのネットワークモードがあることを知っているが、いつどれを使うべきか明確に理解していない。正直に言うと、私も最初はこの落とし穴にハマった。

この記事を読み終えると、3つのネットワークモードの完全な意思決定フローチャートと性能ベンチマーク比較表を入手できる。次にネットワークの問題に遭遇したら、「単一ホストかクロスホストか」を先に判断すれば、私のように無駄な試行錯誤を避けられる。

---

Bridge：デフォルトの選択、単一ホスト通信の王様

Bridge は Docker のデフォルトネットワークモードだ。

docker run を実行するとき、--network を指定しなければ、コンテナは自動的にこのモードに割り当てられる。核心となる仕組みはシンプルだ。Docker はホスト上に docker0 という仮想ブリッジを作成し、各コンテナに独立した IP（通常 172.17.x.x）を割り当て、veth pair（仮想ネットワークケーブル）を通じてブリッジに接続する。

抽象的に聞こえるかもしれない。実は、コンテナを独立した仮想マシンとして扱い、プライベート IP を割り当て、NAT（ポートマッピング）を通じて外部と通信させるようなものだ。

適用シナリオ

単一ホストの複数コンテナデプロイ、Bridge が第一選択だ。

開発環境、テスト環境、さらにクロスホスト通信が不要な一部の本番シナリオでも、これだけで十分。シンプルで、安全で、追加設定が不要だ。

設定例

デフォルトが Bridge なので、指定する必要すらない：

# デフォルト bridge、IP 自動割り当て、-p でポートマッピングが必要
docker run -d -p 8080:80 nginx

ただし、問題がある。デフォルト bridge では、コンテナ間は IP でのみ通信でき、コンテナ名は使用できない。2つのコンテナを起動して、相互にアクセスさせたい場合、手動で IP を調べる必要があり、面倒だ。

どう調べるか？docker inspect を使用する：

# 2つのコンテナを起動
docker run -d --name web nginx
docker run -d --name db redis

# web コンテナの IP を確認
docker inspect web | grep IPAddress
# 出力：172.17.0.2

# db コンテナ内で web を ping（IP のみ使用可能）
docker exec db ping 172.17.0.2

このように、通信のたびに IP を調べる必要があり、面倒だ。コンテナを再起動すると、IP が変わる可能性があり、さらに面倒になる。

推奨される方法は、カスタム bridge を作成すること：

# カスタムネットワークを作成
docker network create --subnet=192.168.100.0/24 my-net

# コンテナを起動し、カスタムネットワークに接続
docker run -d --network my-net --name web nginx
docker run -d --network my-net --name db redis

# web コンテナは db を直接 ping 可能（DNS 自動解決）
docker exec web ping db

これで、コンテナ名をドメイン名として使用できるようになり、かなり便利になった。正直に言うと、この点には驚いた。DNS を手動で設定する必要があると思っていたが、Docker に組み込まれていた。

---

Host：最高性能、最小隔離

Host モードは少し「強引」だ。コンテナがホストのネットワークスタックを直接使用する。

独立した IP も、NAT 変換も、veth pair もない。コンテナ内のネットワークインターフェースがホストのネットワークインターフェースそのもので、性能はネイティブに近く、ほとんどオーバーヘッドがない。

「これほど直接的なら、性能は最高ではないか？」と思うかもしれない。確かにそうだ。しかし、代償は隔離がないことだ。

適用シナリオ

ネットワーク性能に敏感なシナリオでは、Host が最適な選択だ。

ゲームサーバー、リアルタイム通信（WebSocket、ビデオストリーミング）、高頻度取引システムなど、これらのアプリケーションでは数十マイクロ秒のレイテンシが重要で、Host モードはこれらのオーバーヘッドを削減できる。

また、ネットワークデバッグにも適している。コンテナ内で tcpdump を実行すると、ホストのトラフィックを直接キャプチャでき、追加設定が不要で、問題の調査に便利だ。

設定例

さらにシンプルで、-p すら不要：

# host モード、コンテナがホストの 80 ポートを直接占有
docker run -d --network host nginx

起動後、ホストの 80 ポートに直接アクセスすれば、コンテナ内の nginx にアクセスできる。

リスク警告

いくつかの落とし穴に注意が必要だ。

ポート競合：ホスト上ですでに nginx が実行されている（80 ポートを占有）場合、別の host モードのコンテナも 80 を使用しようとすると、エラーが発生し、起動できない。

エラーメッセージは次のようになる：

docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:80 failed: port is already allocated.

トラブルシューティング方法はシンプルだ。まずホストのポート使用状況を確認：

# ポート使用状況を確認
netstat -tuln | grep :80
# または
ss -tuln | grep :80

# プロセスを確認
lsof -i :80

プロセスがポートを占有している場合、それを停止するか、コンテナのポートを変更する。コンテナのポートを変更する場合、Host モードでは -p を使用できないため、コンテナ内でアプリケーションの設定を変更する（例えば、nginx を 8080 でリッスンするように変更）。

セキュリティ：コンテナはホストのすべてのネットワークインターフェースを表示できる。イントラネット、インターネット、VPN 接続も含む。コンテナが侵害された場合、攻撃者はホストのすべてのネットワークリソースにアクセスできる。本番環境では慎重に検討する必要がある。

正直に言うと、Host モードの使用は少ない。大部分のシナリオでは Bridge で十分だ。しかし、性能のボトルネックに遭遇したり、本当に低レイテンシが必要な場合、Host は検討に値する選択肢だ。ただし、隔離の代償を受け入れる前提が必要だ。

---

Overlay：クロスホスト通信の正解

Bridge は単一ホスト通信のみ、Host は性能が良いがホストを跨げない。では、複数のサーバー上のコンテナはどうやって相互にアクセスするのか？ここで Overlay が必要になる。

Overlay ネットワークは VXLAN トンネル技術に基づき、異なるホストに分散されたコンテナを1つの仮想 LAN にまとめ、まるで同じマシン上にあるかのように見せる。

核心原理

VXLAN が Overlay の鍵だ。

コンテナトラフィックの外側にカプセル化層を追加し、「トンネル」を通じて別のホストに転送し、そこでカプセル化を解除して、ターゲットコンテナに渡す。このカプセル化/カプセル化解除プロセスは VTEP（VXLAN Tunnel Endpoint）が担当し、Docker Swarm が自動的に管理する。

例えると：北京から上海に荷物を送る場合、配送業者が荷物を大きな箱に入れ、物流ネットワークを通じて上海に運び、そこで箱を開けて荷物を受取人に渡す。VXLAN がその「大きな箱」で、コンテナトラフィックが「荷物」、VTEP が配送業者の梱包/開梱プロセスだ。

VXLAN の利点は：基盤となる物理ネットワークの接続方法に関係なく、コンテナは同じ仮想 LAN を認識し、IP が統一され、通信がシンプルだ。

前提がある：Overlay ネットワークは Swarm クラスター、または外部 KV ストア（例えば Consul）が必要だ。単一ホストの Docker では作成できず、マルチノードの協調が必要だ。

なぜ Swarm が必要なのか？Overlay ネットワークは複数のホストのコンテナ IP、VTEP 接続、ルーティング情報を管理する必要があり、これらには中央集権的な調整役が必要で、Swarm がその役割を果たす。Swarm を使用しない場合、Consul、Etcd を KV ストアとして使用できるが、設定はより複雑になる。

適用シナリオ

Docker Swarm クラスターでは、Overlay が唯一の選択肢だ。

クロスホストマイクロサービスデプロイ、例えば Web サービスがノード A に、データベースがノード B にある場合、それらは相互にアクセスする必要がある。Overlay はそれらを1つの仮想ネットワークにまとめ、コンテナ名で通信でき、IP を設定する必要がない。

Kubernetes にも類似の概念（CNI ネットワーク）があるが、設定方法は異なる。主に K8s を使用する場合、この記事の Overlay 概念は K8s のネットワーク原理を理解するのにも役立つ。

設定例（完全なフロー）

Overlay の設定は Bridge、Host よりも複雑で、まず Swarm を初期化する必要がある：

# 1. 最初のホストで Swarm を初期化
docker swarm init --advertise-addr 192.168.1.10

# join token が出力される、例えば：
# docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 2. 他のホストで Swarm に参加（上記のコマンドをコピー）
docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 3. Overlay ネットワークを作成
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

# 4. 異なるホストでコンテナを起動し、同じ Overlay に参加
# ノード A で
docker run -d --network my-overlay --name web nginx

# ノード B で
docker run -d --network my-overlay --name db redis

# 5. 通信をテスト（web は db を ping 可能、クロスホスト！）
docker exec web ping db

Overlay を初めて設定した時、落とし穴にハマった：Swarm の初期化を忘れて、直接 overlay ネットワークを作成しようとし、“This node is not a swarm manager” というエラーが発生した。後になって、Overlay は Swarm に依存していることがわかった。

もう1つの詳細：--subnet=10.0.1.0/24、/24 サブネットブロック（256 個の IP）の使用を推奨し、他のネットワークとの競合を避ける。大規模なクラスターでは /16 を使用できるが、IP 範囲を適切に計画すること。

---

性能ベンチマーク比較：データで語る

3つのネットワークモードにはどの程度の性能差があるのか？いくつかの実測データを整理し、直感的な比較を提供する。

核心データ（72時間ストレステスト）

CSDN の本番環境実測レポートによると、3つのモードはストレステスト下で次のような結果を示した：

重要な発見

いくつかの数字が興味深い：

Host は Bridge よりかなり速い。平均レイテンシは 128μs から 32μs に低下し、96μs の差で、約 14% の性能向上だ。スループット面では、Host はネイティブに近く、Bridge は約 80%だ。アプリケーションが毎秒数千回のリクエストを処理する場合、この差は明確になる。

Bridge の NAT オーバーヘッドは無視できない。CPU 使用率は 0.9 コアから 1.8 コアに上昇し、ほぼ倍増した。各外部リクエストが NAT 変換を経るため、処理層が1つ増える。

Overlay の VXLAN カプセル化はさらに重い。クロスホスト通信にはカプセル化とカプセル化解除が必要で、レイテンシは Bridge よりさらに高く、CPU 使用率も大きい。分散シナリオに適しているが、高性能な単一ホストには適していない。

実際の影響

これらの数字は抽象的に見えるが、実際のシナリオでは差が大きい。

例えば、高頻度取引システムでは、毎マイクロ秒が重要で、Host モードの 32μs と Bridge の 128μs の差は、注文が取れるかどうかを決める可能性がある。一方、通常の Web アプリケーションでは、ユーザーリクエストの往復レイテンシは元々数百ミリ秒で、数十マイクロ秒の差はほとんど感じられない。

だから、数字だけで判断せず、自分のシナリオと組み合わせる必要がある。性能重視？Host を優先。セキュリティ優先？デフォルト Bridge。クロスホスト必須？Overlay、性能の代償を受け入れる。

自分の環境でテストする方法

自分の環境で性能差をテストしたい場合、いくつかのシンプルな方法がある：

レイテンシテスト：ping または iperf3 を使用

# コンテナ A でコンテナ B を ping（bridge モード）
docker exec container-a ping container-b

# iperf3 でスループットをテスト（先に iperf3 をインストール）
docker exec container-a iperf3 -c container-b

CPU 使用率モニタリング：docker stats を使用

# コンテナの CPU 使用率を確認
docker stats --no-stream

ネットワークトラフィックモニタリング：tcpdump でパケットキャプチャ分析

# ホストのネットワークトラフィックをキャプチャ（host モードは直接キャプチャ）
docker exec -it container-host tcpdump -i eth0

# bridge ネットワークトラフィックをキャプチャ（ブリッジを指定）
tcpdump -i docker0

本番環境にデプロイする前に、ストレステストを実行して、選択したネットワークモードがトラフィックに耐えられるか確認することをお勧めする。デプロイ後に問題を発見するのを避けるためだ。

---

意思決定フローチャート：シナリオからモード選択へ

これほど多くのことを説明したが、結局どう選べばいいのか？シンプルな意思決定ロジックを提供する。

3ステップの意思決定フロー

ネットワーク設定に遭遇したら、このフローに従う：

ステップ1：クロスホスト通信が必要か？

複数のコンテナが異なるサーバーに分散し、相互にアクセスする必要がある場合（例：Web がノード A に、データベースがノード B にある）、クロスホストが必要。

• YES → ステップ2
• NO → ステップ3

ステップ2：Swarm を使用するか？

クロスホスト通信には2つの方法がある：Docker Swarm（Overlay を使用）または手動ルート設定（Host + iptables）。

• YES → Overlay ネットワーク（最もシンプル、Swarm が自動管理）
• NO → Macvlan または Host + ルート設定を検討（複雑、特殊シナリオに適用）

ステップ3：ネットワーク性能に敏感か？

アプリケーションがレイテンシ、スループットに敏感な場合（高頻度取引、リアルタイム通信、ゲーム）、性能優先。

• YES → Host モード（ただしセキュリティリスクを評価）
• NO → Bridge モード（デフォルトの安全な選択）

シナリオ推奨表

より直感的に、一般的なシナリオの推奨を示す：

シナリオ	推奨モード	理由
単一ホスト Web アプリケーション	Bridge	安全、シンプル、デフォルトで十分
高頻度取引サービス	Host	レイテンシ敏感、最高性能
Swarm マイクロサービスクラスター	Overlay	クロスホスト通信必須
開発デバッグ環境	Bridge（カスタム）	DNS サポート、コンテナ名で通信
完全隔離テスト	None	ネットワークなし、完全隔離

1つの小さなアドバイス

最初から「どのモードが最適か」で悩まないこと。

大部分のシナリオでは、Bridge で十分だ。問題に遭遇してから調整する：

• サービスディスカバリが面倒 → カスタム Bridge に変更
• 性能が本当に不足 → Host を検討、ただしセキュリティの代償を評価
• クロスホストが必要 → Overlay、VXLAN の性能オーバーヘッドを受け入れる

多くのチームを見てきたが、最初から Host を設定し、ポート競合やセキュリティ脆弱性の問題が山積みになる。実は、Bridge はデフォルトで 90% のシナリオを解決でき、過剰に最適化する必要はない。

---

本番環境のベストプラクティス

3つのモードにはそれぞれ長所と短所がある。本番環境でどう使えば安全か？いくつかの実戦経験をまとめる。

Bridge：カスタムネットワーク + DNS

デフォルト bridge には大きな問題がある：コンテナは IP でのみ通信でき、名前を使用できない。

本番環境では、カスタム bridge の作成を推奨する：

# カスタムネットワークを作成、サブネットを指定（競合を回避）
docker network create --subnet=192.168.100.0/24 --name my-app-net

# サービスを起動し、カスタムネットワークに接続
docker run -d --network my-app-net --name web-server nginx
docker run -d --network my-app-net --name redis-cache redis

# web-server は redis-cache に直接アクセス可能（DNS 自動解決）
docker exec web-server ping redis-cache

これで、サービスディスカバリは手動で IP を設定する必要がなく、コンテナ名をドメイン名として使用でき、かなり便利になった。

もう1つ：サブネット計画は合理的に。デフォルトの 172.17.x.x を使用しないこと、会社のイントラネットと競合しやすい。192.168.100.0/24 または 10.10.10.0/24 の使用を推奨し、事前に運用チームと IP 範囲を調整すること。

Host：セキュリティ強化は不可欠

Host モードは性能が良いが、セキュリティが弱い。コンテナはホストのすべてのネットワークインターフェースを表示でき、イントラネット、インターネット、VPN も含む。

本番環境で Host を使用する場合、少なくとも2つのことを行う：

第一：コンテナ権限を制限する。--cap-drop で不要な Linux capabilities を削除する。例えば CAP_NET_RAW（コンテナが自由にパケットをキャプチャするのを防ぐ）：

docker run -d --network host --cap-drop NET_RAW nginx

第二：異常なトラフィックをモニタリングする。コンテナのネットワーク動作を監視する。例えば、突然の大量外部接続、イントラネットの機密インターフェースへのアクセスなど、アラートを上げる必要がある。Prometheus + Grafana でモニタリングするか、専門のネットワークセキュリティツールを使用する。

正直に言うと、Host モードは本番環境ではあまり使用されない。性能が本当にボトルネックになる場合を除いて。大部分のシナリオでは Bridge + カスタムネットワークで十分だ。

Overlay：サブネットサイズ + Swarm 安定性

Overlay ネットワークの鍵は VXLAN カプセル化で、オーバーヘッドが無視できない。

いくつかの最適化ポイント：

サブネットサイズを制御する：/24（256 個の IP）の使用を推奨、大規模なクラスターでは /16（約 6 万個の IP）を使用できるが、事前に計画し、競合を避けること。

# 推奨：/24 サブネットブロック
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

CPU 使用率をモニタリングする：VXLAN カプセル化は CPU オーバーヘッドを増加させる、特に高トラフィックシナリオで。docker stats または Prometheus でモニタリングし、CPU が高すぎる場合は、MTU の調整やクロスホスト通信の削減など、最適化が必要。

Swarm ノード間のネットワーク安定性を優先する：Overlay は Swarm に依存し、ノード間のネットワークが不安定な場合、Overlay に問題が発生する。本番環境で Overlay を使用する場合、Swarm ノード間のネットワークレイテンシが低く、パケットロスが少ないことを確認し、イントラネット専用線の使用が最善だ。

---

まとめ：3つの核心原則を覚える

これほど多くのことを説明したが、結局は3つの文に集約される：

1. 単一ホストはデフォルトで Bridge

90% のシナリオで、Bridge で十分だ。安全、シンプル、デフォルトで使用でき、悩む必要がない。サービスディスカバリが面倒な場合、カスタム Bridge に変更すれば、コンテナ名で通信できる。

2. 性能敏感なら Host を使用

レイテンシ敏感、スループットが重要なシナリオでは、Host が最適な選択だ。ただし覚えておくこと：性能は最高だが、隔離は最も弱い。本番環境で Host を使用する場合、セキュリティ強化が必要だ。

3. クロスホストなら必ず Overlay

複数のサーバー上のコンテナが相互にアクセスする必要がある場合、Overlay が唯一の正解だ。前提は Swarm クラスターで、設定は Bridge、Host より複雑だが、クロスホスト通信には必須だ。

実戦アドバイス

次に Docker ネットワークの問題に遭遇したら、最初に自分に問いかけること：単一ホストかクロスホストか？

単一ホストなら、デフォルトで Bridge。性能が足りない場合、Host を検討、ただしセキュリティの代償を評価。クロスホストなら、Overlay、VXLAN の性能オーバーヘッドを受け入れる。

最初から「どのモードが最適か」で悩まず、Bridge から始めて、問題に遭遇してから調整する。私は逆にやって、最初に Overlay を設定したが、単一ホストシナリオでは全く使用せず、無駄な試行錯誤をした。

bridge/host/none/container の基礎原理にまだ慣れていない場合、シリーズの第11章「Dockerネットワークモード詳解」を先に読むことをお勧めする。基礎を理解してから、この発展的な内容を読むと、よりスムーズに理解できる。

---

参考資料

"Docker は複数のネットワークドライバーを提供し、bridge、host、overlay、macvlan など、各モードは異なるシナリオに適用される。公式ドキュメントは各モードの設定方法と適用シナリオを詳細に説明している。"

"Overlay ネットワークは VXLAN トンネル技術に基づき、Swarm クラスターまたは外部 KV ストアのサポートが必要、クロスホストコンテナ通信に適している。公式ドキュメントは完全な設定フローを提供している。"

"Swarm ネットワーク管理ガイド、overlay ネットワークの作成方法、サービスネットワークの管理、およびクロスホスト通信のベストプラクティスを含む。"

"Docker网络配置最佳实践(生产环境零丢包实测报告)、72 時間ストレステストデータを提供し、Host、Bridge、Overlay の3つのモードのレイテンシ、スループット、パケットロス率の比較を含む。"

"Docker Network Tests under Host/Bridge Mode、Host と Bridge モードの性能差を詳細に比較し、レイテンシテスト方法と実験データを提供している。"