イベント
「KDDI、実はNFVにまじめです」――、通信キャリアでのNFVに関する検証結果を報告
Cloud Operator Days Tokyo 2020 ブレークアウトセッションレポート
2020年8月3日 13:00
クラウドインフラ運用技術者のための年次カンファレンスイベント「Cloud Operator Days Tokyo 2020」が、7月29日～30日にオンライン開催された。
ここでは2日目の7月30日のブレークアウトセッションの模様をレポートする。
通信キャリアの商用サービスためのNFV検証結果
セッション「そういやNFVってどうなったん？最近あまり聞かなかくなったNFVの話（KDDI編）」では、KDDI株式会社の辻広志氏と横山周太氏が、通信キャリアを想定したNFV（Network Functions Virtualization）に関する検証結果を報告した。なお、冒頭で、固定回線を担当している人間の話であり、auは含まないと念が押された。
第一部が、最近のNFVの話。辻氏はまず、最近NFVの話題が少なくなってきたのではないかとして、1つには一般化したという要素を挙げつつ、もう1つ、期待が高かったぶん幻滅されたのではないかと述べた。
幻滅されたのではないかというポイントとして、コストでは従来の機能に対応した形になるためメリットが出せないこと、性能では処理のレイヤーが増えるのでレイテンシーも増えることを辻氏は挙げた。性能を上げるための技術もあるが、それらを用いると柔軟性が多かれ少なかれ失われてしまう。
こうした欠点を挙げたうえで辻氏は、NFVのうれしい点について、仮想化によるインフラのソフトウェア化を挙げた。
・Infrastructure as Codeにより、増設や追加などの作業をOpenStack側の設定で削減可能。
・オートヒーリング（フェイルオーバー）により、故障時に冗長系が自動復旧して品質向上と低廉化が実現
・ハードウェアの抽象化により、ハードウェアのライフサイクルとVNF（Virtual Network Function）のライフサイクルを分離可能
「となると、NFVはいい仕組みだなと思う」と辻氏。
さて、通信キャリアではマルチベンダー構成となる。理想的には、コストはみんなで分け合って、最小に抑えることができる。ただし、VNFベンダーの保証やサポートの条件が限られ、そこで壁がある。特にSR-IOVはシビアだ。その結果生まれるのが、アンチパターンといえるサイロNFVであり、コストが下がらないという。
また、キャリアが求める優先事項は、性能より安定性だと辻氏は説明した。電話のパケットドロップはノイズになるなど、パケットはそう簡単には落とせない。
第二部は、そのうえでマルチベンダーによるNFVに必要な技術を探る話だ。
まず、責任保証はわれわれオペレーターが担保することにする、と辻氏。そのためには、VNFがハードウェアに依存しない抽象化を維持することと、オープンソースの実装であることが必要となる。
そのための技術として、脱SR-IOVでOpen vSwitch-DPDK（OVS-DPDK）と、ストレージ技術のCephを選択したという。
OVS-DPDKを選択した理由として、ドライバーがLinuxに含まれるvirtio-netであること、DPDKアクセラレーションがソフトウェア実装なのでハードウェアに依存しないことを辻氏は説明した。
またCephを選択した理由として、利用者が多いこと、分散SDSでスケーラビリティがあること、ハードウェアの共通化ができることを辻氏は説明した。
ただし、問題は社内実績が乏しいことだ。そこで事前評価を実施した。
第三部は、いよいよ検証の話だ。検証対象は、OVS-DPDKの性能、Cephの性能および可用性、ピーク値ではなくノイジーネイバー問題などの実運用条件、実VNFアプリの動作だ。
検証環境はRed Hat OpenStack PlatformとRed Hat Ceph Storageを使い、ネットワークとしてL3ファブリックを使用した。
まずネットワーク性能検証について、横山氏が報告した。検証方法としては、Pktgen-DPDKのVMとTestpmdのVMの間の通信を測定した。測定項目やパラメータは、一般的な指標（秒間パケット転送数）のほか、音声アプリケーションを意識した。
検証結果として、まずOVS-DPDKでvNICあたりスループット約3Mppsの結果を得た。ただし、別のVMでは約1.5Mppsと半減したという。これは、実はPMD（Poll Mode Driver）スレッドあたり3Mbpsだったとのこと。3Mbpsの結果が出たケースではOVS上の各ポートがそれぞれ別のPMDスレッドに分かれていたが、1.5MbpsではPMDスレッドを分けあっていたとのことだった。
次に、SR-IOV vs. OVS-DPDKの検証。SR-IOVではショートパケットでもワイヤレートに到達した。「1VMで10Gbpsを使い切りたい人は迷わずSR-IOV」と横山氏。さらに、SR-IOVとOVS-DPDKとも、遅延もジッタも問題ないという結果となった。
続いてCephの検証については、辻氏が報告した。検証したのは、VMからの読み書き性能、Cephクラスタ全体での読み書き性能、障害時の動作。
まずVMからの読み書き性能では、Readは最大3K IOPS弱なのに対し、Writeはキャッシュの影響が大きく実態は1K IOPS強だったという。また、マルチスレッドでは、ReadもWriteも6K IOPS程度出たという。
続いてCephクラスタ全体での読み書き性能。これは、最終的にはNICや物理ディスクの速度に収束するという結果となった。特にReadはIOPSより先に帯域で頭打ちとなるという。
障害時の動作については、限界域では復旧動作でI/Oに影響し、例えばリバランスでバックプレーンネットワークの帯域などのリソースが逼迫（ひっぱく）したという。一方、二重障害のときでも、I/Oは停止するが、データ破壊は防止されたという。
最後に実VNFアプリの動作について。3つのベンダーのVMを評価した中で、OVS-DPDKではなぜか性能が出ないVNFアプリがあった。これは、リングバッファが小さいvirtio-netを想定したチューニングが不足しているためではないかとのことだった。
第4部は、検証結果を受けて、NFV商用化に向けた取り組みの話だ。まず、OVS-DPDKとCephについて、10Gbps程度のワークロードであればSR-IOVと遜色（そんしょく）ないだろうと横山氏。それは、SR-IOVでもノイジーネイバーなどを考えると分けるためだという。
PMDスレッドの問題については、重量PMDスレッドの隔離や、ゲストVMに対して十分な数のPMDスレッドを用意すること、負荷状況を見てPMDをリバランスするという対策が語られた。
そのほか、ネットワークでは帯域制限や待機スケジューリング、CephではZone間でL2をまたがないドメインの分割などが語られた。
障害時のNFVのオートヒーリング（フェイルオーバー）についても語られた。セッションを切らないための呼救済としては、事前にシグナルを送り切り替えをうながす独自実装をするという。また二重装置故障や想定外動作を考慮し、二重故障まで考慮した余剰リソースを配備する考えだ。そのほか、VNFM（VNF Manager）にOpenStack Tackerを利用しようと考えているとのことだった。
最後に辻氏は「KDDI、実はNFVにまじめです」と宣言して、この件については今後も継続して情報発信していきたいと語った。