仮想マシンとコンテナ：競合か、それとも共存か？
長年、「仮想マシンはコンテナに置き換えられるのか？」という議論が続いていました。しかし現在では、答えは少し違ったものになっているようです。なぜなら、その間にそもそもの問い自体が変わったからです。つまり、「2つの技術がもはや競合するのではなく、協調して使われているのであれば、置き換えること自体に意味があるのか？」ということです。
この10年ほどの間に、「コンテナが仮想マシンに取って代わる」というイノベーションへの期待に基づく、ある意味で理念的な対立から、より現実的なアプローチへと変化してきました。現在では、Kubernetesのインスタンスが仮想環境の中で実行されることも多く、クラウドプロバイダーは複数の技術レイヤーを組み合わせて、プラットフォーム全体を構築しています。
一見すると、この2つの技術は似ており、同じような結果をもたらすように見えるかもしれません。しかし、それぞれの違いを深く理解することで、それぞれが持つ固有の強みが見えてきます。
2種類のハイパーバイザー
仮想環境（仮想マシンだけに限りません）について説明する際には、仮想マシンを実行するハイパーバイザーの種類について区別する必要があります。
タイプ1のハイパーバイザーは、ベアメタル上でリソースを管理するソフトウェアとして直接動作し、仮想インスタンスからメモリ、プロセッサー、ネットワークインターフェースなどのハードウェアリソースへ直接アクセスできるようにします。XenとKVMは、タイプ1のハイパーバイザーの代表的な例です。KVMは、複雑で体系的なエンタープライズ環境に適した仮想化プラットフォームであるProxmox VEの基盤でもあります。Proxmox VEは、負荷分散、クラスタ管理、高可用性に対応しています。
もう1つがタイプ2のハイパーバイザーです。こちらは、オペレーティングシステム上でプログラムとして動作する、追加のレイヤーの上に構築されます。代表的なものとして、VirtualBoxやVirt-Managerがあります。
図1では、タイプ1とタイプ2のハイパーバイザーの違いを比較しています。
リソースの使用効率や管理のしやすさという点では、タイプ1のハイパーバイザーが圧倒的に優れています。そのため、業務環境では広く利用されています。一方、より多くのリソースを必要とするタイプ2のハイパーバイザーは、複雑で高負荷なワークロードを任されることはほとんどありません。
コンテナ：軽量さを追求して生まれた技術
コンテナは、「軽量であること」を大きな特徴として生まれました。仮想マシンとは異なり、ハードウェアシステム全体を仮想的に再現する必要も、インスタンスごとに完全なオペレーティングシステムを起動する必要もありません。コンテナ内のプロセスは、ホストシステムのカーネルを共有しながら、それぞれ分離された状態で動作します。
この分離を可能にしているのが、Linuxカーネルの機能です。Namespace（名前空間）は、プロセス、ネットワーク、ファイルシステム、ユーザーなどの要素を分離し、それぞれのコンテナからは、あたかも独立した環境であるかのように見える状態を作ります。Control Groups（コントロールグループ、一般にcgroupsと呼ばれます）は、メモリ、CPU、入出力などのリソース使用量を制御・制限することを可能にします。
その結果、従来の仮想マシンよりもはるかに軽量な環境が実現します。コンテナは専用のカーネルを必要としないため、短時間で起動でき、必要なストレージ容量やメモリも少なくて済みます。これにより、同じホスト上で多数のコンテナを実行し、非常に短時間でデプロイすることが可能になります。
ただし、コンテナを小さな仮想マシンと考えてはいけません。コンテナは、まず第一に、アプリケーションを実行するために必要なライブラリや依存関係とともに、分離されたプロセスの集合です。そのため、コンテナの分離レベルは、ホストシステムと共有しているカーネルに依存します。一方、仮想マシンは独自のカーネルと独立したオペレーティングシステムを持っています。
また、コンテナイメージも重要な役割を果たします。コンテナイメージには、アプリケーション、その依存関係、そして再現可能な環境を構築するために必要な設定が含まれています。同じイメージを開発環境、テスト環境、そして最終的な本番環境で実行できるため、環境間の違いを減らすことができます。Dockerは、このモデルの普及に決定的な役割を果たしましたが、コンテナという概念は特定の1つの製品に限定されるものではありません。現在のエコシステムには、Podman、containerd、CRI-Oなどのツールに加え、Open Container Initiative（OCI）が推進する共通規格も含まれています。そしてKubernetesは、コンテナそのものを直接作成するのではなく、1つまたは複数のノードにまたがってコンテナの実行、分散、可用性を管理します。
コンテナの軽量な構造は、仮想マシンを自動的に置き換えることを意味するわけではありません。カーネルを共有することでリソース消費量を抑えられる一方、分離のレベルも異なり、場合によっては十分ではありません。まさにこの点から、仮想マシンとコンテナの「競争」は、次第に「相互補完」へと変わっていきます。仮想マシンはインフラをより明確に分離できる一方、コンテナはアプリケーションのデプロイをより簡単かつ迅速にします。
図2では、仮想マシンとコンテナの構成要素をまとめています。
両者が融合する場所
融合の具体例として、複数のLinux仮想マシンを実行する仮想化クラスタを考えてみましょう。そのうちの一部はKubernetesクラスタのノードとして利用し、その他はデータベース、レガシーシステム、あるいはより強固な分離が必要なサービス専用として利用することができます。Kubernetesに割り当てられた仮想マシンの中では、コンテナランタイムがアプリケーションコンテナを実行し、それらはPodとしてまとめられ、各ノードに分散されます。ハイパーバイザーは物理リソース、分離、高可用性を管理し、Kubernetesはコンテナ化されたアプリケーションのライフサイクル、分散、スケーリングを管理します。
このアーキテクチャでは、仮想マシンとコンテナは同じ役割を奪い合っているわけではありません。それぞれ異なるレイヤーで動作しています。仮想マシンはインフラの境界を定義し、コンテナはアプリケーションを分散・実行する単位を定義します。図3は、この複合的なアーキテクチャを示しています。
図3：仮想化技術とコンテナ技術を統合したアーキテクチャの例。
まさにこの点で、仮想マシンとコンテナの競争という考え方は意味を失います。現代のインフラでは、コンテナは仮想マシンを置き換えるものではありません。多くの場合、コンテナは仮想マシンの中で動作しています。仮想マシンはインフラを分離し、コンテナはアプリケーションの分散と実行を担います。つまり、同じアーキテクチャの中にある、異なる役割を持つ補完的な2つのレイヤーなのです。
これらのテーマを体系的に学ぶには、LPIC-3 Virtualization and Containerization認定が有用な学習手段となります。この認定では、KVM、Xen、libvirt、Linuxコンテナ、Docker、Podman、Kubernetes、および仮想化環境の管理・オーケストレーションに用いられる主要な技術について、知識を体系的に身につけることができます。
<< このシリーズの前の記事を読む | シリーズを最初から読む >>
