クラウドベースの 5G ネットワークのデプロイと運用

※この投稿は米国時間 2022 年 1 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

通信サービス プロバイダ（CSP）は混乱の時期を経験しています。全体的な収益の伸びは減速しており、パンデミックの前に始まっていた傾向が続いて、年間 1% 未満にとどまると予測されています。¹ 同時に、2020 年のデータ消費量はパンデミックの影響で 2019 年より 30% 増加しました。一部の事業者は 60% 増加したと報告しています。² 

収益へのプレッシャーとデータ トラフィック コストの上昇が相俟って、事業者は 3 つの基本的な方法によるイノベーションを余儀なくされています。第 1 の方法として、事業者は新しい収益源の確立を模索しています。第 2 の方法として、ネットワーク使用の増加をネットワーク コストの削減で埋め合わせる必要があります。第 3 の方法は、顧客エクスペリエンスを改善することにより、新規顧客を獲得する機会を増やすことです。

幸いなことに、5G は上記の 3 つの領域それぞれで未来への道を切り開いてくれます。ネットワーク スライシングやプライベート ネットワークなどのコンセプトを利用して、CSP は公共部門と企業の顧客に対して細分化されたネットワーク サービスを提供できます。ハードウェアとソフトウェアの分離により、独自の強みを持つ新しいベンダーが市場に参入することが可能になり、CSP は根本的に新しい方法でネットワークを構築、デプロイ、運用できるようになります。また、ワークロードをエッジに配置する機能は、CSP が消費者と企業の両方に魅力的なエクスペリエンスを提供することを可能にします。このブログ記事では、どうすれば CSP がクラウド ネットワークの強固な基盤を構築できるかについて説明します。

電気通信ネットワークの基礎知識

まずは、電気通信ネットワークが従来どのように構築されていたかを考えることが有益です。当初、ネットワークは物理ネットワーク機能（PNF）を使用して構築されていました。PNF は、ハードウェアとソフトウェアの緊密な組み合わせを使用して特定の機能を実行するアプライアンスです。PNF には特定のアプリケーション専用に構築されているという利点がありましたが、柔軟性がなく、アップグレードするのが困難でした。たとえば、新しい機能をデプロイするには、頻繁に PNF 全体を置き換える（つまり、新しいハードウェア アプライアンスをデプロイする）必要がありました。

デプロイメントのアジリティを高めるための第一歩は、仮想ネットワーク機能（VNF）のコンセプトでした。VNF は、市販（COTS）のハードウェアで動作するように設計されたソフトウェア ワークロードです。VNF は、ハードウェアとソフトウェアが統合されたアプライアンスを利用するのではなく、ハードウェアをソフトウェアから分離しました。それによって、ハードウェアとソフトウェアをそれぞれ別のベンダーから調達することが可能になりました。また、ハードウェアとソフトウェアのアップグレード サイクルを分離することも可能になりました。

しかし、VNF は PNF に優っていたとはいえ、まだ進化の途中の段階にありました。まず、VNF は通常は仮想マシン（VM）内で実行する必要があり、そのためにホスト オペレーティング システム（OS）と VM 内のゲスト OS を橋渡しするハイパーバイザが必要でした。ハイパーバイザは CPU サイクルを消費するため、非効率性を生じさせました。次に、VNF 自体がモノリシック機能として設計されることがよくありました。つまり、ハードウェアとは別に VNF をアップグレードすることは可能でしたが、そのようなアップグレードでは、VNF の一部にのみ影響する機能のアップグレードであっても、大規模な VNF 全体のデプロイメントが必要でした。その結果、リスクと運用の複雑さが生じ、PNF の場合と同様にアップグレードの遅延が発生しました。

クラウド ネットワークの基盤を構築する

クラウドベースのネットワークを確立する秘訣は、VNF からコンテナ化されたネットワーク機能（CNF）に移行するという課題の克服にあります。CNF は、それぞれが独立に操作できる小さなプログラムのコレクションとしてコンテナに編成されたネットワーク機能です。

コンテナは新しいコンセプトではありません。実際、Google は 15 年以上にわたってコンテナ化されたワークロードを使用しています。Google が開発してオープンソース化した Kubernetes は、世界で最も普及しているコンテナ オーケストレーション システムであり、Google の内部コンテナ管理システムである Borg をベースにしています。³ コンテナを使用することには多くのメリットがありますが、根本的なメリットは、リソース スケジューリング、プロセス間通信、セキュリティ、自己回復、ロード バランシングといった多くの面倒な（しかし重要な）タスクについてデベロッパーが悩まずに済むということです。

コンテナ化がネットワーク機能にもたらすメリットの例をいくつか考えてみましょう。まず、新しい機能を実装するためにネットワーク機能をアップグレードするときに、ネットワーク機能全体を再デプロイする必要がなくなります。代わりに、アップグレードの影響を受けるコンテナを再デプロイするだけで済みます。これにより、開発速度が向上し、アップグレードのリスクが軽減されます。なぜなら、大規模な変更を導入するアップグレードを時間を置いて実行する代わりに、小規模な変更をデプロイするアップグレードを頻繁に実行できるからです。小規模な変更は、理解しやすく、異常が発生した場合は容易にロールバックできるため、リスクが低くなります。さらには、セキュリティの脆弱性が発見されてからパッチがデプロイされるまでの時間が短縮されるため、セキュリティ体制も向上します。

セキュリティについて言うと、コンテナ化がネットワーク機能にもたらすメリットのもう一つの例は、自動的なゼロトラストのセキュリティ体制です。Kubernetes では、マイクロサービス間の通信をサービス メッシュで処理できます。サービス メッシュは、障害が発生した場合の再試行や通信に対するオブザーバビリティの提供など、サービス間通信の日常的な側面を管理します。また、セキュリティのような他の重要な側面も管理できます。たとえば、Anthos Service Mesh は、オープンソースの Istio サービス メッシュ（これも Google が共同開発したものです）のフルマネージド実装であり、相互 TLS（mTLS）を使用してすべての通信を認証および暗号化する機能と、個々のマイクロサービスに対応したきめ細かいアクセス制御をデプロイする機能を備えています。

クラウド ネットワークの自動化とオーケストレーション

CNF は大きなメリットをもたらしますが、課題もあります。従来の比較的少数のネットワーク アプライアンスに代わって今では多数のコンテナが存在し、それぞれを設定、管理、保守する必要があります。以前、こうしたプロセスの多くは手動で実施されていましたが、そうした手法を CNF が必要とする規模で経済的かつ確実に実施することは不可能です。

幸いなことに、この課題を解決するためのクラウドネイティブなアプローチが存在します。まず、CNF の自律的なデプロイメントと保守という問題について考えてみましょう。理想的な方法は、データとしての構成というコンセプトを使用することです。目的を達成するために実行する必要がある一連のステップの詳細な記述を指定する「コードとしてのインフラストラクチャ」などの命令型の手法と異なり、「データとしての構成」は宣言型の手法です。つまり、ユーザーは望ましい最終状態（目的である実際の構成）を指定し、自動化されたコントローラに依存しつつインフラストラクチャを継続的に操作して、その状態を実現します。Kubernetes はこのような自動化されたコントローラを備えています。素晴らしいことに、この手法はインフラストラクチャだけでなく、その上で動作するアプリケーション（CNF を含む）にも使用できます。このクラウドネイティブな手法により、デベロッパーは詳細な構成手順を記述する手間とそれに伴うリスクから解放されるため、アプリケーションのビジネス ロジックに集中できます。

別の例として、異常検出、根本原因分析、解決といったネットワーク パフォーマンスに関係する問題について考えてみましょう。クラウドネイティブなアプローチの最初のステップは、インフラストラクチャと CNF の両方のモニタリング データの取り込み、正規化、処理、保存を行えるデータ プラットフォームを作成することです。これにより、データセットを相互に関連付けて異常を検出できます。また、AI / ML の手法を使用して、発生前に異常を予測することさえできます。AI / ML は、異常が発生する原因を把握するためにも不可欠です。つまり、根本原因分析を実行して、理想としては問題が発生する前にそれを修正するために、自動化されたクローズド ループ コントローラを開発することができます。

エッジ向けの設計

VNF から CNF への移行は、現在 CSP が直面している課題に対処するための重要な要素ですが、それだけでは不十分です。CNF にはそれを実行するインフラストラクチャが必要であり、すべてのインフラストラクチャが均一に作成されているわけではありません。

典型的な 5G ネットワークについて考えてみましょう。アクセス ネットワークに関連付けられた機能など、いくつかの機能はエッジにデプロイする必要があります。このような機能には、低レイテンシまたは高スループット、あるいはその両者の組み合わせが必要です。5G ネットワークには、このような機能の例として、無線ユニット（RU）、分散ユニット（DU）、集中ユニット（CU）、ユーザー プレーン機能（UPF）があります。最初の 3 つは無線アクセス ネットワーク（RAN）の構成要素であり、最後のものは 5G コアの構成要素です。加えて、セッション管理機能（SMF）や認証およびモビリティ管理機能（AMF）など、他にもいくつかのコントロール プレーン機能がありますが、これらの機能はそれほど厳密なレイテンシと高スループットを必要としないため、より一元化されたデータセンターに配置できます。さらに、レイテンシ要件により特定のモデル（おそらくは無線トラフィック ステアリング用）をネットワーク エッジで実行する必要がある AI / ML のユースケースについて考えてみましょう。モデル自体はエッジで実行する必要がありますが、モデルのトレーニング（つまり、モデル係数の生成）は、多くの場合、計算集約型の処理であり、レイテンシに影響されないのでパブリック クラウド リージョンでの実行により適しています。

これらすべてのユースケースには 1 つの共通点があります。それは、ハイブリッド デプロイメント環境を必要とすることです。一部のアプリケーションは、可能な限りユーザーに近いエッジにデプロイする必要があります。その他のアプリケーションは、より一元化された環境にデプロイできます。別のアプリケーションはパブリック クラウド リージョンにデプロイして、そこで利用できる大量のコンピューティングとスケール メリットを活用することもできます。エッジ、プライベート データセンター、パブリック クラウドでデプロイメントを行い、それらすべての場所でセキュリティ、ライフサイクル管理、ポリシー、オーケストレーション リソースの一貫したセットを備えた単一の環境を使用できるとしたら、たとえ革新的とは言えなくても、便利ではないでしょうか？それこそが、Anthos によって実現された Google Distributed Cloud が実際に達成したことです。

Google Distributed Cloud を使用すると、以下に示すような 5G ネットワークのデプロイメントを設計できます。

クラウド ネットワークのビジネス上のメリット

上記のアーキテクチャが持つ技術的なメリットだけでなく、ビジネス上のメリットについても考えてみましょう。第 1 に、ハードウェアとソフトウェアの分離というベスト プラクティスに従うことで、CSP はインフラストラクチャとネットワーク機能を異なるベンダーから調達できるようになり、それによってベンダー間の競争が促進されます。第 2 に、個々のワークロードが適切な場所に正確に配置されることで、ハードウェア リソースの効率的な利用が可能になり、低レイテンシで高スループットの魅力的なサービスがユーザーに提供されます。第 3 に、アーキテクチャで共通のハイブリッド プラットフォーム（Anthos）が利用されるので、さまざまな場所のインフラストラクチャの間でワークロードを簡単に移動できます。第 4 に、ワークロードをマイクロサービスに分割することで、企業ユースケースに対応した新しい機能やアプリケーションの開発において、製品化までの時間が短縮されます。最後に、コンテナ管理プラットフォームは、ネットワーク機能とエッジ アプリケーション双方の同一インフラストラクチャ上での同時デプロイをサポートします。これにより、事業者は AR / VR などの新しいエクスペリエンスを、可能な限りユーザーに近いベアメタルに直接デプロイできるようになります。

次世代クラウド ネットワークの現状

他にも多くの点に言及できますが、おそらく最も重要なポイントは、このアーキテクチャは将来の夢ではないということです。それは今まさに存在しています。Google は、大手の CSP およびネットワーク ベンダー パートナーと協力してこのアーキテクチャをデプロイしており、5G に期待される成果を実現できるよう支援しています。その成果とは、新たな収益を上げ、運用コストを削減し、新しい顧客エクスペリエンスを実現することです。

詳しくは、CSP ネットワークのクラウド化を扱った動画シリーズをご覧ください。

エッジで何が起こっているかを発見する どうすれば CSP はエッジでイノベーションを起こせるか 

^{1. Statista、2019 年～2024 年の世界の通信サービス支出の拡大予測}

^{2 PricewaterhouseCoopers、2021 年～2025 年のグローバル エンターテイメントおよびメディアの展望}

^{3. Borg: Kubernetes の前身}