【2026年版】Docker Composeは本番環境で使えるか？Kubernetesとの使い分け完全ガイド

DevOps

この記事の概要

2026年5月、Hacker Newsで「本番環境にDocker Composeを使うべきか」という議論が再燃し、多くのエンジニアの共感を集めた。正しく設定すれば99%以上のアップタイムを達成できる一方、マルチノードのオーケストレーションや自動スケールには対応できない。本記事では、インフラSEが実際に迷う「Docker Compose か Kubernetes か」の判断基準を、2026年の最新知見とコスト比較を交えて解説する。

小規模チームこそDocker Composeが最適解になる

[IMAGE: compose_vs_k8s_overview]

2026年現在、「Kubernetesを使うべきだ」という風潮が強まる一方で、現場では依然として多くの本番システムがDocker Composeで安定稼働している。実際、Hacker Newsの議論では数百のエンジニアが「Docker Composeで本番を問題なく運用できている」と証言した。

なぜDocker Composeで十分なのか。理由はシンプルだ。単一サーバー上で動くアプリケーションにとって、Kubernetesの持つ「マルチノードオーケストレーション」機能は過剰なコストを生む。

コスト面での比較は明確だ。Docker Composeでの運用は月間約$115（サーバー代）＋エンジニア工数$200程度に収まる。一方Kubernetesは、クラスター管理費$644＋エンジニア学習・運用コスト$3,200超になることも珍しくない。スタートアップや社内ツール・バックオフィスシステムでは、この差は無視できない。

Docker Composeが本番に向いているのは以下のケースだ。

  • コンテナ数が1〜5個程度のシンプルな構成
  • 単一サーバーで十分なトラフィック規模
  • チームが小さく、Kubernetes学習コストを割けない
  • エッジロケーション・小売店舗など分散した拠点への展開

「設定が甘い」から障害が起きる——本番Composeの3つの落とし穴

[IMAGE: compose_failure_patterns]

Docker Composeの本番障害の多くは、ツール自体の問題ではなく「Composeが強制しない運用プラクティス」を省略したことで起きる。現場でよく見られる失敗パターンは次の3つだ。

1. ヘルスチェックの未設定

depends_onだけでは「コンテナが起動した」ことは確認できても「サービスが応答できる状態か」は確認できない。DBがまだ初期化中なのにアプリが接続を試みてクラッシュするのはこのパターンだ。

2. リソース制限の未設定

あるコンテナがメモリをリークして他のコンテナを道連れにする「メモリ枯渇」問題は、deploy.resources.limitsを設定するだけで防げる。

3. :latestタグの使用

image: myapp:latestは「どのバージョンを使うかわからない」状態と同義だ。夜間に別バージョンのイメージがpullされ、朝起きたら動かなくなっていたというインシデントはよく発生する。

実際に動く本番Compose設定を書いてみる

[IMAGE: compose_production_yaml]

本番稼働に必要な最小構成

以下は、WebアプリケーションとPostgreSQLを本番運用する際のdocker-compose.ymlのベストプラクティスだ。

version: "3.9"

services:
  app:
    image: myapp:1.4.2  # latestは使わない
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/mydb
    depends_on:
      db:
        condition: service_healthy  # DBがhealthyになるまで待機
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s  # 起動猶予時間
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 128M
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 1G

volumes:
  postgres_data:

secrets:
  db_password:
    file: ./secrets/db_password.txt

重要な設定ポイント解説

restart: unless-stopped vs restart: always

# NG: 手動停止してもすぐ再起動する
restart: always

# OK: 手動停止は維持されるが、デーモン再起動時は復活する
restart: unless-stopped

コアサービスにはunless-stoppedを使う。alwaysはメンテナンス時に手動停止しても勝手に再起動するため管理が困難になる。

ヘルスチェック start_period の意味

healthcheck:
  start_period: 40s  # この間はリトライ失敗してもunhealthyにならない

アプリの起動に40秒かかる場合、この設定がないと起動中にunhealthyと判定されてしまう。

実務での活用シナリオ

シナリオ1: SaaS企業の社内管理ツール

月間アクティブユーザー数百人の社内ダッシュボード。シングルサーバー（AWS EC2 t3.medium）でDocker Composeを運用し、月間稼働率99.5%を達成。Kubernetesへの移行コストは不要と判断。

シナリオ2: 小売チェーンの店舗端末

各店舗に1台ずつ設置するオーダー管理システム。Kubernetesクラスターを構築するインフラがなく、Docker Composeでrestart: unless-stoppedを設定し、ネットワーク断絶時も自動復旧する構成を採用。

シナリオ3: スタートアップのMVP本番環境

初期ユーザー1,000人規模のWebサービス。Docker Composeで素早くデプロイし、ユーザーが10,000人を超えた段階でKubernetesへ移行する計画を立てて運用開始。

3つの設定で本番Docker Composeは安定する

[IMAGE: compose_three_pillars]

冒頭の結論を改めて整理する。Docker Composeは「設定が甘いから本番に向かない」のであって、「ツール自体が本番に向かない」わけではない。

本番運用に最低限必要な3つの設定を押さえれば、99%以上のアップタイムは現実的に達成できる。

  1. restart: unless-stopped — デーモン再起動時の自動復旧を保証する
  2. healthcheck の適切な設定 — サービス依存順序を正確に管理し、障害を検知する
  3. deploy.resources.limits — メモリリークや暴走プロセスによる道連れを防ぐ

Kubernetesへの移行は「スケールが必要になってから」で十分だ。最初からKubernetesを選ぶのは、引越し用のトラックで毎日買い物に行くようなものだ。ツールはユースケースに合わせて選ぶ——2026年においても、この原則は変わらない。

まとめ

観点 Docker Compose Kubernetes
学習コスト 低い 高い
月間コスト目安 ~$300 ~$3,800+
向いている規模 〜10コンテナ・単一サーバー 10コンテナ超・マルチノード
ゼロダウンタイムデプロイ 不可（手動対応） 可能（Rolling Update）
自動水平スケール 不可 可能（HPA）
本番での安定性 設定次第で99%以上 設計次第で99.9%以上

Docker Composeを本番で使う場合は、restart・healthcheck・resources.limitsの3点セットを必ず設定しよう。Kubernetesへの移行は、実際にスケールの壁にぶつかってから検討しても遅くはない。

参考リンク

コメント