Kubernetes登場でCNFの作り方が大きく変化した
辻広志氏（以下、辻）：ここは簡単、簡単と言ったらアレなのですが、みんなが共感しやすいところだったので、最初に入れました。では続いて、ネットワークファンクションの中でのOSS利用に、入っていきたいと思います。
（スライドを示して）これも私見なので異論がある方がいたら申し訳ないのですが、最近のテレコムのアプリケーション、商用アプリケーションは……。どのベンダーがというわけではなくて、これは一般的な話だと思ってください。
昔はVNF（Virtual Network Function）まではバーチャルマシンで提供されていたこともあって、垂直統合のアーキテクチャというか、ソフトウェアスタックだったと思います。先ほど言ったように、LinuxのOS部分は普通のLinuxが使われていたりしますが、ベンダー独自のミドルウェアやHA機能があったりします。
そして、そこにベンダーのアプリケーションがあって、データベースも場合によってはベンダー独自のものもありますが、例えば商用でDBでOracleさんのやつが入ったり。監視のコンポーネントも基本的にはテレコムの専用で。
私もよく見ていましたが、きれいと言うか、専用のGUIが用意されているものがよくあったなぁと思います。
やはりKubernetes登場でCNF（Cloud-native Network Function）という流れになって、作り方が大きく変わってきているなと思っています。（スライドを示して）右手に書いてあるとおり、基本的にKubernetesのエコシステムをうまく使おうとみなさんが努力しているので、Kubernetesの上に自分たちに合うCNIやCSIを持ってきて、その上にはベンダーがもちろんアプリケーション、コアの部分（を持ってくること）もあります。
これは1個しか書いていませんが、これがPod（コンテナ）としては複数あったりします。インメモリデータベースがあったり、監視の部分はPrometheusを使っていたり。データベースもOSSのポスグレ（ PostgreSQL）を使っていたり、Maria DBを使っていたりすることが多いなと。これは感覚論で統計はなにも取っていないですが、私にはこういうふうに見えています。
モダンな作り方に変わってきているという意味合いでは、これはやはり良い側面もあるとは思うし、先ほど言っていたように技術習得として左側（垂直統合型アーキテクチャ）のものは世の中で一般で触れられないものなので、エンジニアから見た時に学習コストが高かったかなと。
それに対して右側（クラウドネイティブなアーキテクチャ）は一般的で、どこでも使えるソフトウェアを使っているので（技術習得という面で）、これはもちろんいい点だなと思います。
ただ反面として、やはりどうしてもベンダーサイロなかたちになっているなと私自身は見ていて思っています。
例えばあるベンダーはデータベースにMySQLを使っているかもしれないし、あるベンダーはポスグレを使っているかもしれない。あるベンダーは監視をPrometheusにしているかもしれないし、あるベンダーはzabbixを使っているかもしれない。やはり使っているソフトウェアコンポーネントが、似ているけどちょっとずつ違うような感じだなと思っています。
こうすると、クラウドネイティブは「データベースだったらPaaSのDBaaS、DB as a Serviceがあって、それをみんなが使ってくれる」みたいな世界観を本当は目指したいのかなというような気もしてきます。
“サーティファイドプログラム”も増えたが、まだ少しベンダーサイロっぽい
辻：（スライドを示して）あともう1点、ちょっと違う切り口ですが、やはり各NFベンダーも、あるいはプラットフォームを売っているベンダーも、最近はやはりサイロだけではやっていけない。「自社の基盤で自社のアプリケーション」だけだとやはりやっていけないとなっているのだと思っています。“サーティファイドプログラム”というもの（については）私も頻繁に聞くなぁと思っています。
あるベンダーは、例えば「Red HatさんのOpenShiftをサポートしていますよ」「VMwareさんのTelco Cloudサポートしていますよ」あるいは「AWSを使えますよ」みたいな感じで、「サーティファイドプログラムとして試験した結果でサポートできますよ」と提案をもらうことが増えたなと私自身は思っています。
ただ、逆の言い方をすると、「サーティファイを取っていないところは使えないのか？」とか。それこそ先ほどのPaaSじゃないですが、そういうところもあるなと思っています。
このままでいいのかということで、先ほど私の課題感や良い（と思う）点も含めて言いましたが、やはり「まだちょっとベンダーサイロっぽくないですか」というところがまず1点です。
あるいは先ほど言ったみたいに、認定されるのは良い点もあるのですが、逆の言い方をすると、「認定されていないもので、ちょっとカスタマイズしたらサポートしてくれないの？」とか。
こういうところもあるし、PaaS、先ほど言ったDBaaSはあったほうが本当はうれしいけれど、そんなの誰が提供してくれるんだっけとか。最後に、実際にKubernetes、テレコとの相性はどうなんだろうとか。
基盤視点では、PaaSありきでアプリケーションを作ってもらうのがいい
辻：こういうところをざっくばらんに話していきたいなと思いますが、何か言いたいことがある方から。小杉さんが言いたそうな目をしているので。
小杉正昭氏（以下、小杉）：どれ（について）しゃべろうかなぁと思っていたんですけど。
辻：ここに書いていなくてもぜんぜんいいですけど。どうでしょう。
小杉：そうですね。例えば、1番目や4番目の話で、オンラインイベントの時に東大の関谷先生（関谷勇司氏）がお話ししていたのですが、アプリケーション自体が昔から交換機のアーキテクチャを踏襲している流れがある中で、基盤側がVM化やコンテナ化しています。そこで相性というと、まず相性は良くないんじゃないかというのがあります。
私は（これを）よく言うのですが、パブリッククラウドはPaaSがあったうえで、それを使ってアプリケーションを開発して動いてます。だからたぶん相性は良くなるはずです。
我々の業界にはいろいろなベンダーがいて、VMやコンテナを提供してくれます。ただ、我々が使っている基盤は、各社1つないしは2つとかあるかもしれないですが、一発で動くかと言うとそうでもありません。
私みたいな基盤をやっている人からすると、いろいろなアプリケーションの部隊から「これが動く基盤にしてください」「チューニングしてください」「設定してください」と（要望が）きて。それでごはんを食べているようなものです。とそういう意味だと、どちらかと言うと、逆にしたい思いはあります。だからたぶん、3番にもつながるんですよね。PaaSありきで提供して作ってもらうのがいいかなと思っています。
ただ、それはそれで課題があります。たぶん4社とも、オペレーションが違うというのがあります。使っているソフトも違うし、組織も違うから、容易に（結末が）推察できますが、「オペレーションまで含めてみんな一緒にできますか？」というと、そこはまだ難しいかなと感じていますね。
辻：ありがとうございます。そうですよね。私もたぶん小杉さんとはけっこう立場が近くて、基盤側の人間なので、NF（ネットワークファンクション）との要件の擦り合わせとか、私の見ている基盤は、NF側に「必ずこの要件を飲んでください」「RFPの時に絶対に入れてください」とやっているところはやはりあります。
そういう活動をして「基盤側に合わせてくださいね」ということをやっているのですが、お話されたとおり、たぶん各ベンダーの立場からすると「楽天さんからはこの要件だけど、KDDIからはこの要件。ドコモさんからはこの要件」となったら、それを全部満たして作るのは大変ですよね。
ここがたぶんジレンマなのだろうなと。1つの大きな間違いのないデファクトが作れればいいのかもしれないですが、そこがうまく動くのかということは私も課題だなと思いました。ありがとうございます。
通信キャリア視点の“当たり前”はインターネット屋視点の“当たり前”ではない
辻：そうですね。CNFというところで、のちほどfree5GCの話もありますが、渡邊さんから見て、実際にソフトバンクにジョインした後に、なにかギャップ（を感じたものや）、そこで見たものはてありますか。「あ、こんなことも通信会社はできないのか」とか（笑）。
渡邊大記氏（以下、渡邊）：あくまで研究開発をやっている立場なので、「こんなことをやっているんだ」というレベルでの話ですが。「ああ、基地局とAMFの間はSCTPを張りっぱなしなんだ」というのは、いろいろな経緯があってそうなっていると思いますが、びっくりしました。
辻：なるほど。そうなんですよね。関谷先生も言っていましたが、通信キャリアが当たり前だと思っていることは、インターネット屋さんから見たらそれこそ当たり前じゃないみたいな。そういうところがありますよね。
プラットフォームにするためには共通化が必要
辻：津留崎さんは、このあたり（なにか）ありますか？ vRANという、ちょっと特殊というか、基地局の側、ハードウェアや無線とかいろいろと。私はコアの人間なのですが、たぶんコアとは違うつらさというか、難しさがあると思います。なにかその点でありますか？
津留崎彩氏（以下、津留崎）：そうですね。弊社はコアは結局OpenStackでVMをやっていて、5Gコアや一部Kubernetesが入っている部分もあるのですが、「やはりvRANはメインコンテナだよね」という感じになっています。
楽天さんもお話されたとおり、やはりコアに比べるとカスタムしなければいけないパラメータがたぶん多く、アクセラレータも扱わないといけないのでつらいです。
「Kubernetesをどうしても使わなければいけなかったのかな」というところは、正直やはり、検討していると多々思うところがありますね。
辻：そうですよね。なぜKubernetesをやっているのか、僕も正直よくわかっていないところがあります。ディスる意味じゃないですが。ここは本当はもう少しコミュニケーションができて、「（Kubernetesを）使ったほうがやはり便利だよね」というコンセンサスが欲しいなと思いますよね。
津留崎：そうです。先ほどの話ともちょっと共通すると思うのですが、その共通化を図っていくことにおいて、Kubernetesは結局テレコムのためのものだけじゃないので。テレコムに持ってきた時、Kubernetesはソフトウェア的には世界ですごく幅広く使われている、実際デファクト（なもの）だと思います。（でも）「ではそれをテレコムのデファクトとして『これならイケる！』というところに持っていけるものなんだったっけ？」というところはけっこう疑問があるなとは思っています。
辻：そうですよね。私は、Kubernetesは普通のHAミドルウェアとして使う分にはいいんじゃないかなと思っていたものですが、それをプラットフォームにするのかは、やはり先ほどの共通化（の話）なんですよね。
プラットフォームにしようと思うと共通化しなければいけないので。たぶんその共通化の仕方がまだまだいろいろ議論が必要なのだろうなというところです。ここはたぶんオペレーターからも「待ってほしいんだったらちょっと待った」という声を上げなきゃいけないのかなとは思っています。
ただ、どこでこういう議論をするのがいいんでしょうね。なかなか難しいですよね。
渡邊：よくわからないですけど、まずオペレーターがどういう運用体験になったらうれしいかをきちんと言語化しないと、クラウドネイティブもクソもないと思いますね。
辻：そのとおりですね。
KubernetesはOpenStackほどテレコム向けとして安定していない
辻：小杉さんはどうですか？
小杉：「まさにそのとおりです」という話です。
辻：なかなかTM Forumとか、その運用系は（関係）あるとは思うのですが。生の話じゃないですけどね。する側（として）なにかありませんか。
小杉：そうですね。やはり時間はけっこうかかるなと思っています。今Kubernetesの話がありましたが、その前のVMの世界でいうと、「OpenStackがデファクトです」となった時に、辻さんの線表みたいなやつにもありましたが、そもそも2012年ぐらいからNFVが始まって。
その時から、テレコム側がOpenStackに対してテレコムのネットワークに必要な要件を入れていったんですね。長い期間をかけて。（その結果）ようやくみなさんが使えるようになって、商用で使っています。だから、ある程度テレコム向けとして安定しているのがたぶんOpenStackなんですね。
そしてKubernetesはそうかというと、まだそういう段階ではないというのは恐らくあります。やはり弊社でもそういった部分、我々が足りないと思っている部分を自分たちで作って提供していく。私はSymphonyの営業ではないのでこれ以上しゃべりませんが、Symphonyとか、やはりそういう状況かなとは思いますね。
辻：ありがとうございます。そうですね。OpenStackはそれこそ先ほど言ったみたいにNFVの規格はたぶん2012年から出ていて、ドコモさんが商用入れたのが2016年でしたね？
個人的にはずっと言っているのですが、OpenStackがNFVでマチュアになったなと思ったのが、2019年か2020年ぐらいだったなって。
私の感覚論ですが、やはり（マチュアになるのに）5、6、7年かかるというので。Kubernetesが出たのが2014年ぐらいだと思いますが、やはりそこぐらいから数えると、（Kubernetesがマチュアになるのには）もうちょっとかかるかもしれないなというところはあるかもしれないですね。ありがとうございます。
（次回に続く）
