BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 仮想マシンとLinuxコンテナのパフォーマンス比較

仮想マシンとLinuxコンテナのパフォーマンス比較

ブックマーク

原文(投稿日:2014/08/13)へのリンク

IBM Research Divisionが、DockerとKVMを使い、コンテナと仮想マシン環境のパフォーマンスを比較した論文を発表した。これはNATあるいはAUFSにおけるDockerの利用コストに注目し、仮想マシン内でコンテナを実行するというプラクティスに疑問を投げかけるものだ。

論文の著者らは、仮想化およびコンテナ技術としてそれぞれKVMとDockerを使い、ネイティブ、コンテナ、仮想化実行に対する、CPU、メモリ、ネットワーク、I/Oのベンチマークを実行した。 ベンチマークには、サンプルとしてRedisとMySQLの負荷も含まれている。 Redisは小さなパケットと大量のクライアントを伴うネットワーキングスタックとして振る舞い、MySQLはメモリやネットワークおよびファイルシステムに負荷を与える。

テストしたすべてのケースにおいて、結果は、DockerのパフォーマンスはKVMと同等、もしくはそれ以上であることを示している。 CPUとメモリのパフォーマンスについて、KVMとDockerには観測可能だが無視できるほどのオーバーヘッドがあり、I/O負荷の高いアプリケーションについては、どちらもチューニングが必要になる。

volumeを使ったときにはパフォーマンスが良いが、AUFSにストアされたファイルを使うと、Dockerのパフォーマンスは低下する。 volumeは、unionファイルシステムをバイパスするよう1つ以上のコンテナ内に特別に設計されたディレクトリであり、ストレージバックエンドにあるようなオーバーヘッドは見られない。 デフォルトのAUFSバックエンドは、特に多数のレイヤと深くネストしたディレクトリ階層を使ったとき、大きなI/Oオーバーヘッドを引き起こす。

Dockerのデフォルトのネットワーキングオプションである、 --net=bridgeもまた、NATパケット書き換えのためのオーバヘッドを引き起こす。これは高パケットレートにおいて顕著に見られる。 ネットワークパフォーマンスは--net=hostを使うことで改善できる。これはDockerに別のネットワークスタックを作らないよう指示し、ホストのネットワークインターフェイスへの完全なアクセスを許すものだ。このオプションは、他のrootプロセスと同様に、コンテナプロセスが小さな番号のポートをオープンして、D-busのようなローカルのネットワークサービスにアクセスするのを許すため、注意して使う必要がある。これはコンテナにあるプロセスがホストのリスタートといった予期せぬことをするのを可能にしてしまう。

KVMのパフォーマンスはかなり改善されてきたが、レイテンシに厳しい、あるいは高いI/Oレートの負荷にはまだ適していない。すべてのI/O操作にオーバーヘッドをいくらか追加してしまうためだ。 このオーバーヘッドは小さなI/Oでは大きくなるが、大きなI/O実行するときは無視できる程度だ。

こうした結果から、この論文は仮想マシンを使ったIaaSの実装に疑問を投げかけている。

世間一般には (そのようなものが、この若いクラウドエコシステムに存在するとして) 、IaaSはVMを使って実装されており、PaaSはコンテナを使って実装されていると言われています。 この結果は、そうでなくてはならない技術的理由は存在しないことを示しています。コンテナベースのIaaSの方がより高いパフォーマンスあるいは簡単なデプロイメントを提供できる場合はなおさらです。 またコンテナは、ベアメタルのパフォーマンスでVMのコントロールと分離を提供するため、IaaSと「ベアメタル」非仮想化サーバ間の差異を取り除くことができます。

仮想化環境でコンテナを実行するのはよく見られるプラクティスだが、この論文はベアメタルLinuxサーバでの実行を推奨している。なぜなら、そうしないと、VMのパフォーマンスオーバーヘッドは避けられず、非仮想化Linuxで直接コンテナを使うことによるメリットが得られないためだ。

この記事に星をつける

おすすめ度
スタイル

BT