この記事の概要
2026年1月、CNCFがコンテナイメージのP2P配信プロジェクト「Dragonfly」をGraduated（卒業）として認定しました。
大規模スケールアウト時にコンテナレジストリが単一障害点となる「Thundering Herd問題」を根本解決するOSSであり、Ant Group・Alibaba・Datadogなど130社以上が本番採用しています。
この記事では問題の本質・Dragonflyの仕組み・containerd連携の具体的手順・AI/MLモデル配信への応用まで、実務視点でまとめます。
P2Pを使えばレジストリは「1回だけ」引けばいい
大規模なKubernetesクラスタを運用していると、ある日突然こんな光景に出くわします。
オートスケーラーがHPAで200 Podへのスケールアウトをトリガーし、全ノードが同時にECRやHarborへ2GBのコンテナイメージを取りに走る。
結果、ImagePullBackOffが連鎖し、デプロイが止まり、MTTRが跳ね上がる。
CNCFに2026年1月14日付けで卒業認定されたDragonfly（https://d7y.io/）は、この問題をP2P（ピアツーピア）配信で根本解決します。
セントラルレジストリへのアクセスを「最初の1ノードの1回だけ」に限定し、残りのノードはそのノードから直接ブロックを受け取ります。
クラスタが大きくなればなるほど配信速度が上がるという逆転の発想です。
Alibaba Groupが2017年に内製ツールをOSS化し、2018年にCNCF Sandboxへ参加、2020年にIncubating、そして2026年1月にGraduatedへ昇格しました。
コミット数はCNCF参加後で3,000%以上増加し、130社以上の企業の271名がコントリビューターとして参加しています。
本番環境では1日あたり数千万のコンテナ起動を支え、ストレージ帯域を最大90%削減、起動時間を数分から数秒に短縮したという実績が報告されています。
なぜ「レジストリをスケールアップ」しても解決しないのか
コンテナオーケストレーションはKubernetesによって高度に分散化されているのに、アーティファクト配信だけは依然として中央集権型のまま、というのが根本的なミスマッチです。
たとえば2GBのイメージを200ノードにデプロイするケースを考えてみましょう。
必要転送量 = 2GB × 200ノード = 400GB（同一データの重複転送）
これは全ノードが「ほぼ同時に」レジストリに殺到する「Thundering Herd（雷鳴の群れ）問題」と呼ばれます。
中央レジストリのレプリカを増やしても、ネットワークスイッチ自体がボトルネックになるため根本解決にはなりません。
症状を隠しているだけです。
具体的な障害パターンとしては以下のようなものがあります。
ImagePullBackOffの連鎖によるPod起動失敗- ECRやGCR APIのレートリミット到達によるスロットリング
- ネットワークイングレス帯域の飽和（特にマネージドKubernetesではノード間帯域が制限されることがある）
- CI/CDパイプラインのデプロイステージでのタイムアウト
この問題はAI/MLワークロードでさらに深刻です。
LLaMA-3やDeepSeekなどのLLMモデルウェイトは130GBを超えることもあり、50台のGPUノードに一斉配信しようとすると標準的なネットワークゲートウェイが即座にクラッシュします。
DragonflyのP2P配信はこう動く
Dragonflyのアーキテクチャは3つのコンポーネントで構成されています。
┌─────────────────────────────────────────────────┐
│ Kubernetes Cluster │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Manager │ │Seed Peer │ │ Node 1 │ │
│ │(Control │◄───│(Supernode│ │dfdaemon │ │
│ │ Plane) │ │ Cache) │ │(DaemonSet│ │
│ └──────────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ ┌────▼──────────────▼────┐ │
│ │ P2P Mesh Network │ │
│ │ Node2 ◄──► Node3 │ │
│ │ ▲ ▲ │ │
│ │ Node4 ◄──► Node5 │ │
│ └────────────────────────┘ │
└─────────────────────────────────────────────────┘
▲（最初の1回だけ）
┌─────┴──────┐
│ OCI Registry│
│ ECR/Harbor │
└────────────┘
Manager（コントロールプレーン）：P2Pネットワークのトポロジーを管理し、各ノード間の最適な転送経路を動的に計算します。
Seed Peer（Supernode）：中央レジストリからオリジナルのアーティファクトを「最初の1回だけ」取得し、P2Pメッシュにシーディングする高可用キャッシュです。
Dfdaemon（Peer）：各ワーカーノード上にKubernetes DaemonSetとしてデプロイされる軽量プロキシです。containerdやCRI-Oからのイメージプルリクエストを透過的に横取りし、P2Pネットワークへ誘導します。
最大の特徴は開発者から完全に透過的な点です。Kubernetes マニフェストもイメージタグも変更する必要がありません。Podがスケジュールされるとcontainerdがイメージをプルしようとしますが、そのHTTPS通信をdfdaemonが静かに横取りします。
データ転送はブロック単位で行われます。
Node Aがブロック1を受け取ったその瞬間から、Node BはNode Aからブロック1を受け取れるようになります。
クラスタ全体が巨大なローカルCDNとして機能し始めるまで数秒しかかかりません。
実装例・コード例
1. HelmでDragonflyをデプロイ
# Dragonflyのリポジトリを追加
helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/
helm repo update
# dragonfly namespaceに展開
helm install --create-namespace \
--namespace dragonfly-system \
dragonfly dragonfly/dragonfly \
--set manager.replicas=1 \
--set seedPeer.replicas=2 \
--set dfdaemon.enable=true
# デプロイ確認
kubectl get pods -n dragonfly-system
# NAME READY STATUS RESTARTS
# dragonfly-manager-xxx 1/1 Running 0
# dragonfly-seed-peer-xxx-0 1/1 Running 0
# dragonfly-dfdaemon-xxxxx 1/1 Running 0 ← 全ノードに展開
2. containerdとの連携設定
dfdaemonはデフォルトで127.0.0.1:65001でリッスンしています。
containerdがこのプロキシ経由でイメージを取得するよう設定します。
# /etc/containerd/config.toml
version = 2
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["http://127.0.0.1:65001","https://registry-1.docker.io"]
# ECRをP2P経由にする場合
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."123456789.dkr.ecr.ap-northeast-1.amazonaws.com"]
endpoint = ["http://127.0.0.1:65001","https://123456789.dkr.ecr.ap-northeast-1.amazonaws.com"]
# containerdを再起動して設定反映
sudo systemctl restart containerd
# 動作確認：ログでP2P転送を確認
kubectl logs -n dragonfly-system -l component=dfdaemon --tail=20
この設定を全ノードに適用後、kubectl rollout restart deployment/<your-app>を実行するだけで以降のイメージ取得がP2Pメッシュ経由になります。
3. AI/MLモデル配信への応用
LLMのモデルウェイト配信にも対応しています。
dfdaemonの設定でHugging FaceやModelScopeのプロトコルを横取りできます。
# dfdaemon の proxyRules 設定例（Helm values.yaml）
dfdaemon:
config:
proxy:
registryMirror:
addr: "http://127.0.0.1:65001"
proxies:
# Hugging Face モデル配信をP2P化
- regx: ".*huggingface.co.*"
useHTTPS: true
# ModelScope 対応
- regx: ".*modelscope.cn.*"
useHTTPS: true
この設定により、vLLMやTensorRT-LLMで130GBのLlama-3ウェイトを50台のGPUノードに展開する際も、最初の1台だけがHugging Faceから取得し、残りのノードはP2Pでブロックを受け取ります。
実務での活用シナリオ
シナリオ1：マイクロサービスの大規模ローリングアップデート
本番環境で30個のマイクロサービスを同時にローリングアップデートするケースでは、各サービス2〜3GBのイメージが100ノードに同時展開されます。
Dragonflyを導入したDatadogのチームは「以前5分かかっていたイメージプルが数秒になった」と報告しています。
シナリオ2：オートスケール時のコールドスタート遅延の解消
トラフィックスパイクによるHPAスケールアウト時、新規ノードへのイメージ配信が律速になりサービスイン遅延が発生するケースがあります。
P2P配信ではクラスタ内に既存のPeerがいれば即座にブロック取得が開始されるため、コールドスタート時間を大幅に短縮できます。
シナリオ3：マルチクラスタへのGitOps展開
ArgoCDで複数のKubernetesクラスタに同じアーティファクトをデプロイする場合、各クラスタのSeed Peerが独立してP2Pメッシュを形成するため、クラスタ間のレジストリ帯域消費を抑制できます。
今日からDragonflyを試すための3ステップ
Dragonflyの最大の強みは「段階的に導入できること」です。
まず非本番環境のクラスタで試し、効果を確認してから本番適用できます。
- Helmでdry-run確認：まず
helm install --dry-runで生成されるマニフェストを確認し、既存のDaemonSetや名前空間との衝突がないかチェックしましょう。 - 特定レジストリだけをP2P化：最初から全レジストリをP2P化するのではなく、ECRや社内Harborなどトラフィックが多い1つのレジストリだけをDragonfly経由にして効果を測定します。
- PrometheusメトリクスでROIを可視化：DragonflyはPrometheusエンドポイントを標準でエクスポートしています。
dragonfly_peer_download_traffic_totalなどのメトリクスを見れば、レジストリへの転送量が何%削減されたかをGrafanaダッシュボードで確認できます。
大規模クラスタほど効果が大きくなるのがDragonflyの特徴です。
現在100ノード以上のクラスタを運用していて、デプロイ時にレジストリ起因の遅延を感じているなら、今すぐ試す価値があります。
まとめ
Dragonflyが解決する「Thundering Herd問題」は、Kubernetesの規模が大きくなるほど深刻化します。
中央レジストリをスケールアップしても根本解決にならない理由はアーキテクチャにあり、P2Pメッシュへのシフトが本質的な解法です。
2026年1月のCNCF Graduation認定は、Alibaba・Ant Group・Datadogといった超大規模本番環境での実績が評価された結果であり、導入にあたってのプロジェクト継続性リスクは低いと判断できます。コンテナイメージだけでなく、LLMウェイトのような大容量AIアーティファクトの配信にも対応が拡張されており、AI時代のインフラにも直結するOSSです。
コメント