コンテナと仮想マシン（VM）の使い分けについては、ネット上で長らく議論されてきました。人によって意見は様々で、純粋なコンテナ派、純粋なVM派、あるいはVM上でコンテナを動かす派などが存在します。本記事では、コンテナとVMの比較、およびそれぞれの適切な利用シーンについて、私個人の見解を交えて解説します。
目次
コンテナ
コンテナはこの5年間で急速に普及しました。その理由は、軽量さと迅速なデプロイが可能な柔軟性にあります。ハードウェア全体を仮想化するのではなく、コンテナはcgroupsとnamespaceを通じてホストOSのリソースを隔離します。これは「OSレベルの仮想化」とも呼ばれます。コンテナはホストのカーネルを共有し、独自のバイナリとライブラリのみを持つため、VMと比較してイメージサイズが小さく、起動速度も格段に速いです。
コンテナのメリット：
- イメージが軽量：ホストとカーネルを共有するため、必要なOSコンポーネントとライブラリを提供するだけで済みます。
- 速度：デプロイが極めて速く、通常は数秒でコンテナを生成できます。
- ポータビリティ：適切なカーネル環境下であれば、コンテナを異なるホストや環境間で容易に移動できます。
- CI/CD：コンテナはそのポータビリティと速度により、VMと比較してCI/CDの構築が容易です。
- ライフサイクル管理：コンテナの更新は、新しいイメージを使用して再起動するだけで済みます。
解決すべき課題：
- セキュリティ：ホストとカーネルを共有するため、ハードウェア全体を仮想化する場合に比べてセキュリティ面で劣ります。
- OSの選択不可：ホストとカーネルを共有しているため、各コンテナで異なるカーネルを実行することはできません。
- 複雑なネットワークが必要：コンテナは通常マイクロサービスとしてデプロイされるため、各コンポーネント間のネットワーク接続が複雑になります。
VM
VMはコンテナに比べて古くからある成熟した技術です。VMはハードウェア層全体を仮想化し、その上にOSをインストールするため、独立した一台のシステムのように動作します。
VMのメリット：
- システム全体の仮想化：これにより、VMはベアメタルサーバーと変わらない感覚で使用でき、直感的な操作が可能です。
- アプリケーションの分割が不要：ベアメタルサーバーと同じように使用できるため、アプリケーションのアーキテクチャを大幅に変更する必要がありません。
- セキュリティ：ハードウェア層全体が仮想化されているため、コンテナに比べてセキュリティと分離性が大幅に優れています。
- OS選択の柔軟性：VM上では、異なるOSを自由に選択してインストールできます。
デメリット：
- サイズ：VMのイメージサイズは非常に大きく、通常は数GB以上になります。
- 起動速度：VMの起動には数分かかる場合があり、急激な需要増加への対応が必要な場面には適していません。
- 実行速度：VMはハードウェア層を仮想化する必要があるため、ベアメタルサーバーと比較してパフォーマンスがいくらか低下します。
活用シーン
コンテナ
ベアメタルコンテナを導入する前に、以下の条件を評価する必要があります：
- アプリケーションのマイクロサービス化：コンテナ利用のベストプラクティスとして、マイクロサービスアーキテクチャを採用する必要があります。
- 信頼されたコードの実行：信頼されたコード（trusted code）を実行することで、カーネルの脆弱性が悪用されるのを防ぐことができます。
- 完備されたベアメタルデプロイメカニズム：コンテナは依然としてOSがインストールされたベアメタルサーバー上で動作する必要があるため、完全なベアメタルプロビジョニングメカニズムが必要になります。
- 特殊なネットワーク要件がない場合：現在、Kubernetesなどのコンテナオーケストレーションエンジンは、マルチNICなどの特殊なネットワーク要件に対して、CNI仕様の制限によりサポートが十分ではありません。
ベアメタルプロビジョニングは、最近のOpenStackにおいても急速に発展している分野です。新たにリリースされたRockyバージョンのIronicでは、多くの実用的な機能が追加されました。興味のある方は、以下の記事を読んでみてください。 OpenStack Rockyリリースについて知っておくべきこと
仮想マシン
一方、VMについては、評価すべき条件がかなり異なります。
- アプリケーションが迅速なスケールアウトを必要としない場合：VMの生成速度はコンテナよりも大幅に遅いため、負荷の急増に対応するために迅速なスケールアウトが必要な場合、コンテナほどの効果は得られません。
- 信頼できないコード（untrusted code）を実行する場合：信頼できないコードを実行する場合は、より完全な分離が提供されるVM上での実行が推奨されます。パブリッククラウドで実行されるサービスが依然としてVM層を介しているのは、サービスプロバイダーがユーザーがその上でどのようなプログラムを実行するかを確認できないためです。
- ハードなマルチテナンシー（hard multi-tenancy）が必要な場合：コンテナオーケストレーションエンジンでは、ハードなマルチテナンシーはまだ実現されていません。
- 特殊なネットワーク要件がある場合：VMは、新しいネットワークカードの動的なプラグイン・プラグアウトやマルチNICなどのアプリケーションにおいて、より成熟した発展を遂げています。
現在、VMの主な需要は依然としてレガシーアプリケーションやパブリッククラウドにあります。前者はマイクロサービスアーキテクチャではないためコンテナ化のメリットが少なく、後者はユーザー間の隔離性やシステムのセキュリティを考慮した結果の選択です。
その中間領域
Kata Containers
Kata Containers これは昨年始まったオープンソースプロジェクトで、軽量かつ高速なVMベースのコンテナを提供することを目指しています。namespaceで隔離する一般的なコンテナとは異なり、Kataはコンテナを軽量なVM内で実行することでセキュリティを向上させ、速度と安全性のバランスを両立させようとしています。
Kata Containersは軽量なVMを通じて隔離を行うことで、信頼できないコード（untrusted code）を実行可能にしつつ、コンテナに近い速度を実現します。VMとコンテナの中間に位置するソリューションと言えます。現在、コミュニティでは大規模なユースケースはまだ多く聞かれませんが、さまざまな環境での検討や試行に値する技術です。
結論
現在、多くの場合において、VMはインフラの基盤として、コンテナはアプリケーションの基盤として機能しています。コンテナとVMにはそれぞれ適した活用シーンがあり、両者は共存し、互いに補完し合える関係にあります。
最後に、ソフトウェアの世界は恋愛と同じで、唯一の正解はありません。あるのは、それぞれの用途に最も適した解決策だけです。自分たちのアプリケーションに最適な方法を選ぶことこそが正解であり、世の中の流行りに流されて一斉に移行するようなことは避けるべきです。
参考文献
Kata Containers
コンテナ化すべきか、せざるべきか、それが問題だ。あるいは、コンテナ vs VM：永遠の議論。
著作権表示：このブログのすべての記事は、 CC BY-NC-SA 4.0 特に明記されていない限り、以下のライセンスが適用されます。
