コンテナ vs. 仮想マシン: ライバルか仲間か？

近年、開発者の間では、Kubernetes のようなクラウドネイティブ・オーケストレーションツールや、コンテナを中心とした DevOps ワークフローが採用され、コンテナが話題になっています。

一方で、仮想マシン（VM）は、AzureのようなパブリッククラウドプロバイダやVMwareが稼働するオンプレミスデータセンターなど、企業の多くのワークロードを今もなお支えています。

2012年ごろプライベートクラウドは当時としては画期的なプロジェクトでした。その際に直面した大きな課題の1つが、インストールしたOSのイメージのサイズが大きいため、そのコピーを持つことでした。

OSのパッチを当てるなどして、イメージをメンテナンスし、複数のデータセンターに移動させる必要があります。そのため、時間とネットワーク帯域の両方を消費してしまいます。結局のところ、そうした問題を抱えるアーキテクトは私一人ではありませんでした。

つまり、コンテナとVMは多くの点で同じですが、多くの点で異なっています。これらの仮想化技術の違いを理解することで、状況に応じてどちらのタイプを使用すべきかを判断することができます。

コンテナの起源

1970年代にはUNIXオペレーティングシステムの一部として分離が行われ、2000年代初頭にはSolarisコンテナによって複数のワークロードが物理サーバを共有できるようになりました。

しかし、コンテナが本格的に普及したのは、2013年に発表されたDockerがきっかけでした。VMwareやHyper-Vなどの仮想化ハイパーバイザーが成熟していたため、開発者や管理者がコンテナ化を理解し、それゆえ迅速に取り入れることはありませんでした。

コンテナとVMの違いとは？

VM は、基盤となるハードウェアとは別にオペレーティングシステムの完全なコピーを含んでいますが、コンテナは OS カーネルをホスト OS と共有します（ホストがベアメタル物理か仮想かに関係なく）。

つまり、コンテナイメージはVMイメージよりも数段小さく、移植性が向上します。開発者の観点からは、アプリケーションがデスクトップで動作するならば、すべてのアプリケーションの依存関係がコンテナ内にあるため、本番環境でも動作します。

コンテナには、アプリケーションのバイナリやライブラリだけが組み込まれています。つまり、どのような場合でも、実行中のコンテナには1つの実行プロセス（プロセスIDは1）、つまりコンテナ内で実行されているアプリケーションが存在することになります。コンテナはホスト OS のカーネルとハードウェアリソースを、ホスト上で動作する他のコンテナと共有します。図１を参照ください。

Architectural differences figure 1

図1. 仮想マシンとコンテナのアーキテクチャの違い

コンテナとVMを比較する場合

コンテナの初期のユースケースは、ウェブサーバのような永続的なデータを必要としないステートレス・ワークロードでした。これは、DockerのようなランタイムとKubernetesのようなクラウドネイティブアプリケーションの導入により進化しました。コンテナはより堅牢になり、MicrosoftやOracleデータベースのような永続的なストレージアプリケーションに使用できるようになりました。

現在では、Kubernetesのようなコンテナオーケストレーション・プラットフォームに、ストレージとネットワークの機能が組み込まれています。KubernetesはGoogleによって作成され、オープンソースプロジェクトになりました。

Dockerコンテナが開発者にとって使いやすいことから爆発的に普及したのと同様に、Kubernetesの急成長は、マイクロサービスアーキテクチャ向けの機能と、AWSやMicrosoft Azureなどのクラウドプロバイダ経由でコンテナを簡単にデプロイして利用できる機能の結果です。

Kubernetesの初期には、クラスタの構築は複雑な作業でした。しかし、クラウドKubernetesエコシステムの登場により、クラスタ構築のプロセスは、1行のコードを実行するのと同じくらいシンプルになりました。Kubernetesはデプロイだけでなく、CPUやメモリなどのハードウェアリソースの管理も行います。Kubernetesは完全にAPI駆動型であるため、開発しやすくなっています。

Kubernetesでは、クラスタ内でコンテナランタイムを定義する必要があります。最も一般的なのはこのランタイムがDockerであるが、多くの組織ではcontainerdやCRI-Oといった他のランタイムを使用している。

コンテナに関するもう1つの重要な概念は、コンテナレジストリです。apt-getやyumのようなオープンソースのパッケージ管理ソリューションのように、コンテナレジストリはコンテナイメージのライブラリです。それらのコンテナイメージは、多くの異なるアプリケーションを含み、自動ビルドプロセスの一部としてCI/CDワークフローに統合されます。これらのレジストリは、要件に応じて、プライベートまたはパブリックにすることができます。また、クラウドプロバイダは、パブリックまたはプライベートにかかわらず、独自のコンテナレジストリをホストする機能を提供しています。

VMを使用する利点は何でしょうか？

近年、コンテナは開発者やDevOpsチームの間で広く普及していますが、ワークロードの大部分は依然としてVMです。Gartner社は、VMなどのIaaSコンポーネントへの支出がパブリッククラウド支出の4分の1を占めていると指摘しています。

多くのレガシー・アプリケーションは、コンテナ上での実行をサポートしていません。なぜなら、これらのアプリケーションはモノリシックなアプリケーション環境で開発されており、アプリケーションを実行させるためには複数のプロセスが実行される必要があるためです。そのため、より高い分離レベルを提供するVMの方が適しています。

また、コンテナにはセキュリティ上の懸念もあります。コンテナにはいくつかの既知の脆弱性があり、VMほど完全には隔離されていないため、コンテナの悪用では他のコンテナを悪用する可能性があります。

コンテナとVMのどちらが優れているか？

とはいえ、コンテナは存在し、なくなることはないでしょう。デプロイメントのワークフローを単純化し、メンテナンスのオーバーヘッドを削減し、ほぼ無限のスケーラビリティを提供することで、ソフトウェア開発のライフサイクルを改善しました。

この点では、パブリッククラウドの構築やマルチクラウド環境のサポートに不可欠なクラウドインフラの自動化を可能にし、ITを根本的に変えたVMに似ています。ほとんどの組織では、コンテナとVMの両方を使用しています（実際、Kubernetesなどの多くのコンテナオーケストレーションプラットフォームはVM上でホストされていることが多いのです）。ほとんどの環境が多種多様なアプリケーションをサポートしているため、これは理にかなっています。

コンテナが成熟するにつれて、多くの組織がMicrosoft SQL Serverのようなデータベースサーバーにコンテナを使用するようになりました。SQL Server 2017から、人気の高いMicrosoftデータベースエンジンがDockerとKubernetesで利用できるようになりました。Dockerは高可用性をサポートし、より堅牢な永続的ストレージオプションを備えているため、多くの組織がローカルのデータベース開発用にDockerを、本番ワークロード用にKubernetesを使用しています。

データベースはアプリケーションの中核であるため、そのパフォーマンスは非常に重要です。データベースのパフォーマンスに関する問題を特定することは、優秀なDBAにとっても困難なことですが、だからこそ、多くの組織がDatabase Performance Analyzer (旧Ignite)を利用しているのです。Database Performance Analyzer を使用すると、データベースコンテナをより簡単に管理し、円滑に動作させることができます。

関連トピックス

コンテナ vs. 仮想マシン: ライバルか仲間か？への1件のフィードバック

コメントを残すコメントをキャンセル

メールマガジン登録

クライム主催セミナー

出展・参加イベント

クライム製品・サービス

新着記事

製品・カテゴリで絞る

タグ・トップ50