エッジ管理ソリューションを構築する際に考慮すべきこと

エッジでのソリューションの導入、オーケストレーション、監視に関して、エッジ アプリケーションと同様にエッジ管理についても考慮したことがありますか?残念ながら、今日のエッジ環境は携帯電話やラップトップとは異なります。エッジは、本質的に異種混合であることが多く、非常に遠隔地に配置されており、リソースの制約、セキュリティ上の懸念、さまざまな接続のバリエーションや課題があります。エッジ デバイスを管理する場合、ラップトップや携帯電話を管理する場合よりも多くの考慮事項があります。

ここでは、エッジ管理ソリューションを構築または選択して導入する際に留意すべき 10 の重要な考慮事項を示します。

エッジ管理ソリューションを構築するには、次のことが必要です。

1) エッジ ノードとその上のアプリケーション/ワークロードの管理/監視を支援します。エッジ ノードは、エッジ アプリケーションを実行するホスト コンピューティング プラットフォームです。アプリケーションを管理および監視するエッジ ソリューションだけでは不十分で、それらのアプリケーションを実行する「マシン」のステータスと状態も理解する必要があります。

2) コンテナ化されたネイティブ バイナリ ワークロードを展開する: 多くの人が、クラウド ネイティブ テクノロジーを使用して、エッジでアプリケーション ワークロードを展開およびオーケストレーションしようとしています。コンテナは優れていますが、今日のエッジは異種混合でリソースが制限されており、クラウド管理のシナリオで一般的に使用されるタイプのコンテナ ランタイムやエンタープライズ グレードのソリューションを実行できない可能性があります。エッジが薄くなると、単純なバイナリ パッケージをエッジ ノードにデプロイ/オーケストレーション/監視する必要がある場合があります。

3) 常に接続する必要があるエッジ ノードを避ける: 一部のエッジ展開では、エッジ ノードが企業に短時間だけ接続することがあります。接続が利用可能になると、費用が高くなる可能性があります。エッジ管理ソリューションは、この制限内で動作する必要があります。通信は必要な場合にのみエッジ ノードによって開始される必要があります。ノードはテレメトリを提供したり、問題を報告したり、更新を確認したりするためにホームに電話をかけます。企業がチェックインしたりステータスを取得したりするためにノードを呼び出し続ける必要はありません。

4) 回復力と耐障害性を備える: エッジではさまざまなことが発生し、エッジ ノードは接続が失われたり、切断/再接続されたり、停電やその他の予期しない再起動が発生することがよくあります。エッジ ノードは、環境的に制御され、物理的に安全なデータ センターとは異なります。エッジ管理ソリューションは、このような種類の問題を検出するだけでなく、接続、電源、またはその他のリソースが回復したときに自動的に正常な動作状態に戻すこともサポートする必要があります。

5) エッジの問題を発見するためのツールを含める: エッジで問題が発生した場合、どのように診断して解決すればよいでしょうか?同様に、エッジノードはリソースが制限されることがよくあります。エンタープライズ サーバーやデスクトップでは見つからないかもしれませんが、お気に入りのオペレーティング システム ツールと分析データは利用できます。エッジ ノードは遠隔地にあるため、たとえエッジ ノードにモニターがあっても、その前に座ることはあまりありません。エッジ管理ソリューションに、問題の診断に役立つツールとデータ フローがあることを確認します。これらの一部は、ノードがエッジ機能を実行するときに必要な通常の操作中に貴重なリソースを消費しないように、必要に応じて構成する必要があります。

6) ローカル操作 (オンプレミス) またはクラウドから: エッジ ノードは通常、バックエンドの「コントローラー」に接続する必要があります。通常、このバックエンド コントローラから、エッジへの「単一ペイン」のヒューマン マシン インターフェイスが提供されます。エッジの性質と顧客の要求により、管理ソリューションは、インターネットや他のシステムから完全に切り離されたバックエンドを運用する柔軟性を提供する必要があります。オンプレミスとクラウドのどちらで実行するかは、エッジ展開における標準的な要件です。外界と何もつながっていない工場を想像してみてください。バックエンド コントローラーはエッジ ノードに接続する必要がありますが、必ずしもインターネットに接続されておらず、クラウドで実行されているとは限りません。

7) エッジでのリソース使用率を最小限に抑えるための小型/軽量エージェントの導入: エッジ ノードは通常、リソースが限られていますが、そうでない場合でも、エッジ データの収集やエッジでのアクションを実行するためのコンピューティングの決定をサポートするには、コンピューティング、メモリ、ストレージ、ネットワークなどの貴重なエッジ ノード リソースが必要です。エッジ ノードの貴重なリソースをすべて、エッジ管理ソリューション エージェントの実行と操作に使用することはできません。エッジの管理ソリューションがエッジのアプリケーションよりも多くのリソースを消費すると、問題が発生します。

8) ヒューマン エッジを簡素化するユーザー フレンドリーなインターフェイスを提供する: エッジは大規模になる可能性があり、場合によっては、エッジ管理ソリューションで数百または数千のエッジ ノードと、これらのノード上のアプリケーションを管理する必要があります。エッジ管理ソリューションは、ループ内のオペレータにとってエッジの状況を簡素化する必要があります。たとえば、管理するノードの健全性とステータスを把握するために、各ノードをドリルダウンする必要がないようにしてください。代わりに、管理ソリューションでは、問題や標準偏差外と思われる事柄についてオペレーターに警告する方法を提供する必要があります。

もちろん、これは、同じソースに関連する特定の問題を組み合わせてフィルタリングするのに役立つユーザー インターフェイスがあることも意味します。オペレーターは、問題が何であるかを把握し、それに関連するすべてのデータを探すのではなく、問題の監視と解決に集中できます。また、オペレーターの中には独自のツールを構築したり、「何が起こっているかを確認する」ことを優先する人もいることを認識してください。したがって、エッジ管理ソリューションでは、スクリプトの作成や代替ツールの構築のための API と CLI も提供する必要があります。

9) エッジのニーズを満たすためのスケーリング: ラボでいくつかのエッジ ノードを展開して管理することは、テクノロジのデモンストレーションには最適ですが、エッジ管理がエッジの規模と距離で機能することを確認してください。エッジ展開がグローバルで、数千のエッジ ノードで構成されている場合、エッジ管理ソリューションがこの規模で困難を極めるとどうなるでしょうか?エッジ管理が失敗し、エッジ ノードにトラックを移動させることが唯一のオプションである場合、エッジ管理ソリューションはエッジ スケーリングに適切に対処していません。

10) ゼロデイ脆弱性が出現する前に支援する: エッジ ソリューションが初めて稼働する日であるゼロデイは、エッジ アプリケーションとエッジ管理ソリューションにとって重要な日です。すべてを監視し、問題を解決することは、エッジ管理ソリューションの重要な要素です。しかし、ゼロデイ脆弱性が出現するまで、エッジ管理ソリューションはどのように役立つのでしょうか?

エッジ ノード ボックスが展開場所に到着すると、エッジ管理ソリューションはどのようにしてその存在を認識するのでしょうか?これらのボックスにはオペレーティング システムとファームウェアはどのようにインストールされるのでしょうか?ところで、インフラストラクチャ ソフトウェアとエッジ管理エージェントはどのようにしてエッジ ノードに到達するのでしょうか?

エッジ ソリューションを展開するには、まず多数の技術者がボックスに触れる必要がありますか?エッジ管理ソリューションは、エッジ システムのゼロタッチ プロビジョニングに非常に近いものになりますか?適切なエッジ管理により、ゼロデイ攻撃が発生する前であっても、ソリューションの運用にかかる負担を軽減できます。これらの点を考慮したソリューションは、エッジ管理のニーズを満たすのに役立つはずです。