仮想マシンからコンテナまで、さまざまなサービス仮想化技術とその適用シナリオについて詳しく説明します。

この記事はWeChatの公開アカウント「jameswhale's Technical Life」から転載したものです。この記事を転載する場合は、jameswhale の Technical Life 公開アカウントにご連絡ください。

オリジナルリンク: https://mp.weixin.qq.com/s/LOXB36aevXoH9EQHFr5E9Q

出典: jameswhale's technical life

WeChat パブリックアカウント ID: jameswhale's technical life

[[329556]]

序文

近年、コンテナやKubernetesなどの技術が、さまざまなインターネット企業のデータセンター、クラウドコンピューティング、ビジネスサービスで広く利用されるようになりました。 1960 年代に登場した仮想マシン (VM) テクノロジと同様に、コンテナもサービス仮想化テクノロジ (サーバー仮想化) ですが、より軽量で、マシンからアプリケーションに重点が移っており、開発、テスト、本番環境の展開の効率が大幅に向上します。ただし、セキュリティと分離性は仮想マシンに比べて若干劣るため、シナリオによっては仮想マシンを完全に置き換えることはできません。この記事では、主に仮想マシンとコンテナの技術を以下の部分から整理し、その違いやつながりについて詳しく説明します。

• サービス仮想化テクノロジーがなぜ必要なのでしょうか?
• 仮想化技術の分類
• ホストベースのサーバー仮想化（仮想マシン）アーキテクチャ
• OS仮想化（コンテナ）アーキテクチャ
• コンテナのカーネルサポート
• 仮想マシン技術の例 (VMWare ESXi)
• コンテナ技術の例 (Docker コンテナ)
• クラウドプラットフォーム（Google Cloud Platform、GCP）における仮想化技術の応用

サービス仮想化テクノロジーがなぜ必要なのでしょうか?

1. ハードウェア リソース (コンピューター ルーム、サーバー、冷却システムなど) を節約し、リソースの使用率を向上します。12306 Web サイトの負荷には明らかなピークと谷があります (休日の前夜に大きくなり、春節の時期に最も顕著になり、通常の時期には比較的低くなります)。ピーク時のトラフィックを処理するために物理サーバーをすべて使用すると、通常時に膨大な無駄が発生します。サービス仮想化（サーバー仮想化/マシン仮想化）技術によって構築されたクラウドコンピューティングプラットフォーム（クラウドコンピュータプラットフォーム）は、この問題を効果的に解決できます。ピーク時には、チケット購入の需要を満たすためにコンピューティング能力を増強し、閑散時には、リソースの利用率を向上させるためにコンピューティング能力を販売することができます。 Tencent Cloud は、CPU、メモリ、ストレージ (1C/1G/50GB など) などのサービスを外部に提供できます。一般ユーザーは、水道、電気、ガスなどの基本的な自治体サービスを購入するのと同じように、サーバーの購入、コンピューター ルームの構築、ネットワーク アクセスの計画、データの災害復旧について心配する必要がありません。
2. 論理リソースの統合: 仮想マシン (VM) テクノロジにより、複数の異なるゲスト オペレーティング システム (およびそれら上で実行されるさまざまなアプリケーション) を物理サーバー上で実行できます。たとえば、メール サーバー、データベース サーバー、Web サーバー、およびその他のアプリケーションを一緒に展開し、効果的に分離できます (リソースとアクセス)。
3. サーバーの移植性: 仮想マシン モニター/ハイパーバイザーは、基礎となる違いを保護します。同じゲスト オペレーティング システムを、ハードウェアに依存することなく、完全に異なるハードウェア アーキテクチャ (Mac、X86 など) を持つサーバー上で実行できます。変更や調整を一切行わずに、あるハードウェア サーバーからまったく異なる別のハードウェア サーバーに移行することができ、ユーザーはそれを認識しません。
4. アプリケーションの信頼性: 仮想マシン (VM) が配置されているハードウェア サーバーが破損した場合、別のハードウェア サーバー (すべて仮想マシン モニター/ハイパーバイザーを使用して展開) にすばやく移行できるため、そのサーバー上で実行されているアプリケーションの信頼性が大幅に向上します。コンテナが配置されている Linux サーバーにアクセスできなくなった場合、コンテナ マネージャー (K8s など) は、業務に影響を与えることなく、別の Linux サーバー上に新しいコンテナを作成できます。 (仮想マシン テクノロジの助けにより、ゲスト オペレーティング システムが Linux である限り、コンテナーは Linux 以外のサーバーでも実行できます。)
5. ネットワークとストレージも仮想化テクノロジを採用しています。ストレージの仮想化は、物理ディスクを論理的にグループ化し、そのグループ化を 1 つ以上の仮想ディスクとしてオペレーティング システムに提示する方法を提供する RAID (Redundant Arrays of Independent Disks) の使用から始まり、長年にわたって存在してきました。 Huawei の OceanStor シリーズ ストレージ アレイはストレージ エリア ネットワーク (SAN) に属し、DevLun (デバイス論理ユニット番号) を介して上位ホストに提供されます。ホストの I/O アクセス品質を確保するために、さまざまなアルゴリズム (SmartVirtualiztion、SmartQos、smartPartition など) が内部的にカプセル化されています。ネットワーク仮想化は、何十年も前から存在している仮想化の別の形式です。たとえば、仮想ローカル エリア ネットワーク (VLAN) は、長い間、物理ネットワーク スイッチを論理的にセグメント化する手段を提供してきました。したがって、ホストのローカル スイッチのビューは、ホストが接続されているスイッチの物理的な構成に限定されず、VLAN 自体の論理表現によって決まります。

サービス仮想化技術の分類

• ホストベースのサーバー仮想化 (VM) テクノロジにより、異なるオペレーティング システムを搭載した複数の VM を同じ物理ホスト システム上で同時に実行できます。さらに以下の3つのカテゴリーに分類できます。

1. 完全仮想化: 完全仮想化は完全なハードウェア エミュレーションを提供します。これにより、仮想マシンの完全な移植性という利点が得られ、たとえば、Dell サーバー上で実行されている仮想マシンを問題なく HP サーバーに再配置できるようになります。その代償として、パフォーマンスが低下し、メモリの読み取りと書き込みが約 2% 失われ、ネットワークとハードディスクの I/O が約 8% ～ 20% 失われます。
2. 準仮想化: 仮想マシン内のゲスト オペレーティング システムを再コンパイルして、仮想化環境にあることを認識させ、ホスト オペレーティング システムまたは VMM/ハイパーバイザーと連携できるようにする必要があります。準仮想化は、次の 2 つの方法で実現できます。1) オペレーティング システム カーネルを再コンパイルします。この場合、オペレーティング システム ブランドは、準仮想化環境と互換性のある OSbuild を提供する必要があります。 2) 準仮想化カーネルモードドライバーをインストールします。準仮想化カーネル モード ストレージおよびネットワーク ドライバーをインストールすることで、ハード ディスクとネットワークの読み取りおよび書き込みの遅延を効果的に削減できます (完全仮想化の 8% ～ 20% から 2% に)。
3. ハードウェア支援による仮想化: Intel と AMD はどちらも、プロセッサの仮想化に積極的に取り組んでいます。 CPU は仮想環境の存在を認識し、VMM/ハイパーバイザーと直接対話し、リング 1 で実行できるようにします。この方法では、ゲスト オペレーティング システムを Ring0 で実行でき、特権命令を実行するために VMM/ハイパーバイザーのトラップ割り込みに依存する必要がなくなり、特権命令の実行遅延が大幅に削減されます。処理パフォーマンスを向上させながら、仮想マシンに異なるハードウェア アドレス空間を割り当てることで、ハードウェア レベルで効果的な分離を実現します。

要約すると、リソースへの直接アクセスはネイティブ レベルのパフォーマンスを提供できますが、移植性が犠牲になります。移植性を向上させるために、仮想化ベンダーは VMM/ハイパーバイザー対応の準仮想化ゲスト オペレーティング システム ドライバーをさらに開発します。これらのドライバーは、ネットワーク カードやストレージ コントローラーなどの合成仮想デバイスを表します。合成デバイス ドライバーを使用すると、ゲスト オペレーティング システムは、ネイティブに近いパフォーマンスを提供しながら、一貫したハードウェア リソース セットを認識できるようになります (別のホストに移行された場合でも)。

• OS仮想化（コンテナ）

OS 仮想化はアプリケーション中心であり、複数の仮想環境 (VE) が共通の OS を共有できるようにし、各環境は完全に仮想化されたホストよりもはるかに少ないオーバーヘッドで実行されます。メモリだけを見ると、仮想マシンの要件はかなり大きくなります。たとえば、ホスト サーバー上で 8 台の仮想マシンが実行されており、各ゲスト オペレーティング システムが 512 MB の RAM を使用しているとします。つまり、アプリケーションまたは VMM のオーバーヘッドを考慮に入れない場合、仮想化のコストは 8 x 512 MB、つまり 4 GB の RAM になります。各オペレーティング システムのインストールに 4 GB のディスク領域が必要であると仮定すると、すべてのゲスト オペレーティング システムを格納するには、物理​​ホスト システム上に 32 GB のディスク領域が必要になります。

OS 仮想化のもう 1 つの利点は、仮想環境でドライバーや完全なハードウェア エミュレーションを必要としないことです。これにより、仮想化環境での I/O をネイティブに近いパフォーマンスで実行できるようになります。 VE はアプリケーション シェルとして実行されるため、ホスト システムのハードウェアに依存することなく、VM と同じ移植性を提供します (ただし、すべて Linux オペレーティング システム上に存在する必要があります)。

セキュリティと分離は仮想マシンほど優れていません (オペレーティング システムによって提供されるアプリケーション レベルの分離)。この理由だけで、コンテナ テクノロジは仮想マシン テクノロジに取って代わることはできません。

ホストベースのサーバー仮想化（仮想マシン）アーキテクチャ

仮想マシンは、ホスト オペレーティング システムがあるかどうかに基づいて 2 つのカテゴリに分類されます。

• タイプ 1 (オペレーティング システムなし、VMM はベア ハードウェア上で直接実行されます)

タイプ2（オペレーティングシステム付き）

VMM (仮想マシンモニター)/ハイパーバイザーの役割

• VM のハードウェア エミュレーションを提供します (完全仮想化シナリオでは、他のシナリオではハードウェアに直接アクセスします)。
• VM アクセスを相互に分離します (ソケットなどのネットワーク経由でのみ通信できます)。
• 不安定な VM がシステム全体のパフォーマンスに影響を与えないように、単一の VM によるシステム リソースへのアクセスを制限します。

命令の実行レベル

命令実行レベルはRing0～Ring3に分かれています。通常、オペレーティング システム カーネルは Ring0 で実行され、デバイス ドライバーは Ring1 ～ Ring2 (または両方が Ring0 で実行) で実行され、アプリケーションは Ring3 で実行されます。

• 従来のX86アーキテクチャ

• 仮想マシンのシナリオ（CPUハードウェアはサポートしない）

• 仮想マシンのシナリオ（CPUハードウェア支援）

OS仮想化（コンテナ）

OS 仮想化レイヤーは、Linux オペレーティング システム カーネルの特性 (名前空間、cgroup など) を使用して、アプリケーションごとに独立した仮想環境 (VE-id) を構築します。各アプリケーションは独立したルートファイルシステム、起動スクリプト、init、プロセス ID (同じ仮想環境内のプロセス ID は重複しませんが、異なる仮想環境内のプロセス ID は重複できます) を持ち、ハードウェア システム全体を排他的に使用していると認識します。仮想環境 (VE) では、オペレーティング システムやデバイス ドライバーなどのインストールが不要です。仮想マシンと比較すると、メモリとハード ディスクのオーバーヘッドが大幅に削減されます。同時に、ハードウェア命令をシミュレートする（オペレーティングシステムのシステムコールを直接呼び出す）必要がなくなり、仮想環境でのアプリケーション実行パフォーマンスはネイティブマシンに近くなります。

コンテナのカーネルサポート

コンテナベースの仮想化では、プロセスを分離したり、これを実現するのに役立つ他の目的を達成したりするために、カーネルによって提供される多くの機能を使用します。ほとんどのソリューションは Linux カーネルに基づいています。カーネルは必要な機能のほとんどを提供するため、コンテナ ツールキットでそれらを再度実装する必要は通常ありません。カーネル コードは、安定していると見なされ、すでに実稼働で使用されている他のソフトウェアによってすでに使用されています。カーネルが提供するメカニズムにセキュリティ上の問題がある場合、修正はカーネルのアップデートとともに配布されるため、コンテナ ソフトウェアにパッチを適用する必要はなく、ユーザーはカーネルを最新の状態に保つだけで済みます。

• chroot: chroot メカニズムを使用すると、プロセスとそのすべての子プロセスのルート ディレクトリを変更できます。これは、ターゲット プロセスとその子プロセスがルート フォルダー (/) として扱う単一のフォルダーへのファイル システム アクセスを制限するために使用されます (プロセスの分離は提供されません)。
• 名前空間 (IBM 提供): カーネル名前空間はプロセス分離の基礎であり、コンテナベースの仮想化を実装するための重要な概念の 1 つです。プロセス、プロセス グループ、さらには完全なサブシステム (プロセス間通信やカーネルのネットワーク サブシステムなど) を分離できます。各名前空間のプロセス ID の割り当ては独立しており、異なる名前空間のプロセスは同じプロセス ID を持つ場合があります。
• コントロール グループ (Google 提供): cgroup は、プロセスとプロセス グループ (作成された子プロセスを含む) を追跡するためのメカニズムであり、他のサブシステムがこれらの機能を拡張し、きめ細かいリソース制御と制限を実装できるようにするフックを提供します。プロセス、プロセス グループにリソースを割り当て、これらの割り当てを管理する機能により、コンテナーの使用を計画および制御できます。同様に、プロセスが特定のリソースの使用を要求した場合、他のプロセスはそれを使用できません。
• 強制アクセス制御: MAC ポリシーは、コンテナ内からのホストや他のコンテナへの攻撃を軽減するために、機密リソース (特定のコンテキストでは必要のないリソース) へのアクセスを制限するためによく使用され、コンテナ仮想化テクノロジのセキュリティが向上します。

仮想マシン技術の例 (VMWare ESXi)

VMWare は仮想マシン市場のリーダーです。VMWare の ESXi を例に挙げてみましょう。

VMkernel は、プロセスの作成と制御、シグナル、ファイル システム、プロセス、スレッドなど、オペレーティング システムと同様の機能を提供します。これは、複数の仮想マシンの実行をサポートするように特別に設計されており、リソース スケジューリング、デバイス ドライバー、入出力スタックなどのコア機能を提供します。ハードウェア デバイス上で直接実行されるため、一般的なオペレーティング システムを使用する必要はありません。

VMWareESXi の利点 (他の仮想マシン プラットフォームと比較)

• 最小限の状態情報: ESXi システムはステートレス コンピューティング ノードとして扱うことができ、すべての状態情報は保存された構成ファイルから簡単にアップロードできます。
• 優れたセキュリティ: ESXi は少量のメモリ (32 MB) のみを使用し、インターフェースも少ないため、攻撃のリスクが最小限に抑えられます。
• ハードウェア レベルの信頼性: ファームウェアに統合されると、ソフトウェアはディスクに保存されている場合よりも破損の影響を受けにくくなり、ローカル ディスク ドライブがなくなることでシステムの信頼性が向上します。

コンテナ技術の例 (Docker)

Docker イメージの例

イメージからコンテナへ（インスタンス化）

画像コンテンツ配信

コンテナ仮想化テクノロジーは、FreeBSD jail、Solaris Zones、Linux Containers (LXC) から、近年非常に人気が高まっている Docker Containers へと進化してきました。開発、テスト、本番環境の展開の効率が大幅に向上しました。 Docker コンテナ テクノロジーは通常、次の 3 つの部分を指します。

• イメージ: イメージは、アプリケーション コードとランタイム構成設定を含む静的な仕様です。コンテナの実行時の外観を指定します。これは複数の読み取り専用レイヤーで構成されており、一度作成すると変更できません (このイメージに基づいて新しいイメージを作成しない限り)。 Dockerfile を使用すると、イメージを作成するための複数のコマンドを整理できます。
• コンテナ: コンテナはイメージのインスタンス化です。実行中の各コンテナには、読み取り専用イメージに基づく書き込み可能なレイヤーがあります。コンテナの操作中に変更されるデータは、この書き込み可能なレイヤーに保存されます。コンテナが削除されると、この書き込み可能なレイヤーの内容も削除されます。 Docker-commit を使用してイメージを保存できます (別の新しいイメージを生成します)。ただし、実際のビジネス シナリオでは、これは通常必要ありません。
• Docker デーモン (または Docker エンジン): コンテナと Linux オペレーティング システムの間にある薄いレイヤーで、コンテナの永続的なランタイム環境を管理するために使用されます。このレイヤーによって根本的な違いが保護されるからこそ、Docker コンテナはどの Linux サーバーでも実行できるのです。

クラウドプラットフォーム（Google Cloud Platform、GCP）における仮想化技術の応用

Google Compute Engine (GCE) は、Google の検索エンジン、Gmail、YouTube などのサービスを実行するグ​​ローバル インフラストラクチャ上に構築された、Google Cloud Platform の Infrastructure as a Service (IaaS) コンポーネントです。 GCE を使用すると、ユーザーはオンデマンドで仮想マシン (VM) を起動できます。 VM は、標準イメージまたはユーザーが作成したカスタム イメージから起動できます。

GCE は、仮想マシンの VMM/ハイパーバイザーとして KVM を使用します。 KVM (カーネルベースの仮想マシン) は、CPU ハードウェアによって提供される仮想化テクノロジ拡張機能 (IntelVT または AMD-V) も含む完全な仮想化ソリューションであり、x86 ハードウェア上の Linux に適しています。ロード可能なカーネル モジュール (Intel の場合は kvm.ko、kvm-intel.ko、AMD の場合は kvm-amd.ko) は、コア仮想化インフラストラクチャを提供します。 KVM を使用すると、ネットワーク カード、ディスク、グラフィック アダプターなどの専用の仮想ハードウェアを備えた、変更されていない Linux または Windows ゲスト OS を含む複数の仮想マシンを実行できます。

K8s コンテナ オーケストレーション システムを介して VM 上に複数のコンテナを展開することで、一方ではプログラムをすばやく起動できます (コンテナの起動時間は仮想マシンの起動時間よりもはるかに短くなります)。 2 つ目は、仮想マシンの追加負荷を効果的に軽減できることです (複数のコンテナを展開できる一方で、展開できる仮想マシンの数は少数に抑えられます)。 3つ目は、自動アップグレード、ノード修復、コンテナの自動拡張・縮小を実現できることです。