CDN をベースとしたエッジコンピューティング プラットフォームの設計と考察

[[343187]]

CDN の重要性は、CDN ビジネス自体だけでなく、CDN のインフラストラクチャ属性にもあります。 CDN ノードはグローバルに分散されています。 5Gの正式商用化により、CDNは現在、最大規模と最強のコンピューティングパワーを備え、エッジコンピューティングに最適な場所になります。ただし、エッジ コンピューティングは単独で存在するのではなく、クラウド センターと連携する必要があります。本稿では、CDNの観点からクラウド、エッジ、エンドが連携したエッジコンピューティング基盤の構築方法を紹介します。

CDNとエッジコンピューティング

CDN の正式名称は Content Delivery Network です。 CDN は、既存のネットワーク上に構築されるインテリジェントな仮想ネットワークです。さまざまな場所に配置されたエッジサーバーに依存し、中央プラットフォームの負荷分散、コンテンツ配信、スケジューリングなどの機能モジュールを使用して、ユーザーが必要なコンテンツを近くで取得できるようにし、ネットワークの混雑を軽減し、ユーザーのアクセス応答速度とヒット率を向上させます。 CDN の主要技術には、主にコンテンツの保存と配信技術が含まれます。

上記は百度百科事典からの説明です。簡単に言えば、CDN はスペースを時間と交換します。スペース的には、エンドユーザーに近いエッジノードに分散されます。時間的には、エンドユーザーはエッジノードから直接リソースを取得するため、ソースサイトに直接アクセスする必要がなく、ユーザーエクスペリエンスが向上します。

あまり適切ではない例えを挙げると、例えば、国内の電子商取引プラットフォームは現在、物流システムを構築しており、1つの都市に1つまたは2つの大規模な物流センター（ソースステーション）が建設され、3番目と4番目の都市に小さな物流センター（エッジノード）が建設されます。ダブルイレブンのような大規模なプロモーションでは、ビッグデータの統計に基づいて、各地の小規模な物流センターに商品を事前に準備し（予熱）、ユーザーがすぐに荷物を入手できるようにします（近くで入手）。したがって、CDN は、パッケージではなく画像、ビデオ、ソフトウェアのインストール パッケージを配布するという点を除けば、インターネット全体の物流システムと考えることができます。一般的に、CDN サービス プロバイダーは、比較的良好なサービス品質を提供するために、数百または数千のエッジ ノードを用意する必要があります。

CDN はすでに十分に実証された成熟したテクノロジーです。 CDN がインターネット全体のトラフィックの大部分を担っていると言っても過言ではありません。 CDN がなければ、さまざまな繁栄したビデオ Web サイト、ライブ ブロードキャスト プラットフォーム、ショート ビデオ アプリは存在しなかったでしょう。同時に、長期にわたる開発を経て、CDN はサプライ チェーン システム、ノード構築、ネットワークの運用と保守において非常に成熟した経験と蓄積を蓄積してきました。

インターネットスマート端末デバイスの急増と5Gおよびモノのインターネット時代の到来により、従来のクラウドコンピューティングセンターの集中型ストレージおよびコンピューティングモデルでは、端末デバイスの適時性、容量、およびコンピューティング能力のニーズを満たすことができなくなりました。クラウドコンピューティングの機能をエッジ側やデバイス側に落とし込み、センターを通じて配信、運用、保守、管理を一元的に行うことが、クラウドコンピューティング、つまりエッジコンピューティングの重要な発展トレンドとなります。

IDC は、2020 年までに世界中で 500 億以上の端末とデバイスがインターネットに接続され、データの 40% 以上がネットワークのエッジで分析、処理、保存されると予測しており、エッジ コンピューティングに十分なシナリオと想像の余地が提供されます。

エッジ コンピューティングの階層構造には、クラウド、エッジ、エンドが含まれます。

クラウド、集中型クラウド: 従来のクラウド コンピューティングの中心ノードであり、豊富なリソース、強力なコンピューティング能力、強力なスケーラビリティを備え、複数のリージョンにサービスを提供しますが、エンド ユーザーからは遠く離れています。同時に、クラウド センターはエッジ コンピューティングの制御側であり、ネットワーク全体のコンピューティング能力とデータの統合管理、スケジュール設定、および保存を担当します。

インフラストラクチャ エッジ: 通常、市、郡、地区などの特定のエリアにサービスを提供します。対象サービスエリアから10～30km離れた場所に設置され、対象サービスエリアのニーズに合わせたコンピューティング、ストレージ、ネットワークサービスを提供します。インフラストラクチャ エッジは通常 IDC 内に配置され、十分なコンピューティング能力とストレージ容量を備え、専用回線または CDN ノードなどのバックボーン ネットワークによってセンターに接続されます。インフラストラクチャ エッジは、アクセス エッジとアグリゲーション エッジの 2 つのレイヤーに分けられます。アクセス エッジはデバイス エッジに近く、ユーザーまたはデバイス エンドに近くなります。集約エッジは、1 つ以上のアクセス エッジからデータを集約し、クラウドと対話します。

デバイスエッジ：携帯電話、スマート家電、各種センサー、カメラなどの端末デバイス。

CDN はエッジ コンピューティングの一形態と見なすことができ、現在、最大かつ最も強力で、最も成熟したビジネス形態です。ただし、CDN のビジネス モデルでは、より多くのエッジ コンピューティング シナリオをサポートするために、技術アーキテクチャをアップグレードする必要もあります。

エッジコンピューティング技術

エッジ コンピューティング テクノロジーは、従来のロジックに従って IaaS、PaaS、SaaS に分類することもできます。

IaaS:エッジで仮想マシンを提供することは、クラウド センターで ECS を購入することと似ていますが、マシンがエッジ IDC に展開される点が異なります (ここでのエッジ IDC は、実際にはクラウド センター IDC を基準としています)。ただし、ネットワークの状況や安定性はクラウドセンターとは異なります。結局のところ、クラウド センターには冗長性を備えた数万台のマシン、専任のオンサイト人員、コンピューター ルーム、ネットワーク メンテナンスがありますが、エッジ ノードにはこれらの条件が備わっていない場合があります。ただし、使用シナリオは明らかに異なります。たとえば、エッジで非常に高いデータ信頼性要件を持つサービスを展開することはお勧めしません。

PaaS:仮想マシンを提供する方法は、一部のユーザーにとって、運用と保守が少し面倒になる可能性があります。たとえば、マシンが異なる場所に配置され、異なるオペレーターに属している場合、異なる場所のネットワークは同じではなく、コンピューター ルームでもネットワークのカットオーバーが発生する場合があります。これらの仮想マシンの管理には多大なコストがかかり、サービスを迅速に切り替えることが困難になります。この場合、ユーザーがエッジ リソースを管理およびスケジュールできるようにするために、エッジ シナリオ用の PaaS サービスが必要になります。コンテナと K8S は、運用と保守のスケジュール レベルでは優れたソリューションです。運用と保守の問題を解決した後、PaaS に対するユーザーの需要はより多様な機能、特に各種ミドルウェア、EdgeKV、EdgeStore などに対する需要に高まります。たとえば、KV にはネットワーク全体でデータを同期する機能が必要です。

SaaS: CDN は典型的な SaaS サービスであり、主に静的ファイル (ファイル、画像、ビデオ) の高速化、ストリーミング メディアの高速化、動的高速化が含まれ、その派生形式にはセキュリティと P2P も含まれます。さらに、ビデオ AI も将来的には重要な SaaS 機能となります。たとえば、自動運転や IoT のシナリオでは、遅延を確保するためにエッジで直接ビデオ AI 処理を実行できることが重要な要件となります。

プログラム可能な CDN:一般的なコンピューティングへの移行に加えて、CDN の重要な方向性はプログラム可能な CDN への移行です。簡単に言えば、関数コンピューティングまたはスクリプトを通じて CDN ロジックを制御することです。たとえば、Cloudfare の EdgeWorker は、エッジで JS スクリプトを実行するための V8 エンジンをサポートしています。この技術ソリューションは、コンテナと比較して、より軽量で、コストが低く、起動時間が短くなります。

エッジ コンピューティングは孤立して存在しているわけではないことがわかります。エッジ コンピューティングは、クラウド コンピューティングと連携する必要があり、いわゆるクラウド エッジ エンド コラボレーションが必要です。

もっと鮮明に表現すると、クラウド コンピューティングは、コンピューター インテリジェンス システム全体の頭脳に例えられます。エッジ コンピューティングは、このシステムの目、耳、手、足となります。クラウド コンピューティングに完全に依存するコンピュータ システムは、あらゆることについて本部に相談しなければならない軍隊のようなものです。外部と頻繁にやり取りする必要がある場合、応答が遅くなり、ネットワークに問題が発生すると完全に役に立たなくなります。エッジコンピューティングが加わることで、中級・下級の役員が主体的なイニシアチブを発揮し始め、ある程度は自主的にインテリジェントな判断や行動決定を行えるようになるようなものです。同時に、スクリーニングされた情報の一部のみを本社にアップロードする必要があります。ネットワーク通信の負担を大幅に軽減します。一時的に本社との連絡が途絶えた場合でも、ある程度の決定は独自に行うことができます。

クラウド コンピューティングと比較して、エッジ コンピューティングにも多くの課題があります。 CDN を例にとると、エッジノードは広範囲に分散しており、単一ノードの規模は小さい (1 台から 100 台程度) です。ほとんどのノードにはオンサイト担当者がいないため、メンテナンス サイクルは長くなります (1 ～ 2 週間)。同時に、ノード ネットワークは複雑で制御不能です。ネットワークのカットオーバーやオペレータの禁止は一般的です。州と国（海外）の間には非常に複雑な通話リンクがあります。

これらの問題に直面して、スケジュール/災害復旧機能、運用および保守機能に対して比較的高い要件を満たす必要があります。 CDN のビジネス モデル自体は、本来、災害耐性とスケジュール可能性を備えています。つまり、ノードに障害が発生した場合、トラフィックを他のノードに切り替えることができます。 CDN ノード アーキテクチャも比較的シンプルで、4 層ロード バランシング (LVS) + 7 層ロード バランシング (Nginx または HaProxy) + キャッシュ サービス (Squid) という古典的な 3 層アーキテクチャです。そのため、CDN の運用と保守も比較的簡単です。マシンは主にデータをキャッシュするため、マシンがクラッシュしても全体的な影響は大きくなく、データの移行も必要ありません。

しかし、CDN が一般的なエッジ コンピューティング プラットフォームに進化する場合、スケジューリング/災害復旧および運用保守機能がスケーラビリティの大きなボトルネックになります。エッジ シナリオでは、スケジューリング、災害復旧、運用と保守をどのように行うかがより重要になります。

したがって、コンテナの軽量性と DevOps 属性を Kubernetes のスケジューリングと組み合わせると、現在のところエッジ コンピューティングに非常に適していると思われます。

エッジコンピューティングにおけるコンテナの実装

コンテナと Kubernetes の適用シナリオは、主に大規模な中央クラスター シナリオです。現在、エッジでのアプリケーションフォームも検討・実践中です。現在、エッジ向け Kubernetes のシナリオは次のとおりです。

K3S: K3S は、Rancher のオープンソースの軽量 Kubernetes ディストリビューションです。 K3S は、Kubernetes コードを大幅に削減し、メインのコア コードのみを保持して作成されます。これは、エッジ コンピューティング環境の x86、ARM64、および ARMv7 プロセッサ上で実行される、小規模で管理しやすい Kubernetes クラスターに対する需要の高まりに対応するためです。 K3S は主にアダプタ側 (デバイス エッジ) のシナリオで使用され、Kubernetes は端末デバイス上で実行できるように簡素化されていることがわかります。

KubeEdge: KubeEdge は、Huawei がオープンソース コミュニティに貢献しているプロジェクトです。名前が示す通り、これもまたリアルエッジのシナリオです。 KubeEdge の利点はデバイス接続にあります。複数のプロトコルをサポートし、標準の MQTT ベースの通信を使用できるため、新しいノードやデバイスを使用してエッジ クラスターを効果的に拡張できます。 KubeEdge の主なシナリオはエッジ アクセス レイヤー (Access Edge) であり、さまざまな IoT 端末デバイスのアクセス問題を解決します。

ACK@Edge: ACK@Edge は、Alibaba Cloud ACK (Kubernetes) のエッジ対応形式です。 ACK@Edge は、その実装においてネイティブ Kubernetes のすべての機能を保持します。すべてのエッジ関連機能はアドオンを通じて実装されます。マスターはクラウド センターに展開され、ノードはエッジに配置されます。 ACK@Edge は、CDN シナリオなどのインフラストラクチャ エッジに適しています。

CDN の実装シナリオを例にとると、クラウド センターに Kubernetes マスターを展開し、クラウド センターが配置されているリージョンの近くの CDN ノードを Kubernetes に接続し、最後に Kubernetes 上にフェデレーション機能を構築してグローバル コンテナ スケジューリングを実行するという形式になります。これにより、Kubernetes のスケジューリング機能とコンテナの DevOps 機能を活用できるようになります。詳細については、https://yq.aliyun.com/articles/711767 を参照してください。

今後の見通しと動向判断

CDN からエッジ コンピューティング プラットフォームへの変革。 CDN はすでに非常に成熟したテクノロジーとビジネスです。成熟しているため、均質化が進んでいます。一方で、CDN事業の粘着性が十分ではない（DNS事業への転換で断ち切られてしまう）ため、現在の国内CDN事業環境はあまり良くありません。 CDN 業界は価格面でレッドオーシャン化しており、CDN メーカーも戦略的にエッジ コンピューティング プラットフォームへの移行を進めています。しかし、5Gはまだ大規模に商用化されておらず、変革への道には実装シナリオの不確実性、顧客の受け入れが不十分であることなど、多くの問題があります。しかし、変化は失敗する可能性があり、変化しないことは間違いなく遅れをとることにつながるため、まずは内部の力を高め、CDNに新しい技術（仮想化/コンテナ/AI）を実装および改良し、さまざまな新しいビジネスとシナリオを積極的に模索することが最優先です。

安全なコンテナは重要な機能であり、コンテナは当然エッジ コンピューティングに適しています。ただし、コンテナには、セキュリティと分離という比較的大きな欠陥もあります。これが、エッジ コンピューティングの主な販売形態が依然として仮想マシンである理由です。したがって、安全なコンテナは、コンテナの DevOps 属性を備えながら、より優れた分離とセキュリティの保証も提供するため、最適なソリューションです。 Kata セキュア コンテナは今年急速に発展しており、セキュア コンテナはエッジ コンピューティングの重要なテクノロジです。

ビデオ AI とエッジ コンピューティングは自然に組み合わせられます。ビデオ AI には現在、顔認識によるアクセス制御、自動ゴミ分別、カフェテリアのセルフサービス チェックアウトなど、多くの応用シナリオがあります。ビデオ AI は今後も急速に発展し続けることが予想されます。しかし、規模が拡大し、シナリオが検討されるにつれて、ビデオ AI における低遅延の需要はますます緊急なものになるでしょう。ビデオ AI 機能をエッジ ノードに展開できる場合: クラウド センターがビッグ データ計算と AI トレーニングを実行し、AI トレーニングの結果がエッジ ノードに送信されます。エッジはビデオ アクセスを担当し、エッジで直接ビデオを処理します。

質疑応答

Q: CND ノードをエッジ コンピューティング ノードに変換する主な側面と Alibaba の実践について紹介していただけますか?ありがとう。

A: 現在、CDN 変革は、インフラストラクチャ変革 (スイッチ、モデル)、ソフトウェア レベルの変革 (コンテナ化)、CDN ノード アーキテクチャ変革 (従来の 7 層ロード バランシングを Kubernetes の Ingress コントローラーに変更するなど) の 3 つの部分で構成されています。

Q: CDN の実装シナリオとしては、クラウド センターに Kubernetes マスターをデプロイし、クラウド センターが配置されているリージョンの近くの CDN ノードを Kubernetes に接続するという形になります。各リージョンのノードが Kubernetes ノードとして扱われるということですか?

A: たとえば、Alibaba Cloud Center の杭州リージョンに Kubernetes マスターを作成し、杭州省全体のすべての CDN ノードをこの Kubernetes マスターに接続します。 CDN ノードはコンピュータ ルームを指します。コンピュータ ルームには 1 ～ 100 台のマシンがあり、CDN ノード全体のすべてのマシンが接続されます。

Q: アリババはエッジコンピューティングと 5G を組み合わせる計画はありますか?具体的な接続ポイントは何ですか?

A: 今年の Yunqi カンファレンスで、当社は 5G エッジ コンピューティング戦略を発表しました。ビデオのリプレイはオンラインでご覧いただけます。現在、具体的な統合ポイントは、シティブレインとシティクラウドです。ただし、5Gはまだ大規模に商用化されていないため、私たちも模索中です。 https://yunqi.youku.com/2019/hangzhou/review?spm=a2c4e.11165380.1395223.1

Q: 将来的に Docker は安全なコンテナに変わりますか?安全なコンテナがトレンドです。開発者は何に注意すべきでしょうか?

A: 実際、Kata と通常の runC コンテナの動作に大きな違いはありません。何に重点を置いているかと言うと、現時点ではカーネル部分だと思います。Kata コンテナはカーネルに対する要件が比較的高く、その安定性にはまだ磨きをかける必要があるからです。

Q: Kubernetes マスターノードをクラウドにデプロイし、CDN ノードをエッジノードとして使用します。 Kubernetes の場合、ノード間のネットワーク通信要件は比較的高くなります。ネットワークが不安定でエッジノードとマスターノードが切断されている場合、エッジノードでサービスの自律性をどのように実現できますか?

A: これは ACK@Edge が解決する問題です。 ACK@Edge は、エッジ テスト マシンに Edgehub コンポーネントを展開します。 kubelet は kube-apiserver を直接要求するのではなく、Edgehub を介して APIServer を要求します。 Edgehub はキャッシュ機能とプロキシ機能を提供し、ネットワークが切断された場合でもエッジノード上の kubelet の正常な動作を保証できます。この機能はエッジ自律性と呼ばれ、ACK によって強化された機能です。

Q: アリババがエッジ コンピューティングでカバーできると考えている実際の価値シナリオや顧客グループについてお話しください。既存のシナリオの多くは、中央コンピューティングで対応でき、必ずしもエッジ コンピューティングは必要ないようです。特に、エッジ コンピューティング ノードでは、あまり価値のない仮想マシンも販売されています。ありがとう。

A: CDN を例に挙げると、CDN はエッジで高速化することでユーザー エクスペリエンスを向上させます。仮想化は単なる形式であり、たとえば、仮想マシンを購入して独自の CDN を構築するだけです。したがって、エッジのシナリオはセンターのシナリオとは明らかに異なります。たとえば、シティブレインにアクセスするには近くのノードが必要です。すべてのトラフィックがセンターに戻されると、センターにかかる圧力は非常に高くなります。

Q: セキュアコンテナのストレージパフォーマンスを考慮しましたか?アクセス ポイントはエッジに配置する必要がありますか、それともクラウドに配置する必要がありますか?

A: 安全なコンテナは最終的にはエッジで実行されます。安全なコンテナの保管は現在大きな問題となっており、Kata のオープンソース ストレージ ソリューションのパフォーマンスは良くありません。 Alibaba Cloud のカーネル チームは多くの最適化を行っており、現時点ではパフォーマンスが大幅に向上しているはずです。

Q: コンテナのセキュリティに関して注意すべきことは何ですか? Kata 以外に、Kubernetes で dockerd を使用する場合のセキュリティに関する推奨事項はありますか?

A: 安全なコンテナを使用するには、まず Kubernetes をruntimeClass に適応させる必要があります。 2 番目に、カーネルの要件も比較的高いです (より安定した 4.* カーネルである必要があります)。セキュリティに関するアドバイス: 証明書を追加し、ポートを変更してください。そうしないと、コンテナーが外部から簡単に挿入される可能性があります。その他のセキュリティに関する提案: クラウド製品はセキュリティ機能が比較的高いため、直接使用してください。

Q: CDN トラフィックの配信はどこで行われますか? DNS ですか、それとも GSLB ですか?リモート災害復旧も同様の方法で実行できますか?

A: CDN のトラフィック分散には、DNS、HTTPDNS、302 スケジューリングが含まれます。 CDN 自体は成熟した技術であり、スケジューリングも非常に成熟した技術です。