招待されていないゲスト。 仮想マシンが明日のアプリケーションに最適なソリューションではないのはなぜですか？

親愛なる読者の皆さん、こんにちは！



休日が続いているにもかかわらず、私たちは外国の技術的思考の勉強を止めず、レーダー・オライリーと時々チェックしています。 特に、5月4日にDinesh Subhravetiが発行した、仮想化の見通しと問題についての記事に興味がありました。 仮想化の適切な使用、分散システムのパフォーマンス、およびビッグデータの正しい操作の問題に触れます。 著者は、仮想マシンが非常に不可欠であるかどうか、そして明日に場所を見つけるかどうかの問題を調査しようとしています。 この巨大なトピックに何らかの形で関連する非常に上位の本が市場に出回っているので、提案された記事が有益で興味深いものに思われることを願っています。 そのような本の出版について何か提案があれば、喜んで聞いてみます。









現在、分散システムの中で最も規模が大きいのは、データセンターのオペレーティングシステムです。 そのため、HadoopはMapReduceフレームワークから、アプリケーションを水平方向にスケーリングするためのユニバーサルプラットフォームであるYARNに進化しています。



さまざまなプログラムが通常共存するこのようなプラットフォームでリッチエコシステムを機能させるには、これらのアプリケーションを適切に分離することが絶対に必要です。 分離メカニズムは、消費リソースの制限への準拠を保証し、アプリケーションとホスト間の不要なソフトウェア依存関係を排除し、セキュリティとプライバシーを保証し、障害をローカライズする必要があります。 この問題は、コンテナを使用して簡単かつ美しく解決されます。 ただし、しばしば疑問が生じます。仮想マシン（VM）を使用しないのはなぜですか？ 最終的に、これらすべてのシステムは、従来のエンタープライズアプリケーションを仮想化することで解決される同じ一連の問題に直面します。

「コンピュータサイエンスの問題は、別のレベルのインダイレクションを追加することで解決されます。もちろん、過剰なレベルのインダイレクションの問題を除きます」-David Wheeler。

なぜ仮想マシンを使用しないのですか？



YARNおよび類似のシステムは、仮想マシンを使用して実際に従来解決されてきたほぼ同じ問題に直面していますが、VMはさまざまな理由で水平スケーリングにはあまり適していません。



費用



仮想化のレベルによって消費されるリソースは、システムの全体的なコストに影響を与える重要な要因になりやすくなります。 このようなオーバーヘッドは、従来のアプリケーションでは重要な役割を果たさない場合がありますが、大規模な分散アプリケーションを扱う場合、リソースオーバーヘッドの割合はすぐに累積します。 水平方向にスケーリングされたクラスター内の各ノードで失われたホストメモリの共有は、電力を大幅に浪費します。 さらに、仮想マシンによるリソースの積極的な使用により、密な構成が防止されます。 原則として、2台の仮想マシンのみが1台の物理マシンで動作できます。

起動待ち時間が長いことは、仮想マシンのコストの主な原因です。 起動してから動作を続ける通常のアプリケーションとは異なり、非常に短期間のタスクが新しいエコシステムで実行されることがよくあります。 大規模で高度に並列化されたタスク内の典型的なタスクが数分以内に完了する場合、この時間のかなりの割合を仮想マシンの起動のみに費やすことは受け入れられません。



鉄からアプリケーション層まで、スタック全体で広範な最適化が行われていますが、仮想マシンに起因する実行時間のオーバーヘッドは依然として問題です。 ハードウェア機能により、プロセッサの仮想化のコストに対処することが可能になりますが、主に入出力に関連するワークロードの下では、コストの問題は依然として深刻です。 そのため、Hadoopの場合、仮想化されたI / Oスタックは、HDFS、ゲストファイルシステム、ゲストドライバー、仮想デバイス、イメージフォーマットインタープリター、ホストファイルシステム、ホストドライバー、最後に物理デバイスで構成されます。 累積コストは、ネイティブ実行と比較して非常に重要です。



興味深いことに、Hadoopのような仮想化された分散フレームワークで実行されたタスクのパフォーマンスを測定する実験の結果は、誤った結論につながる可能性があります。 タスクが文盲の場合、仮想インフラストラクチャでは、ネイティブの機器よりもさらに高速になることがあります。 ただし、これは、タスクの観点からのリソースのより完全な一般的な使用によるものであり、仮想化自体による個々のタスクの加速化によるものではありません。 結局、適切に調整されたタスクは、基本的な機器によって提供されるリソースの量によって最終的に制限されます。



アプリケーションハイパーバイザーのかくれんぼの再生方法



原則として、アプリケーションとオペレーティングシステムは、相互作用を期待して開発されます。 仮想化アプリケーションのコンテキストでは、ハイパーバイザーは物理ハードウェアを管理する通常のオペレーティングシステムの役割を果たします。 同時に、不透明なレベルの仮想化がアプリケーション間で発生するため、アプリケーションとOSの共生は破壊されます。 実際、ホスト、ゲストシステム、およびハイパーバイザーは、通常のオペレーティングシステムの機能のサブセットのみを実行します。 タイプAまたはタイプBハイパーバイザーが関与するかどうかはそれほど重要ではありません（たとえば、Xenの場合、Xenコアがハイパーバイザー、Dom0がホストシステム、ゲストシステムがDomUで動作します）。 Linuxでは、Linux OS自体がホストであり、Qemu / KVMはハイパーバイザーであり、これがゲストカーネルの機能を提供します。 低レベルのシステム機能を実行するプログラムのマルチレベルシステムは、既存のアプリケーションインターフェイスを暗黙的に破壊します。



仮想マシンで実行されるアプリケーションでは、基本的な物理リソースのトポロジと構成を考慮することはできません。 特定のコンポーネントは、アプリケーションに直接接続されたブロックデバイスとして「見える」場合がありますが、離れたNFSサーバーにあるファイルであることが判明する場合があります。 コンピュータおよびネットワークトポロジの難読化により、アプリケーションレベルでのリソース計画が複雑になります。 Hadoopの場合、リソースマネージャーは、物理リソースに関する誤解から生じる最適でない計画決定を行います。 タスクの場所に関するデータと情報は失われる可能性がありますが、これはそれほど悪くはありません。 メインブロックと複製ブロックは同じ障害ドメインに置かれる可能性があり、これによりデータ損失が回復不能になります。



同様に、ハイパーバイザーでは、アプリケーションを「覗く」ことはできません。 アプリケーションレベルでのセマンティクスに関する情報がない場合のリソースの大まかなアイデアでは、多くの最適化オプションを実行できません。 たとえば、ファイルから特定の設定値を読み取ることは、仮想ハードウェアレベルでブロックデバイスによって実行される読み取り操作です。 セマンティックコンテキストがなければ、プリフェッチやキャッシュなどの最適化は効果がありません。 別の例：ハイパーバイザーは、ゲストアプリケーションで使用されていない場合でも、物理メモリの広い領域を予約します-事実、ハイパーバイザーはゲストシステム内の未使用のメモリページを単に検出できません。



技術サポート



多数の仮想マシンとそれらに基づくゲストオペレーティングシステムは、面倒な技術サポートです。 仮想マシンが文字通りその場で作成および削除される広大な動的インフラストラクチャ内の個々の仮想マシンにセキュリティパッチをタイムリーに適用することは、大企業では不可能な作業です。 仮想マシンの急増は別の問題です。 さらに、ゲストOSのライセンス供与の実際のコストは、特に水平スケーリングに関しては非常に高くなる可能性があります。

アプリケーションとオペレーティングシステム間の不適切なペアリング



仮想化は、アプリケーションをハードウェアから「分離」するのに役立つと一般に受け入れられています。 ただし、仮想化により、アプリケーションとゲストオペレーティングシステムの間に新たな密接な関係が形成されます。 アプリケーションは仮想マシンの付属物として実行され、ゲストオペレーティングシステムが仮想化されたイメージのブラックボックスに埋め込まれます。 たとえば、機器を修復するために、仮想マシン全体を移行できますが、実行中のアプリケーションの機能を中断せずにオペレーティングシステムを更新することはできません。



アプリケーションは常にゲストオペレーティングシステムに関連付けられているため、アプリケーションに割り当てられたリソースをオンデマンドでスケーリングすることはできません。 最初に、リソースがゲストオペレーティングシステムに追加され、次にリソースがアプリケーションに提供されます。 ただし、通常、ゲストオペレーティングシステムは追加メモリまたは新しいカーネルを認識できるように再起動が必要です。



仮想マシン：不適切なアプリケーションの抽象化



最終的に、顧客はオペレーティングシステムや仮想マシンではなく、適切に機能するアプリケーションに関心があります。 仮想化する必要があるのはアプリケーションです。 ただし、仮想マシンはアプリケーションを直接仮想化できません。 この欠点を補うために、追加のゲストオペレーティングシステムが必要です。







仮想化には、アプリケーション仮想化のためにゲストOSを備えた追加のレイヤーが必要です

著者のイラスト。



長年の作業の過程で、産業および研究委員会は、仮想マシンに関連する問題を解決するために多くの共同の努力を捧げてきました。 数多くの革新が提案されています。 それらのいくつかは、スタンドアロン技術にまで発展しました。 しかし、慎重に調べてみると、これらの革新の多くは、コンテナと比較して進歩や定性的に新しいレベルへの移行をもたらさないことがわかりました。 このような技術の主な目的は、仮想マシン自体に起因する問題を排除することです。 原則として、産業開発の大部分は間違った方向に向けられています。アプリケーションではなく仮想マシンを最適化します。 このような根本的に誤ったモデルでは、相対的な最適化のみを実現できます。 次の例では、アプリケーションと仮想マシン間の不整合を克服するために発明された広範な技術の一部のみを説明しています。



準仮想化



準仮想化は、仮想マシンのパフォーマンスを最適化する最も一般的な方法の1つです。 ハイパーバイザーはゲストオペレーティングシステムとそのアプリケーションを直接表示することはできず、また、それらに影響を与えることもできないためです。 代わりに、彼はゲストオペレーティングシステムに依存しており、ゲストオペレーティングシステムは彼からプロンプトを受け取り、彼が規定した操作を実行します。 ゲストシステムとハイパーバイザー間のインターフェイスは、「Paravirtualization API」または「ハイパーコールインターフェイス」と呼ばれます。 もちろん、この手法は、変更されていない標準のオペレーティングシステムでは機能しません。 そのような変更を実装することは、それらをサポートするだけでなく、カーネルのバージョンの変更に適応することも簡単ではありません。



動的メモリ割り当て



オペレーティングシステムは、物理メモリを非常に慎重に管理します。 複雑な手法（遅延割り当て、記録中のコピーなど）のおかげで、絶対に必要な場合を除き、すべての場合にメモリ割り当ての要求が拒否されます。 ハイパーバイザーがオペレーティングシステムの内部コンポーネントにアクセスできないことに対処するために、「動的メモリ再配布」と呼ばれる技術が使用されます。これは「バルーニング」とも呼ばれます。 ゲストシステムでは特別なドライバーが使用されます。これにより、未使用のメモリ領域を検出し、この情報をハイパーバイザーに送信できます。 未使用のメモリページは、ゲストオペレーティングシステムから絞り出され、ホストシステムに提供されます。 残念ながら、結果は不快な副作用です。アプリケーションは、定期的に人為的なメモリ不足を経験します。 この手法は弱い解決策を可能にしますが、メモリを集中的に分散するネイティブカーネルメカニズムに比べてまだかなり劣っています。



重複排除



各仮想マシンのアドレス空間の閉じた領域で同じゲストオペレーティングシステムとその標準サービスの複数のインスタンスを使用すると、いくつかのコンテンツサンプルがメモリのいくつかのページに保存されます。 これらのコストを削減するために、「共有ページ共有」（KSM）と呼ばれるオンラインページ重複排除技術が開発されました。 ただし、特にメモリ制限が提供されておらず、NUMA（不均等なメモリアクセス）を使用した構成が使用されているホストでは、深刻なパフォーマンスオーバーヘッドが発生します。



ブラックボックスを開きます



仮想マシンは、ファイルシステムデータを、ゲストファイルシステムが解釈すべきモノリシックイメージBLOBと見なします。 インデックス作成、重複排除、基本イメージのオフライン競合パッチ適用などのために、仮想マシンの不透明なイメージ構造を明確にするためにいくつかの作業が行われました。 しかし、画像形式のすべての特性、それらに割り当てられたデバイスのセグメント、ファイルシステム、およびディスク構造の変化を考慮することは非常に難しいことがわかりました。



コンテナ：水平方向にスケーラブルなアプリケーション向けの費用対効果の高い仮想化



コンテナは、オペレーティングシステムではなく、アプリケーション自体を直接仮想化することを目的とした非常に独特な仮想化メカニズムです。 仮想マシンはオペレーティングシステムを実行できる仮想ハードウェアインターフェイスを提供しますが、コンテナはアプリケーションを実行できる仮想オペレーティングシステムインターフェイスを提供します。 仮想オペレーティングシステムの一貫したインターフェイスを通じて、エコシステムからアプリケーションを分離し、オペレーティングシステムとハードウェアの間ではなく、アプリケーションとオペレーティングシステムの間の定性的に定義され、意味的に豊富なインターフェイスを仮想化します。



コンテナは多くの名前空間で構成され、各名前空間はホスト名のサブセットを仮想名でアプリケーションに投影します。 コンピューティングリソースはプロセス名前空間によって仮想化され、ネットワークリソースはネットワーク名前空間によって仮想化され、仮想ファイルシステムはマウント名前空間によって表されます。 コンテナ化されたプロセスは、仮想化レベルの制御下でホスト上でネイティブに動作するため、コンテナ化された仮想化が適用されるサブシステムは、特定の実用的なコンテキストでの使用に適応できます。 コンテナ化されたプロセスで使用するためにホストとそのリソースが提供される範囲は、細心の精度で制御できます。 たとえば、コンテナ化されたアプリケーションは、ファイルシステムの独自のプライベートビューに制限される場合がありますが、ホストネットワークへのアクセスは許可される場合があります。







コンテナは、複数のネームスペースを使用してホストリソースのサブセットをアプリケーションに投影します。 著者のイラスト



仮想マシンでの作業とは異なり、コンテナーでの作業では、ゲストオペレーティングシステムレベルはありません。そのため、コンテナーは軽量であり、機能の重複はなく、中間レベルに関連するコストはほぼ完全になくなります。 同時に、起動時の遅延も無視できるようになり、スケーラビリティが大幅に向上し、システム管理も簡素化されます。



YARN、Mesos、Kubernetesなどのテクノロジーを使用したデータセンターの最初のバージョンがすでにあります。 これらのデータセンターで適切な分離を確保するために、コンテナがメイン基板として使用されます。 これは、新世代のイノベーション、つまり真の進歩への道を開くものです。