学術委員の呉和全氏: エッジ コンピューティングに関する「10 の新たな疑問」

2年前のエッジコンピューティング技術サミットで、中国工程院の院士である呉和全氏はエッジコンピューティングに関する10の質問を提起し、技術の進化と産業の発展の核心的な問題に直接取り組み、業界で大きな反響を呼びました。

過去 2 年間で、エッジ コンピューティング業界は大きな進歩を遂げ、市場参加者もますます増えています。本日開催された「中国移動『5G+E』ネットワークエッジ融合技術サミット」で、呉鶴全院士が再びエッジコンピューティングについて質問した。ちょっと覗いてみましょう！

エッジはどこですか?

ユーザーに最も近いエッジが端末です。 MEC 機能は端末に展開できますが、端末を MEC とみなすのは適切ではありません。

MEC の実際の展開場所は比較的柔軟です。レイテンシを削減するためにデータ ソースへの近接性を考慮することに加えて、ビジネス アプリケーション サービスの範囲 (キャンパスなど) とビジネス アプリケーション データのローカリゼーションの必要性 (データ セキュリティを考慮) も考慮する必要があります。

モバイル通信ネットワークでは、MEC は DU、CU、または CN のエッジに配置できます。産業企業では、MEC を基地局とともに企業内に設置することができます。つまり、UPF は企業内にありながら、ネットワーク シグナリングはコア ネットワーク内で安全に認証および制御され、データは企業外に漏れません。基地局が企業内にあるかどうかに関係なく、オペレータのコア ネットワークのエッジに設置することもできます。 OTT サービス プロバイダーは、端末/データ ソースとクラウド コンピューティング センター間の任意のノードを MEC ランディング ポイントとして定義できます。これは、純粋なソフトウェア形式、またはミドルウェアが統合されたハードウェア ゲートウェイにすることができます。

2 番目の質問: マルチアクセスとは何ですか?

2016 年、ETSI は MEC の概念をモバイル エッジ コンピューティングからマルチアクセス エッジ コンピューティングに拡張し、エッジ コンピューティングを通信セルラー ネットワークから他のアクセス ネットワークにさらに拡張しました。

マルチアクセス エッジ コンピューティングのマルチアクセスは、MEC が複数のアクセス システムに同時にサービスを提供するということを強調するものではありません。また、MEC にマルチホーム機能があるという意味でもありません。マルチアクセスとは、MEC が WLAN だけでなくモバイル通信ネットワークでも動作できること、つまりアクセスの異種性に適応できることを意味します。マルチアクセスは、MEC がアクセス ネットワーク/メトロポリタン エリア ネットワーク内の複数の種類のネットワーク要素と統合できることからも理解できます。

「3つの質問」：MEC はエッジ クラウドですか?

MEC は、クラウド コンピューティングと相乗的かつ補完的な関係にあるエッジ クラウドです。クラウドコンピューティングは、全体の状況を把握し、非リアルタイムで長周期のデータの分析に重点を置き、定期的なメンテナンスなどの分野で強みを発揮できます。 MEC は地域に特化し、リアルタイムの短周期データの分析に注力しており、地域ビジネスのリアルタイムのインテリジェントな処理と実行をより適切にサポートできます。

クラウド コンピューティングは、集中的な共有サービスの概念です。現状では、MEC サービス端末やアプリケーションがあまり多くないと、集約度が足りません。さらに、クラウド コンピューティングの DaaS、KaaS、PaaS、SaaS はすべて MEC で構成する必要がありますか?

「4つの質問」MEC、CDN、DCの類似点と相違点は何ですか?

従来の CDN は、キャッシュ配信サービスを中心とした I/O 集約型システムです。その主な機能は、ホットなコンテンツを近くで配信すること、つまり「配信を加速する」ことです。 MEC は「加速」する必要があるだけでなく、オープン API 機能やローカライズされたコンピューティングおよびストレージ機能も備えており、ある程度のインテリジェンスも備えています。したがって、MEC は、ワイヤレス ネットワークのエッジに近いマイクロ CDN 機能と見なすことができます。

現在、一部の CDN は単なるホット コンテンツ キャッシュではなく、コンテナー サービス、VM サービス、ベア メタル サービス、サーバーレス機能の組み合わせも提供しており、クラウド サービス プロバイダーのような存在になっています。この観点から見ると、CDN と MEC の境界は曖昧になりますが、データ ソースに対する相対的な位置から見ると、CDN はフォグ コンピューティングに似ています。

MEC には、仮想化されたネットワーク、ストレージ、コンピューティング リソースなどの IaaS 機能があります。 MEC には一定のデータセンター (DC) 機能があることはわかりますが、エネルギー効率の観点から DC は大容量である必要があります。したがって、MEC の主な機能はマイクロ DC になることではありません。

「5つの質問」：MEC は何を計算するのでしょうか?

ETSI の MEC 機能図から判断すると、MEC には IaaS と PaaS の機能、つまりクラウド コンピューティングの主な機能がありますが、それよりも重要なのは、MEC 機能を仮想アプリケーション (ローカル転送、ワイヤレス キャッシング、AR/VR テクノロジ、ビジネス最適化、ポジショニングなどのアプリケーション) にカプセル化し、サードパーティに公開することです。現在のフレームワークは、クラウド ネットワーク機能とのやり取りによって補完される必要があります。

「6 つの質問」MEC はどのようにしてサービスと構成を検出するのでしょうか?

サービス レジストリは、MEC サーバーで利用可能なサービスに対する可視性を提供します。サービスの疎結合の概念を使用して、アプリケーションの展開に柔軟性を提供します。

従来の DNS ベースのサービス検出メカニズムは、主にサービスが静的であるか、サービス アドレスがゆっくりと変化するシナリオを対象としています。サービスが変更されると、DNS サーバーは通常、ドメイン名サービスの同期を完了するのに一定の時間がかかります。これは、大規模で動的な MEC シナリオには適していません。

IoV シナリオでは、ユーザーとコンピューティング デバイスは動的に登録および取り消され、通常はそれに応じてサービスを移行する必要があり、大量のバースト トラフィックが発生します。 WAN の帯域幅は動的に適応できない可能性があります。デバイス層からのサービスの迅速な構成をどのようにサポートするか?

エッジデバイスは大量のデータを生成し、エッジサーバーは多数のサービスを提供します。エッジ サーバーとネットワークの状態に基づいて、適切なコンピューティング サービス プロバイダーにデータを動的に送信するにはどうすればよいでしょうか?

「7つの質問」MECの事業計画はどこから生まれるのか？

迅速に応答するためには、MEC はデータ ソースの近くに配置されるだけでなく、シンプルである必要があります。このため、MEC には小さなデータ処理機能しかありません。数学モデルや AI アルゴリズムには、グローバルかつ長期にわたるビッグデータのトレーニングが必要ですが、これは MEC の得意分野ではありません。そのため、MEC は外部からモデルやルールを取得する必要があります。同時に、MEC ではモデルのスリム化とモデル機能を特定のサブドメインに制限する必要があります。

現在、クラウドと IoT デバイスを接続するオープンソースの開発フレームワークを提供している企業もあり、デバイス側や MEC 上で機械学習機能を備えたアプリケーションを直接開発することが可能になっています。たとえば、Microsoft は Azure ioT Edge Runtime をオープンソース化しており、DJI はこのフレームワークを使用してドローンのローカル画像認識機能を実装しています。 Qualcomm もこのプラットフォームを使用して、モバイル端末デバイス上に画像処理機能を迅速に構築しています。

「8つの質問」クラウドでコンピューティングパワーを構成するにはどうすればいいですか?

ターミナルコンピューティングタスクはクラウドに移行されます。 5G伝送の助けにより、端末はコアソフトウェアをダウンロードしてインストールする必要がなく、ハードウェア要件とコストが削減され、プラグアンドプレイでスムーズな体験が提供されます。モノのインターネットで認識されたデータは、5Gの低遅延を通じてクラウドに直接アップロードされ、IoTとAIがシームレスに統合され、AI+IOT=AlOT（インテリジェントなモノのインターネット）が実現します。

クラウドコンピューティングの機能は、エッジコンピューティングと端末に転用されます。インダストリアル インターネットのエッジ コンピューティングは、ワークショップまたはブランチに構築されます。 IoTモジュールにはAIチップとオペレーティングシステムが組み込まれており、これはIoT端末にエッジコンピューティング機能を組み込むことと同等です。

クラウドエッジデバイスのコンピューティング機能をどのように調整できるかについての9つの質問

MEC は接続され、調整される必要があります。同じ中央クラウドによって管理される複数の MEC が不均一にビジー状態になる可能性があります。アイドル状態の MEC の機能を利用して、ビジー状態の MEC をサポートすることはできますか? MEC 間でストレージおよびコンピューティング リソースを連携するのは簡単ではありません。中央クラウドと MEC は、データの収集とモデルの送信だけでなく、大規模な MEC のリソース管理機能も中央クラウドに必要とします。

ローカル災害が発生した場合にデータが失われないようにするには、MEC を安全なリモート ロケーションまたは中央クラウドに定期的にバックアップする必要があります。さらに、MEC の課金およびセキュリティ管理も、中央クラウド管理の範囲に含める必要がある場合があります。

「10の質問」：MECには決まったパターンがありますか？

MEC の配置は柔軟であり、CDN やマイクロ DC の機能も含め、端末内に配置できるほど小型の MEC の機能も柔軟に実現できます。重要なのは、スリム化に留意しながら MEC の機能を強化することです。そうしないと、コストが制御不能になってしまいます。

多くのシナリオでは、MEC は別個の物理的な存在ではなく、関連するデバイスに統合され、アプリケーション層ソフトウェアの形式で表示されることがあります。 MEC がコンピューティングパワーを表すのであれば、コンピューティングは将来間違いなく遍在するようになり、それは MEC が将来目に見えなくなることを意味します。

通信ネットワークの機能の集中と分散は常に繰り返されています。集中と分散の両方ができればベストです。稀なのは機能の最適な割り当てですが、これを実現するのは非常に困難です。

エッジコンピューティングには現時点で決まったパターンがないとも言えますが、だからこそイノベーションの余地が大きいとも言えます。