PR

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

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へのユーザのリクエストをどこまで抽象化できるのか、今後もオペレータと開発者とで意見を慎重に擦り合わせつつ、着地点を見極めていく必要がありそうです。

日本電信電話株式会社 NTTネットワークサービスシステム研究所
2014年にNTTに入社し、NFV関連機能、特にDPDKプロダクトの開発と検証を担当。2017年よりOpenStackコミュニティでの開発活動に従事している。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています