センターからエッジへ: クラウドネイティブエッジコンピューティングの問題点の詳細な分析

クラウドコンピューティングの発展の歴史は、仮想化技術の発展の歴史でもあります。過去 20 年間、クラウドコンピューティングとインターネットは互いの急速な発展を促進し、中心的なクラウドテクノロジーは社会全体の共通インフラストラクチャになりました。モノのインターネットや人工知能などの技術の継続的な発展、特に産業用インターネットの開発と実装により、集中型クラウドコンピューティングは比較にならないほど衰退し始め、分散型エッジコンピューティングが再び重視されるようになりました。中央クラウドコンピューティングが技術革新によって推進されるのであれば、エッジコンピューティングはビジネス価値によって推進される必要があります。

では、エッジコンピューティングとは一体何でしょうか?エッジコンピューティングのカテゴリは何ですか?エッジコンピューティングと中央クラウドの関係は何ですか?この記事では、その謎を解き明かし、エッジコンピューティングとクラウドネイティブの理解と考え方を詳しく説明します。

1. エッジコンピューティングの理解と考え方

1. エッジコンピューティングの定義

現在、エッジコンピューティングの正確な定義はありません。 IT クラウドコンピューティングの観点から見ると、エッジコンピューティングは中央クラウドコンピューティングの拡張として見られます。 Edge Computing Industry Alliance は、エッジコンピューティングを「オブジェクトまたはデータのソースに近いネットワークのエッジでネットワーク、コンピューティング、ストレージ、およびアプリケーションのコア機能を統合し、俊敏な接続、リアルタイムビジネス、データ最適化、アプリケーションインテリジェンス、セキュリティとプライバシー保護など、業界のデジタル化の主要なニーズを満たすために、エッジインテリジェントサービスを近くで提供するオープンプラットフォーム」と定義しています。 CT 通信の観点から見ると、エッジコンピューティングはもともとモバイルエッジコンピューティング (MEC) とも呼ばれていました。欧州電気通信標準化機構 (ETSI) は、MEC を次のように定義しています。「モバイルエッジコンピューティングは、モバイルネットワークのエッジ、無線アクセスネットワーク (RAN) 内、モバイルユーザーの近くで IT サービス環境とクラウドコンピューティング機能を提供します。」

エッジコンピューティングの定義はさまざまですが、中核となる考え方は基本的に同じです。エッジコンピューティングは、クラウドコンピューティングのコアテクノロジーに基づき、エッジインフラストラクチャ上に構築された新しい形式の分散コンピューティングです。エッジのエンドユーザーに近いコンピューティング能力を提供し、データソースに近いオンサイトクラウドコンピューティングです。

強力なデータセンターを備えた中央クラウドコンピューティングは、ビジネスアプリケーション向けに大規模にプールされ、柔軟にスケーラブルなコンピューティング、ストレージ、ネットワーク、およびその他のインフラストラクチャサービスを提供します。これは、非リアルタイムで長期サイクルのデータやビジネス上の意思決定のシナリオに適しています。エッジコンピューティングは、リアルタイムの短周期データ、ローカル意思決定、および現在人気のオーディオおよびビデオライブブロードキャスト、IoT、産業用インターネット、仮想現実、さらにはメタバースなどのビジネスシナリオに重点を置いており、ワークロードを端末デバイスの近くまたはエンドユーザーの近くにシンクすることで、ネットワーク遅延を短縮し、ユーザーエクスペリエンスを向上させます。

2. タコ型エッジコンピューティング

エッジコンピューティングは、集中型コンピューティングに対する分散型コンピューティングです。エッジコンピューティングの中心的な目標は、迅速な意思決定を行い、中央クラウドのコンピューティング能力を「ラストマイル」まで拡張することです。したがって、中央クラウドから独立することはできませんが、クラウド-エッジ-エンドの全体的なアーキテクチャの下で、集中制御の決定と分散エッジの自律的な決定、つまりタコ型のエッジコンピューティングの両方を備えています。

上の漫画に示すように、タコの体のニューロンの40％は中枢脳に集中しており、残りの60％は脚に分散しており、全体の制御と調整のための1つの脳+分散実行のためのN個の小脳という構造を形成しています。 1 つの脳は、グローバルスケジューリングと、非リアルタイムの長期サイクルのビッグデータ処理および分析に優れています。 N 小脳は、局所的な小規模データ処理に重点を置いており、現場レベルのリアルタイムの短サイクルのインテリジェント分析と迅速な意思決定に適しています。

Octopus スタイルのエッジコンピューティングは、中央クラウド + エッジコンピューティングの分散クラウドエッジ統合アーキテクチャを採用しています。大規模な端末がデータを収集した後、小規模なローカルデータのリアルタイムの意思決定処理はエッジで完了し、複雑で大規模なグローバル意思決定処理は中央クラウドにまとめられ、詳細な分析と処理が行われます。

3. エッジコンピューティングの場所

エッジコンピューティングは、中央クラウドと端末の間に位置し、クラウドコンピューティング機能を中央からエッジに落とし込み、クラウドエッジ連携アーキテクチャを通じて特定のビジネスニーズを解決し、伝送遅延を最小限に抑えます。これもエッジコンピューティングのコア価値です。ただし、中央クラウドと端末間のネットワーク伝送経路は、アクセスネットワーク (距離 30 キロメートル、遅延 5 ～ 10 ミリ秒)、集約ネットワーク、都市間ネットワーク (距離 50 ～ 100 キロメートル、遅延 15 ～ 30 ミリ秒)、バックボーンネットワーク (距離 200 キロメートル、遅延 50 ミリ秒) を経由して、最終的にデータセンターに到達します (データセンター IDC がバックボーンネットワーク上にあると仮定)。時間消費データは、通常のネットワーク輻輳のダイヤルアップ統計、つまりビジネス側で認識される実際の遅延データです。あまり正確ではありませんが、アーキテクチャ上の決定を支援するには十分です。

クラウドコンピューティング機能は徐々にセンターからエッジへと移行しており、ノード数は増加し、カバレッジは縮小し、運用および保守サービスのコストは急速に増加しています。国内ネットワークの現状（中国には中国電信のCHINANETとCN2、中国聯通のCNCNET、中国移動のCMNETなど複数のバックボーンネットワークがある）によれば、バックボーンネットワークノード、都市間ネットワークノード、集約ネットワークノード、アクセスネットワークノード、数万のビジネスサイトコンピューティングノードはすべてエッジコンピューティングを搭載できる。したがって、統一された標準を形成するには範囲が広すぎます。したがって、中央クラウドコンピューティングはテクノロジによって定義され、エッジコンピューティングはネットワークとビジネスニーズによって定義されると言えます。

エッジコンピューティングエコシステムには、3 つの主要サービスプロバイダー、クラウドベンダー、機器メーカー、オペレーター、およびいくつかの新しい AI サービスプロバイダーなど、多くの参加者がおり、いずれも既存の優位性を活かして、より多くの顧客と市場スペースを拡大しています。機器ベンダーは、モノのインターネットを使用して、単一機能のプロフェッショナルクラウドを徐々に構築します。クラウドベンダーは集中型のパブリッククラウドから分散型の地域クラウドへと移行し始めており、地域クラウドはクラウドネットワークを通じて接続され、より広範囲に及ぶクラウドを形成しています。インターネット時代、オペレータはパブリッククラウドと繁栄するモバイルアプリケーションによって完全にブロックされ、パイプラインとしてしか機能できませんでした。しかし、エッジコンピューティングの時代では、ビジネスとネットワークがエッジコンピューティングを定義し、オペレーターが再び脚光を浴び、かけがえのない存在となっています。

4. エッジコンピューティングの種類

（１）ネットワーク定義エッジコンピューティング：

端末とクラウドセンター間のネットワークパスを最適化することで、中央のクラウド機能が徐々に端末に近づき、サービスへのローカルアクセスが可能になります。センターからエッジまで、リージョナルクラウド/セントラルクラウド、エッジクラウド/エッジコンピューティング、エッジコンピューティング/ローカルコンピューティングの 3 つのタイプがあります。

地域クラウド/中央クラウド: バックボーンネットワーク上の中央クラウドコンピューティングサービスを拡大および拡張し、集中型クラウド機能を地域に拡張し、完全な地域カバレッジを実現し、バックボーンネットワークでの時間消費を解決し、ネットワーク遅延を約 30 ミリ秒に最適化しますが、論理的には依然として中央クラウドサービスです。
エッジクラウド/エッジコンピューティング: オペレーターのネットワークノードに沿って中央クラウドコンピューティングサービスを拡張し、中小規模のクラウドサービスまたはクラウドのようなサービス機能を構築し、マルチアクセスエッジコンピューティング (MEC) や CDN などのネットワーク遅延を 15 ミリ秒程度に最適化します。
エッジコンピューティング/ローカルコンピューティング：主に端末に近いオンサイト設備とサービス機能を指し、端末ロジックを分離し、エッジで自律的なインテリジェントサービスを実現します。クラウドは、エッジのリソーススケジューリング、アプリケーション管理、ビジネスオーケストレーション機能を制御し、オールインワンマシンやスマートルーターなどのネットワーク遅延を約 5 ミリ秒に最適化します。

一般的に、ネットワーク定義のエッジコンピューティングは、消費者向けインターネットサービスや新しい 2C サービスに重点を置いており、クラウドセンターの機能とデータを事前にエッジにシンクします。従来の CDN、ビデオ、音声サービスに加えて、今年非常に人気があるメタバースもあります。

現在、ほとんどの消費者向けインターネットサービスは、バックボーンネットワーク上に配置された中央クラウドコンピューティング機能によってサポートされており、そのレイテンシは 30 ～ 50 ミリ秒で、クラウドベースのバックエンドビジネス処理のレイテンシよりもはるかに小さくなっています。コンピューティング能力をエッジに集中させる本来の目的は、主に中央クラウドからの大量のリクエストの負荷を分散し、ユーザーエクスペリエンスを最適化することであり、これはタイムリーな支援というよりも、ビジネスにとっての付加価値です。

ここでオペレータネットワークについてお話しします。クラウドコンピューティング技術の中心は、データセンターの内部ネットワーク、つまりクラウドネットワーク全体を仮想化するもので、VPCやロードバランシングなど多くの製品が派生してきました。オペレータネットワークはデータセンターの外部でほぼ完全に保護されており、弾力性のあるパブリック IP とインターネットエクスポート帯域幅サービスのみが提供されます。中央クラウドコンピューティングとオペレータネットワークの間には統合がありません。ただし、中央クラウドコンピューティングからエッジコンピューティングへの進化は、中央クラウドとエッジをリンクするネットワークに大きく依存します。中央クラウドが脳であり、エッジコンピューティングがインテリジェントアンテナであるとすると、ネットワークは神経であり、動脈です。しかし、実際には、全体的なネットワークの計画と構築はクラウドコンピューティングが開発される前から行われており、クラウドコンピューティング専用のものではありません。そのため、中央クラウドコンピューティングとオペレータネットワークを統合、つまりクラウドネットワーク統合する必要があります。クラウドネットワーク統合の最終的な目標は、クラウド機能のネットワーク化されたスケジューリングとオーケストレーション、およびネットワーク機能の迅速なクラウド化定義を実現することです。当社は、新たなビジネス需要とクラウド技術の革新を活用して、通信事業者のネットワークアーキテクチャに大きな変化、アップグレード、オープン性をもたらすことを目指しています。

現在、ネットワークの容量はクラウドコンピューティングの発展を大きく制限しており、これはエッジコンピューティングとモノのインターネットの構築プロセスで特に顕著です。クラウドネットワークの統合とコンピューティングパワーネットワークは、依然としてオペレーターの独占領域です。新世代の5Gがもたらした破壊的な技術変化は、分野全体に破壊的な変化を引き起こしましたが、解決したのは大量デバイスアクセスと低遅延デバイスアクセスの問題だけです。全体的なバックエンドのサポートとソリューションは明らかに追いつくことができません。現状から判断すると、5G は依然としてビジネスを見つけるのが難しい状況にあります。今後、5Gは消費者分野よりも物理的な産業分野（港、ドック、鉱山など）に大きな変化と価値をもたらすでしょう。

（２）ビジネス定義エッジコンピューティング：

エッジコンピューティングは、消費者向けのインターネットエッジシナリオに加えて、実体経済やスマート社会から派生したシナリオに重点を置いています。

物理的な業界のシナリオでは、歴史的な理由により、エッジとオンサイトに多数の異種インフラストラクチャリソースが存在します。ビジネスニーズ主導のエッジコンピューティングプラットフォームの構築は、既存のインフラストラクチャリソースを統合して活用するだけでなく、中心的なクラウドコンピューティングテクノロジーと機能をエッジとオンサイトに導入し、多数の既存のビジネスオペレーションと管理のクラウド化と、大量のデータの統合的な入力を実現し、企業全体のデジタル変革をサポートします。

スマート社会の派生シナリオでは、ビジネスが新しいほど、ネットワーク遅延の影響を受けやすくなり、データ量が増え、構造化データが非構造化データに徐々に変換されるため、人工知能やニューラルネットワークなどの高度なインテリジェントテクノロジーのサポートが必要になります。

現在、ネットワーク遅延の影響を受けやすい新しいビジネスシナリオはすべて、分散アーキテクチャ戦略を使用してネットワークへの強い依存度を軽減し、クラウドベースのマスターコントロールとオンサイトのリアルタイムコンピューティングを通じて管理されています。エッジコンピューティングは、ビジネスに基づいて、スマートデバイス/プロフェッショナルクラウドと産業エッジ/インダストリークラウドの2つのタイプに分けられます。

スマートデバイス/プロフェッショナルクラウド: クラウドコンピューティング機能に基づいて、スマートデバイス、クラウドサービス、ビデオ監視クラウド、G7貨物IoTなどのエンドとクラウド間のエッジサービスを含む、スマートデバイスを中心とした統合された競争力のあるソリューションを提供します。
産業エッジ/産業クラウド: クラウドコンピューティング機能に基づいて、物流クラウド、航空宇宙クラウドなどの産業アプリケーションとシナリオを中心としたスイート製品とソリューションを提供します。

一般的に、ビジネス定義に基づくエッジコンピューティングは、スマートデバイスと実体経済に重点を置いています。スマートデバイスの場合、AVG、高密度ストレージ、ロボットアームなどの単機能スマートデバイスから、ドローンや自動運転車などの超複雑なスマートデバイスまで、クラウドコンピューティング機能は、デバイス制御および管理アプリケーションの操作をサポートするだけでなく、中央クラウドコンピューティング機能の助けを借りてエッジ側に拡張され、クラウド上にある場合にこれらの製品を集中的かつ標準化された方法で管理できないという問題を解決します。産業エッジでは、クラウドコンピューティングテクノロジーと業界シナリオの抽象的な概要を組み合わせて、業界全体にわたる製品とソリューションが構築されます。産業インターネット全体の構築が加速するにつれ、エッジコンピューティングの今後の発展の重要な方向性となります。

5. まとめ

大規模企業にとって、クラウドエッジのシナリオは非常に複雑です。中央クラウドコンピューティングプラットフォームとエッジコンピューティングプラットフォームの構築は、ビジネスニーズに対応するだけでなく、多くのインフラストラクチャの問題にも直面しています。中央クラウドコンピューティングでは、マルチクラウドの使用とマルチクラウドの相互運用性の問題があります。エッジネットワークリンクでは、複数のオペレータのバックボーンネットワーク、マルチクラウドオペレータネットワーク、およびマルチクラウドクラウドネットワーク統合に問題があります。エンドサイドアクセスネットワークでは、複数事業者の5Gネットワークを共有する問題などがあり、多くの問題はガバナンス対策でしか対処できず、技術プラットフォームレベルでは完全に解決できません。

一般に、エッジコンピューティングの範囲とシナリオの範囲は広く、業界全体では標準的な事例や標準が不足しています。したがって、エッジコンピューティングの実装を促進するには、実際のビジネスシナリオとニーズに基づいて全体的な計画を立て、徐々に価値を構築していく必要があります。

センターからエッジまでKubernetes

Kubernetes は、アプリケーション中心の技術アーキテクチャと哲学に従い、一連の技術システムであらゆる負荷をサポートし、あらゆるインフラストラクチャ上で実行します。インフラストラクチャの違いを下位レベルで保護し、基礎となる基本リソースの統一されたスケジュールとオーケストレーションを実現します。コンテナイメージを通じてアプリケーションを標準化し、アプリケーションロードの自動展開を実現します。中央クラウドコンピューティングの境界を打ち破り、クラウドコンピューティング機能をエッジとオンサイトにシームレスに拡張し、クラウドエッジ統合インフラストラクチャを迅速に構築します。

クラウドネイティブテクノロジーをセンターからエッジに拡張することで、クラウドエッジインフラストラクチャの技術アーキテクチャが統合されるだけでなく、ビジネスの自由なクラウドエッジオーケストレーションと展開も可能になります。中央クラウドにおける Kubernetes の革命的なイノベーションと比較すると、エッジシナリオでは明らかな利点があるものの、その欠点も致命的です。エッジ側のリソースの制限、ネットワークの制限や不安定さなどの特殊な状況のため、さまざまなビジネスシナリオに応じて異なる Kubernetes エッジソリューションを選択する必要があります。

1. Kubernetesアーキテクチャとエッジの課題

Kubernetes は典型的な分散アーキテクチャです。マスター制御ノードはクラスターの「頭脳」であり、ノードの管理、ポッドのスケジュール設定、クラスターの実行ステータスの制御を担当します。ノードは、コンテナの実行と実行ステータスの監視/レポートを担当する作業ノードです。エッジコンピューティングのシナリオには、次のような明らかな課題があります。

状態一貫性のある集中型ストレージアーキテクチャは、大規模なプールされたリソースのオーケストレーションとスケジューリングに基づいてビジネス継続性サービスを実現する、集中型クラウドコンピューティングの主要製品です。
マスター制御ノードとワーカーノードは、リストウォッチメカニズムを使用してステータスタスクのリアルタイム同期を実現しますが、トラフィックが大きく、ワーカーノードは永続データに関してマスターノードに完全に依存しており、自律性がありません。
Kubelet は、過剰な論理処理、さまざまなコンテナランタイムのさまざまな実装との互換性、およびデバイスプラグインハードウェアデバイスドライバーを搭載しており、最大 700M のリソースを占有します。これは、リソースが限られているエッジノード、特に低構成のエッジデバイスにとっては負担が大きすぎます。

エッジコンピューティングには幅広いシナリオと複雑なシナリオが含まれており、統一された標準はまだ存在しません。 Kubernetes オープンソースコミュニティのメインラインバージョンには、エッジシナリオへの適応計画がありません。

2. Kubernetesエッジオペレーションソリューション

中央クラウドコンピューティングとエッジコンピューティングのクラウドエッジ分散アーキテクチャでは、Kubernetes をエッジ分散展開に適したアーキテクチャに適合させる必要があります。マルチクラスタ管理により統合管理が可能となり、エッジオペレーションの集中クラウド管理を実現します。全体的なソリューションは、次の 3 つのタイプに分けられます。

クラスター: Kubernetes 標準クラスターがエッジに移動されます。利点は、カスタマイズされた Kubernetes 開発が不要であることです。また、Kubernetes の複数のバージョンをサポートし、企業がクラウドエッジアーキテクチャの一貫性を真に実現できるようにします。デメリットは、多くの管理リソースを消費することです。このソリューションは、地域クラウド/中央クラウド、エッジコンピューティング/ローカルコンピューティング、大規模な産業エッジシナリオに適しています。
単一ノード: Kubernetes は、単一ノードのデバイスに合理化され、デプロイされます。利点はクラスターソリューションと一致しています。デメリットとしては、Kubernetes の機能が不完全であること、リソースの占有により設備コストが増加すること、ビジネスアプリケーションに対してクラウドとエッジ間で一貫したアーキテクチャの展開と運用を保証できないこと、実用的な問題を解決できないことが挙げられます。
リモートノード: Kubernetes の二次開発と強化された拡張に基づいて、Kubernetes は分離され、クラウドエッジ分散アーキテクチャシナリオに適応され、マスター管理ノードが集中的に展開され、ワーカー管理ノードが分散的に展開されます。

さらに、一貫性はエッジコンピューティングにおける問題点です。エッジにキャッシュを追加すると、通常のネットワーク状況ではデータの一貫性を確保しながら、ネットワーク切断などの特殊な状況でもエッジの自律性を実現できます。 Kubelet が重いという問題もありますが、Kubernetes が Docker を放棄するにつれて、これは合理化され始めました。同時に、ハードウェアの更新と反復は高速であり、Kubernetes のネイティブ性と普遍性を維持することは、わずかなハードウェアコストよりも重要です。実際、Kubernetes コミュニティ自体がエッジ適応ソリューションを提供し、Kubelet にキャッシュメカニズムを追加することを検討できることを期待しています。

3. Kubernetesエッジコンテナは急速に発展している

Kubernetes は、コンテナのオーケストレーションとスケジューリングの事実上の標準となっています。エッジコンピューティングのシナリオでは、国内のさまざまなパブリッククラウドベンダーが、Kubernetes をベースとした独自のエッジコンピューティングクラウドネイティブプロジェクトをオープンソース化しています。たとえば、Alibaba Cloud が CNCF に寄付した OpenYurt は、エッジノードのリモートノードソリューションを使用しています。これは、業界初のオープンソースの非侵入型エッジコンピューティングクラウドネイティブプラットフォームです。「ネイティブ Kubernetes をエッジに拡張する」という非侵入的な設計コンセプトに準拠しており、エッジコンピューティングシナリオを完全にカバーできます。 Huawei、Tencent、Baiduなども独自のエッジコンテナプラットフォームをオープンソース化しています。

エッジコンテナーの急速な発展により、この分野でのイノベーションが促進されましたが、ある程度、エッジコンピューティングプラットフォームの構築時に難しい決断を迫られることにもなりました。技術アーキテクチャの観点から見ると、いくつかのエッジコンテナ製品の全体的なアーキテクチャのアイデアは、主に Kubernetes をクラウドエッジ、弱いネットワーク、および希少なリソースに適したエッジコンピューティングシナリオに分離することであり、本質的にはそれほど違いはありません。製品機能の観点からも同様であり、基本的にはクラウドとエッジの連携、エッジの自律性、ユニット化された展開機能をカバーしています。

4. クラウドエッジ統合クラウドネイティブプラットフォームの構築方法

この段階では、Kubernetes コンテナプラットフォームを中心にクラウドエッジ統合クラウドネイティブインフラストラクチャプラットフォーム機能を構築することが、エッジコンピューティングプラットフォームにとって最適な選択肢です。クラウド上の統合コンテナマルチクラスタ管理により、Kubernetes クラスタ仕様の構成を標準化しながら、分散クラスタを均一に管理できます。

標準クラスター (大規模): ETCD + マスター 3 8c16G、Prometheus + Ingress 5 8C16G、N * ワーカーノードとして構成された 400 ノードを超える大規模クラスターをサポートします。主に大規模なビジネス規模のクラウドネイティブアプリケーションの運用シナリオ向け。
標準クラスター (中規模): 100 ノードを超えるクラスター、ETCD + マスター + Prometheus 3 8c16G、N * ワークノードをサポートします。主に中規模のビジネスシナリオ向け。
エッジネイティブコンテナクラスター: クラウドにクラスター管理ノードを展開し、ビジネスサイトにエッジノードを個別に展開して、IoT 物理デバイスアクセスプロトコル解析アプリケーション、ビデオ監視分析 AI アルゴリズムモデル、その他のビジネスシナリオなど、単一のビジネスシナリオで実行されているアプリケーションをサポートします。

ビジネスシナリオの要件に応じて最適なコンテナクラスターソリューションを選択します。エッジコンテナクラスターソリューションは、他のクラスターソリューションとはまったく異なります。他のクラスターでは、集中管理されプールされた基本リソースを使用して中央クラウドクラスターサービスの一貫性が維持され、すべてのアプリケーションがクラスターリソース全体を共有します。エッジコンテナクラスターのマスター管理ノードは集中的に展開され、共有されます。ワーカーノードは業務現場に分散され、オンデマンドで追加され、自ら運用・保守され、排他的に使用されます。

現在のエッジコンテナ分野では、短期間で統合されたオープンソース製品が登場することは困難です。したがって、この段階では、標準の Kubernetes API を介してエッジネイティブコンテナクラスターを統合することをお勧めします。これは、すべてのエッジコンテナーと互換性のある適度なソリューションです。どちらかを選択する必要がある場合は、非侵入的な設計と、よりエレガントな全体的な技術アーキテクチャと実装を備えた OpenYurt をお勧めします。

3. OpenYurt: インテリジェントエッジコンピューティングプラットフォームのオープンソースプラクティス

OpenYurt は、アップストリームのオープンソースプロジェクト Kubernetes をベースとしており、エッジシナリオに適応したディストリビューションです。これは、クラウドネイティブテクノロジーシステムに依存し、「ゼロ」の侵入で実装された業界初のインテリジェントエッジコンピューティングプラットフォームです。包括的な「クラウド、エッジ、エンド統合」機能を備えており、大規模なエッジコンピューティングサービスと異種コンピューティングパワーの効率的な配信、運用、保守、管理を迅速に実現できます。

1. 設計原則

OpenYurt は、業界で現在主流となっている「集中制御とエッジ操作」のクラウドエッジ分散コラボレーション技術アーキテクチャを採用し、「ネイティブ Kubernetes をエッジに拡張する」というコンセプトを常に実装し、次の設計原則に従います。

「クラウドエッジ統合」の原則：中央クラウドとの一貫したユーザーエクスペリエンスと製品機能を確保することを基盤として、クラウドネイティブ機能がクラウドエッジ制御チャネルを通じてエッジにシンクされ、大規模なインテリジェントエッジノードとビジネスアプリケーションが実現され、インフラストラクチャが業界をリードするクラウドネイティブアーキテクチャの大きな進歩にアップグレードされます。
「ゼロ侵入」の原則: ユーザーに公開されている API がネイティブ Kubernetes と完全に一致していることを確認します。ノードネットワークトラフィックをプロキシすることにより、ワーカーノードアプリケーションのライフサイクル管理にカプセル化抽象化の新しいレイヤーが追加され、分散ワーカーノードリソースとアプリケーションの統合管理とスケジュールが実現します。同時に、私たちは「UpStream First」オープンソース原則に従います。
「低負荷」の原則: プラットフォームの機能特性と信頼性を確保することを基本として、プラットフォームの汎用性を考慮し、すべてのコンポーネントのリソースを厳密に制限し、最小限かつ簡素化された設計コンセプトに従って、エッジデバイスとシナリオの範囲を最大化します。
「ワンスタック」原則: OpenYurt は、強化されたエッジ運用および管理機能を実装するだけでなく、ネイティブ Kubernetes とエッジコンピューティング機能をサポートする Kubernetes クラスター間のワンクリックの効率的な変換を実現するためのサポート運用および保守管理ツールも提供します。

2. 特徴

OpenYurt は、Kubernetes の強力なコンテナオーケストレーションおよびスケジューリング機能に基づいて、限られたエッジリソースや不安定なネットワークなどの状況に合わせて適応および強化されています。中央のクラウドネイティブ機能を分散エッジノードに拡張し、エッジビジネス向けのローカル低遅延サービスを実現します。同時に、リバースセキュリティ制御運用保守リンクを開き、クラウド集中型エッジデバイスおよびアプリケーションに便利で効率的な統合運用保守管理機能を提供します。主な機能は次のとおりです。

エッジノードの自律性: エッジコンピューティングシナリオでは、クラウドエッジ管理ネットワークは継続的な安定性を保証できません。強化された適応は、状態データを持たないネイティブワーカーノード、マスター管理ノードデータへの強い依存、およびエッジシナリオには適さない強力な状態一貫性メカニズムの問題を解決するために使用されます。これにより、クラウドエッジネットワークがスムーズでない場合でも、エッジワークロードが排除されず、ビジネスが通常どおり継続されます。ネットワーク停止中にエッジノードが再起動された場合でも、業務は通常の状態に戻ることができます。つまり、エッジノードの一時的な自律性機能です。
共同 O&M チャネル: エッジコンピューティングシナリオでは、クラウドエッジネットワークは同じネットワークプレーン上に存在せず、エッジノードはパブリックネットワークに公開されません。中央制御はエッジノードとの有効なネットワークリンクチャネルを確立できないため、すべてのネイティブ Kubernetes O&M API (ログ/実行/メトリック) が失敗します。 Kubernetes の機能を適応および強化します。エッジポイントを初期化すると、中央制御ノードとエッジノードの間にリバースチャネルが確立され、ネイティブ Kubernetes 運用および保守 API (ログ/実行/メトリック) トラフィックを受信するため、集中化された統一された運用と保守が実現します。
エッジユニット化負荷: エッジコンピューティングシナリオでは、ビジネス指向のアーキテクチャは一般に、「集中制御と分散操作」のクラウドエッジ共同分散アーキテクチャです。管理側としては、同じ業務を異なるリージョンのノードに同時に展開する必要があります。エッジ側では、ワーカーノードは一般的に広い範囲に分散しており、地域性が強いです。ネットワーク相互通信がない、リソース共有がない、リージョンをまたがるノード間でリソースが異種であるなど、明らかな分離特性があります。 Kubernetes の機能を適応および強化して、リソース、アプリケーション、トラフィックに基づいてエッジロードの統合管理とスケジュールを実装します。
OpenYurt オープンソースコミュニティにさらに多くの参加者を導入し、共同研究開発を通じてより多くのオプションの専門機能を提供することで、OpenYurt の機能は徐々に改善され、カバレッジが拡大しています。
エッジデバイス管理: エッジコンピューティングシナリオでは、エンド側デバイスがプラットフォームの実際のサービスオブジェクトになります。クラウドネイティブのコンセプトに基づき、非侵入的でスケーラブルなデバイス管理標準モデルを抽象化し、Kubernetes ワークロードモデルと IoT デバイス管理モデルをシームレスに統合し、ビジネスのプラットフォーム強化のラストマイルを実現します。現在、EdgeX Foundryオープンソースプロジェクトの統合は標準モデルを通じて完了しており、エッジデバイスの管理効率が大幅に向上しています。

ローカルリソース管理: エッジコンピューティングシナリオでは、エッジノード上の既存のブロックデバイスまたは永続メモリデバイスが、簡単に使用できるようにクラウドネイティブコンテナーストレージに初期化されます。サポートされているローカルストレージデバイスには、(1) ブロックデバイスまたは永続メモリデバイスに基づいて作成された LVM の 2 種類があります。（２）ブロックデバイスまたは永続メモリデバイスに基づいて作成されたQuotaPath。

3. OpenYurt の設計アーキテクチャと原則

（１）設計建築

ネイティブ Kubernetes は集中型分散アーキテクチャです。マスター制御ノードは、スケジュールの管理とクラスターの動作ステータスの制御を担当します。ワーカーノードはコンテナの実行と操作ステータスの監視/報告を担当します。

OpenYurt はネイティブ Kubernetes に基づいています。エッジシナリオでは、中央の分散アーキテクチャ (クラウドマスター、クラウドワーカー) を分離し、集中制御と分散エッジ操作 (クラウドマスター、エッジワーカー) に適応させて、中央の脳と複数の分散小脳を備えたタコのようなクラウドエッジ共同分散アーキテクチャを形成します。主な中核ポイントは次のとおりです。

集中化された強力な一貫性のあるメタデータ状態ストレージがエッジノードに分散され、ネイティブの Kubernetes スケジューリングメカニズムが調整されて、異常な自律ノードの状態によって再スケジュールがトリガーされないようにすることで、エッジノードの一時的な自律性が実現されます。
Kubernetes の機能が完全かつ一貫していることを確認しながら、既存のクラウドネイティブエコシステムと互換性を保ち、クラウドネイティブシステムを可能な限りエッジに統合します。
大規模なリソースをセンターにプールし、複数のアプリケーションに共有リソースのスケジュールを委託するモードは、リージョンの小規模または単一ノードのリソースにも適応され、エッジシナリオでより洗練されたユニット化されたワークロードオーケストレーション管理を実現します。
エッジの実際のビジネスシナリオのニーズに照準を合わせ、オープンコミュニティを通じて、デバイス管理、エッジ AI、ストリーミングデータなどをシームレスに統合し、エッジの実際のビジネスシナリオにすぐに使用できる汎用プラットフォーム機能を提供することで、より多くのエッジアプリケーションシナリオを実現します。

（２）実施原則

OpenYurt は、クラウドネイティブアーキテクチャの概念を実装し、クラウドエッジの共同分散アーキテクチャと、エッジコンピューティングシナリオのエッジ操作を集中制御する機能を実装します。

エッジノードの自律性に関しては、一方では、新しい YurtHub コンポーネントを使用してエッジからクラウドへのリクエストプロキシを実装し、キャッシュメカニズムによって最新のメタデータをエッジノードに保持します。一方、新しい YurtControllerManager コンポーネントは、ネイティブ Kubernetes スケジューリングを引き継ぐために使用され、エッジ自律ノードの異常な状態によって再スケジューリングがトリガーされないようにします。
Kubernetes 機能の完全性とエコシステムの互換性を確保するために、Cloud To Edge Request リバースチャネルは YurtTunnel コンポーネントを追加して構築され、Kubectl や Promethus などの中央運用保守製品の一貫した機能とユーザーエクスペリエンスを保証します。同時に、さまざまなワークロードや Ingress ルーティングなど、他の中心的な機能もエッジに転送されます。
エッジユニット管理機能に関しては、新しい YurtAppManager コンポーネントが追加され、NodePool、YurtAppSet (旧 UnitedDeployment)、YurtAppDaemon、ServiceTopology などを使用して、エッジリソース、ワークロード、トラフィックの 3 層ユニット管理を実装します。
エッジの実際のビジネスプラットフォーム機能を強化するために、エッジストレージの使用を容易にする新しい NodeResourceManager が追加され、クラウドネイティブモードでエッジデバイスを管理する YurtEdgeXManager/YurtDeviceController が導入されました。

4. コアコンポーネント

OpenYurt のすべての新機能とコンポーネントは、アドオンとコントローラーを通じて実装されます。必須のコアコンポーネントとオプションコンポーネントは次のとおりです。

YurtHub (必須): エッジとクラウドの 2 つの動作モードがあります。これは、クラウドのエッジにあるすべてのノードで Static Pod の形式で実行され、ノードトラフィックの SideCar として機能し、ノード上のコンポーネントと kube-apiserver のアクセストラフィックをプロキシします。エッジ YurtHub は、一時的なエッジノードの自律性を実現するためにデータをキャッシュします。
YurtTunnel (必須): サーバーおよびエージェントで構成され、双方向の認証および暗号化されたクラウドエッジリバーストンネルを構築し、ネイティブ Kubernetes 操作およびメンテナンス API (ログ/実行/メトリック) のリクエストトラフィックをクラウドセンターからエッジに転送します。サーバーはデプロイメントワークロードとともにクラウドセンターにデプロイされ、エージェントは DaemonSet ワークロードとともにエッジノードにデプロイされます。
YurtControllerManager (必須): クラウドセンターコントローラー。ネイティブ Kubernetes NodeLifeCycle コントローラーを引き継いで、クラウドエッジネットワークが異常な場合に自律エッジノードの Pod アプリケーションが排除されないようにします。 YurtCSRController は、エッジノードの証明書申請を承認するために使用されます。
YurtAppManager (必須): NodePool: ノードプール管理を含むエッジロードの統合管理とスケジュールを実装します。 YurtAppSet: 元の UnitedDeployment、ノードプールディメンションのビジネスロード。 YurtAppDaemon: ノードプールディメンションの Daemonset ワークロード。クラウドセンターにワークロードをデプロイします。
NodeResourceManager (オプション): エッジノードのローカルストレージリソースの管理コンポーネント。 ConfigMap を変更することで、ホスト上のローカルリソースを動的に構成します。 DaemonSet ワークロードとしてエッジノードにデプロイされます。
YurtEdgeXManager/YurtDeviceController (オプション): クラウドネイティブモードを通じてエッジデバイスを管理し、現在 EdgeX Foundry 統合をサポートしています。 YurtEdgeXManager はデプロイメントワークロードとともにクラウドセンターにデプロイされ、YurtDeviceController は YurtAppSet ワークロードとともにエッジノードにデプロイされます。そして、YurtDeviceController のセットがノードプール NodePool にデプロイされます。
運用および保守管理コンポーネント (オプション): クラスター管理を標準化するために、OpenYurt コミュニティは YurtCluster Operator コンポーネントを立ち上げました。このコンポーネントは、クラウドネイティブの宣言型 Cluster API と構成を提供し、標準の Kubernetes に基づいて OpenYurt 関連コンポーネントを自動的にデプロイおよび構成し、OpenYurt クラスターのライフサイクル全体を実装します。古い Yurtctl ツールはテスト環境でのみ使用することをお勧めします。

OpenYurt は、コア機能とオプションの専門機能に加えて、クラウドエッジ統合の概念を継続的に実装し、豊富なクラウドネイティブエコロジカル機能を最大限にエッジに押し上げます。エッジコンテナストレージ、エッジガーディアンワークロードDaemonSet、エッジネットワークアクセスIngress Controllerなどを実現しており、Service Mesh、Kubeflow、Serverlessなどの機能も予定されていますので、ご期待ください。

5. 現在の課題

（１）クラウドエッジネットワーク

エッジコンピューティングのシナリオで最も頻繁に言及される問題は、クラウドエッジネットワークが貧弱で不安定であることです。実際、国内の基本ネットワークは2015年に全面的にアップグレードされ始め、特に「雪良プロジェクト」の完成後、基本ネットワークは大幅に改善されました。上記のグラフは「第48回中国インターネット発展状況」報告書から抜粋したものです。固定回線100Mbpsアクセスの割合は91.5%に達しました。ワイヤレスネットワークアクセスはすでに 4G および 5G の高品質ネットワークです。

本当の課題はクラウドエッジネットワークの構築にあります。パブリッククラウドを使用するシナリオでは、パブリッククラウドがデータセンターネットワークをシールドし、インターネットエクスポート帯域幅のみを提供します。クラウドエッジをインターネット経由で接続すると、通常は安全なデータ転送の問題を解決するだけで済み、アクセスは複雑になりません。民間構築の IDC シナリオの場合: 主にオペレータネットワークが完全に製品化されていないため、クラウドエッジネットワークを接続するのは簡単ではありません。同時に、ファイアウォールやその他の複雑な製品のプライベート IDC レイヤーの実装を完了するには、専門のネットワーク担当者が必要です。

（２）リスト監視機構とクラウドエッジトラフィック

List-Watch メカニズムは Kubernetes 設計の本質です。アクティブな監視メカニズムを通じて関連するイベントとデータを取得し、すべてのコンポーネントが疎結合され、互いに独立しながらも論理的に統合されていることを保証します。リスト要求は全量のデータを返します。ウォッチが失敗したら、再度リストする必要があります。ただし、Kubernetes では管理データの同期の最適化が検討されています。ノードの kubelet はこのノードのデータのみを監視し、kube-proxy はすべてのサービスデータを監視します。データ量は比較的制御可能です。同時に、gRPC プロトコルが使用され、テキストメッセージデータはビジネスデータと比較して非常に小さくなります。上図は、1200ノードのクラスター規模で作成されたストレステストデータの監視チャートです。

本当の課題は、基本イメージとアプリケーションイメージの配布にあります。中央クラウドにおいても、現在の基本イメージや業務イメージは、迅速なイメージ配信のボトルネックを最適化するために、さまざまな技術を模索しているところです。特に、エッジ AI アプリケーションは、一般的にプッシュアプリケーション + モデルライブラリで構成されます。推論されたアプリケーションのイメージは比較的小さく、モデルライブラリのサイズは非常に大きくなります。同時に、モデルライブラリは自己学習によって頻繁に更新する必要があります。モデルライブラリをより効率的に更新するには、それに対応するためのより多くのテクノロジとソリューションが必要です。

（３）エッジリソースとコンピューティングパワー

エッジのリソース状況はシナリオに細分化する必要があります。オペレータネットワークのエッジとコンシューマ向けエッジコンピューティングの場合、リソースは比較的十分であり、最大の課題はリソースの共有と分離です。物理業界のエッジでは、IDC のサポートがかなりあり、エッジリソースはクラウドネイティブシステム全体を沈めるのに十分です。スマートデバイスのエッジでは、リソースは比較的不足していますが、通常はインテリジェントエッジボックスを介して接続され、一方の端はデバイスに接続され、もう一方の端は中央管理サービスに接続されます。上図のAIエッジボックスから判断すると、全体の構成は急速に向上していることがわかります。長期的には、エッジのコンピューティング能力は、より複雑でインテリジェントなシナリオのニーズを満たすために急速に強化されるでしょう。

（4）Kubeletは重く、多くのリソースを消費する

Kubelet が重くて多くのリソースを占有するという問題を解決するには、ノードのリソースの割り当てと使用法について深く理解する必要があります。通常、ノードリソースは下から上に向かって 4 つのレイヤーに分かれています。

オペレーティングシステムとシステムデーモン (SSH、systemd など) を実行するために必要なリソース。
Kubelet、コンテナランタイム、ノード問題検出器など、Kubernetes エージェントを実行するために必要なリソース。
ポッドで利用可能なリソース。
排除しきい値まで保持されたリソース。

各レイヤーでのリソース割り当て設定には標準がなく、クラスターの状況に応じて構成を検討する必要があります。 Amazon Kubernetes の Kubelet リソース構成アルゴリズムは、予約メモリ = 255MiB + 11MiB * MAX_POD_PER_INSTANCE です。 32 個の Pod が稼働していると仮定すると、メモリの最大 90% を業務用途に割り当てることができ、相対的に Kubelet リソースの使用率は高くありません。

同時に、高可用性に対するビジネスの要件に基づいて、応答性の高い調整も行う必要があります。エッジシナリオでは、通常、単一のノードで多数の Pod を実行することは推奨されません。

4. ビジネスアプリケーション向けクラウドエッジ管理・運用連携モデル

中央クラウドに基づく分散型ビジネスアプリケーションアーキテクチャは、クラウドエッジ分散型コラボレーションビジネスアプリケーションアーキテクチャとは根本的に異なります。中央クラウドでは、DDD ビジネス分野に基づいて、複雑なビジネスシステムを比較的独立したサービスに分割し、全体として疎結合の分散アプリケーションを構築します。しかし、クラウドエッジ分散シナリオでは、集中型の制御と運用、および分散型の運用サポートに重点が置かれます。管理・運用システムをクラウドセンターに集中させて一元管理し、リアルタイムな業務を支えるアプリケーションをエッジに分散させることで、低遅延・高速レスポンスを実現します。

ビジネスアプリケーションの観点から見ると、財務/運用レイヤーと計画/管理レイヤーは制御アプリケーションと運用アプリケーションに属し、集中化された強力な制御を実現するために、中央クラウドを通じて統合および収束する必要があります。遅延に敏感ではなく、セキュリティとビッグデータ分析機能に対する要件が高い。制御、センシング/実行、生産プロセス層は運用支援アプリケーションに属し、中央クラウドを優先させることもできます。ビジネスシナリオが遅延に敏感な場合は、エッジコンピューティング機能を使用して分散型の低遅延応答を実現することを検討します。

リクエスト応答の観点から、レイテンシ（50 ミリ秒以上）の影響を受けないサービスは、中央クラウドコンピューティングおよびクラウドベースのエッジ製品（CDN）に展開できます。遅延（10 ミリ秒未満）に敏感で、オペレータのバックボーンネットワークでサポートできないサービスについては、エッジコンピューティングプラットフォームの構築を検討できますが、ビジネスには相当の投資と人員が必要になります。

物理物流の分野を例にとると、古典的なOTWシステム（OMS受注管理システム、WMS倉庫管理システム、TMS輸送管理システム）は典型的な管理・運用システムであるため、中央クラウドに導入することが推奨されます。中央クラウドデータ集約により、注文の統合や分割、複合輸送などの地域間ビジネスを実現できます。 Wは倉庫管理システムであり、4つの壁のタスクを管理し、運用サポートアプリケーションに属します。倉庫には通常、自動化された機器がいくつかあるため、エッジに W を展開することを検討できます。

V. 結論

エッジコンピューティングプラットフォームの構築にとって、Kubernetes を中核とするクラウドネイティブテクノロジーシステムは、現時点では間違いなく最良の選択であり、構築パスです。ただし、クラウドネイティブシステムは巨大であり、コンポーネントは複雑です。システムを限界まで沈めることは大きな課題と困難に直面することになるが、同時に大きなチャンスと想像力に満ちている。ビジネスアプリケーションがエッジでクラウドネイティブシステムを真に実装する場合、エッジの利点と価値を最大限に活用するには、コンセプト、システム設計、アーキテクチャ設計などの複数の側面から共同で実装する必要があります。

<<: 分散トレースに Spring Cloud Sleuth と Zipkin を使用するためのガイド

>>: Elastic: ElasticsearchはElasticから1つだけあります