クラウド コンピューティング アーキテクチャにエッジ コンピューティングを追加することの長所と短所

エッジ コンピューティングは、すべての IoT デバイスやワークロードに適しているわけではありません。エッジ コンピューティングの例をいくつか見て、いつ、どこでそれをクラウド コンピューティング アーキテクチャの一部として検討すべきかを理解することが重要です。

[[330888]]

エッジ コンピューティングは、従来のクラウド コンピューティング アーキテクチャに比べてパフォーマンス、セキュリティ、コスト面で優れているため、ますます人気が高まっていますが、分散ワークロードに必ずしも最適であるとは限りません。

エッジ コンピューティングとは、エンド ユーザーのコンピューター、携帯電話、IoT センサーなど、データを生成および消費するデバイス上またはその近くでデータを処理するアーキテクチャを指します。これは、中央サーバーに依存してデータを受信、処理し、クライアント デバイスに送り返す従来のクラウド コンピューティングとは異なります。エッジ コンピューティングは、ネットワークの遅延を減らし、ネットワーク上のデータの露出を減らし、場合によっては処理をエンド ユーザーのデバイスにオフロードすることでコストを削減できます。

魅力的なメリットがあるため、クラウド アーキテクトは、できるだけ多くのワークロードをエッジ コンピューティングにプッシュしたいと考えるかもしれません。ただし、そうする前に、各アプリケーションの構造、パフォーマンス要件、セキュリティ上の考慮事項などの要素を考慮する必要があります。

2種類のエッジコンピューティングアーキテクチャ

エッジ コンピューティング モデルが適切かどうかを検討する場合、最初に尋ねるべき質問は、どのようなアーキテクチャが利用可能かということです。主に2つのタイプがあります:

• デバイス エッジ コンピューティングでは、データがクライアント デバイス上で直接処理されます。
• クラウド エッジ コンピューティングでは、集中型クラウド コンピューティング データ センターよりもクライアント デバイスに地理的に近いエッジ コンピューティング ハードウェアでデータが処理されます。

デバイス エッジ コンピューティング モデルは、クライアント デバイスがこの処理負荷を均一な方法で処理できる場合にうまく機能します。デスクトップ コンピューターやラップトップ コンピューターであればこれを処理できますが、低電力 IoT センサーでは、データを効率的に処理するために必要なコンピューティング リソースとストレージ リソースが不足している可能性があります。

さらに、企業がさまざまな種類のエッジ デバイスとオペレーティング システムに依存しており、それらの機能や構成が異なる場合、デバイス エッジ コンピューティング モデルの使用は困難になる可能性があります。

クラウド エッジ コンピューティング モデルでは、エンドユーザー デバイスはアーキテクチャを形成する主な要素ではありません。企業がクラウド エッジ コンピューティング アーキテクチャを使用する場合、データの保存や処理が中央クラウドからそれらのデバイスに移動されないため、エンド ユーザーが使用するデバイスの種類は問題になりません。代わりに、企業はクラウド コンピューティング、つまりエッジ コンピューティングで実行されているサーバーに負荷を移す必要があります。これらのサーバーは通常、中央クラウドよりもエンドユーザーに近いデータセンターに配置されます。

エッジコンピューティングの限界

企業がワークロードをエッジ コンピューティングに移行することを決定する前に、これらのエッジ コンピューティング モデルをサポートすることが合理的かどうかを評価する必要があります。これらの制限により、企業は従来のクラウド コンピューティング アーキテクチャに戻らざるを得なくなる可能性があります。

エッジセキュリティ

エッジ コンピューティングは、データ転送時間を大幅に短縮することでセキュリティ リスクを軽減しますが、より複雑なセキュリティ上の課題ももたらします。

たとえば、企業が管理していないエンドユーザーのデバイスにデータを保存または処理する場合、それらのデバイスがサイバー攻撃者に悪用される可能性のある脆弱性に対して脆弱ではないことを保証するのは困難です。クラウド エッジ コンピューティング モデルを使用してエッジ コンピューティング インフラストラクチャの制御を維持する場合でも、管理するインフラストラクチャが増えると攻撃対象領域が増加します。

多くの場合、処理中のデータを保護するよりも、ネットワーク経由で転送中のデータ（暗号化可能）を保護する方がはるかに簡単です。したがって、エッジ コンピューティングのセキュリティ上の欠点がその利点を上回る可能性があります。

このため、エッジ コンピューティングは、セキュリティ仕様が高いワークロードには適していません。企業が機密データを扱っている場合や、特別なコンプライアンス要件がある場合は、集中型サーバーを備えた標準的なクラウド コンピューティング モデルの方がリスクが低い可能性があります。

遅延要件

エッジ コンピューティングでは、データを処理するためにクラウド コンピューティング データ センターとやり取りする必要がないため、アプリケーションのパフォーマンスと応答性が向上します。これは、真に瞬時の通信フローを必要とするワークロードにとって重要な利点となります。クラウド コンピューティング プロバイダーはデータ センターの拠点を増やし続けていますが、その大規模な施設は人口密集地から遠く離れた遠隔地に設置されていることがよくあります。

ほとんどのワークロードでは、レイテンシ基準が低くなります。従来のクラウド コンピューティング アーキテクチャと比較すると、エッジ コンピューティング ネットワークでは、ネットワーク応答速度が数ミリ秒しか向上しない可能性があります。標準的なアプリケーションの場合、従来のアーキテクチャによって発生するネットワーク遅延は許容範囲内です。また、コストと管理の負担の増加を考慮した後、レイテンシの改善がトレードオフに見合う価値があることを確認します。

データ量

ワークロードに必要なデータの量と、エッジ コンピューティング インフラストラクチャがそれを効果的に処理できるかどうかを検討します。ワークロードで大量のデータが生成される場合、そのデータを分析して保存するための大規模なインフラストラクチャが必要になります。管理の観点から見ると、パブリック クラウド データ センターにデータを移動する方がコストが安く、簡単になる場合があります。

一方、ワークロードが大部分がステートレスであり、大量のデータを伴わない場合、エッジ コンピューティングに最適な候補となる傾向があります。

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

上記のトレードオフを説明するために、エッジ コンピューティングが適している場合と適していない場合の例をいくつか示します。

エッジ コンピューティングの導入の良い例は次のとおりです。

• 自動運転車。自動運転車は膨大な量のデータを収集し、道路上または道路付近にいる乗客やその他の人々の安全を確保するためにリアルタイムで判断を下す必要があります。遅延の問題により、自動運転車の応答時間が数ミリ秒遅れる可能性があり、深刻な結果を招く可能性があります。
• スマートサーモスタット。これらのデバイスによって生成されるデータは比較的小さいです。さらに、人々が帰宅して室温を調整する時間など、収集されるデータの一部はプライバシーに影響を与える可能性があります。データをエッジに保持することは実用的であり、セキュリティ上の懸念を軽減するのに役立ちます。
• 信号機。信号機には、エッジ コンピューティングに適した 3 つの特性があります。変化する需要にリアルタイムで対応します。データ出力が比較的低い。また、インターネット接続が時々失われます。

エッジ コンピューティングがうまく機能しない例をいくつか示します。

• 一般的なアプリケーション。エッジ コンピューティング インフラストラクチャのパフォーマンスや応答性を必要とする通常のアプリケーションを思いつくのは困難です。アプリケーションの読み込みやリクエストへの応答にかかる時間は短縮されるかもしれませんが、その改善はコスト増加に見合うものではありません。
• 監視カメラシステム。監視ビデオは通常、大量のデータを生成します。エッジでデータを処理して保存することは、大規模で特殊なインフラストラクチャが必要になるため、現実的ではありません。集中型のクラウド コンピューティング施設にデータを保存する方がはるかに安価で簡単になります。
• インテリジェントな照明システム。ユーザーがインターネット経由で自宅やオフィスの照明を制御できるシステムは、大量のデータを生成しません。しかし、スマート照明システムは、処理能力が最小限で、超低遅延の要件がない傾向があるため、照明をオンにするのに 1 秒か 2 秒かかっても、大した問題ではありません。ユーザーはこれらのシステムを管理するためにエッジ インフラストラクチャを構築できますが、ほとんどの場合、追加コストをかける価値はありません。