Docker SwarmとKubernetesの違いと使い分け

はじめに

コンテナオーケストレーションは、現代のマイクロサービスアーキテクチャや大規模アプリケーション運用において欠かせない技術となっています。複数のコンテナを管理し、スケーリング、ロードバランシング、サービスディスカバリなどを自動化するために、いくつかの主要なツールが存在します。その中でも特に有名なのが「Docker Swarm」と「Kubernetes」です。

この記事では、Docker SwarmとKubernetesの基本概念から主要な違い、そして実際のプロジェクトにおいてどのように使い分けるべきかについて詳しく解説します。

コンテナオーケストレーションとは

コンテナオーケストレーションとは、複数のコンテナアプリケーションのデプロイ、管理、スケーリング、ネットワーキングを自動化するプロセスです。主な機能には以下のようなものがあります：

コンテナのデプロイと複製
リソース割り当ての管理
コンテナ間のロードバランシング
サービスディスカバリ
スケーリング（自動または手動）
ヘルスチェックと自己修復
ローリングアップデート
シークレット管理

Docker Swarmの概要

Docker Swarmは、Dockerのネイティブクラスタリングソリューションです。Dockerエンジンに統合されており、複数のDockerホストをクラスター化してシングルな仮想Dockerホストとして扱うことができます。

主な特徴

シンプルなセットアップと使用方法：既存のDockerコマンドに慣れていれば、Swarmの使用もスムーズに行えます。
Dockerとの統合：Dockerエンジンに統合されており、追加のインストールが不要です。
宣言型サービス定義：YAML形式のDocker Composeファイルを使用してサービスを定義できます。
自動ロードバランシング：内蔵されたDNSとロードバランサーにより、サービス間の通信が容易です。
TLS暗号化：クラスター内の通信を自動的に暗号化します。

アーキテクチャ

Docker Swarmは、マネージャーノードとワーカーノードの2種類のノードで構成されます：

マネージャーノード：クラスター状態の維持、スケジューリング、API提供などの役割を担います。
ワーカーノード：コンテナの実行に特化しており、マネージャーから割り当てられたタスクを処理します。

マネージャーノードは高可用性を確保するため、通常は奇数（3, 5, 7など）で構成されます。

Kubernetesの概要

Kubernetes（K8s）は、Googleが開発した、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソースのプラットフォームです。

主な特徴

高度なオーケストレーション機能：複雑なアプリケーションデプロイと運用を管理する豊富な機能を提供します。
自己修復メカニズム：障害発生時に自動的に復旧するメカニズムを備えています。
自動スケーリング：負荷に応じてポッド（コンテナのグループ）を自動的にスケールします。
ローリングアップデートとロールバック：ダウンタイムなしでアプリケーションをアップデートし、必要に応じて以前のバージョンに戻すことができます。
豊富なエコシステム：ヘルムチャート、オペレーター、イングレスコントローラーなど、多数の拡張機能とツールが利用可能です。
クラウドプロバイダとの統合：主要なクラウドプロバイダはマネージドKubernetesサービスを提供しています。

アーキテクチャ

Kubernetesのアーキテクチャは、マスターノード（コントロールプレーン）とワーカーノードで構成されています：

マスターノード：API Server、Scheduler、Controller Manager、etcdなどのコンポーネントを含み、クラスター全体を管理します。
ワーカーノード：Kubelet、Kube-proxy、コンテナランタイムなどのコンポーネントを含み、実際のコンテナを実行します。

Docker SwarmとKubernetesの主な違い

1. 複雑さと学習曲線

Docker Swarm:

シンプルで直感的な設計
既存のDockerコマンドとほぼ同じ文法
セットアップが容易で学習曲線が緩やか

Kubernetes:

複雑なアーキテクチャと多様な抽象化レイヤー
独自の概念とAPIが多数ある
セットアップと学習に時間がかかる

2. スケーラビリティと安定性

Docker Swarm:

中小規模のデプロイに適している
シンプルな設計により、中規模までの環境では安定しやすい
非常に大規模なクラスター（数百～数千ノード）では制約がある場合がある

Kubernetes:

非常に大規模なデプロイ（数千ノード）にも対応
複雑なマイクロサービスアーキテクチャに最適
本番環境での高い安定性と信頼性（大手企業での実績多数）

3. 機能の豊富さと拡張性

Docker Swarm:

必要最低限の機能に焦点
シンプルな設計で操作が容易
拡張機能が限られている

Kubernetes:

豊富な組み込み機能と拡張性
カスタムリソース定義（CRD）によるAPIの拡張が可能
多様なプラグインとエコシステム

4. デプロイと構成管理

Docker Swarm:

Docker Composeファイルを使用（バージョン3以降）
スタック単位でのデプロイ
シンプルな構成管理

Kubernetes:

YAML形式のマニフェストファイル
より詳細な設定と制御が可能
Helmなどのパッケージマネージャーでテンプレート化が可能

5. ネットワークモデル

Docker Swarm:

組み込みのオーバーレイネットワーク
シンプルな設定でサービスディスカバリとロードバランシングを実現
ネットワークポリシーの制限が比較的少ない

Kubernetes:

複数のネットワークプラグインオプション（Calico, Flannel, Ciliumnなど）
より詳細なネットワークポリシー制御
サービスメッシュ（Istioなど）との統合

6. アップデートとロールバック

Docker Swarm:

基本的なローリングアップデート機能
シンプルなロールバックメカニズム

Kubernetes:

高度なデプロイ戦略（ローリング、Blue/Green、Canaryなど）
詳細なロールバック管理
プログレッシブデリバリーのための多様なツール統合

7. 高可用性と障害復旧

Docker Swarm:

マネージャーノードの複製によるHA構成
基本的な自己修復機能

Kubernetes:

複数レベルでの高可用性（ノード、ポッド、コントロールプレーン）
高度な自己修復機能
クラスターフェデレーションによる複数クラスター管理

8. モニタリングと可視化

Docker Swarm:

基本的なモニタリングツール
サードパーティツールとの統合が必要

Kubernetes:

組み込みのメトリクスサーバー
Prometheus、Grafanaとの優れた統合
高度なログ集約とモニタリングオプション

9. コミュニティとサポート

Docker Swarm:

Dockerコミュニティのサポート
大規模な採用は減少傾向

Kubernetes:

大規模で活発なコミュニティ
CNCF（Cloud Native Computing Foundation）のサポート
多くの企業によるバックアップと採用

使い分けのガイドライン

Docker Swarmが適している場合

小～中規模のデプロイメント：数十ノード以下のクラスターを運用する場合
シンプルなアプリケーション構成：複雑な依存関係やスケーリング要件がない場合
Dockerエコシステムに既に精通している：既存のDockerスキルを活かしたい場合
迅速な導入が必要：学習コストとセットアップ時間を最小限にしたい場合
リソースが限られている：小規模なチームや限られたインフラリソースでの運用

Kubernetesが適している場合

大規模なデプロイメント：数百～数千ノードのクラスターを運用する場合
複雑なマイクロサービスアーキテクチャ：多数のサービスと複雑な依存関係がある場合
高可用性と耐障害性の要件：ミッションクリティカルなアプリケーションの運用
高度なオートスケーリング：負荷に応じた精密なスケーリングが必要な場合
クラウドネイティブ開発：クラウドネイティブのプラクティスとツールを全面的に採用したい場合
長期的な投資：将来のスケールアップを見据えたプラットフォームが必要な場合

実装例：シンプルなウェブアプリケーションのデプロイ

Docker Swarmでのデプロイ

# docker-compose.yml
version: '3.8'

services:
  web:
    image: nginx:latest
    deploy:
      replicas: 5
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
    ports:
      - "80:80"
    networks:
      - webnet

  backend:
    image: my-backend:latest
    deploy:
      replicas: 3
      placement:
        constraints: [node.role == worker]
    environment:
      - DB_HOST=db
    networks:
      - webnet
      - backnet

  db:
    image: postgres:latest
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=secret
    deploy:
      placement:
        constraints: [node.labels.db == true]
    networks:
      - backnet

networks:
  webnet:
  backnet:

volumes:
  db-data:

デプロイコマンド：

# Swarmの初期化
docker swarm init

# スタックのデプロイ
docker stack deploy -c docker-compose.yml myapp

Kubernetesでのデプロイ

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 5
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: backend
        image: my-backend:latest
        env:
        - name: DB_HOST
          value: db-service
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db-service
  replicas: 1
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
      - name: postgres
        image: postgres:latest
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
        volumeMounts:
        - name: db-data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: db-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi
---
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: db-service
spec:
  selector:
    app: db
  ports:
  - port: 5432
    targetPort: 5432

デプロイコマンド：

# シークレットの作成
kubectl create secret generic db-secret --from-literal=password=secret

# リソースのデプロイ
kubectl apply -f deployment.yaml

移行のシナリオ：Swarmから Kubernetesへ

多くの組織は、小規模で始める際にDocker Swarmを選択し、成長に伴ってKubernetesに移行するというパスを選ぶことがあります。以下は、この移行を段階的に行うためのアプローチです：

現状分析：現在のSwarmスタックを詳細に分析し、依存関係を理解する
Kubernetesの知識習得：チームがKubernetesの基本概念を学ぶ時間を確保する
小規模テスト：非本番環境でKubernetesクラスターをセットアップし、一部のサービスを移行
Kompose等のツールの活用：Docker Composeファイルを変換するツールを使用
段階的な移行：ステートレスサービスから始め、徐々に複雑なサービスに移行
並行運用期間：一定期間、両方のシステムを並行運用し、検証を行う
完全移行：すべてのサービスがKubernetesに移行されたことを確認後、Swarmを廃止

移行時の注意点：

ステートフルサービス（データベース等）の扱いに特に注意が必要
ネットワーキングモデルの違いを理解する
Kubernetes特有の機能（PersistentVolume、ConfigMap、Secretなど）を活用する
モニタリングとログ収集の仕組みを再設計する

まとめ

Docker SwarmとKubernetesは、どちらもコンテナオーケストレーションの分野において重要なツールですが、それぞれ異なる特性と適用シナリオを持っています。

Docker Swarmは、セットアップが容易で学習曲線が緩やかなため、小～中規模の環境や、素早く環境を立ち上げる必要がある場合に適しています。Dockerの知識を持つチームなら、すぐに効率的に使い始めることができます。

一方、Kubernetesは、高い複雑性を持つものの、それに見合う高度な機能と拡張性を提供します。大規模環境、複雑なマイクロサービスアーキテクチャ、クラウドネイティブアプリケーションを運用する場合には、その投資に見合う価値があります。

最終的には、プロジェクトの規模、チームのスキルセット、将来のスケーリング計画、運用要件などに基づいて、適切なツールを選択することが重要です。また、小規模で始めて徐々にスケールアップする場合は、Docker Swarmから始めてKubernetesへの移行パスを計画することも賢明なアプローチと言えるでしょう。

どちらのツールを選択する場合でも、コンテナオーケストレーションの基本原則を理解し、アプリケーションのニーズに合わせた適切な設計と構成を行うことが成功への鍵となります。