Docker環境にマッチしたリソース監視機能

前回の連載終了（2015年6月）から1年も経っていないが、その間にもDockerは急速に利用が拡大しており、それに伴う関連製品の発表やサービスの提供、機能強化が日進月歩で行われている。そこで今回の連載では、進化を続けるDocker本体およびDockerを制御するための関連製品、Dockerをより便利に利用するためのクラウドサービス、SaaS（Software as a Service）などに注目し、その製品やサービスの紹介と合わせて、実際にシステムで利用する際のユースケースなども考えていきたい。

本稿では、Docker実行環境およびDockerコンテナの監視を行うサービスについて述べていきたい。ご存じの通り、Dockerはコンテナ型のサーバ仮想化製品であるため、コンテナごとに割り当てられるリソース（CPU、メモリ、ストレージ）は固定ではなく、ベースとなるOSと共用となる。そのため、既存のsnmpやZabbixなどの監視エージェントなどでリソース使用量を監視しようとしても、ベースOSのデータが取得されてしまい、コンテナごとのリソース使用状況の把握は行えない。

筆者が考えるDockerを監視するための必要な要件および機能は、以下の通りだ。可能な限り、現状のサーバ仮想化環境と同様の監視を実現しつつも、Docker環境の利便性を阻害しない対策の検討が必要となる。

コンテナのリソース状況を測定する方法は、以下の2つが考えられる。

docker statsコマンドを使用する

Docker 1.5より実装されたdocker statsコマンドにより、CPU、メモリ、ネットワークI/Oについてはリソース使用状況が把握できるようになった。さらにDocker 1.9では、ディスクI/Oについての負荷も取得できるように機能強化されている。ところが、実際にスクリプトを利用し、一定間隔（10秒程度）でデータを取得してみると、コマンドの実行結果が取得できない事象が発生した。1台のサーバで同時に起動するコンテナ数を増やしていくと、結果が取得できない事象の頻度も増加する。このため、docker statsだけで本番環境と同様のリソース使用量監視を行うのは、若干不安がある。

cgroups（control groups）からプロセスごとのリソース使用量の値から集計する

上記の問題の発生により、対案としてcgroupsのリソース統計値から取得する方法を検証してみた。cgroupsでは各プロセスが使用しているCPU、メモリ、ディスクI/Oについての統計値の取得が可能である。Dockerのプロセスの起動を検知し、cgroupsから値を取得し、リソース使用量の情報を作成するスクリプトを作成したところ、何とか一定レベルの監視を行える状態を実現できた。

上記のcgroupsを用いる方法にて、Zabbix等の既存の監視ツールにてリソース監視を行うことは可能となったが、cgroupsから性能情報の取得を行うためのスクリプトの作り込みが必要である。またcgroups自体は、Linux OSのディストリビューションやカーネルのバージョンにより、出力が異なる可能性もある。そのため、それぞれの環境に対応するためのカスタマイズが必要なだけではなく、カーネル、Docker本体等のバージョンアップに対しても十分な配慮が必要となり、開発に対する相応のコストも必要となる。

Docker環境を利用する場合は、既存のサーバ仮想化環境とは異なり、Immutable（Disposable） Computingの考え方で運用される。Dockerコンテナは、作成・起動・停止のいずれも非常に短時間で行える。そのため、必要になった時点でコンテナを生成し、不要となったら削除する運用が標準となる。このような運用により、クラスタリングもオートスケールも自由度の高い運用が実現できる。

一方、既存の監視ツールはサーバが固定で存在することを前提としており、Immutable（Disposable） Computing環境のように生成と廃棄を繰り返す状態は想定していない。クラスタリングのために同一サーバを廃棄後に生成した場合は監視を継続する必要があるが、コンテナの場合はIPアドレスも変わるため、どのコンテナを継続監視すべきかの判定を行う必要がある。

これらの理由から、Docker環境のコンテナを監視するためには、既存の監視ツールに対して、かなりの規模の改修が必要となることが想定され、コスト負荷も運用負荷も非常に大きい。

これについては、July Tech Festa 2015でのDatadog社の堀田直孝氏による講演において、Docker環境の監視も行えるSaaSの利用が、非常に有効な解決策であるという説明があった。またその講演では、Docker環境の監視サービスを提供しているベンダーとして、以下の各社が紹介されていた。

そこで実際にサービスを利用し、顧客への提案を行う前に、各サービスの概要や特徴について、事前に調査を行った結果を、以下に紹介する。

New Relic

New Relic社は、2008年に設立されたアメリカ　サンフランシスコに本拠を置く企業である。ソースコードレベルの診断・解析や、システムの死活、性能監視やアクセス解析などをSaaS型で提供している。New Relic社の公式サイト上で紹介されている提供サービスの概要は、以下となる。

PLUGINSはRuby、Java、Shell、Python、Goなどの様々な言語で作成されており、Nagiosのpluginsと同様の使い方をされていると考えられる。

New Relic社のDockerの監視への取り組みは、こちらにまとめられている。Docker環境の監視は、前述のSERVERSとAPMを組み合わせることで実現している。実際には、Docker環境のベースとLinux環境にSERVERSのエージェントをインストールし、各コンテナにAPMのエージェントをインストールする実装となっている。

サイト上で公開されている監視画面でも、コンテナ内のアプリケーションの処理性能とコンテナごとのCPU、メモリなどのリソース使用量が取得できていることが見てとれる。

New Relic社が公開する監視画面

ただ、唯一欠点を上げるとすれば、SERVERSがLinuxにインストールするエージェントであるため、CoreOSやRancherOSなどのDocker専用OSでインストーラが動作しない場合は、利用が行えない可能性がある点だ。その点を除けば、システム監視、解析の非常に優秀なサービスをDocker環境でも利用できる。

サイト上で公開されている各サービスの利用料は、以下の通りだ。全ての機能に無償のトライアルライセンスが準備されており、利用前に試行・評価を行えるのは非常にうれしいところである。

AppDynamics

AppDynamics社は、2008年に設立されたアメリカ　サンフランシスコに本拠を置く企業である。前述のNow Relicと同様に、通常のシステム監視に加えて、システムの利用状況の解析やシミュレーションなども行う多機能なSaaSを提供している。提供機能のリストは以下の通りだ。

非常に多機能であり、概要までは書ききれない。機能の詳細は、販売代理店である丸紅情報システムズの製品説明サイトに記載されているので、そちらを参照して欲しい。

公式サイト上で公開されている監視画面、ユーザ分析画面は以下となる。機能も充実しているが、GUIもかなりの高機能である。

AppDynamics社が公開する監視画面

AppDynamics社が公開する監視画面

ライセンスは、機能制限付きだが無償で利用できるLite版と、有償のPro版が存在する。Pro版に関しては価格が公開されておらず、契約ごとの見積りとなるようだ。

Dockerの監視方法については、AppDynamics社の公式ブログで公開されている。Dockerに対応した拡張監視機能はすでに実装されており、コンテナごとにリソース情報の収集を行っている画面が公開されている。

Dockerにも対応済み

監視、解析機能ともに、今回比較した中で最も多機能な製品だと考えられる。日本語でのサポートも行える販売代理店も存在し、導入支援を受けやすい環境が提供されている。パッケージ版での提供も行っているので、オンプレミス環境にも導入が可能である。大規模システムを総合的に管理する用途などに適していると考えらえる。

Sysdig cloud

Sysdig cloudを提供しているDraios社は、2013年に設立されたアメリカ　カリフォルニア州デービスに本拠を置く企業である。前述のNew Relic社やDATADOG社と同様にシステムの死活、性能監視やアクセス解析などをSaaS型で提供している。

Draios社は元々、sysdig/csysdigというシステム稼働状態の監視と解析のためのツールを提供していた。このツールは、システム上のプロセスやファイル、CPU、ネットワークなどのデバイスへのI/Oの状態を監視し、デバッグが行える情報の取得と記録を行う製品である。

Sysdig cloudは、通常のシステム監視に加えて、システム稼働状態の記録とデバッグのサービスを提供している。前述のsysdig/csysdigの機能を活用しているものと考えられる。提供サービスの概要は、以下の通りだ。

課金プランは以下のようになっており、オンプレミス環境での利用プランも存在する。14日間の無料評価期間も提供されている。

以下に、公式サイト上で公開されている履歴再生の機能と動的トポロジー解析の画面を紹介する。

Draios社が公開する監視画面（履歴再生）

Draios社が公開する監視画面（動的トポロジー解析）

Sysdig cloudのエージェントをLinuxにインストールする場合、合わせてSysdigに対応した専用のカーネルヘッダーもインストールされる。専用のカーネルヘッダーが必要な理由は、前述のリソース状態の正確な把握や、sysdigのプロセスやファイル、デバイスに対するI/Oの完全な記録のためには、カーネル部分から情報を取得するのが確実であるからだと考えられる。

Docker専用OSのCoreOS上でも利用可能だが、他のLinuxと同様に専用のカーネルヘッダーのインストールが必要である。またSysdig Agentは、Dockerコンテナとしてのインストールも可能である。Docker専用OSベンダーであるRANCHER社の公式ブログで、Sysdig cloudの評価結果が掲載されている。Docker環境の監視がどのように行わるのか、大変わかりやすく解説されている。

さらに2015年7月14日に公式サイトのニュースとして、特許出願中のContainerVision™ technologyというコンテナネイティブの監視基盤の提供を発表している。これはベースOSのカーネルからではなく、コンテナ内部からリソースの使用状況の監視を行える機能で、コンテナへのエージェント等のインストールなしで監視が行える機能を実現しているとの発表があった。その発表に添付されていたサンプルの監視画面は、以下の通りだ。

ContainerVision technology使用時の監視画面（サンプル）

カーネルに手を加える点に若干の懸念はあるが、監視ツールとしてもシステムのデバッグツールとしても非常に高機能であると考えられる。ContainerVision™のように、コンテナに対してエージェントのインストールや設定変更も不要で正確な監視が行えるのであれば、製品としての優位性も高いと考えられる。