コンテナ化するのか、あるいはコンテナか仮想マシンかは、果てしない議論です

ミランティスでは、伝統的なモノリシック ワークロードをクラウドに移行する方法について多くのことを考察しています。まず最初に、ワークロードを移動する方法ではなく、ワークロードを移動するかどうかを決定する必要があります。この記事では、あなたの状況においてこの決定を行う際に考慮する必要があるいくつかの課題について説明します。

例外はありますが、アプリケーションをクラウドベースの環境に移動するには、仮想マシンまたはコンテナという２つの基本的なオプションがあります。多くの場合、最も単純なソリューションは、アプリケーションを仮想マシンに単純移行させて終わりにする方法です。しかし、それはしばしば最適なソリューションではありません。

あなたの決定に影響を与えるさまざまな要因を見てみましょう。

仮想マシンとコンテナの違い

仮想マシンまたはコンテナが最終的にプロジェクトにとってより良いかどうかについて議論する前に、2つのアーキテクチャの違いを理解することが重要です。

構造

仮想マシン (VM) は、オペレーティングシステムからメモリとストレージに至るまで、コンピュータ全体を抽象化したものです。VM が構築されたイメージは、アプリケーションをインストールできるオペレーティングシステムだけでなく、Web サーバーやデータベース、さらにはアプリケーション自体など、必要なすべてのアプリケーションを含むことができます。各 VM は、実行されているホストとそのホスト上の他の VM と完全に隔離されています。

一方、コンテナは、既存のマシンの一部を占有するように設計されており、ホスト上のカーネルをシステム上で実行されている他のコンテナと共有し、必要なコードを実行するのに必要十分なオペレーティングシステムとサポートライブラリを含みます。それらは必要なすべてを含むイメージから構築されていて、理想的には他には何も含みません。

リソース要件

これらの異なる構造のため、VM とコンテナを実行するための要件は大幅に異なる可能性があります。VM は本質的にコンピュータ全体であるため、当然のことながらオペレーティングシステムの最小限の部分しか含まないコンテナより多くのリソースが必要になります。したがって、一般的に、コンテナの規模を拡大すのにも少量のリーソースで済み、VM よりも単一のサーバーに多くを収容することができます。

ただし、複数のサービスが単一のVMのリソースを「共有」できるため、単一のVMを置き換えるために必要な複数のコンテナでのリソースの節約のメリットを覆してしまう可能性があります。たとえば、1つのVMの機能を50種類の異なるサービスに分解すると、50種類の部分的なオペレーティングシステムと、1つの完全なコピーとの比較になります。だからあなたが何を得ようとしているのかを正確に理解してください。

セキュリティ

VM とコンテナのどちらがより安全であるかどうかという質問は、論争の的となるものであり、この記事の範囲をはるかに超えたものになりますが、いくつかの主要テーマに触れてみましょう。 (このトピックの全体についての記事に興味がありますか？コメントでお知らせください！)

VM は互いに厳密に分離されていますが、コンテナはカーネルを共有しているため、一方が侵害された場合、そのホスト上の他の人が危険にさらされる可能性があります。さらに、Docker が Linux とやりとりするために使用する libcontainers は、Process、Network、Mount、Hostname、Shared Memory の5つの別々の名前空間に触れています。それぞれがセキュリティ問題を引き起こす可能性があります。

さらに、OpenStack Magnum コンテナプロジェクトの元 PTL Adrian Otto 氏は、「VM は攻撃される断面が小さい。Linux 3.19 カーネルではコンテナのシステムコールが少なくとも397にもなる。」と述べています。

ただし、VM はコンテナよりも攻撃断面が小さいですが、仮想化プラットフォーム全体を考慮する必要があります。VM の「中断」は不可能です。ミランティスのセキュリティ専門家 Adam Heczko は、「[有名なハイパーバイザー] Qemu は これまでに約 217 の脆弱性 の影響を受けており、3つの VM エスケープ攻撃が行われています。VM がコンテナよりも安全性が高いかどうかはわかりませんが、脅威モデルはアーキテクチャとまったく根本的に異なります。」と述べています。

考慮すべきセキュリティのもう1つの側面は、ユーザーが通常必要なソフトウェアを実行する独自の VM イメージを作成するのに対し、コンテナ、特に Docker コンテナは相互の上に構築するように設計されていることです。

たとえば、Web ベースの検索アプリケーションを作成していたとします。次のようにコンテナイメージを作成することができます。

1. Alpine などの最小限のオペレーティングシステムから始めます。
2. Nginx などの Web サーバーを導入します。
3. Nginx で動作する検索アプリケーションを導入します。

ここで問題となるのは、「公式な」なものを使用している限りは、このイメージの最初の2つの層にかなり自信がありますが、何が本当にそこにあるかを調べるのに時間をかけない限り、最後のアプリケーションは謎です。誰でも画像をレポに追加たり、必要なものを呼び出すことができます。開発者が既にインストールした検索アプリケーションを使った Nginx イメージを取得しようとした場合、彼らは自分が思っていることを確実に実現するために努力を行わない限り、データセンターに実際の問題を引き起こすことがあります。

次に、各アーキテクチャの長所と短所を見てみましょう。

VM の長所と短所

VM よりもコンテナの方が有利だと言うのが流行していますが、実際にはプラスとマイナスがあります。

長所

VM の利点は次のとおりです。

• システムの完全な抽象化：アプリケーションのすべてが同じ “サーバー”または複数のサーバー上で実行されているため、それらの間の通信は簡単で、複雑なネットワークを追加する必要はありません。
• アプリケーションを分解する必要がない： ベアメタルマシンと同様の環境で実行しているため、アプリケーション自体のアーキテクチャを変更する必要はありません。
• 同時に複数のアプリケーションを実行する： 1つの VM 上で複数のアプリケーションを実行して、インフラストラクチャ全体の管理を簡素化するのは一般的です。
• 安全性：仮想マシンは長い使用実績があり、かなり安全であると考えられているため、攻撃断面は非常に小さいですが、上記のセキュリティセクションの注意事項を念頭に置いてください。
• 利用可能なさまざまなオペレーティングシステム： ハイパーバイザー内では、ほとんどすべてのオペレーティングシステムを使用できるため、1台の物理サーバー上で複数のオペレーティングシステムを実行できます。

短所

• 大きくなることがあります：それらはあまりにも多く含まれているので、VM は定義するのに必要なイメージと、それを実行するために必要なリソースの両方で大きくなることがあります。
• 起動が遅くなることがあります： VM を起動することは、コンピュータを起動することと同じで、時間がかかることがあります。あなたが一度だけそれを始動させ、数週間または数ヶ月または数年間走らせるなら、これは問題ではないかもしれません。しかし、恒常的に起動しなければならないプロセスで運用しているなら、この待ち時間は間違いなく問題になる可能性があります。
• 実行が遅くなることがあります：基本的にコンピュータ内のコンピュータをエミュレートすることに起因して、仮想マシン上で動作するアプリケーションは、多くの場合、ベアメタル上で実行されているものほどパフォーマンスではありません。
• 簡単にはネストすることはできません：状況によっては別の VM 内で VM を実行することは可能ですが、必ずしも選択肢にはなりません。更にそれを選択できる場合でも、パフォーマンス上のペナルティが相当に大きくなる可能性があります。
• 慎重なセキュリティ設定が必要：公開サブシステムと管理サブシステムや、管理サブシステムとデータサブシステムの間でセキュリティドメインが接続されていたり、それらの間にコンポーネント分散されていたりするため、潜在的なセキュリティ問題を防ぐように VM をホストするプラットフォームは慎重に分析および設定する必要があります。

コンテナの長所と短所

コンテナも普遍的な素晴らしいものではありません。同様に、その長所と短所を見てみましょう。

長所

• 相対的に小さいサイズ：コンテナはホストのカーネルを共有し、絶対に必要なオペレーティングシステムとライブラリコンポーネントのみを含み、通常は単一の機能に制限されるので、それらは非常に小さくなる傾向があります。
• 高速：小規模なので、数秒かそれ以下で起動することができます。いわゆる「サーバーレス」アプリケーションなどの、繰り返し起動と停止が必要なアプリケーションに役立ちます。
• CI/CD:コンテナは頻繁に開始され、再起動されるため、変更を簡単に取り込めます。
• ポータブル：自己完結型であるため、カーネルが適切に配置されている限り、比較的簡単にコンテナをマシン間で移動できます。
• ライフサイクルと配信モデル：コンテナ化されたライフサイクルの構造により、脆弱性評価やイメージレジストリ署名などの高度な機能を組み込むことが容易になります。

短所

• 複雑なネットワークを必要とすることがあります：機能は (理想的には) 複数のコンテナに分割されているため、これらのコンテナは相互に通信する必要があります。しかし、コンテナは単一のユニットではないので、互いに通信する必要があります。Kubernetes などの一部のオーケストレーションシステムでは、マルチコンテナポッドなどのより高レベルのユニットがあり、これを少し容易にすることができますが、VM を使用するよりもさらに複雑です。「実際には、Kubernetes の L3 ネットワーキングモデルは OpenStack の L2 モデルよりもはるかに簡単です」と、Adam Heczko 氏は付け加えます。つまりネットワーキングについての作業量は、機能間の通信なのか、または VM 間の通信について見ているのかに依存します。
• 安全性の低いことがあります：前述のように、コンテナはまだ歴史が短く、異なるいくつかの理由で仮想マシンほど安全であると考えられていません。ただし状況によりゴールまでの道のりは変わるでしょう。
• より多くの先行作業を必要とすることがあります：あなたは正しくコンテナを使用する場合には、そのアプリケーションを様々な構成要素のサービスにを分解する必要があります。それらは有益ですが、VM を使用する場合には必要ありません。
• 信頼性が低いことがあります：これは否定的に聞こえますが、コンテナは一般的にクラウドネイティブコンピューティング用に設計されていて、コンポーネントはいつでも停止する可能性があります。アプリケーションがこのような状況に備えて適切に設計されていることを確認する必要があります。

あなたの意思決定

結局、コンテナや VM を使用するかどうかについての決定は、他のほとんどのIT決定と同じです。”それは状況によります” 。

基本的にアプリケーションの「持ち上げと移動」を行っている場合は、VM を最も混乱の少ない VM に移動する方がよい場合があります。新しいアプリケーションを一から作成する場合は、まずコンテナを使い始める方がよいでしょう。

幸いにも、あなたは困難だけれども短期間での決断をする必要はありません。たとえ30年前のモノリスからでも、最初はいつでも VM に移動することができます。その後、さまざまなコンポーネントを徐々に分解してコンテナ化することができます。

次回にご期待ください。