Sensu と Graphite による大規模インフラの監視

サイトオペレーション本部の渡邉です。
サイトオペレーション本部はデータセンタ・ネットワーク・サーバー・OS・ストレージといった全社的なインフラの管理運用や調査検証などを担当しています。
今回は、2013年に全社のプライベートクラウドとして導入した OpenStack の監視基盤として、OSS の Sensu と Graphite を採用した事例についてご紹介したいと思います。

採用に至るまで

サイトオペレーション本部では、もともと 2011 年から内製のプライベートクラウドを開発運用していました。
プライベートクラウドでは VM のホストとなるハイパーバイザを大量に運用する必要がありますが、その監視基盤として社内で一般的に利用されているカスタム Nagios を採用していました。
構成概要は次の通りです。

• Nagios サーバー
  • 各ホストに対して SSH, Ping の死活監視を実行
  • Active-Active の2台冗長構成で互いを監視しておりオートフェイルオーバする設定
• 各ホストにインストールされたエージェント
  • リソース監視・セキュリティ監視の結果を Nagios サーバーへ送信
  • エージェントは内製のもので、メトリクスの収集・送信も担当

監視対象の増加に対しては、キャパに応じて Nagios を新規構築して増加分の監視をまかなうシンプルな手法を採用していました。
この手法でも運用は出来ていましたが、やはり監視対象が増加するにつれてスケーラビリティの観点から限界を感じることが多くなりました。

Nagios の設定ファイルは数百台を対象に監視するとどうしても内容が煩雑化してしまいます。
それを何セットも運用するのは、各種ユーティリティを駆使していてもオペレーションが難しく、職人芸のようになっている状況でした。
また、ホストから収集されたメトリクスは各 Nagios 上にストアされていましたが、統合的な活用がうまくできていない状況でした。

そこで、プライベートクラウドを OpenStack へ移行することが決定したタイミングで、監視基盤についてもスケーラビリティを重視した見直しを行い、調査検討の結果 Sensu と Graphite が採用されました。
それぞれのポイントについて紹介していきます。

Sensu とは

Sensu は Heavy Water Operations, LLC の Sean Porter 氏らによって 2011 年から開発されている OSS の監視ツールです。
主に次のような特徴があげられます。

• 各コンポーネントがメッセージキューを介して動作
  • 処理性能をスケールアウトさせやすいアーキテクチャ
• Nagios のプラグイン資産を流用可能
  • 仕様が共通なので、ほぼそのまま使える
• 構成管理ツールとの連携を前提にした設計
  • Chef や Puppet の cookbook, manifest を標準で提供
• Client が立ち上がると自動で監視がスタートする
  • Server 側で設定変更の必要がない

具体的な構成としては、メッセージキューに RabbitMQ, データの永続化に Redis を組み合わせて運用することになります。
公式ドキュメントの図が動作をイメージしやすいので引用します。

出典：http://sensuapp.org/docs/0.16/overview

Sensu 自体は4つのコンポーネントから構成され、それぞれの役割は次の通りです。

Server

Server は Client に対しての Check Request の発行と、逆に Client から送信されてきた Check Result の処理・ハンドリングを担います。
Check とは監視項目のことで、どのようなコマンドで監視を実施するかの定義にくわえて、その実行結果に応じて Server がどのようなリアクションを取るべきかを定義するハンドラを設定できます。
これを用いて Check Result が CRIT ならメールを送信する・メトリックデータであるなら Graphite に転送するなどの機能を実現します。
基本的に Sensu 全体の処理性能はこの Server の数によって決まるため、Client の増加に応じて適宜スケールアウトさせていくことになります。

Client

Client は監視対象のホスト上で動作し、RabbitMQ から Check Request を取得してその内容に応じた Check 処理を実行する役割を担います。
Server からの Check Request の有無にかかわらず定期的に Check 処理を実行させる設定も可能です。
この方式は Server から Check Request を発行する必要がないので Server 側のオーバヘッドを小さくできるメリットが有ります。
ただし裏を返すとこれを止めるには対象となる全ての Client の設定を変更しなければなりません。
そこで、常に実行されていても問題ない・実行されてほしい、メトリック収集処理などで利用するのが一般的です。

API

API は Redis に格納されている Sensu の各種データについて RESTful なインターフェースを提供する役割を担います。
これを利用することで、監視履歴の参照やアラート制御、監視対象の追加・削除などのさまざまな操作を HTTPS 経由で実現できます。

Dashboard

Dashboard は Webブラウザーから各種操作をしたり情報を可視化するための UI を提供する役割を担います。
Sensu v0.13 からは標準の Dashboard が変更され、操作性や機能が大幅に改善されています。

Graphite とは

Graphite は Orbitz, LLC の Chris Davis 氏らによって、2006年から開発されている OSS のグラフツールです。
主に次のような特徴が挙げられます。

• 分散型の時系列データストレージ
  • 処理性能をスケールアウトさせやすいアーキテクチャ
• パワフルなグラフレンダリング Web API
  • 豊富な処理関数と出力形式が用意されデータを活用しやすい

公式サイトでの紹介によれば、これまでに Google や GitHub などでの採用実績があるようです。
構成としては大きくフロントエンドとバックエンドから構成され、それぞれの役割は次の通りです。

graphite-web

graphite-web は Web API, Web UI を提供するフロントエンドの役割を担います。
Django で構成されており、グラフライブラリとして Cairo を利用しています。

carbon

carbon は時系列データを管理するバックエンドの役割を担っており、機能別に3つの daemon を提供します。

carbon-cache

carbon-cache は carbon の最もコアとなる daemon です。
RRD に変わる効率的なデータフォーマットとして Whisper を採用しています。
比較的小規模な環境であれば1つの carbon-cache のみでも十分に運用が可能です。

carbon-relay

スケールアウトを前提にする場合は carbon-cache に加えて carbon-relay を利用することになります。
具体的には carbon-relay を carbon-cache の前段に配置してデータの受け口にするかたちで構成します。
carbon-relay はデータを carbon-cache に振り分ける役割を担い、レプリケーションとシャーディングを提供します。
実際の運用ではさらに HAProxy などを利用して carbon-relay の冗長性を確保する必要があります。

carbon-aggregator

carbon-aggregator は carbon-cache の IO 負荷を減らしたい場合に利用します。
ただし集約により粒度を落とすため使い方が難しく、この資料にもあるように基本的にあまり利用されないようです。
本件でも carbon-aggregator は利用していません。

どのように導入していったか

Sensu と Graphite の導入を始めたのは2013年9月頃で、Sensu の作者である Sean Porter 氏を社内に招いてアドバイスをいただくなどしつつ、既存の Nagios と並走させるかたちで徐々に導入をすすめていきました。その変化を順に世代に分けて追っていきたいと思います。

第1世代

第1世代はテストランニングとして次のような構成でスタートしました。

Sensu については Nagios のイメージをそのままもってくるようなかたちで全てのコンポーネントを1つのサーバーに収める All-in-one 構成としていました。
監視項目は約10項目を60秒間隔で回しており、通知は1日に1回の頻度でメールと社内チャットに流れるように設定していました。

Graphite については HDD では IO が厳しいことがわかっていたので、55GB ほどの RAM Disk をデータストア部とするように設定して、定期的に永続化ジョブを走らせる手法を選択しました。
フラッシュメモリを採用しなかったのは単に調達ができなかったためですが、結果的に現在に至るまでこの方式を採用しています。

かなりシンプルな構成ですが、この状態で約500台のクライントに対して安定して動作しました。

第2世代

第2世代は第1世代と大きな差はなく、基本的に冗長化されていなかった面を補強した構成になります。
RabbitMQ は3台でクラスタを組んで冗長化させ、Sensu Client の接続をロードバランスさせました。
carbon-relay は2台に増強し、Sensu Server からの接続をロードバランスさせました。
第2世代ではクライアント数が約1000台まで伸びていましたが、引き続き安定して動作しました。

第3世代

Nagios との並走を停止し、Sensu + Graphite に本格的に移行したのが現行の運用構成となる第3世代です。
ハイパーバイザ数の急激な増加に加え、その配下にある各 VM のメトリクスの収集も開始してデータ量が大幅に増えたたため、処理性能の向上を主眼に構成がアップデートされています。

Sensu については Sensu Server の VM を大量に並べることで処理性能をスケールアウトさせています。
第2世代で冗長化できていなかった Redis を Redis Sentinel とあわせて冗長化する補強も行われました。

Graphite については各 daemon の特性にあわせてより効率的にサーバーリソースを活用できるよう調整を行いました。
特に CPU bound な carbon-relay がボトルネックになりがちな状況だったため、carbon-cache を動かしているストレージサーバー上でも carbon-relay を動かすようにする等して並列度を高める工夫をしています。
さらにこの過程で Graphite をバージョンアップしており、daemon の管理に megacarbon を利用したり、データフォーマットを Whisper から ceres に移行するなど、新機能を積極的に取り入れることも行われました。
データの永続化についても GlusterFS を利用するように変更されました。

さいごに

ここまでで Sensu と Graphite の概要と、それらを組み合わせてどのように運用してきたかを紹介しました。
とりあえずの構成から要件に応じて柔軟にスケールアウトしてこれたことがお分かりいただけたかと思います。

運用してみて特に大きなメリットであると感じたのは Sensu Client が立ち上がると自動で監視が始まる点です。
監視対象の追加時にサーバー側の設定を変更する必要がないというのは想像以上にオペレーションコストの削減に寄与してくれました。
また、Nagios のプラグイン資産を無駄にせずにできたことも大きく、パワフルな環境にスムーズに移行することができました。

もし導入される際には、特に Sensu については Chef や Puppet などの構成管理ツールを組み合わせることをおすすめします。
サイトオペレーション本部では Chef を利用しており、cookbook として sensu-chef と chef-monitor を使っています。

本稿が Sensu や Graphite をご検討されていたり、運用されている方のご参考になれば幸いです。
最後までお読みいただきありがとうございました。