🦖

Docker LLM Gatewayのキャッチアップ

2025/10/03に公開

AWS

Docker

Model Context Protocol

tech

 TL;DR 📋
本記事の内容: Docker LLM Gatewayの実装手法と、MCPプロトコルによるマルチエージェント統合

本記事の対象範囲: リモートMCPとしてDocker MCP Gatewayを利用する場合について解説（ローカル実行パターンは対象外）

理解できること:
Docker LLM Gatewayのアーキテクチャ設計と実装手法
MCP（Model Context Protocol）を活用したマルチツール統合

なぜFargateで動作しないのかの技術的制約と根本原因
EC2での実装パターンと単一インスタンス依存の課題
セキュリティ境界設計と運用監視のベストプラクティス


対象読者: LLMアプリケーション開発者、インフラエンジニア、MLOpsエンジニア


 🚀 課題（背景・問題提起）
 LLMアプリケーションの複雑化現代のLLMアプリケーションでは、単一のモデル呼び出しでは解決できない複雑なタスクが増加しています。特にリモートMCP環境（HTTP経由でのMCPツール利用）では、以下の課題が顕著です：

マルチツール統合: git操作、データベースアクセス、ブラウザ自動化を統合したワークフロー

セッション管理: 長時間の対話セッションと状態保持

スケーラビリティ: 複数のエージェントサーバーの動的スケーリング

セキュリティ: コンテナ間の安全な通信とリソース分離

 従来手法の限界モノリシックアプローチ：
🔴 単一プロセスでの全機能実装 → 障害時の影響範囲が大きい
🔴 言語・ライブラリの制約 → 最適な技術選択ができない
マイクロサービスアプローチ：
🔴 複雑なAPI設計 → 開発・運用コストの増大
🔴 非標準プロトコル → エコシステムとの連携困難

 💡 解決策（アプローチ）
 Docker LLM Gateway アーキテクチャDocker LLM Gatewayは、Model Context Protocol (MCP) を基盤とした統合プラットフォームです：
           インターネット / 社内LAN
                   │ HTTPS
           ┌───────▼───────────┐
           │  ALB / NLB (任意) │
           └───────┬───────────┘
                   │ (MCP: Streamable HTTP)
   ┌──────────────────────────────────────────┐
   │  EC2 (Docker Engine あり)                │
   │                                          │
   │  ┌────────────────────────────────────┐  │
   │  │ Docker MCP Gateway (1コンテナ)     │  │
   │  │  ↕ バインドマウント                │  │
   │  │  /var/run/docker.sock             │  │
   │  └──────┬──────────────┬────────────┘  │
   │         │              │                │
   │  ┌──────▼───┐   ┌──────▼────┐   ┌──────▼────┐
   │  │ git-mcp  │   │ pg-mcp    │   │ playwright│
   │  │ (Container)│ │ (Container)│   │ (Container)│
   │  └──────────┘   └───────────┘   └────────────┘
   └──────────────────────────────────────────┘

 アーキテクチャの詳細解説🔧 中央制御の仕組み：
Docker MCP Gateway が Docker API (/var/run/docker.sock) を通じてバックエンドコンテナを動的に生成・破棄
各MCPツール（git-mcp、pg-mcp、playwright等）は独立したコンテナとして隔離実行

重要: ホストのDocker Engineへの直接アクセスが必須要件
🌐 通信プロトコル：
クライアント ↔ Gateway: MCP (Streamable HTTP または stdio)
Gateway ↔ MCPコンテナ: stdio (プロセス間通信)
単一エンドポイント (/mcp) でのマルチツール統合

 核心的な価値提案
統一プロトコル: MCPによる標準化されたツール通信

動的スケーリング: Docker APIを使ったコンテナのオンデマンド起動

技術多様性: 各ツールを最適な言語・フレームワークで実装可能

運用簡素化: 単一エンドポイントでの統合管理

 ⚠️ 重要な制約：なぜFargateでは動作しないのか
 Fargateの根本的制約Docker LLM Gatewayが AWS Fargate で動作しない 理由は、Fargateのセキュリティモデルと技術的制約にあります：
        Fargate タスク (Firecracker micro-VM)
        ┌──────────────────────────────┐
        │  mcp-gateway:latest          │
        │  -v /var/run/docker.sock     │  ← ✕ ソケットが存在しない
        │  --privileged                │  ← ✕ 非許可
        │  Docker Engine 操作          │  ← ✕ 不可能
        └──────────────────────────────┘

 具体的な制約項目

制約項目
詳細理由
技術的背景


ホストパス bind-mount 非対応

/var/run/docker.sock へのアクセス不可
Fargateは ephemeral storage のみ許可

Docker Engine が存在しない
Firecracker micro-VM 上で直接コンテナ実行
Docker in Docker の概念自体が不適用

特権コンテナ禁止

--privileged フラグ利用不可
セキュリティ境界を厳格に維持

ホスト制御の制限
システムレベル操作の遮断
他テナントへの影響を完全遮断


 Docker MCP Gateway の必須要件 vs Fargateの制約Docker MCP Gateway の動作要件:
┌─────────────────────────────────┐
│ 1. /var/run/docker.sock へのアクセス   │ ← Fargateでは不可能
│ 2. Docker API でのコンテナ操作        │ ← Docker Engine が存在しない
│ 3. ホストネットワークでの通信          │ ← セキュリティ制約で遮断
│ 4. 動的なコンテナ lifecycle 管理      │ ← 権限不足
└─────────────────────────────────┘

 なぜEC2が必要なのか
 EC2での動作要件        EC2 インスタンス (ホストOS)
        ┌────────────────────────────────┐
        │  Docker Engine (systemd)       │
        │  ├─ /var/run/docker.sock       │  ← ✅ 直接アクセス可能
        │  └─ Container Runtime          │  ← ✅ 制御可能
        │                                │
        │  ┌──────────────────────────┐  │
        │  │  MCP Gateway Container   │  │  ← ✅ 特権実行可能
        │  │  Docker Client           │  │  ← ✅ API呼び出し可能
        │  └──────────────────────────┘  │
        └────────────────────────────────┘

 🔍 詳細解説
 MCPプロトコルの技術的優位性
 1. MCP通信方式の比較

項目
MCP (Streamable HTTP)
MCP (stdio)
従来REST API


対象環境
リモート通信
ローカル実行
リモート通信

エンドポイント数
1個
N/A (プロセス間)
複数必要

双方向通信
✅ 同一接続内
✅ パイプ通信
❌ 一方向のみ

プログレス通知
✅ リアルタイム
✅ リアルタイム
❌ ポーリング必要

LB/Proxy対応
✅ 優秀
N/A
✅ 標準

セッション管理
✅ JSON-RPC継続
✅ プロセス生存期間
❌ ステートレス

MCPの特徴：
🎯 統一仕様: stdio/HTTP両方で同じJSON-RPCメッセージ
🎯 ツール発見: 動的なツール機能の取得
🎯 プログレストークン: 長時間処理の進捗通知

 2. コンテナ分離による技術多様性Docker LLM Gatewayでは、各MCPツールを最適な技術スタックで実装できます：
🐍 Python エコシステム     📦 Node.js エコシステム
├─ データサイエンス系       ├─ ブラウザ自動化
│  (pandas, numpy)        │  (puppeteer, playwright)
├─ AI/ML ライブラリ       ├─ API統合
│  (transformers)         │  (axios, fetch)
└─ データベース接続        └─ 高速JSON処理
   (psycopg2, SQLAlchemy)     (V8 engine)

⚡ Go 高性能処理          🦀 Rust システムレベル
├─ 並行処理              ├─ メモリ効率性
│  (goroutines)          │  (zero-cost abstractions)
├─ ネットワーク処理        ├─ 型安全性
│  (net/http)            │  (ownership system)
└─ バイナリサイズ最適化     └─ システムコール制御
   (static compilation)      (tokio async runtime)

 スケーラビリティ設計パターン
 水平スケーリング戦略       ロードバランサー (ALB/NLB)
              │
     ┌────────┼────────┐
     ▼        ▼        ▼
  Gateway-1 Gateway-2 Gateway-3
     │        │        │
  ┌──┼────┐ ┌─┼────┐ ┌─┼────┐
  ▼  ▼    ▼ ▼ ▼    ▼ ▼ ▼    ▼
 📦 📦   📦📦 📦   📦📦 📦   📦
 MCP Tools  MCP Tools  MCP Tools
スケーリング考慮事項：
🎯 コンテナ起動遅延: 初回起動時のイメージPull時間
🎯 リソース競合: Docker Engineの同時処理限界
🎯 状態管理: セッション情報の永続化戦略

 単一EC2インスタンス依存の根本問題Docker MCP Gatewayをリモート接続（Streamable HTTP）で使用する場合、全てのMCPツールが単一のEC2インスタンス上に集約される 制約があります：
           リモートクライアント (複数)
              │  │  │  │  │
              ▼  ▼  ▼  ▼  ▼
         ┌─────────────────────┐  MCP over HTTP
         │  ALB (Load Balancer) │  ← ❌ 真の負荷分散は不可能
         └─────────┬───────────┘
                   │ (実際は単一インスタンスへルーティング)
              ┌────▼────┐
              │  EC2-1  │  ← 🔴 ボトルネック：全処理が集中
              │         │
              │ ┌─────┐ │
              │ │ MCP │ │  ← 全MCPツールがここに存在
              │ │ GW  │ │
              │ └─────┘ │
              │ git-mcp │
              │ pg-mcp  │
              │ browser │
              └─────────┘

 制約の技術的詳細

制約項目
内容
影響


Docker Socket依存

/var/run/docker.sock は単一ホストのみ
他EC2から制御不可

コンテナローカル実行
MCPツールコンテナは同一ホスト内実行
分散処理不可

状態共有の制限
ファイルシステム・ネットワーク共有が前提
クロスホスト連携困難

セッション局所性
Gateway-Container間の直接通信必須
ホスト間通信オーバーヘッド


 真の負荷分散が実現できない理由❌ 期待される負荷分散 (不可能)
    ┌─────────┐   ┌─────────┐   ┌─────────┐
    │ EC2-1   │   │ EC2-2   │   │ EC2-3   │
    │ GW+MCPs │   │ GW+MCPs │   │ GW+MCPs │
    └─────────┘   └─────────┘   └─────────┘
         ▲             ▲             ▲
         └─────────────┼─────────────┘
                       │
                   Load Balancer

✅ 実際の動作 (制約あり)
              ┌─────────┐
              │ EC2-1   │  ← 全リクエストが1台に集約
              │ GW+MCPs │
              └─────────┘
                   ▲
                   │
               Load Balancer  ← 意味をなさない

 セキュリティ境界設計┌─────────────────── セキュリティ境界 ───────────────────┐
│                                                      │
│  ┌──── Gateway セキュリティ ────┐                    │
│  │  • TLS終端                   │                    │
│  │  • 認証・認可                │                    │
│  │  │  • Bearer Token          │                    │
│  │  • レート制限               │                    │
│  └─────────────────────────────┘                    │
│              │                                       │
│  ┌──── Container セキュリティ ─────┐                  │
│  │  • ネットワーク分離              │                  │
│  │  • リソース制限                 │                  │
│  │  • Read-onlyファイルシステム     │                  │
│  │  • 非特権ユーザー実行            │                  │
│  └─────────────────────────────────┘                  │
│                                                      │
└──────────────────────────────────────────────────────┘

 運用・監視の要点
 監視すべきメトリクス

カテゴリ
メトリクス
重要度
アラート閾値例


パフォーマンス
レスポンス時間
🔴 High
> 5秒

リソース
コンテナ起動数
🟡 Medium
> 50個

信頼性
エラー率
🔴 High
> 5%

セキュリティ
認証失敗率
🟡 Medium
> 10%


 ログ戦略📝 構造化ログ (JSON)
├─ Gateway レベル
│  ├─ リクエスト/レスポンス
│  ├─ コンテナ lifecycle
│  └─ エラートレーシング
└─ Container レベル
   ├─ MCPメッセージログ
   ├─ ツール実行結果
   └─ パフォーマンス指標

 📊 まとめ
 🎯 Docker LLM Gateway の適用判断Docker LLM Gatewayは、MCPプロトコル統合とコンテナベース分離を実現する強力なソリューションですが、適用には明確な前提条件があります：

 ✅ 適用推奨ケース
複雑なマルチツール統合が必要（git + DB + ブラウザ等）

技術多様性を活かしたい（Python/Node.js/Go/Rust混在）

EC2での運用が可能な環境

MCP標準準拠のエコシステム構築を目指す

 ❌ 適用非推奨ケース
Fargate必須の環境制約がある

単純なAPI統合で十分な要件

運用コスト最小化が最優先

高可用性・自動スケールが必須要件
間違っている部分などありましたら是非コメントなどで教えて下さい🚀
参考資料:
MCP Protocol Specification
Docker MCP Gateway GitHub

制約項目	詳細理由	技術的背景
ホストパス bind-mount 非対応	`/var/run/docker.sock` へのアクセス不可	Fargateは ephemeral storage のみ許可
Docker Engine が存在しない	Firecracker micro-VM 上で直接コンテナ実行	Docker in Docker の概念自体が不適用
特権コンテナ禁止	`--privileged` フラグ利用不可	セキュリティ境界を厳格に維持
ホスト制御の制限	システムレベル操作の遮断	他テナントへの影響を完全遮断

項目	MCP (Streamable HTTP)	MCP (stdio)	従来REST API
対象環境	リモート通信	ローカル実行	リモート通信
エンドポイント数	1個	N/A (プロセス間)	複数必要
双方向通信	✅ 同一接続内	✅ パイプ通信	❌ 一方向のみ
プログレス通知	✅ リアルタイム	✅ リアルタイム	❌ ポーリング必要
LB/Proxy対応	✅ 優秀	N/A	✅ 標準
セッション管理	✅ JSON-RPC継続	✅ プロセス生存期間	❌ ステートレス

制約項目	内容	影響
Docker Socket依存	`/var/run/docker.sock` は単一ホストのみ	他EC2から制御不可
コンテナローカル実行	MCPツールコンテナは同一ホスト内実行	分散処理不可
状態共有の制限	ファイルシステム・ネットワーク共有が前提	クロスホスト連携困難
セッション局所性	Gateway-Container間の直接通信必須	ホスト間通信オーバーヘッド

カテゴリ	メトリクス	重要度	アラート閾値例
パフォーマンス	レスポンス時間	🔴 High	> 5秒
リソース	コンテナ起動数	🟡 Medium	> 50個
信頼性	エラー率	🔴 High	> 5%
セキュリティ	認証失敗率	🟡 Medium	> 10%

TL;DR 📋

🚀 課題（背景・問題提起）

LLMアプリケーションの複雑化

従来手法の限界

💡 解決策（アプローチ）

Docker LLM Gateway アーキテクチャ

アーキテクチャの詳細解説

核心的な価値提案

⚠️ 重要な制約：なぜFargateでは動作しないのか

Fargateの根本的制約

具体的な制約項目

Docker MCP Gateway の必須要件 vs Fargateの制約

なぜEC2が必要なのか

EC2での動作要件

🔍 詳細解説

MCPプロトコルの技術的優位性

1. MCP通信方式の比較

2. コンテナ分離による技術多様性

スケーラビリティ設計パターン

水平スケーリング戦略

単一EC2インスタンス依存の根本問題

制約の技術的詳細

真の負荷分散が実現できない理由

セキュリティ境界設計

運用・監視の要点

監視すべきメトリクス

ログ戦略

📊 まとめ

🎯 Docker LLM Gateway の適用判断

✅ 適用推奨ケース

❌ 適用非推奨ケース

Discussion