ここでは、仮想マシンとコンテナの違いについて取り上げます。仮想マシンとコンテナ、それぞれの主な違いについて深く掘り下げていきます。コスト、セキュリティ、パフォーマンスの観点から両者の比較を理解することで、アプリケーションに適した選択をするための準備が整います。

仮想マシン

「仮想マシン」（VM）という用語は、仮想化として知られるプロセスを使用した物理コンピュータのエミュレーションを指します。この技術を利用したクラウドサービスの例としては、以下のようなものがあります：

• Amazon Elastic Compute Cloud (EC2)
• Azure Virtual Machine
• Google Compute Engine

仮想化の中核となるのは、ハイパーバイザーと呼ばれるソフトウェア・アプリケーションです。物理サーバにハイパーバイザをインストールすると、同じ物理サーバ上に複数のオペレーティングシステムを存在させるレイヤが追加されます。これらのオペレーティング・システムは独立したコンピュータとして機能し、ハイパーバイザを通じて処理、メモリ、ネットワーク・アクセスなどの基本リソースにアクセスします。

VMは通常、完全なオペレーティング・システムと複数のアプリケーションを同時に実行する機能を備えた物理サーバに似ています。VMについて説明する場合、通常はギガバイト、仮想プロセッサの数、割り当てられたメモリという単位で説明します。VMは、ウェブサーバやアプリケーションサーバとバックエンドデータベースの両方を同じインスタンス上でホストすることができます。新しいVMは、数分以内にプロビジョニングして稼働させることができます。

コンテナ

コンテナは仮想化のもう1つの形態ですが、フットプリントがはるかに小さく、デプロイと起動時間が高速です。コンテナをサポートする技術は数十年前から存在していましたが、2013年にDockerが登場するまで広く受け入れられることはありませんでした。現在ではDockerに加えて、KubernetesやOpenShiftといった他のコンテナ技術も選択できるようになり、コンテナ化されたアプリケーションのデプロイと管理が可能になっています。

ハイパーバイザーの代わりに、コンテナはホストサーバーのオペレーティングシステム上にサービスとしてインストールされたコンテナエンジンを使用します。コンテナエンジンは、ホストマシン上のリソースへのアクセスを管理します。各コンテナはホスト・サーバーのオペレーティング・システムからリソースを共有するため、コンテナ・イメージはVMイメージよりも大幅に小さくなります。

一般的にコンテナはメガバイト単位で測定され、クラウド環境で使用することで多くの組織がマイクロサービスアーキテクチャを実装するのに役立ちます。コンテナには通常、特定の機能を持つ単一のサービスのみが含まれ、数秒でデプロイして実行できます。コンテナは、システムが需要の増加に応じて同じサービスのインスタンスを追加できるスケーラブルな環境で特に有用です。コンテナに障害が発生した場合、コンテナエンジンは障害の発生したコンテナを破棄して置き換えることができるため、回復力のあるフォールトトレラントなシステムを構築できます。

主な違い

VMとコンテナの明らかな違いについてはすでに説明しました。コンテナはより小さく、より迅速にデプロイでき、スケーラブルでフォールト・トレラントなシステムをサポートできます。一方、VMは単一のインスタンスで複数のリソース集約的なタスクを同時に実行でき、より耐久性があり長持ちすると考えることができます。

コンテナが解決に役立つ重要な問題の1つは、環境の一貫性です。従来の開発では、開発環境と本番環境の間でオペレーティングシステムのバージョンや構成に違いが生じることがありました。エンジニアがコンテナを使ってソリューションを構築する場合、すべての依存関係を含むコンテナを作成します。エンジニアは、そのコンテナが開発ワークステーション上でも本番環境と同じように動作することを合理的に期待できます。

長所と短所を深く掘り下げる

上述した違いは、VMとコンテナの明確な対比を提供し、システムのアーキテクチャと設計に基づいて、どちらがニーズに最も適しているかについての結論を導き出すことができます。しかし、実際にはすぐに明らかにならない、考慮すべき追加要素もあります。次に、これらの要因のいくつかを深く掘り下げていきます。

コスト

コンテナとVMのコストの違いに対処する方法はいくつかあります。いずれにせよ、アプリケーションをサポートする環境が必要になります。アプリケーションの負荷が大きく変化する場合、その変化に応じて環境の規模を拡大・縮小することがメリットになるかもしれません。その場合、コンテナはスケーラビリティとコストの両面で有利になります。

ただし、アプリケーションのサポートや開発にかかる費用は、ホスティングよりも経費に大きく影響します。クラウドネイティブなアプリケーションをゼロから開発していて、エンジニアリングスタッフがコンテナを使用したマイクロサービス・アーキテクチャの開発とデプロイの経験を持っている場合は、コンテナが当然の選択肢になるでしょう。

例えば、現在も将来もユーザーのニーズを満たすレガシー・アプリケーションをサポートする必要があるとします。その場合、VMを使用してアプリケーションのホスティングを継続するか、クラウドベースの戦略を追求するのであれば、自社のデータセンターからパブリック・クラウド・プロバイダーのいずれかのVMに移行した方がよいでしょう。また、既存のITスタッフの専門知識とトレーニング、およびトレーニングや追加雇用にかかるコストも考慮する必要があります。

コンテナが提供する利点を活用するためのアプリケーションの設計と再構築は、コストのかかる取り組みになる可能性があります。アジャイル開発、CI/CD、DevOpsのプラクティスは成功の確率を高めることができますが、それでもリスクの要素はあります。このような取り組みに着手する前に、組織は徹底的な分析を行う必要があります。

セキュリティ

最も費用対効果が高く、パフォーマンスの高いクラウドアーキテクチャであっても、システムを安全に保てなければ意味がありません。VMとコンテナ環境では、セキュリティに関して異なる難しさがあります。その一例として、VMとコンテナではインスタンス間のセグメンテーションの実装方法が異なります。

VMの場合、ハイパーバイザーはしっかりとしたセグメンテーションの境界を維持します。この境界は、あるVMが同じホスト上の別のVMや、基盤となるホストと相互作用することを防ぎます。セグメンテーション攻撃は依然として発生する可能性がありますが、ハイパーバイザ技術はこの境界を厳格に適用するため、このような攻撃が発生する可能性は低くなります。

ホスト・オペレーティング・システム（OS）は、コンテナのセグメンテーション境界を維持します。OS は名前空間と cgroups 機能を使用して論理環境を作成し、プロセス、ファイル、およびネットワーク状態を 1 つのコンテナに関連付け、他のコンテナからは見えないようにします。これは基盤となる OS の機能に依存するため、古いバージョンでは問題が発生する可能性があります。経験豊富な管理者がホストマシンのセキュリティ確保と堅牢化を行うことで、脆弱性のリスクを減らすことができます。また、コンテナ・イメージとホスト・マシンをさらにセキュアにして保護するために、業界の専門家やツールの助けを借りることもできます。

設定のドリフトは、セキュリティを比較する際のもう一つの重要な考慮事項です。通常、コンテナは頻繁に破棄され、再デプロイされるため、環境の老朽化に伴って設定が変更される可能性は低くなります。また、コンテナの構成はコンテナマニフェストに文書化されているため、コンテナの構成や、どの依存関係を含むかを簡単に観察や検証が可能です。逆に、VM には常に明確に文書化されているわけではない複雑な構成が含まれている可能性があり、より永続的な性質を持つことから、構成ドリフトが発生しやすくなります。

最後になりますが、脆弱性スキャンは、新しいデプロイメントに潜在的に危険なコードや脆弱なコードが含まれるのを防ぐための効果的なツールです。サードパーティのツールは、コンテナにもアプリケーションにも利用できます。しかし、コンフィギュレーションと同様に、複数のアプリケーションやサポートするライブラリやソフトウェアが含まれる可能性のあるVMと比較すると、コンテナはこれらのスキャンの対象としてそれほど複雑ではありません。

パフォーマンス

コンテナとVMの性能比較は、システム設計や構成によって生じる変動要因のために難しい場合があります。ホストマシン上のリソースへのアクセスという観点から見ると、VMは仮想化リソースに依存しているため、パフォーマンスのオーバーヘッドが増加します。同時に、コンテナはグラフィック・カードなどのホスト・システムのリソースに直接アクセスできます。とはいえ、ハイパーバイザーとコンテナ・エンジンは改善を続けており、VMからコンテナに切り替えてもパフォーマンスが劇的に向上するわけではありません。

コンテナがVMを凌駕する1つの領域は起動時間であり、前述したように、VMが数分かかるのに対し、新しいコンテナは数秒で済みます。コンテナは、コンテナ・エンジンがサポートするすべてのコンテナ間でリソースの使用を最適化する方法から、もう1つの利点を得ています。VMは起動時にほとんどのリソースを恒久的に割り当てる必要があり、その結果、リソースを必要としないVMのリソースが拘束され、高負荷が発生している同じホスト上の別のVMがそのリソースを使用できなくなる可能性があります。

最後に、VMでは各インスタンスにオペレーティング・システムをインストールする必要があるため、ホスト・マシン上の重複したコンポーネント、ライブラリ、サービスのために大量のストレージ割り当てが発生します。マシン上でホストされるすべてのコンテナは、そのマシンのオペレーティング・システムに依存します。この設計により、冗長性が削減され、リソースがより適切に割り当てられるようになります。

正しい決断を下すために

上記のようなさまざまな要因を考慮すると、組織に適したアプローチを選択するのは難しいことです。ある組織にとって最適でも、別の組織には適さないかもしれません。コンテナは、その利点を活用できるクラウドネイティブ・アプリケーションにメリットをもたらします。一方、仮想マシンは、レガシー・アプリケーションをパフォーマンスとコスト効率の高い方法でサポートできる、確立された実績のあるテクノロジーです。

クラウドの優れた点は、この決定がどちらか一方である必要がないことです。例えば、コンテナを仮想マシン上でホスティングすることで、両方の利点を活用できることに気づくかもしれません。AWS Elastic Container Service（ECS）やGoogle Kubernetes Engine（GKE）のような確立されたコンテナ・プラットフォームを使用することで、複雑さの軽減を選択することもできます。さらに、コンテナ化に適した純粋なソフトウェアベースのアプリケーションもあれば、特定のハードウェア要件を持つアプリケーションはVMにデプロイした方がうまく機能するかもしれません。

時間をかけてオプションを検討し、理解してください。また、時間の経過とともにニーズが変化し、新しいテクノロジを活用するためにアプリケーションを再設計することで、低コストでより優れたパフォーマンスを実現できる場合もあります。