Dockerコンテナの監視を行うサービス

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、メモリなどのリソース使用量が取得できていることが見てとれる。

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

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

AppDynamics

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

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

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

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

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

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

Sysdig cloud

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

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

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

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

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

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™のように、コンテナに対してエージェントのインストールや設定変更も不要で正確な監視が行えるのであれば、製品としての優位性も高いと考えられる。

DATADOG

DATADOG社は、2010年に設立されたアメリカ　ニューヨークに本拠を置く企業である。前述のNew Relic社と同様にソースコードレベルの診断・解析や、システムの死活、性能監視やアクセス解析などをSaaS型で提供を行っている。実際に使用してみると、まずグラフ表示がきれいで見やすいと感じられた。公式サイトで公開されているダッシュボードの画面を以下に紹介する。

DATADOG社が提供する機能として公式サイト上で紹介されているものを、以下の表にまとめた。

日本語化された詳細なドキュメントが、DATADOG DOCSで公開されている。初期導入から各プロダクトの監視設定の方法や、監視設定のカスタマイズの手順まで詳細に記載されており、製品の理解を助け、導入へのハードルを大きく下げている。

各プロダクトや基盤の監視を行うIntegrationはPythonで記述されており、ソースも公開されている。基本的には設定ファイルの一部を実行環境に合わせて変更するだけで使用できるが、取得するデータのカスタマイズも可能である。

監視結果を表示するダッシュボードは、GUIによって取得するデータと表示するグラフをカスタマイズできる。

他の製品同様、DATADOGも通常のLinuxなどのOSを監視する際にエージェントをインストールするが、Docker環境では以下の特徴がある。

1. Docker環境へのDATADOGエージェントのインストールは、DATADOGコンテナを起動する形で行う
2. コンテナのリソース監視のみであれば、DATADOGエージェントのインストールは不要
3. コンテナの生成を自動的に検出し、リソース監視を開始できる

コンテナのデータ取得には、cgroupsを使用しており、エージェントレスでかつコンテナごとの正確なデータ取得を実現している。公式サイトで公開されているDockerの監視状況の画面を以下に示す。

価格構成は、以下の表のようにシンプルである。Freeプランが存在するのは、大変ありがたい。

signal fx

SignalFx社は、2008年に設立されたアメリカ　カリフォルニア州サン・マテオに本拠を置く企業である。リソース使用状況やアプリケーションの処理件数や処理時間を集計し、分析を行うSaaSサービスを提供している。サーバOSやアプリケーションから取得されたデータをメトリック化し、signal fxに送信すると為替や株価のように統計情報として集計、分析を行う機能を提供している。さらに集計、分析を行ったメトリックが指定した条件にマッチした場合、アラートを送信する機能も提供している。

メトリックをsignal fxに送信する方法だが、Linuxのcollectdを使用している。通常はcollectd単体でもグラフ作成は可能だが、内部でグラフ化するのではなく、メトリックをSignalFx社のサービスに送信する設定を行い、集計と分析・グラフ化をSaaSサービスにて実施する形となる。

集計されたデータの分析・グラフ化は、SignalFx社サイト上のダッシュボードのGUIで行う。ダッシュボードには、グラフ以外にもマークダウン記法が使用できるドキュメント表示の機能も存在する。

公式サイト上で公開されているダッシュボードの画面イメージを以下に示す。

Dockerの監視方法については、SignalFx社の公式ブログに記載されていた。やはりcgroupsからDockerコンテナのCPU、メモリ、ディスクI/Oの使用量などの数値を取得し、送信を行う方法が解説されている。他の監視も同様だが、signal fxではシステム利用者側で集計したいメトリックをシステムより抽出し、送信する作業を行う必要がある。

コンテナの自動検出とメトリック抽出に対応したサンプルが、やはり公式ブログで公開されている。取得結果を元に監視を行ったサンプル画面は、以下の通りだ。

価格は、測定するデータの送信量によって変動する。

料金は1分あたりの送信メトリック数により変化するが、誤ってsnmpなどの情報を全て送ってしまうと、1回で1万件くらいメトリックが送信されてしまう。利用に際しては、課金額を抑えるために、利用者側で必要最低限のメトリックを送信するように十分な検討と設計が必要である。

Librato

Libratoを提供するSolarWinds Worldwide, LLC社は、1998年に設立され、インフラ基盤やサーバ、アプリケーションなどに様々な運用・監視製品を提供する老舗ベンダーである。Libratoを2015/02/02に買収し、SaaS型運用サービスも提供を開始した。

前述のsignal fxと同様に、サーバ側で収集したリソース使用量やアクセス件数などのデータをメトリック化し、Libratoのサービスに送信することで集計とグラフ化や、閾値に対応したアラート発行を行う機能を提供している。公式サイトにて公開されている画面イメージは以下のようなものだ。

メトリックの送信方法として、以下の3種類のインターフェースが提供されており、そのインターフェースごとに課金が異なる。

Dockerの監視方法については、公式ブログにトレジャーデータ社の田村清人氏が寄稿された記事が掲載されている。コンテナのCPU、メモリなどの利用状況は、やはりcgroupsから取得しているが、Libratoへの送信にはcollectdではなくFluentdを利用している。公式ブログ上で公開されている監視画面イメージは、以下の通りだ。

Libratoのサービスを効率よく利用するためには、signal fxと同様にメトリックの集計に利用者側での十分な設計と開発が必要となる。SignalFx、Libratoは、共にエージェントに対してcollectdやFluentdなどから取得したメトリックをSaaS側に転送するインターフェースを持っている。一部カスタマイズは必要だが、他のサービスに提供されているサンプルを流用することも有効な手段だと考えられる。

Scout

Scoutは2007年に内部ツールとして開発され、2008年にOSSとして公開されている。前述のsignal fxやLibratoと同様に、サーバ側で収集したリソース使用量やアクセス件数などのデータをメトリック化し、Scoutのサービスに送信することで集計とグラフ化や、閾値に対応したアラート発行を行う機能を提供している。

リソース監視とグラフ化、アラートに機能を集約しており、インストールと設定の容易さを最大のメリットとして挙げている。またインストールのための、ChefやPuppetのレシピも公開されている。各種プロダクトを監視するプラグインも提供されており、そのプラグインの導入もGUI上の操作で行える。プラグインは全てRubyで作成されており、カスタマイズも行いやすくなっている。公式サイトで公開されている監視画面イメージを、以下に示した。

Docker環境の監視は、DATADOGと同様にエージェント実行用のコンテナをインストールする形となり、ベースOSへのエージェントのインストールは不要である。標準の機能でコンテナのリソース使用量およびDocker環境へのコンテナの作成、削除などのイベントの監視も行える。コンテナのリソース使用状況およびDocker上でのイベントの監視画面は、以下のようなものだ。

課金は、シンプルな2つのプランが提供されている。14日間の無料評価期間も提供されている。

導入も設定も比較的容易で、課金プランもわかりやすい。手間をかけずに、シンプルな監視基盤を構築したい場合に良い選択肢になると考えられる。1点問題があるとすれば、製品名の「scout」で技術情報を検索しても、情報がなかなか見つけられない点である。

Mackerel

最後に国産製品からMackerelをご紹介したい。Mackerelは、株式会社はてなが提供しているSaaS型サーバ監視サービスだ。前述のsignal fx、Librato、Scoutと同様に、サーバ側で収集したリソース使用量やアクセス件数などのデータをメトリック化し、Mackerelのサービスに送信することで集計とグラフ化や、閾値に対応したアラートを発行する機能を提供している。

Mackerelは2007年ごろから、はてな社内部の監視ツールとして開発されており、それをベースに2014年9月にSaaS型で提供が開始された。日本国内での導入事例も多く、特にコマースサイトやゲームなどの大規模なコンシューマ向けサービスを展開している企業に採用されている。

国産製品ということもあり、日本語のドキュメントやユーザ事例などが充実している。公式で公開されているプラグインは20点程度だが、利用者が開発して公開しているものも含めると、かなりのプロダクトをカバーできている。Docker向けのプラグインは、公式のGitHub（mackerelio/mkr）で公開されている。ただ、Docker専用OSへの対応に関する情報は、執筆時点では発見できなかった。

監視データを参照するダッシュボードのサンプル画面が公式サイトで公開されている。2015年7月には、ダッシュボードのカスタマイズも実装されている。

リソース使用状況等の通常監視データ以外のメトリクスを、サービスメトリックと呼んでおり、そのサービスメトリックもhttp＋json apiで独自に登録し、fluentdで取得したメトリックをMackerelエージェントのAPIで送信できる。サービスメトリックのグラフは、Mackerel以外のサイトに埋め込んで表示させることも可能である。さらに外部からのURLアクセスの正常反応を確認する、外形監視機能が提供されていることも特徴と言える。

課金は有料プランと無料プランが存在するが、現在は期間2週間のTrialプランも提供されている。詳細は、以下の表にまとめた。

国内ベンダー提供のSaaS型監視サービスで、Dockerに対応しているものは非常に少ない。前述の海外（ほとんどアメリカだが）のサービスと比較しても、機能面では遜色はないと考えられる。今後の機能強化や改善による、さらなる利便性の向上が楽しみなサービスである。

利用するサービスの選定にあたって考慮すべき点

以前より、監視サービスをアウトソーシングするためのSaaS化は行われていたが、技術の進歩は著しく、今や利用状況の可視化、問題分析までが実装されているほどだ。またSaaS型ということもあり、個人でクラウドサービスを利用するほどの容易さで使い始められるのは、便利な時代になったと感じる。今回紹介できなかったサービスも多々存在し、サービスの選定の際に、何らかの基準が必要になる。その基準となりそうな考え方をまとめてみた。

サービス面での必要性

最初に紹介したNew RelicやAppDynamicsは、監視機能に加えて、ユーザアクセス解析やエラー発生個所特定やパフォーマンス問題分析など、システムを運用するための課題・問題解決に直接役立つ運用状況の解析を行うサービスを提供している。

高機能であるため、利用料金は他の監視中心のサービスと比較すると高額になるだけではなく、監視運用負荷の上昇や取得した解析データをどう使うのかの判断も必要となる。それらのサービスが業務上必須であれば、迷うことなく選択すべきだが、運用や導入の負荷を少なく監視だけを始める場合、他の条件でサービスを選択すべきと考えられる。

実行時の環境で解析を行いたいのであれば、強力な解析ツールであるsysdigを利用できるSysdig cloudを選択すべきであるが、本番環境への負荷を考慮すると開発・テスト環境で行うべきかもしれない。

カスタマイズに使用する言語

各サービスを使いこなす上で、監視に使用するプラグインやテンプレートを運用者がカスタマイズする必要が発生する。カスタマイズの容易性をGUIで実現している製品も多数存在する。また、使用する言語の標準を統一している製品も存在する。たとえばDATADOGはPython、ScoutはRubyとなる。運用者のスキルに合わせて、使いやすい言語で開発が行える製品を選定するのも良い手だと考えられる。

監視間隔と通信の距離遅延

SaaS型監視サービスで注意すべきなのは、監視対象の拠点と監視ベンダーのSaaS拠点がネットワーク越しの遠隔地に存在する点だ。そのため、監視データの間隔を60秒としているサービスも存在するが、監視としてはやや長く感じられる。実際には、多くのサービスが1秒間隔を実現している。

監視間隔が短いということは、送信するメトリックの情報量が多くなるということで、通信負荷の増加が懸念される。さらに監視ベンダーのSaaS拠点が遠隔地に存在する場合、距離遅延による通信速度の低下も懸念される。

大規模監視を短い間隔で行う場合、監視対象の拠点と監視ベンダーのSaaS拠点が近い方が問題の発生を抑えることは明らかである。パブリッククラウドであれば、監視対象拠点を監視ベンダーのSaaS拠点に近づけることも一考の余地がある。また国内拠点で動かせないとなれば、国内でサービスを提供しているベンダーを選択することも一手だろう。

その他の手としてはメトリックをUDPで送信する機能を持つEtsy/StatsDのインターフェースを採用した製品を選択する手もある。TCPと異なり、送達確認がないため、大量のデータを高速に送信することが可能である。パフォーマンスデータのように、リアルタイム性が求められるメトリックに関しては有効な選択肢となるだろう。

Docker基盤の監視

これからのDocker基盤は、Red Hat Atomic HostやCoreOS、RancherOSなどのDocker専用OSで構築されることが多くなると考えられる。これまではLinux OSに対してインストーラを使用してパッケージインストールを行っていたが、Docker専用OSの場合、これはあまり好まれる方式ではない。やはり監視エージェントもコンテナとして提供される形が望ましいだろう。その点では現状、DATADOGとScoutが少し先行していると考えられるが、他ベンダーも追随することが予想される。

まとめ

ほぼ各社の製品に共通しているのは、監視対象システム側にインストールしたエージェントが収集したメトリックをSaaS側で受け取り、グラフ化、監視、アラート発行を行うことである。エージェントにメトリックを受け渡すインターフェースはcollectd、Fluentd、StatsDなど複数に対応している。必要な監視スクリプト（のサンプル）が、使用製品の公式サイトに存在しない場合も、他社サービス向けのリポジトリに流用可能なスクリプトが公開されている可能性が高い。実際に「collectd docker」でGitHub上を検索すると、かなりの数のリポジトリがヒットするので、これらを活用しない手はないだろう。

今回紹介した各社のサービスは、ほとんどが無償のTrial期間や小規模のFreeプランで実際に使用しての評価が行えるようになっている。サービス導入に際しては事前に評価を行い、使い勝手の良さを確認することが良いだろう。

SaaSであるので、使いたいサービスの一部分を一定期間だけ使うことも可能である。必要となるサービスを選択し、既存の監視機能なども含めて、より効率良く、業務負荷の低い運用監視を実現したい。