KubeCon Europe、テレコムオペレータを集めたTelecom User Groupは議論百出

KubeCon Europeは、Kubernetesを中心としたクラウドネイティブなオープンソースソフトウェアに関するカンファレンスだが、ベンダーやコミュニティと言ったソフトウェアを作る側だけではなく、使う側のユーザーも多数が参加している。キーノートに登場したSpotifyやConde Nast、そしてCERNもユーザーであり、ユーザー目線でクラウドネイティブなシステムについて語るのである。

そんなユーザーの中で、業界としてオープンソースソフトウェアに多くのコミットメントをしてきたのがテレコム業界だ。AT＆T、NTT、British Telecom、Telstraなどのキャリアと、Cisco、Juniper、Nokia、Ericsson、富士通、NECなどの機器やソリューションを納入するベンダーが、固定網、ワイヤレスサービス、そしてこれからはIoTなどの新しいサービスを提供するために、LinuxやOPNFV（Open Platform for NFV）、OpenStackなどを使ってプラットフォームやソリューションを構築してきた。

OpenStackを利用したネットワークサービスの提供という意味では、AT＆TやChina Telecom、NTTなどが先行してOpenStack上にソリューションを構築し、そのノウハウの共有をOpenStack Summitやユーザーグループが果たしてきた。それに倣ってか、CNCFも今回のカンファレンスでTelecom User Groupを立ち上げた。そしてそのキックオフミーティングとなったセッションが、3日目に開催された。今回のレポートでは、その内容を紹介しよう。

キックオフミーティングにはCNCFのDan Kohn氏が登場

「CNCF Telecom User Group」と題されたグループのキックオフというのがこのセッションの目的だが、ポイントはCNCFがVNF（Virtual Network Function）のクラウドネイティブ版とも言えるCNF（Cloud-native Network Functions）のテンプレートを出したことと、それがレベル分けされていたこと、そしてOpenStackとの棲み分けからKubernetesへの移行が明記されていたことだろう。

CNCF Telecom User Groupとは

では順番に紹介していこう。最初にグループの定義、位置付けだ。これについては、字の多い上記のスライドで概観できる。要約してみよう。

• このグループはソフトウェアの開発は行わない。しかしCNCF配下のプロジェクトの活動をフォローし、提案を行う
• 関連するプロジェクトは、以下のとおり
  • Kubernetes Federation v2（マルチクラスターに跨るKubernetesを管理するためのSIG）
  • Helm（Kubernetesのパッケージマネージャー）
  • Envoy（Istioで使われる軽量Proxy）
  • CNF Testbed（CNFをテストするためのフレームワーク）
  • OpenPolicyAgent（CNCFプロジェクト）
  • Prometheus
  • Fluentd
  • Jaeger
  • OpenTelemetry（監視及びロギングツール）
  • LinkerdとIstio（サービスメッシュ）
  • Operators（Kubernetes運用管理のためのパッケージフレームワーク）
  • エッジ向けワーキンググループ

ここで注目は「ソフトウェアを開発しないこと」と「サービスメッシュが含まれているが、IstioはCNCF配下ではないと明記してあること」、「CI/CDツールが含まれないこと」、「マルチクラスターからエッジまで視野に入れていること」だろうか。特にソフトウェアを開発しないという宣言は、重大といえよう。つまり、テレコムオペレーターに適したソフトウェアを個別に開発することはないという意味となる。

実はこのミーティングルームに集まった参加者のうち、テレコムオペレーター関係者は1/3程度で、残りはいわゆるオペレーターにソフトウェアやハードウェアを販売するベンダーであった。そのためか、賛同と失望のため息が聞こえたのは気のせいだろうか。つまりTelecom User Group（以下、TUG）自身がオペレーター用のソフトウェアを開発しないということは、ベンダーがそこに参入する余地があるということだ。それはその直後に解説されたCNFの部分で、より明らかになる。

VNFからCNFへ段階的に移行することを想定

このチャートで分かることは、「テレコムオペレーターはOpenStackから徐々にKubernetesによるコアネットワークの実現に移行するべき」というCNCFの発想だ。過去においてベアメタルの上にOpenStackもしくはVMware上に構築されたVNFが、現在はベアメタル上のOpenStackによるVNFとKubernetesの上のCNFに移行しているというのがCNCFの認識だ。そして将来的には全てがKubernetesの上のCNFに置き換わる、OpenStackの時に実装されたVNFはKubernetesの上で実装され、レガシーなVNFはOpenStack/KubeVirt/Virtlet上で実行するべきというビジョンだ。Kubernetesが全てのインフラストラクチャーになるという、いかにもCNCF的な視点である。

それを文章で説明しているのが次のスライドだ。

PNF/VNFからCNFへの進化

PNF（Physical Network Function）もVNF（Virtual Network Function）もしばらくは併存するが、最終的にはCNFに収束、エンタープライズもそれに倣ってモノリシックなシステムからクラウドネイティブなシステムに移行するというのがCNCFの発想だ。その上で、ではそのクラウドネイティブなネットワーク機能、すなわちCNFとは何か？　という部分の説明に用いられたのが、次の2枚のスライドだ。つまりCNFにはいくつかの階層があり、下からBronze CNF、一番上にGold CNFを定義し、一番上のGold CNFを使うようにレコメンドするという内容だ。

Bronze CNFの内容。レガシーなVNFをポーティングしただけ

Gold CNFはCNCFのプロジェクトをフルに使ったクラウドネイティブなものを指す

会場からは当然のように「BronzeとGoldがあって、Silverがないのはなぜか？」と言った質問が挙げられた。しかし「それはこの後で定義する」と言う答えに留まったが、意図するところは「Bronzeで止まるのではなく、Goldを作れ」というCNCFのメッセージだろう。つまりBronzeは悪いサンプルで、Goldこそが正解。将来のKubernetesベースのプラットフォームに対して、最適な解はこれだという明確な意思表示と言える。

そしてCNF Testbedについても言及した。CNF Testbedは、VNFとCNFの比較を行こと、VNFと同様の機能を実装していることを確認すること、そしてそれを、ベアメタルホスティングを手がける企業Packetが提供するベアメタルサーバーで実証することが目的のプロジェクトであると紹介した。

ここまででCNFを開発し、Testbedで検証するという一連の流れが解説されたことになる。その後「ペットと家畜」の例えを使って「ネットワーク製品の評価のためのラボはペットのように製品を扱っていた」として、CNF TestbedはCNFのテストを家畜に対して行うようにすると宣言した形だ。

ペットと家畜の例えでCNF Testbedを紹介

そしてTestbedの必要性についても「繰り返し実行できること」の重要性を語り、Googleの寄付によって3年分のテストが実行可能なマシンタイムは確保されていることなどを説明した。

Testbedの重要性を強調

ここまででTUGとCNF Testbedの説明を終わり、以降は参加者との質疑応答となった。一番最初に質問したのはCanonicalのCEO、Mark Shuttleworth氏だったのは驚きだった。最前列の席に座って真っ先に質問というよりも、自分が言いたいこと語って颯爽と部屋を去っていったShuttleworth氏は、テレコムオペレーターに対するベンダーとして存在感を出したとも言える。

CanonicalのCEO、Matk Shuttleworth氏

他にもEricsson、Juniperなどから様々な質問が出たが、回答するKohn氏からは「前の失敗を繰り返さない」という主旨のことをコメントしており、その度に失笑が漏れたのは印象的であった。

またChina Telecomのエンジニアからは「これまでOpenStackベースで多くの投資をしてプラットフォームを構築してきた。それからの移行については？」」という当然の質問が出されたが、それについては「これから議論していこう、今日はまだキックオフだ」ということで、いなされた形になった。参加したNTTのエンジニアが個別に質問した回答によれば、今日のスライドもまだ確定したものではなくあくまでもDraftであり、今度の議論に参加することで変わる可能性はあるということを強調していたという。

会場内でAT＆Tのエンジニアらしき参加者を見つけることはできなかった。AT＆Tは早くからOpenStackを活用しており、AirshipやStarlingXなど主導するプロジェクトも多く存在する。そういう立ち位置から見れば、この間までOpenStackでプラットフォームを作っていたのに、明日からはKubernetesで作り直せというのは、メリットなしでリスクしか見えない状況だ。さらに、移行パスがないというのでは、乱暴という印象は免れないだろう。

参加者の様子。なかなか質問が途切れない

TUGとしてプロジェクト化することには賛成だが、実際にどのような作業が発生するのかはまだ見えないというのが、この時点での感想だろう。事実、最後に「これからこのプロジェクトを推進するためにはボランティアが必要だ。誰かやりたい人は？」という問い掛けには、先ほどまで質問でうるさいくらいだった会場が一瞬静かになったのだ。OpenStackでのテレコムオペレーターのグループも実質それほど機能しているわけではないということを踏まえて、CNCFがどのようにこのグループTUGを発展させていくのか、注目したい。