エッジ コンピューティング ワークロード: VM、コンテナー、それともベアメタル?

私たちはコネクティビティとスマートデバイスの時代に生きています。スマートデバイスの数が増加するにつれて、データの増加は急速に新たな高みに達しています。このデータは、エンドユーザーからクラウドまたはデータセンターに到達した後に処理、保存、分析されるため、アクセス時に遅延や帯域幅の問題が必然的に発生します。 Nati Shalom がブログ記事「エッジ コンピューティングとは何か?」で述べているように、エッジ コンピューティングとは、基本的に、処理能力をネットワークのエッジ、つまりデータ ソースの近くに移すことです。これにより、組織はデータへのアクセス速度と消費される帯域幅の点で大きな利点を得ることができます。

エッジは非常に重要な役割を果たすため、エッジ ワークロードが実行されるインフラストラクチャ テクノロジを考慮することも同様に重要です。

エッジワークロード向けのテクノロジーの提供

インフラストラクチャ テクノロジーでは、物理サーバーから始まり、仮想マシン (VM) の誕生、そして最新のコンテナへと、完全なパラダイム シフトが起こっています。 VM は過去 10 年ほど素晴らしい成果を上げてきましたが、コンテナは VM よりも本質的に優れた利点を備えています。エッジ ワークロードの実行にも最適です。

次の図は、コンテナが VM と比較してどのように機能するかを示しています。

各仮想マシンは、共有ハイパーバイザー (ソフトウェアまたはファームウェア レイヤー) 上で独自のオペレーティング システムを実行し、「ハードウェア レベルの仮想化」を実現します。対照的に、コンテナは物理インフラストラクチャ上で実行され、同じカーネルを共有するため、「OS レベルの仮想化」が実現します。

この共有オペレーティング システムでは、コンテナーのサイズがメガバイト単位で維持されるため、コンテナーは非常に軽量かつ柔軟になり、VM の起動時間が数分から数秒に短縮されます。さらに、コンテナは同じオペレーティング システムを共有するため、OS 管理者の管理タスク (パッチ適用、アップグレードなど) が軽減されます。一方、コンテナの場合、カーネルの脆弱性によりホスト全体がダウンする可能性があります。しかし、攻撃者が VM カーネルに到達する前にホスト カーネルとハイパーバイザーを経由するだけであれば、VM の方が依然として優れた選択肢となります。

現在、ベアメタル機能をエッジワークロードに導入するという目標に向けて、多くの研究が進行中です。 Packet は、低遅延とローカル処理のニーズを満たす独自の提案に向けて取り組んでいる組織の一つです。

VM 上のコンテナかベアメタルか?

CenturyLink は、ベアメタルおよび仮想マシン上での Kubernetes クラスターの実行に関する興味深い調査を実施しました。このテストでは、netperf と呼ばれるオープンソース ユーティリティを使用して、両方のクラスターのネットワーク遅延を測定しました。

物理サーバーにはオーバーヘッドとしてハイパーバイザーがないため、結果は予想どおりになります。ベアメタル サーバー上で実行される Kubernetes とコンテナーは、レイテンシが大幅に低くなります。実際、VM 上で Kubernetes を実行する場合よりも 3 倍低くなります。さらに、VM 上でクラスターを実行する場合、ベアメタルと比較して CPU 消費量が大幅に増加します。

すべてのエッジワークロードをベアメタル上で実行する必要がありますか?

データベース、分析、機械学習アルゴリズム、およびその他のデータ集約型エンタープライズ アプリケーションは、ベアメタル上でコンテナを実行するのに最適ですが、VM 上でコンテナを実行することにはいくつかの利点があります。あるホストから別のホストへのワークロードの移動、問題が発生した場合の以前の構成へのロールバック、ソフトウェアのアップグレードなどの機能は、ベアメタル環境と比較して、VM にすぐに簡単に実装できます。

したがって、前述したように、軽量で起動/停止が速いコンテナはエッジ ワークロードに適しています。ベアメタルまたは VM 上で実行する場合には、常にトレードオフが存在します。

パブリッククラウドとエッジワークロード

Microsoft Azure や Amazon を含むほとんどのパブリック クラウドは、Containers as a Service (CaaS) を提供しています。 。どちらも既存のインフラストラクチャ層の上に構築され、仮想マシンをベースとしているため、エッジ コンピューティングに必要な移植性と柔軟性を実現します。

AWS はまた、クラウドのような機能をエッジに拡張し、ローカルでの情報収集と実行を可能にするソフトウェア レイヤーとして「Greengrass」をリリースしました。

どのように動作するか見てみましょう。

Greengrass グループは 2 つのコンポーネントで構成されます。 1 つ目は、AWS Lambda、メッセージング、セキュリティのローカル実行のための Greengrass コアです。 2 つ目は、ローカル ネットワーク経由で Greengrass コアと通信する IoT、SDK 対応デバイスです。 Greengrass コアがクラウドとの通信を失っても、他のローカル デバイスとの通信は維持されます。

企業での導入とそれに伴う課題

コンテナは、その速度、密度、柔軟性により、現在最も注目されているテクノロジーの 1 つです。セキュリティは、コンテナ上でエッジ ワークロードを採用する企業にとって障壁となる可能性があります。主な問題は次の 2 つです。

• サービス拒否: 1 つのアプリケーションが実行されている場合、そのアプリケーションがオペレーティング システムのリソースの大部分を消費し、他のアプリケーションが実行を継続するために必要な最小限のリソースを奪い、最終的にオペレーティング システムを強制的にシャットダウンさせる可能性があります。
• カーネルの悪用: コンテナは同じカーネルを共有するため、攻撃者がホスト オペレーティング システムにアクセスすると、ホスト上で実行されているすべてのアプリケーションにアクセスできるようになります。

今後の方向性: 最新情報

インフラ技術のさまざまな発展の中で、ニューヨークを拠点とするスタートアップ Hyper は、VM とコンテナという両方の長所を兼ね備えた技術の提供に取り組んでいます。 HyperContainers (Hyper の呼び名) により、この 2 つが融合します。コンテナのスピードと柔軟性、つまり最小限のリソースフットプリントで 1 秒未満でインスタンスを起動する機能を実現します。同時に、VM のセキュリティと分離も提供し、ハードウェアによる分離を通じてコン​​テナの共有カーネルの問題を防止します。

元のリンク:

https://enterpriseiotinsights.com/20171010/opinion/edge-computing-workloads-vms-containers-or-bare-metal-tag10