Docker Composeリソース 計算ツール｜CPU/RAM合計とホスト推奨スペックを即算出

Composeリソース計算の基本

基本の考え方

合計CPU = Σ(サービス毎の想定CPU × レプリカ数)

合計RAM = Σ(サービス毎の想定RAM × レプリカ数)

ホスト推奨 = 合計 × 1.3〜1.5（余裕係数）

Docker Composeは複数コンテナを1つのcompose.yamlファイルで宣言的に定義するオーケストレーションツール。開発環境、CI、ステージング、小規模本番で広く使われます。ホストスペックの見積は、全サービスのCPU/RAMを合算し、余裕係数1.3〜1.5倍で算定するのが業界標準の実務目安です。

負荷特性による補正

• アイドル多め（Webアプリ）：合計×1.2倍程度で十分
• 継続的な負荷（バッチ・DB）：合計×1.5〜2倍
• スパイク型（API・ジョブ）：ピーク時想定で1.5倍
• 本番運用：SLA目標に応じてCPU使用率50-70%が上限になるよう2倍見積

OSと Docker daemon の消費

ホストOS（Linux+systemd）とDocker daemon（dockerd＋containerd）はベースで500MB〜1GBのRAM、CPU 0.2〜0.5コアを常時消費します。特にログ集約（fluentd/fluentbit）、モニタリング（Prometheus/Node Exporter）を同居させる場合は追加で1〜2GB。ホストサイジング時は差し引いて計算しましょう。

deploy.resources の書き方

基本記法（Compose Specification）

services:
  web:
    image: nginx:1.27-alpine
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 128M

limitsは上限（超えたらCPUスロットリング/OOM Kill）、reservationsは保証量（この分は必ず確保）です。Compose Specification（旧: version 3）以降の標準記法。docker compose upで起動する場合は limits/reservations の両方が有効ですが、Swarmモードのdocker stack deploy 以外では reservations は「予約」扱いで実強制されない点に注意（cgroupsによるCPU shares/memory reservationとして反映）。

単位表記

legacy: cpus / mem_limit

Compose v2以前で使われた cpus: 0.5 / mem_limit: 512m は非推奨だが後方互換で動作します。新規プロジェクトはdeploy.resources.limits形式で書きましょう。docker compose（Compose V2）はKubernetes記法との親和性を高める方向に進化しています。

cgroups v1/v2 とリソース制御

OOM Killer と swap 抑制

OOM Killer の挙動

ホストRAMが枯渇するとカーネルが最もメモリを消費しているプロセスを強制終了します。コンテナ内の場合はPID 1（コンテナのメインプロセス）が終了し、コンテナ全体が再起動される挙動が一般的。Docker Composeでrestart: alwaysやrestart: unless-stoppedを指定するとdockerdが自動再起動しますが、根本原因（メモリリークや過負荷）を解消しないと再起動ループになります。

swap 抑制の重要性

LinuxのswapoutはディスクI/Oが発生してレイテンシが100〜1000倍悪化します。DBサーバ・低レイテンシAPIではvm.swappiness=1（実質swap無効化）または swap partition/file を削除する運用が定石。コンテナ内はmemswap_limit: -1指定でswap全許可も可能ですが、通常はmemoryとmemswap_limitを同じ値にしてswap使用を防止します。

監視・アラート設計

• ホスト全体：Memory usage 80%超で警告、90%超で緊急
• コンテナ単位：memory limits の70%超で警告、90%で緊急
• OOM Killer発火：dmesg | grep -i oomで検知、Prometheusでnode_vmstat_oom_killメトリクス監視
• swap使用：常時0を目標。使用開始をアラート発火条件に

主要スタック別リソース目安

Docker Composeで頻用される代表的なスタックの1インスタンスあたりCPU/RAM目安です。負荷・データ量で大きく変動しますが、開発環境やスモールスタート本番の初期見積として参考にしてください。

推奨ホストスペックとインスタンス選定

合計リソースからインスタンス選定

Burstable vs 汎用インスタンス

AWS T系(t3/t4g)、GCP E2はCPU Credit方式のBurstableで、常時50%以下のCPU利用が前提。継続的なCPU負荷ではCredit枯渇でスロットリング発生し、応答時間が数倍悪化。継続負荷が予想されるDB・バッチ・ストリーミングはM系（汎用）やC系（コンピュート最適化）を選択しましょう。

ARM64（Graviton/Ampere）の活用

2024〜2026年時点で、ARM64インスタンス（AWS Graviton3/4・GCP Tau T2A）は同スペックのx86_64より20-40%安く、消費電力・熱発生も少ない。多くの人気イメージ（node/nginx/postgres/redis）がmulti-archで提供されており、docker buildxでARM64ビルドすればコスト削減が可能。ネイティブモジュールを含むアプリ（Node.jsのbcrypt等）はビルド確認が必要です。

Kubernetesへの移行指針

ネットワーク・ストレージI/Oの見積

CPU/RAM以外に、Composeスタックの全体性能を左右するのがネットワーク帯域とストレージI/Oです。特にDB・キャッシュ・ログ集約サービスはI/Oバウンドになりやすく、CPU増強しても性能が伸びないケースが頻発します。

ストレージI/Oの目安

ネットワーク帯域の見積

コンテナ間通信は基本的にホストのlocal loopbackで高速ですが、外部通信はENI/仮想NICの帯域に依存。AWS EC2ならt3.medium=5Gbps、m6i.large=12.5Gbpsが上限。ストリーミング・動画配信ワークロードは帯域基準でインスタンス選定を優先しましょう。

Docker独自ネットワーク

Composeが自動作成する{project}_defaultbridgeネットワークで各サービスがサービス名で名前解決されます。overlay ネットワークは複数ホストにまたがるSwarm用途、host ネットワークはホスト直結で最高速だがポート衝突リスクあり。本番はcustom bridge推奨です。

よくある間違い・注意点

• CPU limitを厳しくかけすぎる — CPUスロットリングは応答時間を数倍悪化させます。ミッションクリティカルなAPIやDBにはlimitsを緩めに、reservationsで保証する設計が定石。cgroupsのCPU shares（相対重み）で優先度をつけるのも有効です。
• memory limitを設定しない — 未設定だとメモリリークするコンテナが全RAMを食い潰し、OOM Killerがランダムに他コンテナを殺す事故に。全サービスに必ずmemory limitを設定し、監視でしきい値到達を早期検知しましょう。
• reservations だけで安心する — reservationsは「予約」であり、docker compose upで使う限り実際のリソース強制はlimitsが担当。docker stack deploy(Swarm) やKubernetesで初めてreservationsが厳格に有効化されます。
• swap 有効環境で本番運用 — DBやリアルタイムAPIをswap有効ホストで運用すると、swapout発生時にレイテンシが100倍以上悪化。本番Linuxホストはvm.swappiness=1または swap 削除を推奨。
• cgroups v1環境で最新機能が使えない — memory.oom.group、pids.max、CPU pressure metrics等のcgroups v2機能はv1では利用不可。RHEL 9・Ubuntu 22.04+へのアップグレードを計画しましょう。
• Compose を本番運用の唯一手段にする — 単一ホストで完結する小規模なら十分ですが、可用性・スケール・ローリング更新が必要になったらKubernetes（マネージド or 軽量）への移行を早期に検討。移行が遅れるほど負債が積み上がります。

関連する規格・仕様

• Compose Specification ― Docker Composeファイルフォーマットの公式仕様。Compose V2以降の基盤。
• OCI Runtime Specification ― Open Container Initiative（LinuxFoundation）が策定するコンテナ実行時仕様。Docker Engine・containerd・runc・CRI-Oが準拠。
• OCI Image Format Specification ― コンテナイメージの標準フォーマット。docker save/loadやDocker Hub、GHCR、GARなど各種レジストリの共通基盤。
• Kubernetes Resource Model ― CPU（millicore）・Memory（バイト単位）のリクエスト/リミット記法。Composeとの互換性のベース。
• Linux cgroups v2 API ― Linuxカーネルのリソース制御API。Docker Engine 20.10以降がv2を完全サポート。
• SPDX / SLSA ― ソフトウェア部品表（SBOM）とサプライチェーンセキュリティ。Dockerイメージのセキュリティ管理で使用。
• CIS Docker Benchmark ― Center for Internet Securityが公開するDockerホスト・コンテナのハードニング基準。

参考文献・公式資料

Docker Composeとリソース制御の詳細情報は、以下の公式ドキュメント・団体資料を参照してください。

• Docker Docs - Compose ― Docker Composeの公式ドキュメント。インストール・コマンド・compose.yaml書式の一次資料。
• Compose Specification (GitHub) ― Compose ファイル形式の正式仕様。deploy.resources 等の詳細定義。
• Docker CLI - docker compose reference ― docker compose コマンドの公式リファレンス。
• Open Container Initiative (OCI) ― コンテナランタイム・イメージフォーマットの標準化団体（LinuxFoundation）。
• Linux Kernel Documentation - cgroups v2 ― cgroups v2 のカーネル公式ドキュメント。
• Kubernetes Documentation - Resource Management ― K8sにおけるCPU/Memory requests/limitsの公式ガイド。
• Kompose - Compose to Kubernetes converter ― CNCF Sandboxプロジェクト。Compose→K8sマニフェスト変換ツール。
• CIS Docker Benchmark ― Docker運用のセキュリティ・ハードニング基準。
• Cloud Native Computing Foundation (CNCF) ― Kubernetes・containerd・Prometheus等のクラウドネイティブ技術管理団体。
• AWS EC2 インスタンスタイプ ― Docker運用時のホスト選定に使うEC2の公式スペック表。

よくある質問（FAQ）

ケース別 Compose設計シナリオ

関連計算ツール