───KamueeはPCベースで稼働するルーティングエンジンということですが、この開発をスタートした背景を教えていただけますでしょうか？

小原：私は大学での研究時代から現在に至るまでインターネットのルーティングやそのアルゴリズムの研究をしていますが、この研究仲間が画期的なルーティング・アルゴリズムである「Poptrie（ポップトライ）^*1」を発明したので、それを一緒に論文にまとめ、世界的に著名かつ論文採択が超難関な「ACM SIGCOMM^*2（以降、SIGCOMM）」という学会に2015年に応募したのが始まりです。無事に論文が採択され^*3、Poptrieが世界の権威たちから有用性を認められたので、まずはルータメーカさんをいろいろ回ってみました。しかし、この理論がどこまで機能するのかまだ不明な状態でしたし、メーカさん側は開発コストや商流などの問題もあるらしく、あまり興味を示されなかったというのが現実でした。
そこでNTTコミュニケーションズでは、その理論でどの程度うまくいくのかを実際に確かめるため、プロトタイプのソフトウェアルータを作ろうとしたのがKamueeのスタートです。

───つまり、はじめから商品化を考えていたのではなくて、まずはご自分たちの理論を実用化できるかどうか試してみたのがKamueeのスタートだったわけですね。

小原：その通りです。インターネットではパケットを転送するときにまずIPアドレス検索を行いますが、全世界での検索となると約80万経路^*4になると言われています。ソフトウェアルータでその膨大な経路検索を行うと「遅くて使えない」^*5というのがこれまでの常識でした。そこを打破できる画期的なアルゴリズムがPoptrieですから、これを活用して経路検索自体を高速化し、大量のパケットを高速に通信するプログラムを作りました。単なるサンプルプログラム的なところから始め、そこにファイルから読み込んだルーティングテーブル（経路表）に保存したものを読み込んで、どれだけの性能が出るか研究を進めました。論文が採択されたのはSIGCOMM 2015でしたから、2016年頃だったと思います。

───80万の経路検索ということですが、ハードウェアルータと今までのソフトウェアルータではその検索能力はどのぐらい違うのでしょう？

小原：経路検索の性能は1秒間に何回ルーティングテーブルの検索ができるかという単位＝lps（lookup per second）で調べます。
今までのソフトウェアルータでは、およそ毎秒200万回検索＝2Mlpsのレンジが限界でした。これに対してハードウェアルータでは、TCAM（Ternary Content Addressable Memory）と呼ばれる特殊なメモリを搭載してルーティングテーブルの検索をさせており、およそ100倍の200Mlps（2億lps）ぐらいが可能です。

───経路を検索する性能が100倍も違うのですか。大きな違いですね。

小原：はい、この経路検索性能がルータの性能に関わってくるので、ここは大きなポイントです。ルータの性能は1秒間に何個のパケットを転送するかという単位＝pps（packets per second）で調べますが、1個のパケットを転送するには１回ルーティングテーブルを検索する必要がありますので、ルータの性能を高めて大量のパケット転送をするためには経路検索性能が求められるのです。残念ながら今までのソフトウェアルータの経路検索性能はハードの1/100ですから、「遅くて使えない」と言われていたのも仕方がありません。
しかしPoptrieはこの経路検索を高速化する技術ですので、KamueeはTCAMを使ったハードウェアと同等の200Mlps（2億lps）というルックアップ＝経路検索を達成できたのです。

───Kamueeの経路検索性能はハードウェアルータと同等ですか。では、実際のルータとしての性能はどのぐらいですか？

【図1】Kamueeのベンチマーク測定イメージ＜実験室内＞

拡大

小原：Kamueeのルータ性能については【図1】のような設定で実験を行いました。
Kamueeと計測器（Spirent）を100GbE４本で直結し、ランダムな終点IPアドレスのパケットを大量（90Gbps×4本＝360Gbps）に送り込み、612,927経路のルーティングテーブルを検索させながらパケットが戻ってきたものの総量で計測しました。
その測定結果は【図2】の通りで、Kamueeをハイエンドサーバ（CPU: Skylake Platinum 2基）に搭載し、4ポートある100GbEの1ポートについて1・4・8・12個のCPUコアを割り当てて測定した結果をグラフ化したもので、グラフのX軸はイーサネットフレームのサイズ（64～1518Byte）、Y軸は転送に成功したトラフィック量（スループット）となっています。
64Byteショートフレーム^*6・12cpp（cores per port）という設定では、スループット＝222.11Gbps、パケット転送＝330.52Mppsを達成しています。これはハードウェアルータのスループットと比べても良好な値であり、ソフトウェアルータとして「世界最高レベルの性能」に該当します。 

【図2】Kamueeのベンチマーク測定結果＜実験室内＞

拡大

───世界最高レベルのソフトウェアルータ、素晴らしいです！　
では世界最高レベルをもたらしたPoptrieのアルゴリズムについて教えてください。

小原：とてもスマートな方法でルーティングテーブルのデータ圧縮を行うというのが、その答えです。今まではbinary tree／木構造でルーティングテーブルを実装しており、200MBぐらいのメモリを消費していた処理が、Poptrieで圧縮すると1/100の2MBに落ちたのです。このサイズならCPUキャッシュに収めることができ、メインメモリまでアクセスしにいかなくても検索ができるので、高速の経路検索が可能になるわけです。このキャッシュメモリだけで検索が完結するという点も画期的なところです。

───1/100まで圧縮できるということは、ルーティングテーブルの構造自体が異なっているということでしょうか？

【図3】通常の2分木とPoptrieの2^kの多分木の木構造イメージ^*7

拡大

小原：一応、Poptrieも内部に木構造を保持しています。ただ、その無駄な枝を刈ると言いますか、木構造の無駄な部分をまとめていくやり方がとてもスマートなのです。
通常の木構造は左右2つに枝分かれしていく2分木ですが、Poptrieでは一度に64分木する、非常に大きな多分木です。ちなみに【図3】はPoptrieの多分木を説明するためのイメージで、右側の木構造はk＝2の4分木を示しています。

───なるほど、80万経路を2分木で検索すると縦にずーっと見てく必要がありますが、64分木だと一遍にくし刺し検索でき、縦の段数も格段に短くできるわけですね。

【図4】子ノードの配列表現によりメモリ使用量が削減するイメージ^*7

拡大

小原：まさにその通りですね。その代わり64分木にまとめると、メモリを多く消費することになります。しかし、Poptrieではそこをまたギュッと圧縮できるので、64分木にして縦の検索段数を減らした上で、横にも広く伸びないということを実現できるのです。つまり先ほどもお話したように、全経路情報が2MBになるのでCPUキャッシュにのせることができ、経路検索時にCPUがメモリを参照する回数が削減されるため、従来の方式と比べ経路検索の高速化を可能にするわけです。

───Poptrie以外は1と0、右か左でしか検索していないということでしょうか？

小原：はい。「IPアドレスが32bitなので、32段必要だ」というのが普通の考えだったのですが、Poptrieの発明後から考えると「なんで元からそういうことをしなかったわけ？」みたいな、目から鱗の話でした。ただ64分木自体は、数学の世界ではたくさん使われている話です。それを汎用サーバにフィットさせる技術として考えたことがPoptrieの特長です。

───「Poptrieの特長」という言い方をお聞きしますと、Kamueeの特長としては他にもあるということを示されているようですが・・・。

小原：はい。Poptrieはエレガントなルーティングテーブルのルックアップアルゴリズムですが、Kamueeでは、それを実際に使うためにDPDK^*8のライブラリを使って、パケット転送のスピードアップを図っています。Kamueeはルーティングテーブルをリナックスカーネルとやりとりするなどすべてを司っており、実際のスケジューリング、そのパケットを受け取っていつまでに出すかというようなことも行っています。

江坂：DPDKというのはソフトウェアルータなどのパケット処理を行うソフトウェア向けのSDKで、これを採用することにより一般的なUNIX系OSを利用しつつ、高速なパケット転送を実現しています。DPDKによってカーネルの割り込みやコンテキストスイッチによるオーバーヘッドを削減し、40GbEや100GbEの性能を活かせるソフトウェアの構築が可能となります。Kamueeではパケット転送の各処理部分に対して個別にCPUコアを割当てるのではなく、1回のパケット受信から送信まで同じCPUコアで処理するRun to completionモデルで設計することで高速なパケット転送を実現しているのです（【図5】を参照）。
またこのモデルは、NIC（Network Interface Card）に対してCPUコアを柔軟に割当て、分散して並列処理をすることにより、効率的にスケールアウトすることも可能になります。

【図5】DPDKを採用したKamueeでのRun-to-completionモデル

拡大

小原：これら以外にも、Telnet端末の機能を実装し、経路を書いたり消したりできるようになっていますし、Kamueeには他にも様々な工夫がされています。

───では、ハードウェアルータと比較して、Kamueeをお勧めするメリットは何でしょう。普通の汎用サーバで使えるから安いということでしょうか？

小原：安い・個人で試せる・UNIX文化に近いだとか、いろいろなことがあります。例えば個人や大学でネットワークを作ろうとしたとき、高いハードウェアルータは買えないので、オープンソースを使うような文化がありますから、どちらかというとそちら寄りの利用が想定できるでしょうか。我々研究者が新しいアルゴリズムを作ったときにそれを試せるようなプラットフォームが必要ですが、Kamueeなら商用で使っている性能と同じレベルで自作することができるようになります。

───ハードウェアルータは、どのぐらい高いんですか？

小原：我々が開発を始めたころのハードウェアルータは、1憶円・2憶円の冷蔵庫みたいな大きなものでした。それと同じ性能を数百万円のハイエンドサーバで出すことを目標としてやってきています。最近はルータメーカでも同じような路線でやっているところもあるようですが、初期の導入費用以外にサブスクリプション方式をとるなど毎年費用が掛かるようです。

───ということは、ハードウェアルータは、初期費用が安い場合でも「買っておしまい」ではなく、毎年予算化しなくてはいけないですね。

小原：さらに、10GBのインターフェースが1本あると年間数十万とかそういう感じなので、100GBを4本使いたい時には、ざっと値段が10倍ぐらいになってしまい、ビックリすることがあります。

───それに比べると、Kamueeは高性能・広帯域で破壊的に安いと言えるわけですね！

───では、このKamueeの実証実験のうち、JGNを使った"さっぽろ雪まつり"の先進的な実験で実運用の検証についてお伺いしたいと思います。

うめきた会場の非圧縮フル解像度8K映像による超高精細立体映像伝送デモ

拡大

小原：今年、2020年2月に行われた”さっぽろ雪まつり2020”での先進的な実験「2本の非圧縮フル解像度8K映像による超高精細立体映像伝送」に参加しました。これは50Gbps超^*9の大容量リアルタイムデータのマルチキャスト配信という、ものすごく大きなチャレンジでしたが、その結果は大成功といって過言ではないと思います。
実は2019年の「”さっぽろ雪まつり2019” 8K映像配信実験」にも参加したのですが、うまく行かなくて一旦持ち越しているんです。2020年はリベンジで大成功を収めたというのが実態ですね。もともとKamueeはマルチキャスト用に作っていなかったので、いろいろ足りない部分があったんです。 

───昨年と違い、今年のKamueeはマルチキャストに対応するルータに改良されて参加されたわけですね。

小原：その通りです。ただ我々だけで改良したのではなく、JGNがなければできなかった話なんです。JGNというと通常ネットワークを思い浮かべますが、もう一つの側面にJGNを中心としたコミュニティもあると思っています。雪まつりの先進的な実験は、このコミュニティが中心になって行われていますよね。

───「JGNがなければ今回の成功はなかった」と言っていただけるのはうれしい限りです。でも、雪まつり実証実験の参加団体として毎回50を超える団体が名前を連ねていますが、このコミュニティの果たした役割は何なのでしょう？

小原：2019年の実験に初めて参加したとき、そのコミュニティの皆さんとやり取りし、競合・協同する企業という垣根を越えて率直に情報交換させていただける場になっていることがとても素晴らしいと思いました。我々もそこでマルチキャストルータという新しい事例の課題や詳細について教えていただき、そのおかげで、再度仕切り直してチャレンジすることにつながったのです。
そして2020年が2019年と大きく違った点は、雪まつり2020の事前段階から神奈川工科大学の丸山先生に協力いただき、準備したマルチキャスト用ルータをJGN上でテストすることができたことです。これがなければ、”さっぽろ雪まつり2020”での成功はあり得なかったと言えます。「まだパケットロスがある」などいろいろな問題点を指摘くださるとともに、我々のチャレンジに対しても深く理解いただき、精神的なサポートまでしてくださいました。本当に感謝しております。実際に新しいKamueeの事前テストを行った期間は1～2か月でしたが、大手町のアクセスポイントに配置し、合宿のような感じで集中的にトライを重ねてから、本番に臨むことができました。

【図6】”さっぽろ雪まつり2020”実証実験の参加機関（順不同）
＜画像をクリックするとPDFでもご覧いただけます＞

拡大

───2020年は新しいKamueeで、どのように50Gbps超のリアルタイムデータマルチキャスト配信に取り組まれたのでしょうか？

小原：まずは【図7】「雪まつり Kamueeマルチキャスト構成」のトポロジをご覧ください。今回の実験は8Kの立体映像配信ですから、雪まつりの雪像を2台のフル解像度8Kカメラで撮影し、RチャンネルとLチャンネルという別々の映像経路で大阪デモ会場まで送信し、受信側で映像を同期して大型プロジェクタに投影^*10しました。鑑賞時には偏光3Dメガネを着用することで立体映像を実現しています。
Kamueeは緑色のラインであるLチャンネル映像経路上、JGN関東-2のAP（アクセスポイント）にコアルータとして配置されています。

【図7】雪まつり2020 Kamueeを組み込んだマルチキャスト構成

拡大

───【図7】の中央右にあるピンク色の枠部分ですね。

JGN関東-2APのラック上のKamueeを搭載したサーバ

拡大

小原：はい、Kamueeを搭載したサーバをJGN関東-2APのラックに置かせていただいて使いました。【図7】でも分かるように、実はKamueeの部分では大阪デモ会場へ行くルートだけでなく、分岐して秋葉原にあるIPAの施設にも行くようにルーティングしています。
またこの部分では、2019年の失敗を踏まえてJGNの運用者に協力いただき、Kamueeがきちんと動作しない場合でもイベント全体に迷惑がかからないよう、Kamueeを外して迂回できるような構成になっています。しかし、結局はKamueeが故障せず、迂回をお願いすることもありませんでした。おかげさまで【図8】のマルチキャスト映像配信ストリームに示されている通り、2020年は2/3～2/7の間ずっと視覚的にもロスがなく、51Gpbsの大容量帯域マルチキャストを2つのダウンストリーム（大阪デモ会場と秋葉原のIPA施設）に伝送し続けることができて、良かったです。

【図8】フル解像度8Kのマルチキャスト映像配信のストリーム＜2/3～2/7＞

拡大

───素晴らしい結果です!! 十分に事前準備をなさったので、雪まつり2020実証実験は初めから自信がおありになったのではありませんか？

小原：いえいえ、それは結果論です。2019年は失敗してひどい目を見てますので、自信なんてありませんでした。こういうイベントでの実験では最後まで何があるか分からないものですから。

───【図7】では、IPAではLチャンネル映像しか受信していないようですが、ここでは立体映像を見られないのでしょうか。

小原：そうなんです。大阪うめきたのデモ会場で公開した立体映像は裸眼で見たり写真で撮ったりすると二重に見えるため、ぼやけた感じになってしまいます。これに対して、IPAでは１チャネル映像だけなので、8Kの高精細を観賞することができて、我々イベント当事者にとっても楽しいものでした。
この構成図で分かるように、たくさんのルータやスイッチ、光伝送装置などがつながり、ルーティングプロトコルが動いて伝言ゲームのように映像伝送をしているのですが、多くのハードウェアルータの中でソフトウェアルータのKamueeが何の問題も起こすことなく、4日間無事に大阪デモ会場とIPA施設へと8K映像を送り続けることができたわけです。

───この実運用での成功により、有名なルータメーカの専用機器と伍して、遜色なくKamueeを使えることが証明できましたね！

小原：はい、それを目指してきましたので、成功例の1つとして、こういう大きな話もできるようになり、うれしいです。

───2020年は新型コロナの流行で多くのイベントがリモート開催になっており、雪まつり2021の実証実験については未定だと思いますが、今後もJGNのこのようなイベントに参加される予定はおありですか？

小原：ぜひ参加していきたいです。特に雪まつりの実証実験は毎年チャレンジングな人達が集まっており、こういう場でしか試せない実験が可能ですから。
それこそ雪まつり2020における「50Gbps超のマルチキャスト映像伝送」などという先進的な実験は、他では絶対にできない話です。

───今回の雪まつりでの成功を受けて、Kamueeの今後についてお伺いしたいのですが・・・

小原：現在は、汎用サーバのハードウェア上にKamueeをのせてコアルータとして利用していますが、ピュアソフトウェアルータなので、将来的にはNFV^*11で仮想ルータとして利用することを視野に入れて開発を進めています。これは、ハードウェアルータには実現できない場面になります。

───NFVというのはNetwork Function Virtualization、ネットワーク機能を仮想化という意味ですね。そこでKamueeを活用できるようにするということですか？

小原：NFVというのは、【図9】に示すように汎用サーバ自体を仮想化し、ハイパーバイザという仮想化基盤上で動く複数のVM（仮想マシン）にソフトウェアとしてネットワーク機器の機能を実装しようという方式です。そのVM1つ1つが通常のパソコンサーバの役割を果たしますので、そこにそのままKamueeがのるのではないかという話です。
つまり1つの汎用サーバに複数のKamueeをのせることもことも可能ですし、柔軟性も高くなってきます。

【図9】NFVの概念（イメージ）

拡大

───現在はマシンもネットワークも、全体的に仮想化の方向に進んでいるように思うのですが・・・。

小原：はい、ネットワークのソフトウェア化みたいなことは、もう誰にもあらがえない潮流のようになっています。ですから、そこで使えるツールが出てくればとても貢献できるのではないかと考え、Kamueeはそれを目指しています。

───その研究のためにも、JGNに対して具体的なご要望はありますか？

江坂：雪まつりもそうですが、Kamueeのように研究段階のシステムはいろいろなフィールドで試すことがとても大事です。そういうフィールド提供の最たるものがJGNではないかと思っています。また、今後の話になるとは思いますが、我々の作っているものを検証する場として使わせていただける場から一歩越えて、JGNにKamueeを組み込んで使っていただけるようにするというところが、我々としての究極の目標になるのではないかとも考えています。

小原：そうですね。JGNには、ぜひ最先端のネットワーク技術を押し進めるようなリードをしてもらいたいと思っていますので、そういう最先端技術、もっとネットワークをよくしていくための活動として、例えばNFVで運用するネットワークでソフトウェアルータをたくさん立てて大容量・広帯域の通信転送をするテーマがあればKamueeを提供して、互いにテーマや要望、運用方法などを要求しあって、研究を進めることができたらいいと思います。現在、NFVでネットワークを運用しているネットワークは、今のところどこにもないようですから・・・。

江坂：将来的には、そういう関係が作れるまでいけたらいいですね。

───最先端のネットワーク技術を検証できる場としてのJGNが重要だということですね。最後に成果をアピールできる段階にまできたKamueeの実用化・商用化について、お話できる範囲で教えてください。

江坂：もちろん世の中に商用Kamueeを出していきたいというつもりですので、今、気合を入れて頑張っているところです。Kamueeの商用サービスが始まることが決まりましたら、適切な媒体でニュースリリースとして発表します。ご期待ください。

───はい、楽しみにお待ちしています。今日はありがとうございました。

＜2020.7／Web会議システムを利用し、リモート環境にてインタビュー＞

【JGNを含む総合テストベッドに関するお問合せはこちら】
　　tb-info[アット]ml.nict.go.jp