Dockerコンテナのパフォーマンス劣化とチューニング

2015年5月26日(火)
佐藤 司森元 敏雄

はじめに

本連載の第2回『ベアメタル環境とDockerコンテナ環境の性能比較』で実施したコンテナ環境とベアメタル環境との性能比較では、コンテナ環境は高負荷時に挙動が不安定になるという結果となった。本記事には皆様からTwitterなどのソーシャルメディアを通じて、検証についてのご意見や問題点の解消方法について貴重なご指摘をいただいている。今回はこれらを参考に、発生したパフォーマンス劣化の原因の調査と改善策を模索していきたい。

まず筆者が目をつけたのは、Dockerが利用しているコピーオンライトデバイスの部分がパフォーマンス劣化の原因となっているのではないだろうか? という点である。実際にテストを実施しながら検証していきたい。

ストレージドライバとは

ストレージドライバは、物理サーバ上ではストレージ(HDD)コントローラのチップセットドライバだが、Dockerではコンテナ記憶域に使用されるコピーオンライトのファイルシステムの種類を指す用語だ。

Dockerのv1.5で利用出来るストレージドライバは、以下の5種類である。

表1:Dockerのv1.5で利用出来るストレージドライバ

ファイルシステム概要・特徴
aufsAnother UnionFS。overlavfs(unionfs)の信頼性や性能を向上させるために開発されたファイルシステム
btrfsB-tree file system。Oracleが開発したコピーオンライトのファイルシステム。耐障害性や修復機能などを持つことを目的に開発されている
device-mapper仮想的なブロックデバイスを作成し、それをファイルシステムとして利用する。Linux LVMも本技術を利用し、複数の物理HDDを1つの仮想ディスクに結合している
overlayfsunionfsとも呼ばれる。Linuxのunion mountの機能を利用したファイルシステムで、LiveCDなどで起動したOS上にマウントすることで書き込みも可能な状態を実現する
vfsVirtual File System。通常のLinuxファイルシステムをマウントして利用する。コピーオンライトはサポートしていない。

OSやDockerを標準設定でインストールした場合、筆者の環境ではCentOS 6.6やCentOS 7ではdevice-mapperが選択され、一方Ubuntu 14.04ではaufsが選択された。これはDockerがインストール時に、ホストOSで利用出来るストレージドライバを検出し、適合したストレージドライバは優先順位をつけて利用される仕組みとなっているためだ。

稼働中のDockerが利用しているストレージドライバは、以下のコマンドで確認出来る。

root@centos7:~ # docker info
Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-253:1-33556714-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 0 B
 Data Space Total: 107.4 GB
 Data Space Available: 28.4 GB
 Metadata Space Used: 577.5 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.1.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 1
Total Memory: 1.797 GiB
Name: tissrv152
ID: 3NO4:WORM:B4X7:MHAT:RWFT:72LT:RIEU:M3CF:FYJB:NMLM:J4YH:KQAH

 == ホスト環境準備今回の検証では「CentOS Linux release 7.1.1503」と「Docker version 1.5.0-dev」を利用する。ホストサーバのスペックは、以下の表を参考にして欲しい。

表2:ホストサーバのスペック

CPUIntel(R) Core(TM) i7 870 @ 2.93GHz
コア数8コア
Memory4GB
Swap4GB
HDD1Western Digital 1TB(SATA3 7200rpm)
HDD2Western Digital 1TB(SATA3 7200rpm)
HDD3Western Digital 1TB(SATA3 7200rpm)
NIC1負荷発生端末(JMeter)とのみ接続可能なクローズドなネットワーク
NIC2インターネットへ接続可能なネットワーク

今回の検証環境は、連載第2回のものとは異なっている。変更点は以下の通りとなる。

  1. ベースOSをCentOS 6.6からCentOS 7.1に変更
  2. DockerをVer 1.4.1からVer 1.5.0に更新

変更の理由は、これから利用をしていくCentOS 7系で評価を行うべきとのご指摘に対応をしたものである。さらに2015年4月20日にepelリポジトリのDockerがVer 1.5.0に更新された。Ver 1.5.0はLinuxカーネルのVer 3.0系を推奨としており、システムの安定性も考慮し、上記の変更を行っている。

JMeterサーバは連載第2回から変更は行っていないため、説明は割愛する。

Dockerコンテナ準備

今回の検証も、連載第2回と同じくRedmine+MySQLを処理性能測定用のプロダクトとして利用する。ただし今回は、読者の方にも同じ検証が行えるように、DockerHubにsameersbn氏が公開しているRedmineコンテナ(https://github.com/sameersbn/docker-redmine/tree/2.5-stable)を利用することにした。

このコンテナは最新版ではないのだが、前回行った物理環境がApacheで動いているため、コンテナ環境でもApache上で動くRedmineコンテナを選出したい経緯がある(最新版はnginxで稼働する構成となる)。既存で公開されているDocker imageを使用しているため、最新のRedmineとMySQLを利用していない点はご容赦いただきたい。

表3:本記事で利用するコンテナ

利用コンテナバージョン
sameersbn/redmine:2.5.02.5.0 stable

テスト項目

今回は連載第2回で行ったテストを、様々なチューニングを行ったDockerコンテナに対して実施し、性能改善の有無を検証する。ただし、テスト回数を1000回/60秒から2000回/60秒へと増やしている。これは、CentOS 6.6+Docker 1.4.1の環境上では1000回/60秒の条件で多発したエラーが、今回のCentOS 7.1+Docker 1.5.0環境では全く発生しなかったためだ。ベースOS、Dockerともにバージョンアップが行われたことで、大幅に性能が改善していると考えられる。ただ、2000回/60秒に増やしたところ、やはりベアメタル環境では発生しなかったレスポンス悪化とエラーが再発するようになったため、負荷を上げる形で検証を行うこととした。

JMeter上から実行したオペレーションは以下となる。

1.参照オペレーション

  1. Redmineのログイン画面へアクセス
  2. ユーザ名とパスワードを用いてRedmineにログイン

本オペレーションでは、原則、DBやディスクには参照の処理が行われる。CPU、ネットワーク、ディスクに平均的に負荷を発生させることを目的としている。

2.更新オペレーション

  1. Redmineのプロジェクトに対して新しいチケットを1件作成
  2. 表題と内容を記載し登録

本オペレーションでは、チケットの登録が行われるため、ディスクの更新が発生する。データ量は小さいがDB、ディスクへの負荷を発生させることを目的としている。

JMeter上から発生させる負荷量は以下となる。

高負荷

  • 参照、更新のオペレーションを2000件/60秒の間隔で実行する
  • テスト時間は60秒間で行い、それを3回繰り返して平均を取得する
  • 負荷のスコアはJMeter上のスコアを利用する。

テスト1:基準となるデータの測定

前回の検証で利用したコンテナはRedmineとMySQLがそれぞれのコンテナに分離していたが、今回のコンテナは1個のコンテナにRedmineとMySQLが統合さている。まず性能評価の基準を作成するために、ダウンロードしたコンテナイメージを変更することなく性能測定を実施する。コンテナが統合されていることにより、コンテナ化のネットワークの負荷が小さくなる点で差異が発生する可能性が考えられる。そのため後述でコンテナを分離し、ネットワークを介したテストも実施するのでご安心いただきたい。

まずはコンテナを立ち上げる。

[root@host_server ~]# docker run --name=redmine -p 8080:80 -d sameersbn/redmine:2.5.0

ここでは、コンテナ内に対してはチューニング等の変更は加えていない。テスト開始の準備として、Redmineが立ち上がりWebブラウザでアクセス出来るようになったら、デフォルト設定をロードし、テストするためのプロジェクトを一つ作成する。

表4:テスト1の結果

作業1分間のオペレーション平均(ミリ秒)中央値(ミリ秒)90%Line(ミリ秒)最小値(ミリ秒)最大値(ミリ秒)Error%スループットKB/sec
アクセス2000154906258620241111829810.0014.463.5
ログイン実行200017311381367681252810.0014.485.2
Projectへ遷移200015321707037539211068738.6213.972.4
チケット作成20001655130835789130018.6213.971.3
平均20008549.254004.2526704.2512.25626759.3114.1573.1

テスト中に取得できたiostatの最大値を以下に示す。この値は、テスト中iostatコマンドを用いて3秒おきに出力されるIOデータのWriteに注目し、最大値を抽出したものだ。この後のテストでも、同様のデータ抽出方法を採用している。

テスト1で取得できたiostatの最大値
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          43.82    0.00    5.27    7.56    0.00   43.35

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.33     1.67    3.00  140.67   102.67  3229.83    46.39     1.04    7.22   10.33    7.15   5.77  82.97
dm-1              0.00     0.00    3.33  110.67   102.67  3229.50    58.46     1.05    9.25   13.10    9.13   7.27  82.87
dm-2              0.00     0.00    1.67  276.33    26.67  3328.00    24.13     1.12    4.03   19.40    3.93   2.81  78.23
dm-3              0.00     0.00    1.33  264.33     5.33  3340.00    25.18     1.25    4.70    9.25    4.67   3.16  83.83

テスト1の結果を見ると、平均の待ち時間(90%Line)が約26秒とかなり遅く、エラー率も10%近い値を出している。またテストを行っている時のDiskIOをウォッチしていると、書き込みの最大値が3229kB/sとなっており、こちらも若干遅いように見える。

ログやコンテナ内のApacheの設定から察するに、「アクセス」の作業で投げられたHTTPリクエストが、ApacheのMaxClientsである150件を超え、60秒でタイムアウトしている様子だ。そのため何度検証を行っても待ち時間(90%Line)が60000ミリ秒を大きく超えることはなかった。この値を本記事の基準とし、次のテストから性能の改善を試みる。

株式会社アーベルソフト

インフラ基盤の設計・構築・運用までの全ての工程を担当。最近は、OSS製品を活用したインフラ基盤の提供を行っている。利用するOSS製品の調査・研究も行っており、現在は、DockerとTerraformに注目している。
>株式会社アーベルソフト

TIS株式会社

R&D部門である戦略技術センター所属。
金融系の大規模システム開発やプライベートクラウド開発環境の構築・運用の経験を生かし、OSS製品を中心としたの技術調査・検証を担当。
> TIS株式会社

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

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