クラウドネイティブはテレコムを救うのか – CNF、Kubernetes、OpenStack から考える通信基盤

クラウドネイティブという言葉は、コンテナ、Kubernetes、マイクロサービス、宣言型 API、サービスメッシュのような技術要素と一緒に語られることが多くなりました。一般的な Web アプリケーションや社内システムであれば、この方向性はかなり自然です。

しかし、同じ言葉をテレコムの通信基盤へそのまま持ち込むと、話は急に難しくなります。通信基盤は単なるアプリケーション実行環境ではなく、加入者を収容し、旧世代との互換性を保ち、輻輳や障害に耐え、社会インフラとして継続動作することを求められる領域だからです。

したがって、テレコムにおけるクラウドネイティブ化は「Kubernetes を使えば解決する」という話ではありません。むしろ、Kubernetes や OpenStack、CNF、NFV、OSS を、通信基盤の重い要件にどう接続するかという設計課題です。

PNF から VNF、そして CNF へ

通信ネットワーク機能は、長く専用ハードウェア上で動作してきました。これは PNF、Physical Network Function として整理できます。その後、汎用サーバーと仮想化技術の普及により、ネットワーク機能は VNF、Virtual Network Function として仮想マシン上に載るようになりました。

NFV は、専用機器から汎用サーバー、仮想化基盤、OpenStack や VMware のような VIM へ機能を移す流れを制度化したものです。ETSI NFV の参照モデルも、この文脈で多くの製品や OSS に影響を与えてきました。

その先にあるのが CNF、Cloud-native Network Function です。ただし、CNF は単に VNF をコンテナに入れたものではありません。コンテナで起動するだけなら、それはコンテナ化であって、必ずしもクラウドネイティブ化ではありません。

段階	主な実行基盤	設計上の焦点
PNF	専用ハードウェア	装置単位の性能、冗長化、保守
VNF	仮想マシン / NFV 基盤	汎用サーバー化、VIM、仮想ネットワーク
CNF	コンテナ / Kubernetes	マイクロサービス化、スケーリング、宣言型運用、ライフサイクル管理

CNF はただのコンテナ化ではない

CNF の本質は、ネットワーク機能をクラウドネイティブな設計へ近づけることにあります。つまり、コンテナで動くことだけではなく、機能分割、柔軟なスケーリング、迅速なデプロイ、サービス単位でのリソース最適化、運用自動化までを含みます。

5G Core では SBA、Service Based Architecture が導入され、NF の機能は NF サービスとして分割されます。サービス間は API を介して連携し、従来の装置中心の構成よりもソフトウェア的な構造になります。

ただし、機能を分ければ単純になるわけではありません。NF サービス間の依存関係は増えます。複数拠点に分散配置されれば、ハードウェア、ネットワーク、ソフトウェア、リソース設計の組み合わせも増えます。ここに、クラウドネイティブの美しさとテレコムの現実の衝突があります。

Kubernetes だけでは通信基盤の要件を吸収できない

一般的な Web アプリケーションであれば、Pod、Service、Ingress、Service Discovery によって多くの通信要件を抽象化できます。Kubernetes は、このようなアプリケーション実行環境の抽象化に強いプラットフォームです。

一方で、テレコムの CNF では要求されるネットワーク構造が大きく異なります。VRRP、BGP / BFD、SCTP マルチホーミング、複数 IP アドレス、OAM と Data Plane の分離、SR-IOV、DPDK、CPU pinning、HugePages、NUMA 配置など、下位レイヤの物理性が強く残ります。

これは Kubernetes の限界というより、Kubernetes が抽象化している世界と、テレコムが守らなければならない世界の粒度が違うということです。テレコム CNF はクラウドネイティブでありながら、同時に非常に物理的です。

論点	一般的な Web アプリケーション	テレコム CNF
通信	Service / Ingress で抽象化しやすい	複数ネットワーク、経路制御、冗長化が前提になる
性能	水平スケールで吸収しやすい	レイテンシ、パケット処理性能、NIC、NUMA が効く
運用	アプリ単位で更新しやすい	通信サービス全体の継続性と互換性が重い
抽象化	Kubernetes の標準機能で成立しやすい	CNI、SR-IOV、DPDK、物理設計との接続が必要

ライフサイクルの短さが別の制約になる

Kubernetes を通信基盤へ持ち込むと、ライフサイクルの問題も大きくなります。Kubernetes や OpenShift は変化の速いソフトウェアであり、定期的な更新が前提です。一方、通信システムは長期運用、慎重な変更、サービス停止を避けることを強く求めます。

特に UPF のようなデータプレーン CNF では、OS、Kernel、Kubernetes、OpenShift、CNI、NIC、ドライバ、DPDK、SR-IOV の組み合わせが性能と安定性に直結します。CNF ベンダーが検証した構成を、オペレーター環境でも再現したいと考えるのは自然です。

その結果、マルチベンダー環境では、CNF ごとに求める Kubernetes / OpenShift のバージョンや設定が異なるという問題が起こります。この時点で「Kubernetes 基盤を一つ作って全部の CNF を載せればよい」という発想はかなり危うくなります。

VNF と CNF は共存する

すべてのネットワーク機能が CNF 化されるわけではありません。旧世代の 4G 系機能、IMS、固定網のコア機能、OSS / BSS、監視系などは、今後も VNF や仮想サーバー上で維持される可能性があります。

変化の少ない機能を無理にマイクロサービス化することは、必ずしも合理的ではありません。クラウドネイティブは唯一の正解ではなく、選択肢の一つです。新しい技術を使うことが目的ではなく、変更を小さく、安全に、速くすることが目的です。

その意味で、テレコム基盤は CNF と VNF の両方を収容できる必要があります。変化するものは CNF 化し、変化しにくいものは VNF として維持する。ただし、判断軸は変化速度だけではありません。DPDK、SR-IOV、NUMA、CPU pinning のような性能要件をどこまで強く持つのかも、CNF 化や基盤分離を考える上で重要です。

つまり、VNF と CNF の使い分けは、古いか新しいかではなく、変化速度、性能要件、運用責任、検証済み構成をどう扱うかで決めるべきものです。

OpenStack は古いのか

CNF や Kubernetes の話になると、OpenStack は古い仮想化基盤のように見えることがあります。しかし、テレコムの文脈では、OpenStack は単なる古いレイヤではありません。物理ハードウェア、ネットワーク、ストレージを抽象化し、API で扱える IaaS として意味を持ちます。

OpenShift on OpenStack のような構成では、OpenStack は Kubernetes とベアメタルの間に置かれます。もちろん、レイヤが増えることでオーバーヘッドや運用対象は増えます。しかし、その代わりにハードウェアや物理ネットワークの差分を吸収し、CNF ごとに必要なクラスタや仮想ネットワークを切り出しやすくなります。

この場合、OpenStack は余計な層ではなく、差分を吸収する層です。テレコムにおける抽象化とは、現実を消すことではありません。現実の複雑さを、どこで、どの粒度で、誰の責任として扱うかを決めることです。

そして、責任境界を決めた後に初めて、自動化の対象が見えてきます。OpenStack、Kubernetes、CNF、物理ネットワークのどこに差分があり、どこを標準化し、どこを個別制御するのかが決まらなければ、自動化しても運用は安定しません。

自動化は設計を代替しない

CNF 時代には自動化も重要になります。ただし、自動化は設計を代替しません。何を測るのか、何を制約条件にするのか、どの性能指標を守るのか、どのリソースを動的に調整するのかを決めなければ、自動化する対象が定まりません。

Kubernetes Operator や最適化エンジン、AI による運用支援を使うとしても、前提となる設計が必要です。障害時に何を自律制御し、何を人間が判断するのか。どこまでを標準化し、どこからを個別設計にするのか。そこを決めずに自動化だけを掲げても、運用は安定しません。

OSS は使うものではなく関わるものになる

テレコムクラウドは、大量の OSS の上に成り立ちます。Linux、Kubernetes、OpenStack、CNI、CSI、OVN、Ceph、Prometheus、Grafana、Ansible、Terraform / OpenTofu。これらを単なる無料部品として扱うだけでは、基盤の重要部分を他人任せにしていることになります。

重要なのは、どの OSS を使うかだけではありません。自社にとって失われると困る OSS は何か。どの OSS の設計思想に乗るのか。どこまで自社で理解するのか。どこにコントリビュートするのか。どの領域をベンダー任せにし、どの領域を自社の技術として持つのか。

希望は戦略ではありません。OSS を使うなら、その OSS の成熟度、活発度、コミュニティ、リリースサイクル、脆弱性対応、運用体制まで含めて見る必要があります。

クラウドネイティブは解答ではなく設計課題である

テレコムにおけるクラウドネイティブ化は、単純な技術置換ではありません。PNF を VNF にし、VNF を CNF にし、Kubernetes に載せれば終わるという話ではありません。

本質は、通信という重い要件を持つ領域で、何を抽象化し、何を残し、何を自動化し、何を標準化し、何を自社の技術として保持するかです。

クラウドネイティブは、テレコムを簡単にはしません。むしろ、これまで装置やベンダーの中に隠れていた複雑性を表面化させます。だからこそ、Kubernetes を使うことではなく、Kubernetes をどの責任境界に置くのかが重要になります。

テレコムクラウドの難しさは、クラウドネイティブであることではありません。クラウドネイティブでありながら、キャリアグレードでなければならないことです。

参考

• ETSI – Network Functions Virtualisation
• Kubernetes Documentation – Overview
• OpenStack Documentation