Jump to section

VNF と CNF の違い

URL をコピー

仮想ネットワーク機能 (VNF) は、ディレクトリサービス、ルーター、ファイアウォール、ロードバランサーなどのネットワーク機能を提供するソフトウェア・アプリケーションです。これらは仮想マシン (VM) としてデプロイされ、多くの場合、通信プロバイダーにとっては、プロプライエタリー・ハードウェア上にあるレガシー・ネットワーク・アプライアンスの物理ネットワーク機能 (PNF) からデジタル・トランスフォーメーションを進める際の次のステップとなります。  

VNF はネットワーク機能仮想化 (NFV) アーキテクチャの主要コンポーネントであり、 NFV インフラストラクチャ (NFVI) 上に構築されます。このインフラストラクチャには、コンピューティング、ストレージ、ネットワーキングなどのリソースを VNF 間で効率的に割り当てる、Red Hat® OpenStack Services on OpenShift® のような仮想インフラストラクチャ・マネージャー (VIM) が含まれます。NFVI を管理し、新しい VNF をプロビジョニングするためのフレームワークは、NFV によって定義される管理、自動化、およびネットワーク・オーケストレーション (MANO) 要素内に構築されます。 

VNF は現在、標準的なネットワーク・アーキテクチャの一部ですが、デジタル・サービス・プロバイダーがよりアジャイルなサービスの提供を目指しているため、VNF には依然として制限があります。最初期における物理要素から VNF への移行では、多くの場合、ベンダーは単に組み込みソフトウェアシステム全体をアプライアンスから引き上げて、1 つの大きな VM を作成していました。しかし、これらの VM の最適化は行わなかったため、できあがったのは管理と保守が依然として困難なままの、非効率的な単一目的の仮想アプライアンスでした。 

さらに、このようなタイプのレガシー VNF では、クラウド環境におけるスケーラビリティを実現することが困難です。初期の VNF 実装を向上するための措置を講じたプロバイダーもおり、多くのサービスプロバイダーは、多数の VNF を実行する環境を単純化するために、共通の水平型 NFVI クラウド・プラットフォームを導入しました。これらの変化は、NFV を 5G またはエッジネットワークの基盤テクノロジーとして機能させるのに役立ちます。それでも、VM の「重み」は、アジリティ、スケーラビリティ、オーバーヘッドの削減を必要とする大規模な 5G またはエッジデプロイメント向けの VNF の効率を制限する可能性があります。  

アプリケーションに集中型および分散型ロケーションを使用するクラウドネイティブ・アプローチを導入するデジタル・サービス・プロバイダーは、柔軟性、スケーラビリティ、信頼性、可搬性の向上によるメリットを得ることができます。仮想化を超えて完全にクラウドネイティブな設計に移行することで、市場や顧客が要求する革新的で差別化されたオファーを迅速にデプロイするために必要な効率とアジリティを新しいレベルに押し上げることができます。

クラウドネイティブ・アプローチと他のアプローチを分ける重要な特長は、VM ではなくコンテナを使用することです。コンテナを使用すると、オペレーティングシステムやその他のサーバーリソースへのアクセスを共有しながら、実行に必要なすべてのファイルと一緒にソフトウェア (アプリケーション、関数、マイクロサービスなど) をパッケージ化できます。このアプローチにより、コンテナ内のコンポーネントを、すべての機能を維持したまま複数の環境 (開発、テスト、プロダクションなど) の間で、さらにはクラウド間でも容易に移行することができます。

VNF の進化形であるクラウドネイティブ・ネットワーク機能 (CNF) は、コンテナ内で稼働するように設計および実装されています。ネットワーク・アーキテクチャ・コンポーネントをコンテナ化することで、同じクラスタでさまざまなサービスを実行し、すでに分解されたアプリケーションのオンボードが容易になると同時に、ネットワーク・トラフィックを正しい Pod に動的に転送できます。

 

 

This figure shows the evolution of network functions from the traditional vertically integrated approach, to VNFs managed by a common VM orchestration platform, to CNFs managed by a common container orchestration platform.

この図は、従来の垂直統合アプローチから、共通の VM オーケストレーション・プラットフォームが管理する VNF、そして共通のコンテナ・オーケストレーション・プラットフォームが管理する CNF へのネットワーク機能の進化を示しています。  

これらの機能の多くをコンテナに移行する CNF の導入は、VNF の基本的な制限の一部を解決することができます。ネットワーク・コンポーネントのコンテナ化により、環境内のクラスタ間で機能を実行する方法と場所を管理できます。 

しかし、CNF はネットワーク機能をコンテナ化するだけではありません。コンテナのパッケージ化にとどまらず、クラウドネイティブ原則のメリットを最大限に活用するには、マイクロサービスへの分解、更新中の複数バージョンの許可、一般的なロードバランサーやデータストアといった利用可能なプラットフォームサービスの使用など、ネットワーク機能ソフトウェアの更なる再設計が必要になります。 

さらに、クラウドネイティブ環境の導入が拡大するにあたり、その移行の間は CNF とレガシー VNF を共存させなければなりません。デジタル・サービス・プロバイダーは、増大する需要を効果的に処理し、デプロイメントを加速し、複雑さを軽減するために、ネットワークの開発、デプロイメント、保守、運用を完全に自動化する必要があります。構成とデプロイメントの標準化された手法、オープンソース・コミュニティで成熟したツール、厳密なテストと認証は、プロバイダーにとって今まで以上に重要です。

オープンで一貫性のある基盤により、通信プロバイダーは、ロケーションやフットプリントに関係なく、信頼性に自信を持ってサービスを運用できます。NFV (VNF を使用) とクラウドネイティブ・アーキテクチャ (CNF を使用) 上にその基盤を構築すると、後者の場合は特に、柔軟性とアジリティが向上します。自動化は、効率的かつ容易なエコシステムの大規模運用の継続に重要な役割を果たし、デジタル・サービス・プロバイダーがサービスや機能をより迅速に変更および追加して、顧客のニーズや要求により適切に対応できるようにします。

関連資料

記事

ステートフルとステートレス

あるものがステートフルかステートレスかは、別の何かとの通信の状態が記録される期間と、その情報をどのように保存する必要があるかによって決まります。

記事

Quarkus とは

Quarkus は、Java 仮想マシン (JVM) およびネイティブコンパイルのために作成された Kubernetes ネイティブの Java スタックで、Java をコンテナに最適化します。

記事

サーバーレスとは

サーバーレスは、開発者がサーバーを管理する必要なくアプリケーションを構築および実行できるようにするクラウドネイティブ開発モデルです。

クラウドネイティブ・アプリケーションの詳細はこちら

製品

統合されたテスト済みのサービス一式を備えたエンタープライズ・アプリケーション・プラットフォームであり、ユーザーの選ぶインフラストラクチャを使ってアプリケーションを市場に投入するために活用できます。

リソース

e ブック

クラウドネイティブとハイブリッドクラウドの融合:戦略ガイド

e ブック

クラウドネイティブ・アプリケーションへの道

トレーニング

無料のトレーニング

Developing Cloud-Native Applications with Microservices Architectures