分散型から真のエッジへ: エッジ コンピューティングの 4 つの例

すべてのアプリケーションがエッジ コンピューティング用に構築されているわけではありません。実際、今日ではエッジ コンピューティングの採用がかなり限られていることを考えると、今日のほとんどのアプリケーションはエッジ コンピューティングの候補ではないと言っても過言ではありません。

たとえば、多くの種類の分散型企業施設は、個人の生産性向上ツールから在庫管理や小売管理に至るまでのさまざまなアプリケーションへのアクセスに依存しています。これらのアプリケーションがオフプレミスでホストされており、ネットワーク接続に障害が発生すると、従業員と顧客が切断され、収益が失われ、製品と施設の制御が失われる可能性があります。

ほとんどの企業は、デスクトップ コンピューターをエッジ システムと見なさないのと同じように、上記のシナリオをエッジ コンピューティング アプリケーションと見なしません。対照的に、保護的なローカル処理は分散コンピューティングの範疇に入ります。エッジ アプリケーションとして扱うと、コスト、開発の複雑さ、製品選択のプレッシャーが増大する可能性があります。

では、エッジ コンピューティングは実際にはどのようなものなのでしょうか?企業ではどのような用途があるのでしょうか?エッジ コンピューティングの実際の使用例が出現するにつれて、最も先進的な例では、エッジ アズ ア サービス クラウド オファリングだけでなく、分散コンピューティングから真のエッジへの移行も強調されています。

エッジコンピューティングの4つの例

エッジ コンピューティングがどこで役立つかを理解するための最良の方法は、エッジ コンピューティング アプリケーションの進化を反映する実際の例をいくつか選択することです。

1. 販売時点

一見すると、販売時点は保護されたローカル処理の範囲内にあるように見えます。ただし、販売時点では微妙な違いがあります。アプリケーションの遅延が従業員や顧客の行動に影響を及ぼす可能性があります。

レジ係や顧客が商品のバーコードをスキャンすると、通常は音声、画面上の商品の説明、またはその両方による肯定的なフィードバックが期待されます。このリモート サイトのアクティビティには潜在的なレイテンシ制約がありますが、自動化された製造アプリケーションほど厳密ではありません。

したがって、POS は分散コンピューティングとエッジ コンピューティングの組み合わせです。アプリケーションにリモート コンピューティング リソースを使用すると、データ センターの接続性やリソースの混雑によりレイテンシの問題が発生する可能性がありますが、ローカル アプリケーションでは、レイテンシをさらに管理するために特別なテクニックが必要になることはほとんどありません。ただし、スキャンの失敗は小売業の損失につながる可能性があるため、開発者はスキャン応答時間の制限を慎重に確認する必要があります。

2. 倉庫保管

このエッジ コンピューティングの例は、分散エッジの境界の反対側、つまり手動と自動の商品移動と会計を組み合わせた倉庫アプリケーションです。

これらのアプリケーションでは、トラックが施設に到着したり施設から出発したりし、作業員がこれらのトラックに商品を出し入れします。貨物は在庫から引き落とされたり、在庫に追加され、トラック輸送在庫にリンクされたり、リンク解除されたりします。商品自体はパッケージ化され、バーコードが付けられており、商品が棚やコンベアベルト上を移動すると、スキャナーがバーコードを記録し、商品の移動を示すモデルを作成するのに役立ちます。

活動のペースは速く、人間と自動化された施設の間で動きを調整する必要があるため、停止して失われた情報を回復することは不可能であり、システムが追いつくことができません。多くの場合、自動荷物処理では、荷物が流れていく途中で新しいルートに荷物を転送するため、遅延が発生すると間違った荷物が配達される可能性があります。

従来のローカル在庫プロセスは機能していますが、自動化されたプロセスも機能しています。さらに、レイテンシ管理も非常に重要です。これにより、エッジ コンピューティング アプリケーションのウェアハウスは、ローカル コントローラーとサーバー リソースによってサポートされる可能性が最も高くなります。したがって、開発者はこれを組み込み制御アプリケーションとして検討する必要があります。

3. 多機能輸送

輸送におけるエッジ コンピューティングの例としては、道路、鉄道、航空会社、海運会社などが挙げられます。多用途トランスポートでは、内部エッジホスト型アプリケーションをエッジ サービス アプリケーションに変換できる問題が明らかになります。

配送アプリケーションでは、コンテンツと配送の両方が重要です。バーコード、QR コード、RFID は、積み込みや積み下ろし中、あるいは移動中でもセンサーが読み取ることができるため、あらゆる種類のオブジェクトを識別できます。センサーを搭載したテレメトリ デバイスは、温度や GPS 位置などの追加の詳細を提供できます。

これらのメトリックを読み取るための通常のアプリケーション構造は、多くのポイントでデータを収集し、それをオンプレミスに送信することです。これは、エッジ/クラウドまたはエッジ/データセンター アプリケーションに最適なモデルです。輸送アプリケーションでは、重要なポイントでセンサー データをバッチで取得するのが自然なため、データが失われないようにし、問題を迅速に分析できるようにするために、レイテンシ管理が重要です。

現在、さまざまな施設関連デバイスがこのユースケースのアプリケーションをサポートしていますが、モバイル サービス (5G を含む) の使用の増加もエッジ マネージド サービスへの関心を高めています。センサー レポートの同じバッチ特性により、輸送アプリケーションは使用の点で散発的になる傾向があり、エッジ ホスティングによるサポートに適しています。

4. スマートシティ

ある意味では、この最後の例は残りの例の合計です。スマート シティは確かに都市であるかもしれませんが、学校のキャンパス、スタジアム、さらには戦場である可能性もあります。スマート シティは多様性と予測不可能性の組み合わせを特徴としており、多くの場合、問題が発生すると財産や生命が危険にさらされる可能性があります。

スマートシティは世界が広いことを示しています。基本的に、アプリケーション レベルで処理するには、相互依存するシステムに分割する必要があります。これらはそれぞれ、より広い視点からのライブ コンポーネントであるため、それぞれがローカル イベントを処理し、より広いシステムに継続的にイベントを提供します。各レベルでの操作のイベント中心の性質は、低レイテンシのローカル処理を意味し、システム全体の同期は、イベントの一貫性のある迅速な移動に依存します。

個別に考えると、スマート シティの一部の要素は、分散コンピューティングの他のエッジ ユース ケースと見なすことができます。スマート シティ環境では、店舗の前を通りかかる買い物客にオファーを知らせるために、保護的なローカル処理であっても、システムとリアルタイムで統合する必要がある場合があります。これには価格と在庫に関する知識が必要です。都市（または都市のような施設の集合）がよりスマートになるほど、その集合のシステム要素はよりリアルタイムかつエッジ中心になる必要があります。