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

現在、エッジコンピューティングはあらゆる分野から広く注目を集めており、多くのアプリケーションシナリオで成果を上げています。本稿では、エッジコンピューティング分野の特殊性を踏まえ、プログラミングモデル、ソフトウェアとハードウェアの選択、ベンチマークプログラムと標準、動的スケジューリング、垂直産業との緊密な統合、エッジノードの実装という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のエッジノードを構築し、高帯域幅、低遅延、ローカライズされたサービスをネットワークのエッジに集約し、ネットワーク効率をさらに向上させ、サービス機能を強化する予定です。したがって、エッジノードの選択方法、エッジノードと既存のインフラストラクチャの関係の処理方法、エッジノードの信頼性の確保方法を検討することが非常に急務となっています。

<<: クラウドバーストの定義と応用

>>: 60 個の DevOps「武器」、どれを使っていますか?