新しいクラウド ネイティブ シナリオのロックを解除 | クラウド ネイティブは、クラウド、エッジ、エンドの統合開発を加速します

クラウド ネイティブがクラウド エッジ エンド統合の開発を加速


「第 14 次 5 カ年計画」では、「クラウド サービスとエッジ コンピューティング サービスの開発を調整する」必要性が明確に示されました。同時に、国務院の「第 14 次 5 カ年計画」デジタル経済発展計画でも、 「特定のシナリオ向けのエッジ コンピューティング機能を強化する」ために必要です中国のクラウド コンピューティングが包括的な開発の時期に突入したため、エッジ コンピューティングの需要が急増し、クラウド エッジ デバイスの統合が将来の重要な進化の方向性になりました


クラウドネイティブとエッジ コンピューティング テクノロジーの幅広いアプリケーションと深い統合により、クラウド エッジ エンド統合の実装プロセスがさらに加速されます。

クラウド ネイティブ エッジ コンピューティング アーキテクチャ


以下は、Lingqueyun のエッジ コンピューティング ソリューションに基づく完全なエッジ コンピューティング アーキテクチャの紹介です. このアーキテクチャには、端末、エッジ、クラウドの 3 つの部分が含まれます. 端末部分には、カメラ、センサー、VGA、ロボットなどを使用できます. 第 2 部では、エッジ端末は、エッジ デバイスからの距離に応じて、エッジ ゲートウェイ、ニア エッジ、ファー エッジの 3 種類のコンピューティング環境にさらに分けられます。


エッジ ゲートウェイは、デバイスと密接に接続されている部分 A であり、通常、エッジからクラウドへのデータ伝送の最初のホップは、有線または無線の手段によってデバイスに直接接続されます。エッジ ゲートウェイは、多くの種類のアプリケーションと多くのデバイス インターフェイスの特性を備えています. コンテナー テクノロジを採用するための鍵は、ゲートウェイの統合を改善し、複数の種類のゲートウェイを 1 つに統合することです. 私が遭遇したエッジコンピューティングのプロジェクトでは、当初、お客様のエッジゲートウェイはインターフェースによってデバイスが異なり、20以上のアームボードを使用してさまざまなデバイスを管理していました.コンテナを使用した後、リソースの統合を実行し、最終的なソリューション 使用するアーム ボードは 9 枚のみで、リソースを半分に節約できます。


ニア エッジはパート B で、通常はエッジ サイトに従って展開されます。スーパーマーケット、ガソリン スタンド、高速料金所、飛行機はすべて、ニア エッジ コンピューティング環境と見なされます。この環境とデバイス間のネットワーク遅延は、約 2 ミリ秒で制御する必要があります。このプラットフォームは通常、3 つ以上の物理サーバー ノードで構成され、エッジ コンピューティングの重要な部分です。この部分の特徴は、重要なエッジ サービスを実行し、ストレージ、ネットワーク、GPU、ミドルウェア、マイクロサービス フレームワークなど、より多くのサポートを必要とすることですが、全体的なリソースはまだ比較的逼迫しています。コンテナ プラットフォームは、このようなコンピューティング環境に最適です。ビジネスの基本的な運用サポートを提供するだけでなく、ビジネスの柔軟なスケーリング、障害の自己修復、バッチ リリースなどを保証し、ビジネスに付加価値をもたらします。


次のコンピューティング環境は、パート C であるファー エッジです。この環境はリージョンごとにデプロイされ、エンドポイント間のネットワーク遅延は約 10 ミリ秒に制御されています。この部分をエッジ コンピューティングとクラウド コンピューティングの間に置く理由は、この部分が一部の顧客のコンピューティング モデルに存在しないか、またはこの部分が完全にビジネス レベル アーキテクチャに基づくエンタープライズ プライベート クラウドに進化するためです。インフラストラクチャの観点から見ると、ファー エッジは完全な機能を備えたプライベート クラウドであり、多くのビジネス形態があるため、通常、仮想マシンとコンテナーの 2 つのコンピューティング モデルをサポートする必要があります。幸いなことに、Kubernetes には Kubevirt のようなプロジェクトがあり、クラウド ネイティブな方法で仮想マシンを管理できます. 実際には、これは新しいテクノロジではなく、オペレーターなどのシナリオで広く使用されています. リモート エッジ環境では、ソフトウェア定義のデータ センターの考え方を採用し、k8s をベースとして使用して、データ センターに必要なすべてのコンピューティング、ネットワーク、ストレージ、負荷分散、セキュリティ、およびその他の機能を実行します。また、ファー エッジには、ニア エッジとエッジ ゲートウェイの統合管理機能もあり、管理オブジェクトにはビジネス側とプラットフォーム側の管理が含まれます。


最後はパートDのクラウドコンピューティング環境です。この部分は、IaaS、PaaS、およびその他の機能として一般的に理解されているものです。リモートエッジ環境の一元管理には分散クラウドアーキテクチャを採用し、アプリケーションのプッシュダウン、一元的な運用保守、リモートエッジ環境のプラットフォームアップグレードをクラウド上で行うことができます。


実際には、すべての顧客がこのような複雑で巨大なアーキテクチャに従う必要があるわけではありません. 通常、顧客が必要とするのは、完全に顧客のビジネス アーキテクチャに依存するアーキテクチャ全体のサブセットです.


Lingqueyun のエッジ コンピューティング アーキテクチャでは、このような複雑なアーキテクチャをゼロから構築することはありません。代わりに、安定して動作し、数百の主要な企業顧客によって検証された成熟した製品アーキテクチャに基づいて、エッジ コンピューティング環境の特性に適応させるために少量の拡張と強化が行われます。このソリューションが十分なリッチさを備えていること 機能的で十分な安定性があること

K8s コンテナー + エッジ コンピューティング = エッジネイティブ


プラットフォームの本質は、ビジネスをより適切にサポートすることであり、ビジネスの柔軟性と安定性が私たちが追求する究極の目標です。エッジ コンピューティングの分野では、クラウドで実行される新しいビジネス タイプを表すクラウド ネイティブと同様に、エッジ機能をフルに活用できるビジネス タイプを表すためにエッジ ネイティブを使用します。コンテナは、エッジ コンピューティングに優れたインフラストラクチャを提供するだけでなく、エッジ ネイティブ サービスの開発と運用を効果的にサポートすることもできます。ここでは、エッジネイティブ ビジネスの 7 つの特徴を 1 つずつ分析します。


まず、ビジネスは通常階層的です。エッジ ゲートウェイからニア エッジ、ファー エッジ、そして最終的にはクラウドに至るまで、ビジネスのさまざまな部分がさまざまな階層環境で実行され、それらが一体となって 1 つの完全なビジネスを構成します。コンテナが提供するマルチレベルのエッジ管理機能は、エッジ コンピューティングの実際の構築アーキテクチャと完全に一致し、コンテナはビジネスレベルの展開の柔軟性を向上させ、ビジネスはクラウドからエッジにすばやく移行したり、クラウドから移行したりできます。クラウドへのエッジ。


次に、ビジネスにはキャッシュが必要です。これはエッジ側での大量のデータ処理に関係しており、エッジコンピューティング自体ではこのような問題を解決できず、従来はビジネス自体でしか解決できませんでした。コンテナを採用すると、x86 サーバーであろうとアーム ボックスであろうと、コンテナはミドルウェアとデータベース サービスをエッジ ゲートウェイまたはニアエッジ環境に簡単にシンクできます。


第三に、ビジネスは柔軟に拡張できる必要があります。エッジ コンピューティング リソースが限られているからこそ、柔軟なリソース割り当てメカニズムであるエラスティック スケーリングがより重要になります. 従来のエッジ コンピューティング モデルでは、インフラストラクチャは企業がそのような問題を解決するのを助けることができず、そのような問題はビジネス レベルで解決する必要があります. . ビジネスに多くの問題をもたらします。ただし、柔軟なスケーリングはコンテナーの強みです. 標準の k8s には HPA 機能が含まれています. シンプルな構成により、CPU、メモリ、および監視指標に基づいてビジネスを柔軟に拡張および縮小し、リソースのより集中的な使用を実現できます.


第四に、事業形態は複数の小さなサービスで構成されるべきです。このスモール サービスの概念は、クラウド マイクロサービスの概念から借用したものであり、サービスはできるだけ小さくする必要があり、よりコンパクトなデバイスに適応でき、サービス間の依存関係を減らして、迅速なサービス アセンブリを可能にすることを強調しています。これはまさにコンテナの利点です. コンテナ自体は小規模なサービスを運ぶのに最適なツールです. さらに, サービスメッシュなどのテクノロジーは, C, C++, Java およびその他のサービスのサービスガバナンスの実装にも役立ちます.開発とトラブルシューティングを迅速に支援します。


第 5 に、エッジネイティブは地球に近いサービスです。ビジネス機器、データ、インタラクションはすべてエッジ側で行われ、ガソリン スタンド、スーパーマーケット、高速料金所などのシナリオを想像できます。コンテナー内のサービス ルーティング テクノロジは、ローカル サービスだけでなく、極端な状況下でのクロスローカル サービスも実現する、柔軟なビジネス パブリッシングを実装できます。


第六に、障害の自己修復。障害が発生した場合のエッジコンピューティングの一般的な現象は、エッジ側には安定した冷却と耐衝撃対策がないため、データセンターよりも障害が発生しやすく、企業の運用と保守のコストが大幅に増加します。私のクライアントの中には、オフィスビジネスの通常の運営を維持するために、各都市で数人を雇う必要があるものがあります。コンテナー ポッド コピー管理テクノロジは、高速な障害の自己修復を実現できます. プローブがビジネスにサービスを提供できないことを検出すると、コンテナー プラットフォームはすぐに再起動してビジネスを移行し、クラスターで実行されている十分なコピーがあることを確認します.


最後に、セキュリティ要件もエッジネイティブの典型的な機能です。これは、エッジ コンピューティングの攻撃ポイントが増加したためです。コンテナは、コンピューティング、ネットワーク、およびストレージにおける分離の問題をすでに解決しており、DevSecOps は企業がコード セキュリティとイメージ セキュリティを向上させるのに役立ちます。さらに重要なことに、最近の Ngnix 0day 脆弱性問題のように、ソフトウェア サプライ チェーンで脆弱性問題が発生すると、これを解決するためにビジネスをアップグレードする必要があります.コンテナ環境では、ビジネス バッチによって脆弱性問題を迅速に解決できます。プラットフォーム自体の問題も、ワンクリックのプラットフォーム アップグレードで解決できます。


エッジネイティブはビジネスのゴールですが、それはビジネス開発チームだけの責任ではなく、クラウドネイティブと同様にインフラやプラットフォーム側で十分なサポートを行う必要があり、コンテナはそれを実現するための重要なテクノロジーです。エッジ -ネイティブの手段。

コンテナ エッジ VS ハイパーコンバージド エッジ


 

顧客とのコミュニケーションにおいて、エッジ プラットフォームの問題を解決するためにハイパー コンバージェンスを使用することをためらう顧客もいます.ここでは、ハイパー コンバージェンスとコンテナーのエッジ コンピューティングへの適応度を技術的な観点から単純に比較できます。


ここでは、ハイパーコンバージェンスとコンテナ技術のアーキテクチャを抽象化します. 左側がハイパーコンバージェンスアーキテクチャです. 通常、複数のハイパーコンバージェンスサーバーがサイトに配置され、エッジ側の統合管理がクラウド管理によって実現されます.プラットフォームをクラウドで、右側がコンテナ技術 、物理サーバを現場で管理するKubernetesをデプロイし、クラウドでのコンテナクラウド管理によるエッジ側の一元管理を実現。


クラウドからエッジまで、これら 2 つのソリューションを 1 つずつ比較できます。まず、クラウドでは、ハイパーコンバージド ソリューションの管理オブジェクトは仮想マシンであり、本質的にリソースを管理し、アプリケーションの実行状態を認識することはできませんが、コンテナ ソリューションによって管理されるオブジェクトはコンテナです。 , ビジネス自体, ビジネスの運営と維持にとって非常に重要.


クラウド エッジ ネットワーク レベルでは、従来の管理フローおよび監視フロー データに加えて、帯域幅消費の重要なオブジェクトは、仮想マシン イメージまたはコンテナー イメージです.コンテナー イメージのサイズは、サービス自体に似ています。仮想マシン イメージの 1% ~ 10%。したがって、イメージをエッジ側に配信すると、コンテナ テクノロジによって、すでに不足しているクラウド側のネットワーク帯域幅をネットワーク レベルで大幅に節約できます。


エッジ側では、ハイパーコンバージェンスは仮想マシンを使用してサービスを実行します. 仮想マシンが実行された後、各仮想マシンは独立したオペレーティングシステムを必要とするため、仮想マシンの運用リソースは比較的高くなります. コンテナーは共有オペレーティング システムであり、コンテナーが占有するランタイム リソースは基本的にコンテナー内のビジネスと同様であり、追加の支出はありません。このように、コンテナ テクノロジのリソース占有には大きな利点があり、CPU やメモリなどのより多くの運用リソースをビジネス用に確保できます。


さらに, 最も重要なことは、ビジネスに対するプラットフォームのサポートです.コンテナーはより合理化され、柔軟です. 障害の自己修復、伸縮自在なスケーリング、およびグレースケール パブリッシングはコンテナーの強みであり、これらの仮想化の実装は面倒です.
したがって、顧客とソリューションについて話し合った後、ほとんどの顧客は純粋なコンテナ エッジ ソリューションを好み、コンテナを使用してニア エッジまたはエッジ ゲートウェイの構築をサポートし、仮想化、ハイパーコンバージェンス、およびコンテナの共同構築を遠方で使用します。エッジとクラウド。

クラウド ネイティブ エッジ コンピューティングは、ISV の提供、O&M を可能にします


 

従来のエッジ コンピューティングには明確な使用シナリオがあり、ビジネスがデータに近づくプロセスです。現在、ますます多くの ISV が、サービス提供と O&M の効率を向上させるために、エッジ コンピューティングのようなソリューションの採用を検討し始めています。ISV のこの部分には、教育、医療、ラジオやテレビなどの業界が含まれます。


従来、ISV は顧客ごとにオンサイト展開とオンサイト開発を行う必要があり、プロジェクトには数週間から数か月、さらには数年にわたるオンサイト サービスが必要であり、ISV の人件費を押し上げていました。


この問題を解決するために、ISV はエッジ コンピューティング ソリューションを採用して、リモート サービスの提供、運用、および保守の統合を実現し始めています。ソリューションは非常にシンプルで、各顧客環境にコンテナ管理プラットフォーム、つまり K8s を展開し、クラウドにエッジ管理モジュールを展開し、顧客環境をクラウド環境ネットワークに接続して、統一された運用を実現します。クラウド環境による顧客業務の維持管理。このアーキテクチャは、顧客サービスの応答速度をある程度向上させると同時に、プロジェクト フィールド サービスのコストを削減することができます。現時点では、これはまだ革新的なテクノロジー モデルですが、将来的には、企業が新しいビジネス モデルを形成し、運用能力を向上させ、持続可能な収益を達成するのに役立つ可能性があります。


クラウド側コラボレーションの新しいエクスペリエンスをすぐに開始


Lingqueyun の ISV パートナーになることを希望している場合、またはエンタープライズ レベルのコンサルティングと試用が必要な場合は、クラウド ネイティブ エッジ コンピューティングのベスト プラクティスを調べるために、当社にご連絡ください。

前: AceCon スピーチレコード | クラウド ネイティブ エッジ構築の実践共有

次へ: インテリジェント製造の次の目的地: クラウドネイティブ + エッジ コンピューティングの二輪駆動

おすすめ

転載: blog.csdn.net/alauda_andy/article/details/126649066
おすすめ