Red Hat と Verizon によるハイブリッド・モバイル・エッジの構築について

昨年、Verizon と Red Hat が連携し、Verizon 5G Edge と Red Hat OpenShift を使用してハイブリッド・モバイル・エッジコンピューティング (MEC) ソリューションを提供することを発表しました。これは、Kubernetes を使用して、AWS Wavelength によるパブリック 5G ネットワークと AWS Outposts によるプライベート 5G ネットワークを単一のコンピューティングメッシュに収束するための斬新なアプローチです。

そして現在、両社はマルチクラウド・ハイブリッド MEC に新しい抽象化レイヤーを追加しようとしています。お客様はエッジデプロイメントにおいてより多くの選択肢を求めており、物理的な配置、ネットワークの種類、クラウドプロバイダーの選択も同様に重要であると考えています。

re:Invent では主に Red Hat OpenShift のアーキテクチャに焦点を当てましたが、今回は、「なぜハイブリッド MEC なのか」を裏付ける理論について説明したいと思います。その主な 3 つの領域は次のとおりです。

1. MEC によって、最近のコンピューティングおよびネットワークの最適化をどのように活用できるか

2. 基盤となる Red Hat OpenShift の設計がいかに優れた柔軟性を備えており、先進的なアーキテクチャやテクノロジーに対応できるか

3. ハイブリッド MEC を活用すると、エンドツーエンドのバリューチェーンをどのように再設計できるか

5G Edge で実行する Red Hat OpenShift

Verizon 5G Edge で Red Hat OpenShift を使用すると、パブリックネットワーク上の 13 を超える地点 (Wavelength Zone など) のどこにでも、オンデマンドで低遅延のアプリケーションを柔軟にデプロイでき、プライベート・マネージド・ネットワーク上で拡張可能な場所の数に制限はありません。

画像出典

Red Hat OpenShift は、Verizon 5G Edge のあらゆる場所で開発者とアプリケーションのエクスペリエンスを標準化するのに役立ちます。おそらくさらに重要なのは、Verizon 5G Edge を使う場合、ユーザーは Red Hat Advanced Cluster Management for Kubernetes (ACM) を使用して単一画面からデプロイメントを実施できるため、よりシームレスな作業が可能になることです。また、Red Hat OpenShift を使用すると、広範な Red Hat パートナーが事前に統合を完了しているおかげで、同じツールを使用してアプリケーションの開発、管理、デプロイを行うことができます。加えて、Verizon 5G Edge が新しい地域、さらには新しいクラウドプロバイダーへと拡張した場合でも、同じエクスペリエンスが得られます。

これは朗報です。プライベートネットワークとパブリックネットワークで同時に低遅延のエクスペリエンスを提供できるため、データ・アーキテクチャとしてのアプリケーションを再考し、地理的に分散されたアプリケーション設計によってパーソナライズされたエクスペリエンスを提供することが可能になります。たとえば、このハイブリッド・エッジ・アーキテクチャを使用すると、物流会社は保有車両と支店のオフィスを単一のコンピューティングメッシュで接続できるので、コスト効率を高め、デプロイメントを容易にすることができます。

さらに、企業にとっては、クラウドそのものだけでなく、クラウド周辺のリソースを変革することも可能になります。専用のハードウェアを仲介せずにクラウドにオフロードできるため、柔軟性が高く、軽量で動的なデバイスプールが実現します。

エッジアプリケーションの未来は、新しいインフラストラクチャ・パターンや、5G 主導による新様式のネットワーク・インテリジェンスだけではありません。むしろ、パブリックネットワークとプライベートネットワークの両方で、クラウドからエッジにつながるコンピューティングメッシュを構築し、単一のアーキテクチャでアプリケーションのエクスペリエンスを統合することだと、Red Hatは考えています。Verizon は、Red Hat OpenShift を使用することで、どうすればこのようなエクスペリエンスが可能になるかを探求し始めました。

しかし、そもそもモバイルエッジはどのようにして生まれたのでしょうか。

エッジへのシフト

高速 5G ネットワークの出現により、企業はかつてないほどエッジを活用し始めています。しかし、あらゆることについてそうだというわけではありませんでした。

過去 10 年間、モバイルデバイスにはデータ量の増加、遅延の低減、クラス最高の信頼性が求められていたため、ネットワークのパラダイムが顧客の要求に対応するのは困難でした。

この課題に対処するために、クラウドプロバイダーは 2 つの補完的なアプローチを採用しました。それは、コンピューティングをエンドユーザーに近づけること、そして、ネットワークをダウンストリームデバイスに近づけることです。前者の例として、コンテンツ配信ネットワーク (CDN) は、高密度化されたポイントオブプレゼンス (PoP) を使用して、FaaS (Function-as-a-Service) 機能を備えた静的ストレージリソースを強化しています。これにより、コンピューティングとストレージのデプロイメントモデルがますます軽量化されました。しかしネットワークの動作が非決定論的であるため、エッジベースの FaaS で遅延の問題が発生する可能性が残ります。

そこで、ネットワークの最適化が同様の役割を担うようになりました。相互接続サービスがネットワークエッジをトポロジー的にクラウドに近づけたのと同じように、AWS Global Accelerator などのソリューションは、大規模なパフォーマンスを強化するための有用なアプローチを開発しました。コンピューティングをユーザーに近づける代わりに、サービスはユーザーをネットワークに近づけることができます。

どちらのソリューションも顧客のアーキテクチャに多大な価値をもたらしますが、モバイルの領域ではいずれも最もパフォーマンスの高いソリューションとはされていません。遅延の大部分がエア・インタフェースによって消費される場合、エッジでのコンピューティングの柔軟性を備えたネットワーク・アクセラレーターのパフォーマンスを真に実現できるのは、キャリアネイティブのサービスだけです。

モバイルエッジは、これまでで最も説得力のある機会の 1 つになっています。開発者は、リアルタイム・クラウド・コンピューティング・プラットフォームである Verizon 5G Edge を使用してその柔軟性を活用し、既存の仮想プライベートクラウド (VPC) 環境を、エッジワークロードと非エッジワークロードを管理するための単一画面から、パブリック 5G ネットワークのエッジに拡張することができます。開発者は、これらのオンデマンドの従量課金制コンピューティング環境を使用して、群集分析、予知保全、視覚障害者向けの視覚補助テクノロジーなどのソリューションを構築しています。

しかし、開発者は、エッジコンピューティングの関連モデルでこれと同じパブリッククラウドのエクスペリエンスを大規模に作成する、つまり、VPC 環境をプライベート 5G ネットワークのエッジに拡張する必要があります。それがなぜ重要なのでしょうか。

企業がアプリケーション・ワークフローを構築する際、アプリケーション・アーキテクチャ (Kubernetes など) が特定の環境に制約され、特定の地理的範囲を超えて拡張できないコンピューティングサイロが意図せずに導入されてしまうことがよくあります。しかし、遅延耐性のあるコンポーネント (コントロールプレーンなど) を再利用し、遅延による影響を受けやすいコンポーネントを単一のコンピューティング・クラスタ内で、数千キロ離れたパブリックネットワークとプライベートネットワークに分散させる方法があったとしたらどうでしょうか。

Red Hat OpenShift がエッジに適している理由

クラウドネイティブ・アーキテクチャで Red Hat OpenShift を使用する、最も基本的なソフトウェア抽象化の 1 つが、MachineSet の概念です。クラスタに必要なノード数を決定する場合、MachineSet はマシンの操作を管理し、次に、現在利用可能な基盤となるリソース (すなわち、VM) を管理します。

ReplicaSet が従来の Kubernetes 環境で安定した Pod のセットを維持するのと同じように、MachineSet は、クラウドプロバイダー、イメージ、論理ノード自体のフレーバーなど、基盤となる物理ハードウェアを表現します。

この MachineSet 抽象化の利点は、各マシンオブジェクトが特定のクラウドプロバイダーまたはデプロイメントモデルに固有である一方、MachineSet を組み合わせることでネットワーク自体の複雑さを抽象化できることです。たとえば、次に示すデプロイメントは、re:Invent 2021 で示された「Red Hat OpenShift Service によるアプリケーションのビルドとデプロイの高速化」です。

ここでは、Red Hat OpenShift で実装を単純化する方法の例として高可用性 (HA) を使用します。従来、AWS のような単一のクラウドプロバイダーでは、高可用性アーキテクチャはリージョン内の 3 つ以上のアベイラビリティゾーン (AZ) のそれぞれにある MachineSet で構成されるため、多くの障害ドメインが得られます。

ここにハイブリッド MEC 環境を追加すると、パブリック MEC (AWS Wavelength など) とプライベート MEC (AWS Outposts など) の両方にまたがる各エッジも障害ドメインとすることができます。このようにして、複雑さを増すことなく、これらのエッジコンピューティング・ゾーンのそれぞれで追加の MachineSet をインスタンス化できます。Red Hat OpenShift を使用すると、エッジを追加するにはデプロイメントのマニフェストファイルを追加するだけです。たとえ基盤となるインフラストラクチャのコンポーネントがそれぞれ 1,000 キロ以上離れたゾーンに存在していようが、それは変わりません。

この設計を証明するために、米国バージニア州北部の 3 つの AZ、ニューヨーク市とボストンの Wavelength Zone、テキサス州の専用の Outpost に、実際に Red Hat OpenShift クラスタを作成しました。すべて 200 行未満の YAML で書かれています。

これは、Red Hat OpenShift を使用して、複雑なオーケストレーションをよりシームレスに行う方法の 1 つにすぎません。MachineSet によって、単一のクラウドプロバイダーを超えて他のクラウドに拡張し、追加のエッジトポロジーを導入できます。インターネットを介して他のクラウドプロバイダーのコントロールプレーンに直接接続している限り、この拡張機能を同じクラスタの一部として実行することもできるため、運用上のオーバーヘッドをさらに削減できます。

今すぐ Red Hat OpenShift を使用して Verizon 5G Edge で構築

モバイルエッジがまだ始まったばかりであることは否定できません。それでも、昨年 Verizon では 22 カ国から 100 を超える 5G Edge Computing Challenge への応募があり、医療、小売、ゲームなどの分野に適用されるモバイルエッジの力が実証されました。

Verizon 5G Edge のフットプリントが拡大し続ける一方、一貫していることが 1 つあります。それは、今後数年間のエンタープライズ・アプリケーションのモダナイゼーションの過程において、エッジへの移行は、するかしないかの問題ではなくなるということです。むしろ、自身のニーズに最適なアーキテクチャを模索する顧客に対して、エッジは無限の変化を見せ続けるでしょう。

Verizon 5G Edge で実行する Red Hat OpenShift の詳細は、インフラストラクチャの基礎を確認するか、今年の MWC Barcelona に参加してください。