大規模インフラの監視システム

こんにちは。インフラチームの ebisawa です。

今回はグリーのインフラにおける各種機器の監視がどのように行われているのかご紹介させていただきたいと思います。一般にサーバの監視というと、システムダウンを検出するための死活監視を意味する場合と、ネットワークトラフィック等のモニタリングのことを意味する場合とがあります。今回の監視は特に後者についてのお話です。大規模なインフラの監視には、やはり特有の課題があります。

どんなツールを使っているのか

グリーではサーバの各種リソース使用状況をモニタリングしてグラフ化するためのツールとして、Cacti を利用しています。Cacti は、大変有名なツールなので皆様ご存知かと思いますが、バックエンドの RRDtool で作成したグラフを閲覧するための使いやすいユーザーインターフェイスを備えています。

http://www.cacti.net/

ツールの使われ方

得られたデータは、やはりパフォーマンスチューニングの際の参考としたり、サーバ増強の時期を判断するのに使われたりするのが基本です。特にデータベースアクセスの最適化は重要なので、MySQL より取得できる数値はなるべく多く収集してグラフ化しています。その他サーバの用途に応じて、それぞれのテンプレートを用意しています。

変わったところでは、均等にロードバランスしている複数の同一機種サーバ間でデータを比較し、特異的に他と異なる挙動を示す個体を検出することで、ハードウェア障害の前兆を見つけることができる場合があります。

データ収集の対象

グリーは、運用する全てのサーバとラックスイッチを含む全てのネットワーク機器をモニタリングしており、エンジニアが必要だと思ったとき、いつでも任意のサーバのデータを参照できるようになっています。

監視対象機器が増えてくると、全てのサーバを監視するのが難しくなってくるため、代表的な機器のみに限って監視すれば十分ではないかと思えてきますが、それでも全台監視を続けるのは、いざというときに必要なデータがすぐに手に入るようにするためです。

監視システムの規模

閲覧時の使い勝手を考えると、監視システムが複数に分割されているのは好ましくないため、全機器分のデータを１つのサーバで検索し閲覧できるようにしています。これは多くのエンジニアに気軽に参照してもらうことで価値を発揮するシステムですから、規模が拡大していっても従来と変わらない使い勝手を維持することが重要と考えるためです。

とはいえ、扱う対象の規模が文字通り桁違いに増大していくなかでは、従来と変わらない機能を維持し続けるだけでも様々な困難を乗り越えなくてはならなくなります。

例えば、現在グリーで運用中の Cacti サーバは、次のような規模の監視対象群をモニタリングしています。

• 登録デバイス数: 4桁後半
• 登録グラフ数: 19万くらい
• RRD ファイルサイズ合計: 500GB以上

この全てのグラフが５分ごとに更新されます。これを可能にするにはいくつかの工夫が必要でした。

大規模インフラの監視における課題

通常、監視サーバに大掛かりなシステムが想定されることは稀だと思います。余裕のあるサーバ上でついでに稼働されていたり、仮想化技術を用いて集約されていたり、特に問題があると認識されることは少ないのではないでしょうか。

ところが、監視対象となるインフラの規模が増大してくると、監視システムを稼働させるサーバにも相応の性能が求められることに気づきます。そのうち 1 台のサーバの処理能力では足りなくなってきます。Cacti を利用する場合、現在では、それなりに高性能のサーバを用いても 1000 台程度を監視するのが限界だと思います。特に収集したデータによりデータベースを更新する際のディスク I/O がボトルネックとなりがちです。

しかし、それ以上に深刻なのが、増え続けるサーバを監視システムに登録する作業コストの問題です。一般的に、誰かが何らかの作業をし続けないと維持できない仕組みのシステムは、圧倒的な数の力の前ではすぐに破綻します。何らかの形で運用を自動化し、原則放置のままうまく動き続ける仕組みが必要です。

グリーの監視システムの歴史

グリーでは、当初は 1 台の Cacti サーバで間に合っていましたが、限界を迎えると、2 台目の Cacti サーバを立ち上げました。それも限界を迎えると、次をどうするかが問題になりました。監視サーバが複数に分割されていると、必要なデータがどのサーバに存在するのか分からなくなり不便でした。

また、当時は登録作業等の運用も手動で行っていたため、登録作業を後回しにしたたま忘れられるケースが目立つようになってきました。必要なデータが見つからないことが多くなると、そもそもあまり使われなくなってしまいます。

分散監視システム及びサーバ自動登録システムの検討

そこで、大規模インフラの監視に対応する、スケールアウト可能な監視システムが必要だと考えられましたが、当時は希望通りの仕様のものを見つけることができませんでした。それに、それまで使っていた Cacti には使い慣れていましたから、Cacti を使い続けることができればベターだと思われました。

そこで、Cacti をベースとした分散監視システムの開発を行いました。実現可能性を検討したところ、意外と簡単に実現できそうなことに気づいたのでした。また、同時に社内で使用されているサーバ管理データベースとの連携システムを開発し、サーバの登録の自動化することに挑戦しました。

Cacti による監視サーバ分散の仕組み

あまり詳しく書いても最後まで読んでもらえなさそうなので、概要を簡単に説明します。

求められる要件を整理すると、データ閲覧に用いるフロントエンドサーバは１台だけにしたいということと、データ収集処理を行うサーバは複数台に分散したいということです。そうすると、よくあるマスタ/スレーブ構成を実現すればよいように思われます。

ここで、Cacti の実装を調べてみると、内部はおおまかに以下のような構成となっていることがわかります。

• おおまかに、Web UI を提供するフロントエンドと、データ集種を行うポーリング部とに分かれている
• 監視対象サーバより収集したデータは RRDtool を用いたデータファイルに格納される
• 設定データは MySQL データベースに格納される

ここで、フロントエンドとポーリング部とが独立した動作となっているところがポイントです。フロントエンドとポーリング部は、物理的には異なるサーバで動いていてもよいように見えませんか？ 例えば次のような構成が可能ではないでしょうか。

実験の結果、実際に上のようなサーバの分離が可能であることがわかりました。あとは、スレーブサーバが複数存在する場合に、それぞれに異なる監視対象サーバを割り当てるにはどうすればよいのかとか、実際はスレーブサーバ上に存在する RRD ファイルが、あたかもマスタサーバ上に存在するかのようにフロントエンド部を騙すにはどうすればよいのか等、いくつかの課題を解決すれば完成です。この方法では、原則として Cacti のコードを修正する必要がないのもポイントです。

サーバ管理データベースとの連携

グリーでは、当時運用中の機器を管理するデータベースが存在しており、外部からそのデータを参照することが可能となっていました。そこで、サーバ管理データベースから新規サーバ情報を取得して、Cacti に新規デバイスとして登録し、適切なテンプレートを適用して対応するグラフを追加登録するツールを開発しました。

Cacti には、デバイスやグラフを登録するための CLI が標準で付属しているため、これを利用することができました。付属の CLI で足りない部分は独自に CLI を追加したり、直接 MySQL に置かれているテーブルを更新することで対応しました。

登録作業は定期的なバッチ処理により全自動で実行されており、通常は人が設定作業を行う必要がないようになっています。そのため、監視システムの運用に必要な作業は定期的なスレーブサーバの増設程度となっています。

まとめ

このように、グリーでは、独自に拡張した Cacti を用いて監視システムを運用しており、全サーバ、全ネットワーク機器を常時モニタしています。運用も多くが自動化されており、担当者は普段は何もすることがありません。

既存のツールはグリーのような規模の環境での利用を想定したものでない場合が多いので、定番のツールをそのまま使って解決できることが少なくなってきています。グリーのインフラチームは、サービス運用を支えるためのツールの改良や、新規開発にも取り組んでいます。