エッジコンピューティングの導入を成功させる4つの要素

クラウド コンピューティング テクノロジーが初めて登場したとき、それがすべてのコンピューティングを網羅するものであるという見方が一般的でした。一般的な類似点は電力網であり、これは地域の分散型発電施設を大幅に置き換えることができます。

ただし、パブリック クラウドが必ずしもオンプレミスのハードウェアを置き換えられない理由は多数あります。特にエッジ コンピューティングでは、データが収集され使用される場所にコンピューティングを近づけることが求められます。

時間的に厳しい状況でオンプレミスの運用を自動化するために機械学習がますます使用されるようになるため、これは重要になります。さらに、常に中央サイトに依存する場合と比較して、ローカルでアクションを実行すると、接続が切断された場合に、より高速になるだけでなく、より回復力も高まります。

ただし、エッジ コンピューティング アーキテクチャの実装は必ずしも簡単ではありません。企業がサービスをネットワークのエッジにプッシュする場合、次の 4 つの要素を考慮する必要があります。

1.自動化を検討する

自動化と管理は重要であり、エッジ コンピューティング デバイスの数が膨大であること、および現地に IT スタッフがいない (または常勤スタッフがいない) 可能性があるという事実から、自動化と管理が必要になります。

自動化では、ソフトウェアを使用して繰り返し可能な指示とプロセスを作成し、IT システムと人間のやり取りを減らします。これにより、IT プロビジョニング、構成管理、パッチ適用、アプリケーション オーケストレーション、セキュリティ、コンプライアンスが向上します。自動化は、多くの場合、エッジ エンドポイントに近い自動化されたワークフローと集中制御レイヤーを通じて実現されます。ローカライズされた実行により、高いレイテンシと接続の中断が防止され、集中制御によりエッジ環境の統合制御が実現します。

たとえば、小売チェーンでは、エンドポイントを自動化してインフラストラクチャの運用を効率化し、セキュリティ ポリシーを適用し、ブランチ オフィス全体でデバイス構成を標準化することができます。大規模な構成、災害復旧、ブランチの移行、特定のイベントに対応するアクションはすべて、エッジ環境で自動化が役割を果たすことができる例です。

これに密接に関連しているのは、標準的な運用環境の作成を含む管理です。これを実行することがスケーリングの鍵となります。開発から本番までの環境全体に標準化されたイメージを展開する場合は、これらのシステムをエッジ管理コンソールに登録する必要もあります。セキュリティ ポリシーを維持することも重要な管理機能です。

2. ビジネスプロセスを恣意的に構築しない

エッジ コンピューティングは、管理されていない場合は混乱状態になる可能性があります。自動化および管理システムが導入されている場合でも、エッジ環境とデータセンター環境全体で高度な一貫性を維持するには、アーキテクチャへの取り組みが依然として必要です。

一貫性が欠如している理由の 1 つは、周辺機器がデータ センター内のサーバーよりも小型で性能が低いことが多いことです。したがって、異なるソフトウェアを実行する必要があります。

しかし、必ずしもそうとは限りません。少なくともすべてがそうではありません。企業は、他の場所で実行されている小さなコア Linux OS からシステム イメージを構築し、それをカスタマイズして、ドライバー、拡張機能、ワークロードに関して必要なものを正確に追加できます。その後、イメージはユニットとしてバージョン管理、テスト、署名、展開できるため、運用チームはデバイス上で何が実行されているかを正確に把握できます。

段階的に適用されたイメージの更新は、次回の再起動時にのみ実行されるように構成することもでき、ダウンタイムを最小限に抑えることができます。アプリケーション固有のヘルスチェックに応じて更新を元に戻すことができるスマート ロールバックによって、ダウンタイムを短縮することもできます。

エッジ デバイスを含むハイブリッド クラウドでは、多くの場合、ある程度のカスタマイズが必要になりますが、通常は、必要なカスタマイズを行っても一貫したコア環境を維持することは可能です。

3. エッジでもKubernetesが必要

この一貫性は Kubernetes にも拡張されます。

「ちょっと待ってください…Kubernetes はクラウド プラットフォームとサーバー クラスター専用ではないのですか?」と思う人もいるかもしれません。必ずしもそうではありません。

まず、エッジデバイスはもはやそれほど小さくありません。たとえば、最近の調査では、企業内の上級運用管理者は、データ分析をローカルで実行できることがエッジ コンピューティングの主な利点であると述べています。

機械学習モデルのトレーニングは、通常、依然として集中化された場所で行われますが、モデル推論はますますエッジに押し進められるようになっています。これにより、分析のためにすべてのデータをローカルに送り返すために高帯域幅接続を使用する必要性が大幅に軽減されます。これは、必要なローカル アクション (マシンのシャットダウンや故障など) が、信頼性が高く高速なネットワーク リンクに依存しないことも意味します。

今日の作業負荷が比較的軽い場合でも、選択肢を残しておくことをお勧めします。おそらく、ワークロードが増加し、高可用性オプションを追加したり、信頼性の高いネットワーク リンクへの依存を減らしたりする必要があるかもしれません。

ただし、Kubernetes を採用することは、上記で説明したのと同じ理由、つまり一貫性の面でも理にかなっています。データセンターで Kubernetes を実行する場合、エッジで Kubernetes を実行すると、ソフトウェア ライフサイクル管理を標準化し、ハイブリッド クラウド環境全体で一貫性を実現できます。このため、フットプリント、可用性、ネットワーク要件が異なるさまざまなユースケースに合わせて Kubernetes を最適化するためのさまざまなプロジェクトが進行中です。

4. 助けを申し出る

現在、エッジ コンピューティングに関する情報源は数多くあります。しかし、企業がすでに実装しているパターンに基づいて完全なエッジ アーキテクチャを文書化するオープン ソースの作業について知りたいと思います。

ポートフォリオ アーキテクチャは、エッジを含むオープン ソース ソフトウェアの成功した展開を示し、アーキテクチャのベスト プラクティス、ツール、およびその他の関連リソースへのリンクを提供します。これらには、サービスとプラットフォームの高レベルの抽象化、主要なノードとサービス、それらの相互作用とネットワーク接続を記述するスキーマ、および特定のサービスの詳細な説明が含まれます。

ポートフォリオ アーキテクチャは、共通の繰り返し可能なプロセス、ビジュアル言語とツールセット、プレゼンテーション、アーキテクチャ図を使用して開発されます。ポートフォリオ アーキテクチャは、複数の展開で効果的であり、特定の共通の問題 (または問題のクラスター) を解決するテクノロジの組み合わせに重点を置いています。

検証パターンは、リファレンス アーキテクチャからの自然な進化です。

これらには、エッジ ソフトウェア スタックの構築に必要なすべてのコードが含まれているため、概念実証をより迅速に行うことができます。一般的なモデルには、データ センターと 1 つ以上のエッジ Kubernetes ベースのクラスターが含まれます。すべてのステップは GitOps によって完全に自動化され、一貫性のある大規模な自動デプロイメントが可能になります。ユーザーは特定のアプリケーションのモードを変更できます。

さらに、関心のあるユーザーは改善点を伝えることができ、複雑な分散ソフトウェア スタックの初期展開と継続的な運用に適用されるオープン ソース開発モデルの別の例が提供されます。

静的なリファレンス アーキテクチャとは異なり、検証済みのパターンは現在の製品バージョンに対して継続的にテストされるため、展開は最新の状態に保たれ、リスクを軽減しながら最新の機能を使用できます。

検証モードでは、セキュリティなど、アーキテクチャ自体の一部ではないものの、ソフトウェアの展開の一部として重要な他の側面も考慮されます。たとえば、機密性と ID 管理は、最も複雑な展開にとって非常に重要です。それにもかかわらず、重要な要素に焦点を当てるために、それらは「市場構造」や参照アーキテクチャから除外されることがよくあります。

その理由の 1 つは、エッジ コンピューティングの展開では、常に複雑で独特な乱雑な物理世界とのやり取りが必要になるためです。ただし、他の人が学んだことを活用し、自動化、管理、一貫性という基本原則を念頭に置いておけば、真のビジネス価値が得られます。