DOCKER VISUALIZER
コンテナ vs 仮想マシン
Docker（コンテナ）と VM（仮想マシン）の仕組み・構成・性能を層ごとに比較します。
-
初期状態
2つの隔離技術を概観する
仮想マシン（VM）とコンテナはどちらもアプリケーションを隔離して実行する技術ですが、隔離のアプローチが根本的に異なります。
VM：ハードウェアごと仮想化し、各VMが独自のOSカーネルを持つ。
コンテナ：ホストOSのカーネルを共有しながら、Namespace と cgroup でプロセスを隔離する。
左がVM、右がコンテナの構成です。
VM：ハードウェアごと仮想化し、各VMが独自のOSカーネルを持つ。
コンテナ：ホストOSのカーネルを共有しながら、Namespace と cgroup でプロセスを隔離する。
左がVM、右がコンテナの構成です。
ステップ制御
進捗1 / 8
構成情報
フォーカスoverview
VM層数11
CT層数6
比較VM vs Docker
Hardware
Hypervisor
Guest OS
Host OS / Docker
VM App
Container App
COMPARISON STEPS
12つの隔離技術を概観する
2物理ハードウェア — 両者の共通基盤
3核心の違い — ハイパーバイザー vs カーネル共有
4ゲストOS — VM最大のオーバーヘッド
5ランタイム層 — フルインストール vs 最小限
6アプリ実行 — 同じアプリ、異なるフットプリント
7定量比較 — 5つの指標で比較
8まとめ — 隔離の強さ vs 効率のトレードオフ
1コンテナと仮想マシンとは
VM（仮想マシン）とコンテナはどちらもアプリケーションを隔離して実行する技術ですが、隔離のレベルが根本的に異なります。
アナロジーで言えば、VMは一戸建て、コンテナはマンションの一部屋です。一戸建ては基礎・壁・屋根をすべて独自に持ちますが、マンションは構造体を共有しつつ部屋単位で隔離します。
VM（ハイパーバイザー型）
ハイパーバイザーがハードウェアを仮想化し、各VMが独自のカーネル・OS・ファイルシステムを持つ。ハードウェアレベルの完全隔離を実現する。
VMware vSphere, Microsoft Hyper-V, KVM
コンテナ（OS レベル仮想化）
ホストOSのカーネルを共有し、Namespace と cgroup でプロセス・リソースをOSレベルで隔離する。カーネルを含まないため極めて軽量。
Docker, containerd, Podman, CRI-O
VMは独自のOS（基礎）を持つ一戸建て
コンテナはカーネル（構造体）を共有するマンション
隔離レベル: VM > コンテナ
効率: コンテナ > VM
🐳コンテナとは
コンテナはホスト OS のカーネルを共有しながら、アプリケーションを隔離して実行する技術です。アプリと依存ライブラリだけをパッケージ化するため、OS 全体を含む VM と比べて非常に軽量です。
Linux カーネルの Namespace（プロセス・ネットワーク・ファイルシステムの隔離）と cgroup（CPU・メモリの使用量制限）という2つの仕組みで隔離を実現しています。
軽量・高速
OS カーネルを含まないため、イメージサイズは数十〜数百 MB。起動は 1 秒未満で、プロセスを起動するのとほぼ同じ速度です。1台のサーバーで数百のコンテナを動かすことも可能です。
ポータビリティ
アプリと依存関係をイメージにまとめるため、「自分の PC では動くのにサーバーでは動かない」問題を解決します。Docker がインストールされていればどの環境でも同じように動作します。
Namespace と cgroup
Namespace: コンテナごとにプロセスID、ネットワーク、ファイルシステムを分離します。コンテナ A からコンテナ B のプロセスやファイルは見えません。
cgroup: コンテナごとに CPU やメモリの使用量を制限します。1つのコンテナが暴走しても、他のコンテナやホストに影響しません。
# コンテナの構成（イメージの中身）
アプリのバイナリ (例: python app.py)
依存ライブラリ (例: Flask, numpy)
設定ファイル (例: config.yaml)
─────────────────────────────────
カーネルは含まない → ホスト OS のカーネルを共有
🖥️仮想マシン（VM）とは
仮想マシンはハイパーバイザーという仮想化ソフトウェアを使って、1台の物理サーバー上に複数の「仮想的なコンピュータ」を作る技術です。各 VM は独自の OS カーネルを持ちます。
VM の中で動く OS はゲスト OS と呼ばれ、ホスト OS とは完全に独立しています。Linux のホスト上で Windows の VM を動かす、といったことも可能です。
ハードウェアレベルの完全隔離
各 VM は独自のカーネルを持つため、1つの VM で脆弱性が見つかっても他の VM には影響しません。クラウドプロバイダー（AWS, Azure 等）がマルチテナント環境で VM を採用する理由がこれです。
異なる OS を共存可能
コンテナはホストと同じカーネルしか使えませんが、VM なら Linux ホスト上で Windows を動かしたり、異なるバージョンの Linux を並行して走らせることができます。
ハイパーバイザーの2つのタイプ
Type 1（ベアメタル型）: ハードウェア上で直接動作。VMware ESXi, AWS Nitro, KVM など。本番環境で使われる。
Type 2（ホスト型）: OS 上のアプリとして動作。VirtualBox, VMware Workstation など。開発・テスト用途で使われる。
VM のデメリット
ゲスト OS 全体を含むため、イメージサイズは数 GB〜数十 GB。起動に 30 秒〜数分かかります。1台のサーバーで動かせる VM は数十台程度で、コンテナの数百台と比べると密度が低いです。
# VM の構成（VM イメージの中身）
アプリのバイナリ (例: python app.py)
依存ライブラリ (例: Flask, numpy)
設定ファイル (例: config.yaml)
ゲスト OS カーネル (例: Linux 6.1)
OS ユーティリティ (例: systemd, apt)
─────────────────────────────────
OS 丸ごと含む → 数 GB〜数十 GB のサイズ
2それぞれの特徴
起動速度
VM: 30秒〜数分（BIOS + カーネルブート + サービス起動）
コンテナ: 1秒未満（プロセス起動のみ、カーネルブート不要）
リソース効率
VM: ゲストOSがメモリ 1〜8GB を常時消費。CPU仮想化のオーバーヘッドあり
コンテナ: OSオーバーヘッドなし。実アプリのメモリだけ使用（数十MB〜）
隔離の強さ
VM: ハードウェアレベルの完全隔離。カーネルが別なので脆弱性の影響範囲が限定的
コンテナ: カーネル共有のため攻撃面が広い。カーネル脆弱性で全コンテナに影響の可能性
ポータビリティ
VM: VMイメージは大きく移動コスト高。ハイパーバイザー間の互換性問題あり
コンテナ: イメージがOS差異を吸収。どのDockerホストでも同一動作を保証
3ユースケース
VM: マルチテナント環境
AWS EC2、Azure VM、GCP Compute Engine など。テナント間の完全隔離が必須のクラウドインフラで採用される。カーネル脆弱性による横展開を防止する。
コンテナ: マイクロサービス
各サービスを独立したコンテナとしてデプロイ。Kubernetes で数百のコンテナをオーケストレーションし、スケールアウト・ローリングアップデートを実現する。
VM: 異なるOSが必要な場合
Linux 上で Windows アプリを動かす、macOS 上で Linux テストを行うなど。異なるカーネルが必要な場合は VM でしか実現できない。
コンテナ: CI/CDパイプライン
GitHub Actions、GitLab CI でビルド・テスト環境をコンテナで構築。高速起動と再現性の高さにより、テスト実行時間を大幅に短縮できる。
🧩用語解説
ハイパーバイザー（Hypervisor）
＝ ハードウェアを仮想化してVMを作るソフトウェア
＝ ハードウェアを仮想化してVMを作るソフトウェア
ハイパーバイザー（Hypervisor）とは、1台の物理サーバー上に複数の仮想マシンを作り出すためのソフトウェアです。 物理サーバーのCPU・メモリ・ストレージを仮想化し、複数のVMに分配します。Type 1（ベアメタル型）はハードウェア上で直接動作し（ESXi, KVM, Hyper-V）、本番環境で使われます。Type 2（ホスト型）はOS上で動作し（VirtualBox, VMware Workstation）、開発・テスト用途が多いです。
カーネル（Kernel）
＝ OSの中核。HWとアプリの橋渡し役
＝ OSの中核。HWとアプリの橋渡し役
カーネル（Kernel）とは、OSの最も中核にあるソフトウェアで、ハードウェアとアプリケーションの間を仲介する役割を持ちます。 CPU・メモリ・デバイスなどのハードウェア資源を管理し、アプリケーションにシステムコールAPIを提供します。 VMでは各VMが独自のカーネルを持ちますが、コンテナではホストOSのLinuxカーネルを全コンテナが共有します。 そのためWindowsカーネルが必要なアプリはLinuxコンテナでは動きません。
Namespace
＝ コンテナの「見える範囲」を制限する仕組み
＝ コンテナの「見える範囲」を制限する仕組み
Namespaceとは、Linuxカーネルが提供するリソース隔離の仕組みで、各コンテナに「自分専用の環境」があるように見せる技術です。 PID（プロセスID）、NET（ネットワーク）、MNT（ファイルシステム）、UTS（ホスト名）、IPC（プロセス間通信）、User（UID/GID）の6種類があります。 コンテナ内の PID 1 はホストから見ると別の PID（例: 4521）を持ちます。
cgroup（Control Group）
＝ コンテナの「使える量」を制限する仕組み
＝ コンテナの「使える量」を制限する仕組み
cgroup（Control Group）とは、Linuxカーネルが提供するリソース制限の仕組みで、各コンテナが使えるCPU・メモリなどの量に上限を設ける技術です。 Namespaceが「何が見えるか」を制御するのに対し、cgroupは「どれだけ使えるか」を制御します。
docker run --memory=512m --cpus=2 のようなリソース制限はcgroupで実現されています。OCI（Open Container Initiative）
＝ コンテナの業界標準仕様
＝ コンテナの業界標準仕様
OCI（Open Container Initiative）とは、コンテナ技術の業界標準仕様を策定する団体・規格のことです。 コンテナイメージの形式（Image Spec）とランタイムのインターフェース（Runtime Spec）を定義しています。 Dockerが事実上の標準だったコンテナ技術をオープン標準にしたもので、OCI準拠のランタイム（runc, crun, gVisor）なら、どのエンジン（Docker, Podman, containerd）でも相互運用できます。
5ハイパーバイザー vs カーネル共有
VMとコンテナの最も根本的な違いは、カーネル（OSの中核）が独立しているか共有しているかです。この構造の違いが、起動速度・リソース効率・隔離強度のすべてに影響します。
仮想マシン (VM)
ハイパーバイザーがハードウェアを仮想化し、各VMに仮想CPU・仮想メモリを割り当てます。 各VMは独自のカーネルを持つため、VM-1 が Ubuntu、VM-2 が Windows のように異なるOSを同時に動かせます。
Type 1（ベアメタル）: ESXi, KVM, Hyper-V — HW上に直接動作。本番環境向け
Type 2（ホスト型）: VirtualBox, VMware Workstation — OS上で動作。開発向け
Type 2（ホスト型）: VirtualBox, VMware Workstation — OS上で動作。開発向け
コンテナ (Docker)
ホストOSのLinuxカーネルを全コンテナが共有します。ゲストOSは不要です。Namespace（PID・NET・MNT等）で各コンテナの見える範囲を制限し、cgroup でCPU・メモリの使用量を制限することで、プロセスレベルの隔離を実現します。
Namespace: PID（プロセスID）, NET（ネットワーク）, MNT（ファイルシステム）等 6種
cgroup: CPU上限, メモリ上限, ディスクI/O, ネットワーク帯域を制限
cgroup: CPU上限, メモリ上限, ディスクI/O, ネットワーク帯域を制限
この構造の違いが生む影響
起動速度
VM: カーネルブートが必要 → 30秒〜数分
CT: プロセス起動のみ → 1秒未満
CT: プロセス起動のみ → 1秒未満
リソース効率
VM: OS分のメモリ常駐 → 数GB/台
CT: アプリ分のみ → 数十MB/個
CT: アプリ分のみ → 数十MB/個
隔離強度
VM: HWレベル隔離 → 非常に強い
CT: カーネル共有 → 中程度
CT: カーネル共有 → 中程度
6起動フローの違い
VMとコンテナで最も体感しやすい違いが起動速度です。VMは「仮想的なコンピュータを1台丸ごと起動する」のに対し、コンテナは「既に動いているOS上でプロセスを1つ起動する」だけです。この違いがなぜ生まれるのか、それぞれの起動フローを詳しく見ていきます。
1. VMの起動フロー（30秒〜数分）
①
BIOS/UEFI POST: 電源ON後、仮想ハードウェアの自己診断テスト（POST）を実行。仮想CPU・仮想メモリ・仮想ディスクの認識と初期化を行います。物理マシンと同じブートシーケンスを仮想的に再現するため、この工程だけで数秒かかります。
②
Bootloader (GRUB): ブートローダーが仮想ディスクからカーネルイメージ（vmlinuz）と初期RAMディスク（initrd）をメモリにロードします。GRUBメニューのタイムアウト待ちも含まれます。
③
Kernel Boot: Linuxカーネルが起動し、仮想デバイスドライバの読み込み、メモリ管理の初期化、CPUスケジューラの設定、ファイルシステムのマウントを行います。物理マシンと同等のカーネル初期化プロセスをすべて実行します。
④
init / systemd: PID 1 として init プロセス（通常は systemd）が起動し、ネットワーク管理（NetworkManager）、ログ収集（journald）、cron、SSHサーバーなどのシステムサービスを依存関係順に起動します。最も時間がかかる工程です。
⑤
Network Setup: DHCPクライアントがIPアドレスを取得し、DNSリゾルバの設定、ルーティングテーブルの構築、ファイアウォール（iptables/nftables）ルールの適用を行います。
⑥
Application Ready: ようやくアプリケーションプロセスが起動できる状態になります。Webサーバー（nginx等）やアプリランタイム（Node.js, JVM等）の初期化がさらに数秒かかります。
ポイント: VMは「仮想的なコンピュータを1台丸ごと起動する」ため、物理マシンと同じブートシーケンス（BIOS → Bootloader → Kernel → init）をすべて通過する必要があります。各VMが独自のカーネルを持つからこそ、この長い起動プロセスが毎回必要になります。
2. コンテナの起動フロー（数十ms〜1秒未満）
①
clone() — Namespace作成: clone() システムコールに CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWUTS フラグを渡し、新しい Namespace を一括作成します。これにより、コンテナ内のプロセスは独立した PID空間・ネットワークスタック・ファイルシステム・ホスト名を持ちます。カーネルは既に起動済みなので、わずか1ms程度で完了します。
②
cgroup設定 — リソース制限: /sys/fs/cgroup/ 配下にコンテナ専用のcgroupディレクトリを作成し、CPU上限（cpu.max）、メモリ上限（memory.max）、I/O帯域（io.max）などの制限値を書き込みます。docker run --memory=512m --cpus=2 のオプションがここで適用されます。
③
rootfs Mount — OverlayFS: コンテナイメージの読み取り専用レイヤー群と、書き込み可能な上位レイヤーを OverlayFS で合成し、コンテナのルートファイルシステム（/）としてマウントします。イメージはすでにローカルにpull済みなので、ディスクコピーは不要です。pivot_root でルートを切り替え、コンテナ外のファイルシステムを隠蔽します。
④
exec() — ENTRYPOINT実行: Dockerfile の ENTRYPOINT / CMD で指定されたコマンドを exec() で実行します。このプロセスがコンテナ内の PID 1 になります。カーネルブート・initシステム・デーモン起動は一切不要で、アプリケーションが直接起動します。
ポイント: コンテナは「既に動いているカーネル上でプロセスを1つ起動する」だけなので、BIOS・ブートローダー・カーネル初期化・systemdによるサービス起動がすべてスキップされます。これが数百〜数千倍の起動速度差を生む根本的な理由です。
3. 起動時間の比較
VMの起動時間の大部分はinit/systemd によるサービス起動が占めます。SSHサーバー、ログ収集、NTP同期、ファイアウォールなど、アプリと直接関係ないシステムサービスを数十個起動する必要があるためです。コンテナはこれらすべてが不要で、アプリプロセスだけを直接実行します。
7仕組みの違い
1. リソースの使われ方の違い
VMは各ゲストOSが4GBずつメモリを消費するため、3台で12GBがOS維持だけに使われます。コンテナはホストOSの数百MBだけで済み、残りすべてをアプリに使えます。
2. 隔離の違い
VMは各VMが独自のカーネルを持つため、1つのVMのカーネル脆弱性が他のVMに影響しません。コンテナは共有カーネルの脆弱性が全コンテナに影響する可能性があります。そのためセキュリティが最重要な環境ではVMが選ばれます。
3. 両者の併用パターン（Firecracker / microVM）
AWS Lambda や Fargate で使われる Firecracker は、軽量なmicroVM（起動125ms）の中でコンテナを動かすハイブリッド方式です。VMレベルの隔離とコンテナの軽量さを両立し、マルチテナント環境でのコンテナ実行を安全にします。
8よくある質問
Q. VMとコンテナは併用できる？
はい、実際のプロダクション環境では併用が一般的です。EC2（VM）上で ECS/EKS（コンテナオーケストレーション）を動かすのが典型例です。VMがインフラレベルの隔離を提供し、その上でコンテナがアプリレベルの隔離とデプロイの柔軟性を提供します。
Q. Mac/WindowsでなぜDockerが動く？
Docker は Linux カーネルの Namespace と cgroup に依存するため、Mac/Windows ではネイティブに動作しません。Docker Desktop は裏側で軽量な Linux VM（Mac では Apple Virtualization Framework、Windows では WSL2/Hyper-V）を起動し、その中で Docker Engine を動かしています。つまり Mac/Windows での Docker は「VM の中でコンテナを動かしている」状態です。
Q. コンテナはVMより安全？
いいえ、隔離の強さはVMの方が上です。VMはハードウェアレベルの隔離を提供し、カーネルが完全に分離されます。コンテナはカーネルを共有するため、カーネルの脆弱性が全コンテナに影響する可能性があります。ただし、Seccomp、AppArmor、SELinux、rootlessコンテナなどの追加セキュリティ機能を組み合わせることで、コンテナのセキュリティを大幅に強化できます。
Q. Firecracker / microVMとは？
AWS が開発した軽量 VM テクノロジーです。通常の VM が数秒〜数十秒で起動するのに対し、Firecracker の microVM は 125ms で起動します。最小限のデバイスモデルしか持たないため、攻撃面が極めて小さく、Lambda や Fargate の基盤として使われています。VMの隔離強度とコンテナの起動速度を両立する「良いとこ取り」のアプローチです。
Q. KubernetesはVMとコンテナのどちらを使う？
Kubernetes は主にコンテナ（Pod）をオーケストレーションするプラットフォームです。各 Node（Worker）は VM であることが多く（EC2, GCE等）、その VM 上で kubelet が Pod（コンテナ群）を管理します。つまり「VM の上でコンテナを動かす」構成が標準です。Kata Containers を使えば Pod を microVM として実行し、より強い隔離を得ることもできます。
関連コンテンツ
Dockerコンテナライフサイクル
Docker コンテナの状態遷移（create → start → running → stop → remove）をステップで可視化します
Docker Compose
マルチコンテナ構成の起動・通信・停止の仕組みを可視化
Docker データ永続化
Volume・Bind Mount・tmpfsの3方式の仕組みとコンテナ削除時のデータの行方を可視化
マルチステージビルド
複数ステージで最終イメージを劇的に軽量化する仕組みを可視化
Docker Registry
イメージのpush/pullとレイヤー単位の転送の仕組みを可視化
docker build とレイヤーキャッシュ
Dockerfileの各命令でレイヤーキャッシュがヒット/ミスする仕組みを可視化。命令の順番がビルド速度に与える影響を理解できます