Dockerストレージドライバーの性能比較

＃＃＃
はじめに
　先週、米国ノースカロライナ州のRaleighにある、Red Hatの本社オフィスに出かける機会がありました（写真1）。米国のソフトウェア企業というと、西海岸のイメージがあるかも知れませんが、Raleighは、東海岸に位置します。古くから情報技術産業に力を入れている都市で、有名企業の研究・開発拠点が多いことで有名です。

fig01

写真1　Red Hatの本社ビル

　今回は、Docker/OpenShiftの開発メンバーと会う機会があったのですが、特にPerformance EngineerのJeremy Ederに見せてもらった、Dockerのディスクアクセス性能に関するデータが面白かったので、すこし紹介しておきたいと思います。

Dockerのストレージバックエンドの性能比較
　Dockerでは、Dockerイメージを保存するストレージ機能をプラグインドライバーで選択できるようになっています。Dockerがオープンソースとして公開された当初は、AUFSというレイヤー型ファイルシステムが使用されていましたが、Linuxカーネルの正式機能ではないという問題点がありました。そこで、Red Hatのエンジニアは、「dm-thin」というDevice Mapperのシンプロビジョニングモジュールを利用したプラグインを作成して、Dockerから利用できるようにしました。RHEL7/CentOS7に同梱のDockerでは、これがデフォルトのプラグインになっています。dm-thinの機能については、以前のコラムでの解説も参考にしてください。

　dm-thinは、論理ボリュームの内部にDockerイメージを保存しますが、この際、論理ボリュームを作成するバックエンドのデバイスにいくつかの選択肢があります。RHEL7/CentOS7にDockerをインストールしたデフォルトの構成では、スパース形式のイメージファイルをループバックマウントしたデバイス上に論理ボリュームが作成されるため、あまり、I/O性能がよくありません。開発目的にDockerを利用するユーザー向けに、環境に依存しない簡単なセットアップ手順を提供するため、このような構成を選択したということです。すこし手間がかかりますが、物理デバイスを用いて論理ボリュームを構成すると、大幅に性能が改善します。

　図1は、Jeremyが行った性能測定の結果です。1000個のコンテナーを一気に起動して、すべて起動したら、今度はすべてを停止／削除するという処理を行い、全体としてかかった時間を表しています。これを見ると、「loop-lvm」（ループバックマウントを使ったdm-thin）→「btrfs」→「direct-lvm」（物理ボリュームを使ったdm-thin）の順に性能が向上していることがわかります。この例では、direct-lvmは、loop-lvmの半分以下に時間が短縮されています。

この続きは以下をご覧ください
リンク