DPDKでアプリケーションを高速化！見えてきたOpenStackとのギャップ

連載 [第5回] :

OpenStack Summit Vancouver 2018レポート

2018年6月26日(火)

　今回のOpenStack Summit Vancouverでも、前回に引き続きコンテナとNFVが大きく注目トピックとなっていました。今までNFVに関しては要件定義レベルの議論が多かったのですが、今回のサミットではすでに実装されたNFV機能に関するオペレータからの具体的なフィードバックが増えたように感じました。特に、データプレーンの高速化技術に関しては、実装が要件定義に追い付いてきたことから多くの意見や課題が聞かれました。そこで本記事では、データプレーンの高速化技術として注目度の高いDPDKをキーワードにサミットを振り返ってみたいと思います。

2017年にLinux FoundationのプロジェクトとなったDPDKのロゴ

　DPDKは“Data Plane Development Kit”の略で、それ自体アプリケーションというわけではありません。あくまでアプリケーションを作成するための開発用ライブラリであり、公式ページでも “a set of libraries and drivers for fast packet processing” と紹介されています^※1。

※1: https://dpdk.org/

　ただ、ここではあえてちょっと変わった角度から意見を述べさせてください。普段OpenStackで活動する著者からすると、DPDKはOSが隠蔽しようとするハードウェアをあえてユーザやアプリケーションに意識させ、チューニング手段を提供する技術だと思っています。

　DPDKで作成したアプリケーションは、共通の起動オプション（EAL Command-line Options^※2）を持つことになります。このオプションにより、例えば以下のようなチューニングパラメータを制御できます。

-c COREMASK：アプリケーションが使用する物理CPUコアを指定するビットマスク
–socket-mem：各CPUソケットで使用するメモリ量

※2: http://dpdk.org/doc/guides/testpmd_app_ug/run_app.html

　つまり、どのCPUコアをどれだけ利用するか、どのCPUソケットのメモリ領域をどれだけ使用するかを設定できます。これは性能チューニングの際に重要になります。

　例えば、使用するハードウェアが複数のCPUとメモリを一つのシステムに乗せたNUMA（Non-Unified Memory Access）アーキテクチャとなっている場合、仮想マシンが動作するCPUソケットと、仮想スイッチなどのネットワークバックエンドの動作するCPUソケットが別であると、同じソケット上に片寄せした場合と比べて性能が下がってしまいます。これはCPUコアがメインメモリにアクセスする際、遠いメモリの方が近いメモリよりアクセスコストが高いことが原因です。

　DPDKが提供するオプションを活用し、両者の使用するNUMAノードを明示的に同じに指定することで、最適な性能を得ることができます。

リモートアクセス発生による性能劣化の例

　この点でDPDKは、普通のアプリケーションでは意識しないようなハードウェアレイヤをあえて意識することでチューニング手段を提供する技術だと捉えることができるでしょう。

　一方で、OpenStackは全く逆のポリシーで設計されています。OpenStackはエンドユーザにハードウェアレイヤを意識させないように設計されています。一番簡単な例でいえば、エンドユーザは仮想マシンをデプロイする際、ホストの指定ができません。指定できるとすると、それはクラウド下の物理サーバをエンドユーザに意識させることになるからです。

　ホスト指定に関しては管理者用のAPIは用意されています。しかし先ほど述べたようなもう少し粒度が細かいハードウェア制御、例えば仮想マシンの仮想CPUコアを動作させる物理CPUコアの指定に関しては、管理者向けのAPIすら用意されていません。

　この点で、OpenStackとDPDKは、設計指針レベルですでにギャップがあると筆者は感じています。この点について筆者もサミットで発表し、同意の声や、これからの可能性を期待する声が聞かれました。

A basic gap between OpenStack and DPDK

　現在、このギャップを克服するため、OpenStackコミュニティ内ではプロジェクトの垣根を超えた様々な取組みがなされています。例えば、先ほどのようなCPU指定ができない課題に対しては、“ネットワークバックエンドが動作するCPUソケットと同じCPU上に仮想マシンをデプロイしたい”といったように、ユーザからのリクエストは性能チューニングに最低限必要な抽象度にした上で、詳細なスケジューリングはNovaの内部で行うアーキテクチャ^※3がRocky Releaseに向けて提案されています。これにより、下位のハードウェアを隠蔽するOpenStackの原則ポリシーを変更することなく性能チューニングを行えると期待が高まっており、今回のサミットでも実現の仕方について話し合われました。

※3: https://review.openstack.org/#/c/541290

　さらに、このような課題をいち早く取り入れ、OpenStackの世界でも性能を落とすことなくパケット処理を行うことを目的とするSPP（Soft Patch Panel）というDPDKベースの新しいプロジェクトもサミットの中で紹介されました。DPDKやOpenStackのリポジトリ上ですでにソースが公開されています^※4^※5。

※4: http://dpdk.org/browse/apps/spp/

※5: http://git.openstack.org/cgit/openstack/networking-spp/

　バッファのキューサイズや使用メモリチャネル数など、DPDKで用意されているチューニングパラメータは他にも沢山あります。これらのチューニングパラメータをどこまでOpenStackにダウンストリームすべきなのか、その際、OpenStackへのユーザのリクエストをどこまで抽象化できるのか、今後もオペレータと開発者とで意見を慎重に擦り合わせつつ、着地点を見極めていく必要がありそうです。