クラウドエッジコンピューティング: データセンターを越えて¶

エッジコンピューティング検討のより深い説明¶

エッジコンピューティングにおける「エッジ」とは、分散されたデータ源やエンドユーザに可能な限り近い、管理ドメインの外の領域を示します。このコンセプトは通信事業者のネットワークや、小売業のような分散した出張所を抱える大規模エンタープライズ、もしくはその他の、特に IoT の文脈で語られるアプリケーションに当てはまります。

エッジコンピューティングの特徴の一つに、アプリケーションはエッジの位置に強く結びついているということがあります。通信事業者にとって「エッジ」とは、エンドユーザーに近くありつつもプロバイダが制御できる場所を示すでしょうし、潜在的にはエンドユーザーの持つ機器上で動作するワークロードという要素も含むでしょう。大規模エンタープライズにとっては、アプリケーションやサービスまたはワークロードが利用される場所（例として小売店や工場）のことを示します。この定義の目的からいうと、 IoT やセンサー機器のように、最小のクラウドアーキテクチャをサポートするためだけに極端に能力を制限された終端機器はエッジではありません。エッジコンピューティングに絡む議論の多くが、この差異を明確にしていないため、このことは熟慮すべき事項です。

以下のような点でエッジコンピューティングは、データセンターコンピューティングと類似しています。

• エッジコンピューティングは、コンピュート、ストレージそしてネットワークといった資源を含みます。
• エッジコンピューティングの資源は、多くのユーザやアプリケーションに共有されるかもしれません。
• エッジコンピューティングの恩恵は、資源プールの仮想化や抽象化により生み出されます。
• エッジコンピューティングの恩恵は、コモディティ・ハードウェアを利用する能力により生み出されます。
• エッジコンピューティングは、相互運用性をサポートするため API を利用します。

エッジコンピューティングは、大規模データセンターのコンピューティングと次のような違いがあります。

• エッジサイトは、可能な限りエンドユーザに近づけます。これにより、高い遅延や信頼できないコネクションを克服し、ユーザ体験を改善します。
• AR/VR 機能用の GPU/FPGA プラットフォームのように、特別なハードウェアが必要かもしれません。
• エッジは、異なる位置に分散された多数のサイトへ拡張することが出来ます。
• エッジサイトの場所と、終端アクセスリンクの同一性は重要です。ユーザーの近くで実行すべきアプリケーションは、エッジの確かな場所に存在すべきです。これは、エッジコンピューティングにおけるアプリケーション配置の共通課題です。
• サイトの全体プールは動的に考慮されるべきです。サイトの物理的な隔離のため、エッジサイトは往々にして互いが接続され、またWAN接続によりコアと接続されるでしょう。エッジサイトは、インフラストラクチャプールに何度も参加したり、離脱したりするでしょう。
• エッジサイトは遠隔地にあり、潜在的に遠隔操作される可能性があります。それ故に遠隔管理されるべきです。
• エッジは、データセンターほどの大きさから1台の装置に至るまで、サイトの大きさやスケールの多様性をサポートします。
• エッジサイトは、資源の制限を受けるかもしれません。既設サイトへの容量追加は、スペースや電力の要件により制約を受けます。
• ユースケースによっては、特大の規模におけるマルチテナンシーも求められます。
• データセンタークラウドからエッジコンピューティングを隔離することは、「外部クラウド」がセキュリティ侵害を受けたときも、サービス影響を出さないことを確実にするために必要となるかもしれません。

エッジコンピューティングのコンセプトは、エッジサイト (例としてコンピュート、ネットワークやストレージのインフラストラクチャ) だけでなく、エッジサイト上で実行されるアプリケーション (ワークロード) の双方をカバーすべきです。エッジコンピューティング環境におけるどんなアプリケーションも、クラウドが提供する機能ーすなわちコンピュート、ブロックストレージ、オブジェクトストレージ、仮想ネットワーク、ベアメタルやコンテナといった機能のいくつか、あるいは全てを潜在的に利用しなければ価値がないのです。

エッジコンピューティングをクラウドコンピューティングから分別する、必要不可欠な特徴とは次のようなものです。

• 潜在的かつ後半に分散された複数のサイトの動的プールをサポートする能力
• 潜在的に信頼できないネットワークコネクション
• ネットワーク間をまたぐサイトにおいてリソース制限が解決困難となる可能性

ユースケース¶

恐らくユースケースを分類する方法はたくさんあるでしょうし、このペーパーは完全なリストを提供するには短すぎるでしょう。しかし考え方の整理を助けるいくつかの例と、コラボレーションのための重要な機会をここに掲載します。

分散アーキテクチャから利益を受ける主要な4つのワークロードは、分析、法令遵守要件、セキュリティとNFVです。

シナリオ¶

エッジコンピューティングのパラダイムにおける基本的な特徴は、インフラがエンドユーザに近いところに位置しているということであり、サイト分散の規模が大きく、エッジノードは WAN 接続されているということです。いくつかのシナリオを更に深く調査することは、ユースケースに紐付けられる現在の機能を我々が検討するのに役立ちます。それはまた、弱点を強調したり、改善の機会を得るのにも役立ちます。

1. 小売/金融/遠隔地 「箱の中のクラウド」: アプリケーションパッケージをサポートするエッジコンピューティングインフラは、特定の企業や産業向けにカスタマイズされます。企業に利用される場合には大抵、アプリケーションパッケージとエッジコンピューティングインフラは究極的に統合されて分散インフラとなります。その目的は、ハードウェアの大きさを抑え、複数拠点のデプロイメントを標準化し、エッジに位置するアプリケーションの交換作業に大きな柔軟性をもたらし (さらにハードウェアの違いにかかわらず同じアプリケーションを動作させ)、迅速に起動し、そして断続的な WAN 接続という心配事にも配慮するというものです。コンテンツをキャッシュし、あるいはコンピュートやストレージ、ネットワークを自給自足アプリケーションのために提供することは、限られた接続性という状況におけるエッジコンピュータの明らかな利用法です。

2. モバイル接続性: モバイル/無線ネットワークは、クラウドエッジコンピューティングの共通な環境要素になりそうです。モバイルネットワークは、少なくとも 5G が広く利用されるまでは、制限され予測不可能な帯域によって特徴付けられるでしょう。例えば遠隔修理や遠隔医療のための高いリアリティ、公共事業（水道、ガス、電気、設備管理）データを監視する IoT 装置、商品目録、サプライチェーンや輸送ソリューション、スマートシティ、スマートロード、そして遠隔セキュリティといったアプリケーションは、多かれ少なかれ全てモバイルネットワークに頼っています。これらのアプリケーションは全て、エッジコンピューティングのワークロードをエンドユーザに近づけるという機能に恩恵をうけることになるでしょう。

   

3. Network-as-a-Service (NaaS): 根本的に異なる環境における個別ネットワークサービスアプリケーションの提供ニーズから、NaaS のユースケースはエッジにおける分散プラットフォーム自身の小さなフットプリントと、エッジ外のサービスをサポートする信頼性に乏しく制限された WAN を管理する強力な集中管理ツールの両方が求められます。このシナリオの主要な特徴は、小さなハードウェア、移動（これに伴いネットワーク接続が変化します）と恒常的なワークロードの変化、データとアプリケーションが混在することが挙げられます。マイクロノードをサポートするインフラへのニーズは、ケースの一つです。これは非伝統的な形でパッケージされた (冷房のあるデータセンター内にある19インチラックだけではありません) 少量のコンピュータです。NaaS はエッジにある数千から数万ノードをサポートすることが求められるでしょうし、メッシュや階層型アーキテクチャのどちらか、あるいは双方を必ずサポートすることが求められるでしょう。さらに要求サイト上で必要なときに素早く起動し、終わればシャットダウンすることも求められます。API と GUI から同じデータセンター内でなく異なった場所に置かれている大規模なコンピュートノードの変更を反映する必要があるでしょう。

   

4. Universal Customer Premises Equipment (uCPE): このシナリオは、今日既に開発されていますが、アプライアンス程度の大きさをしたハードウェアのためにサポートが求められ、高可用性が求められる定常的に安定したワークロードが乗る制約付きのネットワーク接続によって性格づけられます。そして数百から数千のノードにまたがってデータとアプリケーションが混在することをサポートすることも必要ですし、既存の uCPE デプロイメントにスケールすることも新たに必要となるでしょう。

   これは特に、サービス連携アプリケーションの異なる組合せが求められる異なったサイトや、協調動作するアプリケーションの異なる組合せが求められるサイト上で稼働する NFV アプリケーションに適用できます。メッシュや階層型アーキテクチャは、断続的なネットワーク接続のためにローカライズされた機能と、データ処理の格納と転送を行う必要があります。自己修復と自己管理は、ノードの遠隔制御とともに必要となります。

5. Satellite enabled communication (SATCOM): このシナリオは、しばしばもっとも遠く厳しい条件に配布された多数の終端装置によって性格づけられます。そして同時に、とりわけ非常に高い遅延や、限られた帯域、そして衛星通信のコストを考慮する場合、ホスティングサービスのための分散プラットフォームを最適化する際に意味をなします。具体的なユースケースの例としては、船舶 (漁船からタンカーまで) や航空機、石油掘削装置、鉱山の運営や軍用基準のインフラが挙げられます。

   

チャレンジ¶

たくさんのエッジ適用例が世界中で進められている一方で、新興や既存を問わずチャレンジや制限を解決する広範な適用のために、新しい考え方が必要とされています。

私たちは、ハードウェアとアプリケーションライフサイクルをサポートするプラットフォームサービスの両面から、伝統的なデータセンター集中型クラウドと比較し、より障害許容性を持ち強固である設計をすることにより、エッジコンピューティングプラットフォームのあるべき姿を確立しました。このため私たちは、エッジのユースケースが、標準的なデータセンターインフラが行ってきたのと同様な保守サポートを持つことは当然でない様に思います。ゼロタッチプロビジョニングや自動化、全インフラとプラットフォームスタックの自律オーケストレーションは、これらのシナリオにおいて極めて重要なものです。

しかし熟慮が必要なチャレンジが更にあります。

その一つとしてエッジのリソース管理システムは、ハイレベルなメカニズムセットを提供すべきであり、その結果 WAN により相互接続される地理的に分散された IaaS インフラの運用や利用を可能にするシステムになるでしょう。言い換えればこのチャレンジは、IaaS コアサービスを前述したエッジの特徴ーネットワーク切断や帯域、コンピュートとストレージの容量制約、無人デプロイメントなどなどを実現するために変化（そして必要があれば拡張）させます。

いくつかの予測可能なニーズは次のようなものです。

• マシン/コンテナの ライフサイクル(設定、スケジューリング、デプロイメント、停止/レジューム、シャットダウン) を担当する仮想マシン/コンテナ/ベアメタルマネージャ
• テンプレートファイル (別名仮想マシンやコンテナイメージ) を担当するイメージマネージャ
• ユーザに仮想ネットワークと外部アクセスとの接続のようにインフラ接続を担当するネットワークマネージャ
• エッジアプリケーションにストレージサービスを提供するストレージマネージャ
• 分散インフラを運用し利用するためのユーザインターフェイスを提供する管理ツール

これらのニーズは比較的明らかであり、既存のプロジェクトを活用し適応させることで満たされる可能性があります。しかしエッジコンピューティングの他のニーズは、よりチャレンジングです。これだけに限ったものではありませんが、次のようなものが含まれます。

• WAN 接続越しのストレージ遅延への対処
• エッジでの強化セキュリティ—各サイトにおける物理とアプリケーションの一体的な監視、そして必要なときに自律的に有効化される修正動作
• 全ノードのリソース使用率の一斉監視
• 多くのエッジサイトとワークロードの運営と調整を行い、潜在的にコントロールプレーンのピアリングや「自己組織化するエッジ」に導くオーケストレーションツール
• エッジプラットフォームの連携 (またはクラウドの中のクラウド) のためのオーケストレーションを調査し、IaaS コアサービスに導入する必要があります。
  • 自律的なエッジへの組み込みと切り離し操作。これは初期のソフトウェアデプロイメントと資源管理がシステムコンポーネントをアップグレードするのも含みます。
  • データとワークロードの自動再配置—地理的に分散したハードウェア向けにロードバランスを行います
• 抽象的な状態伝達の同期の幾つかの形は、断続的なネットワーク接続と共に連動する「コア」のインフラにおいて必要とされます。
• 限定された接続性に起因するネットワークのパーティショニング課題を処理する新しい方法—長短どちらのネットワーク障害にも対応します。
• エッジアプリケーションのライフサイクルを管理するツール、次のようなものを含みます。
  • アプリケーションコンポーネントの遅延要件に対処するための先進的な配置制約の定義
  • 配置要件 (初期配置) を満たすためのアプリケーションのプロビジョニングとスケジューリング
  • 内部/外部のイベントに従ったデータとワークロードの再配置 (移動性のユースケースや障害、性能その他の考慮)
• 配置を意識したインテグレーション: 同じアプリケーションはすべてのエッジデプロイに同時に必要とはならないでしょう。配置と需要を意識することは必要とされるようです。
• 資源が制限され、遠隔サイトへの拡張のために機能が制限された分散ハードウェアは、マクロレベルの全体アーキテクチャ設計と運用ツールの設計の双方で熟慮が必要になります。メッシュネットワーク上の他のサイトや階層型ネットワークのコア要素からリモート資源を要求に応じて取得できるという概念は、ハードウェア導入の効率性を損なうことなく、ローカル需要の変動を満たすことができることを意味します。