エッジコンピューティングが早急に解決すべき問題

現在、エッジ コンピューティングはあらゆる分野から広く注目を集めており、多くのアプリケーション シナリオで成果を上げています。本稿では、エッジコンピューティング分野の特殊性を踏まえ、プログラミングモデル、ソフトウェアとハ​​ードウェアの選択、ベンチマークプログラムと標準、動的スケジューリング、垂直産業との緊密な統合、エッジノードの実装という6つの方向性が、今後数年間で緊急に解決する必要がある問題であると考えています。

[[256413]]

1. プログラミングモデル

このプログラミング モデルにより、開発者はアプリケーション製品を迅速に開発できるようになり、その結果、この分野の発展が急速に促進されます。クラウド コンピューティングのシナリオでは、ユーザー プログラムはターゲット プラットフォーム上で作成およびコンパイルされ、その後クラウド サーバー上で実行されます。インフラストラクチャはユーザーに対して透過的です。たとえば、このプログラミング モデルに基づく Amazon の Lambda コンピューティング サービスでは、サーバーを事前に構成したり管理したりすることなくコードを実行できるため、ユーザーの使用が大幅に容易になります。ただし、エッジ コンピューティング モデルとクラウド コンピューティング モデルには大きな違いがあります。機能的な観点から見ると、エッジ コンピューティングは、図 4 に示すように、弾力的な管理、共同実行、異機種環境などの特性を備えた分散コンピューティング システムです。

図 4 に示すように、エッジ コンピューティングには 3 つの重要な側面があります。

• アプリケーション/サービス機能は分割可能です。エッジ コンピューティングのタスクは、実行のために別のエッジ デバイスに移行できます。タスクの分割可能性には、タスク自体を分割すること、またはタスクをサブタスクに分割することのみが含まれます。タスクの実行は移植性を満たす必要があり、つまりタスクの移行はエッジデバイス上でのデータ処理を実現するための必要条件です。
• データを配布できます。データの分散性は、エッジ コンピューティングの特性であると同時に、処理されるデータ セットに対するエッジ コンピューティング モデルの要件でもあります。エッジ データの分散可能性とは、データ プロデューサーによって生成される大量のデータから得られるさまざまなデータ ソースを指します。
• リソースを配布できます。エッジ コンピューティング モデルのデータにはある程度の分散性があるため、データの処理に必要なコンピューティング、ストレージ、通信のリソースも分散可能である必要があります。エッジ コンピューティング システムにデータ処理とコンピューティングに必要なリソースがある場合にのみ、エッジ デバイスはデータを処理できます。

したがって、従来のプログラミング モデルはエッジ コンピューティングには適していません。エッジ コンピューティングのデバイスのほとんどは、異種コンピューティング プラットフォームです。各デバイス上の実行環境やデータは異なり、エッジデバイスのリソースは比較的限られています。エッジ コンピューティング シナリオでユーザー アプリケーションを展開するのは非常に困難です。 Li らエッジデバイスのリソース制約をターゲットにした軽量プログラミング言語 EveryLite を設計しました。この研究では、主にインターフェース呼び出しであり、時間と空間の計算量が限られているコンピューティング移行タスクにおけるコンピューティングタスクをマイクロタスクと呼びます。 EveryLite は、物理デバイス上のエッジ コンピューティング シナリオでマイクロタスクを処理できます。実験的な比較では、EveryLite の実行時間は JerryScript と Lua に比べてそれぞれ 77% と 74% 短く、コンパイル後のメモリ使用量は JerryScript と Lua に比べてそれぞれ 18.9% と 1.4% であることが示されています。したがって、エッジ コンピューティング シナリオにおけるプログラミング モデルの研究には大きな余地があり、緊急性も求められています。

2. ソフトウェアとハ​​ードウェアの選択

エッジ コンピューティング システムは、断片化と異種性が特徴です。ハードウェアレベルでは、CPU、GPU、FPGA、ASIC などさまざまなコンピューティング ユニットがあります。同じ種類のコンピューティング ユニットに基づいていても、完成したマシン製品は異なります。たとえば、NVIDIA GPU をベースにしたエッジ ハードウェア製品には、強力なコンピューティング能力を持つ DRIVE PX2 と、コンピューティング能力が弱い Jetson TX2 の両方が含まれます。ソフトウェア システムでは、ディープラーニング アプリケーション向けに、TensorFlow、Caffe、PyTorch などのさまざまなフレームワークがあります。さまざまなソフトウェアとハ​​ードウェア、およびそれらの組み合わせには独自のアプリケーション シナリオがあるため、開発者は独自のアプリケーションのニーズを満たす適切なソフトウェアおよびハードウェア製品を選択する方法がわからないという問題が発生します。

ソフトウェアとハ​​ードウェアを選択する際には、アプリケーションのコンピューティング特性を深く理解して、アプリケーションの要件を満たすコンピューティング機能を備えたハードウェア製品を見つける必要があります。また、開発に適したソフトウェア フレームワークを見つける必要もあります。同時に、ハードウェアの電力消費とコストが許容範囲内であることも考慮する必要があります。したがって、ユーザーがエッジ コンピューティング プラットフォームのパフォーマンスと電力消費を分析し、ソフトウェアとハ​​ードウェアの選択の参考となる一連のツールを設計して実装することが非常に重要です。

3. ベンチマーク手順と基準

エッジ コンピューティングの発展に伴い、学界と産業界は、さまざまなエッジ コンピューティング シナリオ向けに設計されたハードウェアまたはソフトウェア システム プラットフォームをますます多く立ち上げ始めています。そこで私たちは、これらのシステムプラットフォームを包括的かつ公正に評価する方法という緊急の課題に直面しています。従来のコンピューティング シナリオにはすべて、並列コンピューティング シナリオの PARSEC、高性能コンピューティング シナリオの HPCC、ビッグ データ コンピューティング シナリオの BigDataBench など、従来のベンチマーク セットがあります。

エッジ コンピューティングはまだ比較的新しいコンピューティング シナリオであるため、業界にはシステム パフォーマンスを評価するための権威あるベンチマークがまだありませんが、学術コミュニティでは探索的な作業が始まっています。 SD-VBS と MEVBench はどちらも、モバイル デバイスを評価するためのマシン ビジョン負荷に基づくベンチマーク テスト セットです。 SD-VBS は 28 個のマシン ビジョン コア ロードを選択し、C および Matlab 実装を提供します。 MEVBench は、特徴抽出、特徴分類、オブジェクト検出、オブジェクト追跡に関連する一連の視覚アルゴリズムを提供し、シングルスレッドおよびマルチスレッドの C++ 実装を提供します。 SLAMBench は、モバイル ロボット コンピューティング システム用に設計されたベンチマークです。評価負荷として RG&D SLAM を使用し、さまざまな異種ハードウェア向けに C++、OpenMP、OpenCL、CUDA バージョンを提供します。 CAVBench は、インテリジェント コネクテッド ビークルのエッジ コンピューティング システム向けに設計された初のベンチマーク テスト セットです。評価対象としてインテリジェントコネクテッドビークル上の代表的なアプリケーション6つを選択し、標準入力データセットとアプリケーションシステムマッチング指標を提供します。

エッジ コンピューティング シナリオの範囲が広いため、短期的には、すべてのシナリオのエッジ コンピューティング プラットフォームに適応できる統一されたベンチマーク セットは存在しません。代わりに、コンピューティング シナリオの種類ごとに従来のベンチマーク セットが用意されます。その後、ベンチマーク セットを統合して相互に借用し、エッジ コンピューティング シナリオにおけるさまざまな種類のコア負荷を調べ、最終的にエッジ コンピューティング シナリオの標準的なベンチマーク セットを形成します。

4. 動的スケジューリング

クラウド コンピューティングのシナリオでは、タスク スケジューリングの一般的な戦略は、計算負荷の高いタスクを、実行に十分なリソースを持つコンピューティング ノードに移行することです。ただし、エッジ コンピューティングのシナリオでは、エッジ デバイスによって生成された大量のデータを既存の帯域幅リソースを介してクラウド コンピューティング センターに送信して集中コンピューティングすることはできず、エッジ デバイスごとにコンピューティング機能とストレージ機能が異なります。したがって、エッジ コンピューティング システムは、タスクの種類とエッジ デバイスのコンピューティング能力に応じて動的にスケジュールする必要があります。スケジュールには 2 つのレベルがあります。

• クラウド コンピューティング センターとエッジ デバイス間のスケジューリング。
• エッジデバイス間のスケジューリング。

クラウド コンピューティング センターとエッジ デバイス間のスケジュールには、ボトムアップとトップダウンの 2 つの方法があります。ボトムアップとは、ネットワークのエッジにあるエッジ デバイスによって収集または生成されたデータの一部またはすべてを前処理して、不要なデータを除外し、伝送帯域幅を削減することを意味します。トップダウンとは、クラウド コンピューティング センターによって実行される複雑なコンピューティング タスクを分割し、エッジ デバイスに割り当てて実行することで、エッジ デバイスのコンピューティング リソースを最大限に活用し、コンピューティング システム全体のレイテンシとエネルギー消費を削減することを意味します。 2017 年、Kang らは、軽量スケジューラ Neurosurgeon を設計しました。これは、モバイル デバイスとデータ センター間でディープ ニューラル ネットワークの異なる層のコンピューティング タスクを自動的に割り当てることができ、モバイル デバイスの電力消費を最大 94.7% 削減し、システム レイテンシを最大 40.7 倍高速化し、データ センターのスループットを最大 6.7 倍向上させます。エッジ デバイス間での動的なスケジューリングも必要です。エッジ デバイスのコンピューティング機能とストレージ機能はそれぞれ異なり、時間の経過とともに変化します。また、エッジ デバイスが実行するタスクの種類も異なります。したがって、システム全体のパフォーマンスを向上させ、システム タスクで過負荷になっているデバイスにコンピューティング タスクがスケジュールされるのを防ぐために、エッジ デバイスでタスクを動的にスケジュールする必要があります。張らら遅延に敏感な社会的知覚タスクのためのエッジタスクスケジューリングフレームワーク、C〇GTAを設計しました。実験により、フレームワークがアプリケーションとエッジ デバイスのニーズを満たすことができることが示されました。

要約すると、動的スケジューリングの目的は、データ転送のオーバーヘッドを最小限に抑え、アプリケーション実行のパフォーマンスを最大化するために、アプリケーションのエッジ デバイス上のコンピューティング リソースをスケジュールすることです。スケジューラを設計する際には、タスクが分割可能でスケジュール可能かどうか、どのようなスケジューリング戦略を採用する必要があるか、どのタスクをスケジュールする必要があるかなどを考慮する必要があります。動的スケジューリングでは、エッジ デバイスのエネルギー消費、コンピューティングの遅延、送信されるデータの量、帯域幅などの指標間のバランスを見つける必要があります。現在の研究によれば、エッジデバイスタスクの実行遅延を効果的に削減する動的スケジューリング戦略をどのように設計し実装するかが、解決すべき緊急の問題です。

5. 垂直産業との緊密な協力

クラウド コンピューティングのシナリオでは、さまざまな業界のユーザーがデータをクラウド コンピューティング センターに送信し、そのデータはコンピューター担当者に引き渡されて、データの保存、管理、分析が行われます。クラウド コンピューティング センターはデータを抽象化し、ユーザーにアクセス インターフェイスを提供します。このモデルでは、コンピュータ専門家はユーザー業界から切り離されます。データ自体に重点を置いており、ユーザーの業界知識についてあまり詳しく知る必要はありません。

ただし、エッジ コンピューティングのシナリオでは、エッジ デバイスはデータ生成者に近く、垂直産業とのつながりが密接になります。エッジ コンピューティング システムの設計と実装には、多くのドメイン専門知識が必要です。一方、垂直産業では、競争力を高めるためにエッジコンピューティング技術を活用することが急務となっていますが、コンピューターの専門知識が不足しているという問題に直面しています。したがって、コンピュータの専門家は、タスクをより適切に完了し、草の根レベルで使用できるコンピューティング システムを設計するために、垂直産業と緊密に連携する必要があります。垂直産業と協力する場合、次の 3 つの問題に対処する必要があります。

• 業界標準とのギャップを減らします。さまざまな業界において、長年の経験と基準が蓄積されています。エッジ コンピューティング システムの設計では、障壁を減らすために業界標準に近づける必要があります。たとえば、自動運転車の研究では、自律運転タスクを完了するために、インテリジェントなアルゴリズム、組み込みオペレーティングシステム、オンボードコンピューティングハードウェアなど、さまざまなコンピューター分野の知識を使用する必要があります。これはコンピュータ専門家にとってのチャンスであり、多くのインターネット企業が研究にリソースを投資しています。しかし、業界標準を満たす自動車を開発したい場合、コンピューターの知識を応用するだけでは不十分です。また、自動車の電力システム、制御システムなど、自動車分野の専門知識を十分に理解している必要があります。そのためには、従来の自動車メーカーとの緊密な協力が必要です。同様に、スマート製造、産業用 IoT などの分野でも、現場に組み込まれ、業界標準を満たすエッジ コンピューティング システムを設計する必要があります。
• データ保護とアクセスのメカニズムを改善します。エッジコンピューティングでは、データプライバシー保護を実現するという前提の下、業界と連携して、統一された使いやすいデータ共有およびアクセスのメカニズムを設計する必要があります。さまざまな業界の特殊性により、病院や公安機関など、多くの業界ではパブリック クラウドにデータをアップロードしたくありません。エッジ コンピューティングの主な利点は、データがデータ生成者に近いエッジ デバイスに保存されるため、データのプライバシーが確保されることです。しかし、これによりデータ保存スペースの多様化も生じ、データの共有やアクセスに悪影響を及ぼします。従来のクラウド コンピューティングでは、データはクラウドに送信され、統合されたインターフェイスを介してアクセスされるため、ユーザーの使用が大幅に容易になります。エッジ コンピューティングでは、これを活用してデータ保護とアクセスのメカニズムを設計する必要があります。
• 相互運用性を向上させます。エッジ コンピューティング システムの設計は、業界の既存のシステムと簡単に統合でき、業界の現状を考慮して活用でき、現実とかけ離れていないものでなければなりません。例えば、ビデオ監視システムでは、近年登場したインテリジェントコンピューティング機能を備えたカメラのほか、現実には依然として多数の非インテリジェントカメラが存在し、大量のビデオデータを毎日収集してデータセンターに送信しています。学者たちは、店舗やガソリンスタンドですでに利用可能なコンピューティング機器を活用するために A3 システムを設計しました。しかし、現実にはカメラの周囲にコンピューティング デバイスはありません。したがって、エッジ コンピューティングの研究では、まず、非インテリジェント カメラの近くにエッジ コンピューティング デバイスを配置する方法を検討する必要があります。現在のソリューションでは、ほとんどの場合、処理用にさらにデータセンターや AI マシンを設置したり、さまざまな個人用戦闘装備などのモバイル デバイスを使用してデータを収集したりしています。前者は非常に高価であり、本質的には依然としてクラウド コンピューティング モデルです。後者は通常、モバイル環境で使用され、一時的なコンピューティング センターに過ぎず、クラウドと対話することはできません。ビデオ監視の分野では、Luo et al. EdgeBox ソリューションを提案しましたが、まだ議論の初期段階にあります。コンピューティング機能と通信機能の両方を備えており、カメラとデータセンターの間にミドルウェアとして挿入してデータの前処理を完了できます。したがって、垂直産業と緊密に連携して、シンクとアベイラビリティに優れたエッジコンピューティングシステムを設計し、コンピューターとさまざまな産業の間でウィンウィンの状況を実現する方法は、エッジコンピューティングが直面している緊急の課題です。

6. エッジノード着陸の問題

エッジコンピューティングの開発は業界から幅広い注目を集めています。しかし、エッジノードの実際の導入においては、エッジコンピューティングに適したビジネスモデルをどのように確立するか、エッジノードとコンピューティングに関わるエッジコンピューティングデータをどのように選択するか、エッジノードの信頼性をどのように確保するかなど、いくつかの緊急の課題も浮上しています。

1) 新しいビジネスモデル。クラウド コンピューティングのシナリオでは、クラウド コンピューティング企業はコンピューティング サービスのプロバイダーです。データの収集、保存、管理を行い、ソフトウェア、ハードウェア、インフラストラクチャの構築と保守を担当します。ユーザーはサービスに対して料金を支払うため、コンピューティング ノード自体のコストやサービス品質のアップグレード プロセスに注意を払う必要はありません。このビジネス モデルにより、ユーザーはクラウド サービスを使用する際の利便性が向上し、クラウド コンピューティング企業は収益性が向上し、サービス品質が向上します。

エッジ コンピューティングのシナリオでは、エッジ ノードはデータ生成者の近くに分散され、地理的に分離されているため、エッジ ノードの均一性を維持することが難しく、ソフトウェアとハ​​ードウェアのアップグレードも困難になります。たとえば、セキュリティ サービスを提供するカメラでは、使用中にソフトウェアとハ​​ードウェアのアップグレードが必要になります。ソフトウェアのアップグレードはインターネットを通じて一律に実行できますが、ハードウェアのアップグレードには現場訪問が必要です。各エッジノード（カメラ）のハードウェアのアップグレードとメンテナンスをサービスプロバイダーに頼ると、莫大なコストがかかりますが、サービスユーザーは一般的にハードウェア機器のメンテナンスに注意を払わなかったり、慣れていなかったりします。例えば、CDN サービスの適用においては、CDN サーバーを家庭単位で構成するか、キャンパス単位で構成するかを考慮する必要があります。設定方法が異なるとコストが変化し、サービス品質の安定性に不確実性が加わります。 CDN を維持するために必要なオーバーヘッドは、支払者がサービス プロバイダーであるかユーザーであるかを考慮する必要があります。

したがって、業界では、エッジ ノードの構築と保守の費用を誰が負担するか、ソフトウェアとハ​​ードウェアのアップグレードのプロセスを誰が主導するかなど、エッジ コンピューティング サービス プロバイダーとユーザーの責任を明確にするために、1 つ以上の新しいビジネス モデルを模索する必要があります。

2) エッジノードの選択。エッジ コンピューティングは連続体であり、エッジとはデータ ソースとクラウド コンピューティング センター間のあらゆるコンピューティング リソースとネットワーク リソースを指します。 （実際のアプリケーションでは、ユーザーはクラウドツーエンドリンク全体の任意のエッジノードを選択して、レイテンシと帯域幅を削減できます。エッジノードのコンピューティングパワーとネットワーク帯域幅の違いにより、異なるエッジノードを選択すると、コンピューティングレイテンシに大きな違いが生じます。既存のインフラストラクチャをエッジノードとして使用できます。たとえば、ハンドヘルドデバイスを使用して通信にアクセスする場合、最初にオペレーターの基地局に接続してから、バックボーンネットワークにアクセスします。既存のインフラストラクチャをエッジノードとして使用するこの方法では、レイテンシが増加します。ハンドヘルドデバイスが基地局をバイパスしてバックボーンネットワークのエッジノードに直接アクセスできる場合、レイテンシは削減されます。したがって、通信レイテンシとコンピューティングオーバーヘッドを削減するために適切なエッジノードを選択する方法が重要な問題です。このプロセスでは、既存のインフラストラクチャをエッジノードと統合する方法を検討する必要があります。エッジコンピューティングテクノロジーは、新興のエコロジカル環境を構築し、既存のインフラストラクチャに革命的な変化をもたらすでしょうか？

3) エッジデータの選択。エッジノードの数が多く、生成されるデータの量や種類も膨大です。これらのデータは互いに重複しており、問題に対して複数の解決策が存在することがよくあります。たとえば、リアルタイムの道路状況監視アプリケーションでは、車載カメラを使用してデータを取得し、信号機からのリアルタイムのデータ統計を使用し、路側コンピューティング ユニットを使用して車両速度を計算できます。したがって、特定のアプリケーションに対して異なるデータ ソースからデータを合理的に選択し、遅延と帯域幅を最小限に抑えてサービスの可用性を向上させる方法が重要な問題となります。

4) エッジノードの信頼性。エッジ コンピューティングにおけるデータ ストレージとコンピューティング タスクのほとんどは、エッジ ノードに依存しています。安定したインフラストラクチャ保護を備えたクラウド コンピューティング センターとは異なり、多くのエッジ ノードは自然環境にさらされています。エッジノードの信頼性を確保することは非常に重要です。たとえば、コンピューター ビジョンに基づく公共安全ソリューションでは、ストレージとコンピューティングにスマート カメラを利用する必要があります。ただし、極端な気象条件下では、カメラは物理的な損傷を受けやすくなります。たとえば、嵐はカメラの角度を変え、吹雪はカメラの視界範囲に影響を与えます。このようなシナリオでは、エッジ ノードの物理的な信頼性を確保するためにインフラストラクチャの協力が必要です。同時に、エッジ データには時間的および空間的な特性があり、データは非常に一意で回復不可能なものになります。エッジノードのデータ信頼性を確保するには、適切な複数のバックアップ メカニズムを設計する必要があります。したがって、エッジ コンピューティング ノードの物理的な信頼性とデータの信頼性を確保するためにインフラストラクチャをどのように使用するかが重要な研究テーマです。

エッジノードを実装する過程では、多くの試みがなされてきました。例えば、中国聯通はエッジクラウドの構築を提案し、2020年までに6,000～7,000のエッジノードを構築し、高帯域幅、低遅延、ローカライズされたサービスをネットワークのエッジに集約し、ネットワーク効率をさらに向上させ、サービス機能を強化する予定です。したがって、エッジノードの選択方法、エッジノードと既存のインフラストラクチャの関係の処理方法、エッジノードの信頼性の確保方法を検討することが非常に急務となっています。