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

※この記事は読者によって投稿されたユーザー投稿のため、編集部の見解や意向と異なる場合があります。また、編集部はこの内容について正確性を保証できません。

CTC教育サービスはコラム「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の半分以下に時間が短縮されています。

この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai/nakai68.html

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

インデックス
検索エンジンがWebページをデータベースに保存しているデータベース。データベース ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]