Yahoo! JAPANに学ぶメトリクス収集のケーススタディー：Sensuで始めるクラウド時代のシステム監視（9）

新たなクラウド監視ツールとして注目され始めている「Sensu」の活用方法を解説する本連載。今回は、Yahoo! JAPANにおける「Sensu」でのメトリクス収集事例を紹介します。

[北田駿也，ヤフー株式会社]

連載目次

Sensuによるメトリクスの収集フロー

　前回は、Yahoo! JAPANの「Sensu」運用事例として、採用の経緯や世代ごとのシステム構成を紹介しました。今回は、実際にSensuでメトリクスを収集する方法や注意点などを紹介します。

　現在、Yahoo! JAPANのプライベートクラウドでは6000台以上の物理サーバを運用しており、さらにその上で9万台以上のサーバ（仮想マシン）を稼働しています。これら9万6000台の物理／仮想サーバのメトリクスをSensuで収集しています。

　実際、これだけの大規模システムのメトリクスをSensuで収集するとなると、さまざまな問題に直面します。そこで今回は、Yahoo! JAPANがそうした問題に対してどのように取り組んできたかも併せて紹介していきたいと思います。

　Sensuでメトリクスを収集する場合は、通常の監視と同様、「Sensu Client」にメトリクス収集用のプラグインを追加します。詳しい設定方法は、本連載第6回「InfluxDBとChronografでメトリクスを可視化する」で説明されているので、そちらを参照してください。ここでは“メトリクスの収集フロー”について説明していきます。

　まず、Sensu Clientはメトリクス収集用のプラグインを実行し、その出力（メトリクス）を通常の監視プラグインと同様、オープンソースのメッセージブローカーソフトウェアである「RabbitMQ」に転送します。Sensu Serverは、RabbitMQからメトリクスを取り出し、あらかじめ設定した「メトリクスハンドラ」により、時系列データベースへとメトリクスを転送します。この流れをまとめると、以下の図1のようになります。

図1　Sensu Server／Sensu Clientによるメトリクスの収集フロー

Sensuでメトリクスを収集する際の注意点

　Sensuでメトリクスを収集する際には、幾つか気を付けなければならないポイントがあります。以降は、Yahoo! JAPANでの事例も踏まえながら、その注意点を紹介していきます。

Checkのスケジューリングについて

　Sensuにおける「Check」のスケジューリングは、“Sensu Serverが行うタイプ”と“Sensu Clientが行うタイプ（Standalone）”の2つがあります。

　まず、Sensu Serverがスケジューリングするタイプ（図2）ですが、こちらはSensu ServerがRabbitMQを通して、Sensu ClientにCheckを実行するように命令を発行します（図2の（1））。そして、Sensu ClientがCheckプラグインを実行し、その結果をSensu Serverに返します（図2の（2））。

図2　Sensu Serverが「Check」をスケジューリングするタイプ

　ここで気を付けなければならない点は、Sensu ServerからのCheck実行命令には“遅延が発生する”ということです。例えば、Sensu Serverが1分おきにCheck実行命令を発行するようにスケジューリングしていたとしても、Sensu Clientの方では必ず1分おきではなく、数秒ずれてCheckが実行されてしまいます。そして、RabbitMQのメッセージ量が多くなるに従って、この遅延も大きくなり、無視できないものになっていきます。

　Yahoo! JAPANの環境でも、この方式でメトリクスを収集していた時期がありました。しかし、収集されるメトリクスの間隔に1〜2分の開きが出て、データの均一性がなくなってしまったため、この方式でのメトリクス収集はやめました。

　一方、Sensu Clientが行うStandaloneですが、こちらはSensu Client自身が一定間隔でCheckを実行します。そのためメッセージの遅延がなく、メトリクス収集のような、常に一定間隔で実行したいようなプラグインに向いているといえます（図3）。

図3　Yahoo! JAPANでは、メトリクス収集用のプラグインの実行はStandaloneタイプで行っている

　Yahoo! JAPANの環境でも、このような理由からメトリクス収集用のプラグインの実行はStandaloneで行うようにしています。

RabbitMQのパフォーマンスについて

　RabbitMQのパフォーマンスは、ある程度まではスケールアウトできます。しかし、扱うメッセージの量が多くなるにつれて、メッセージの配送が遅延してきます。そして、負荷によってはメッセージ自体をさばけなくなってしまいます。このため、ある程度のシステム規模になった場合には、RabbitMQのパフォーマンスに注意する必要があります。

　実は、RabbitMQに負荷をかける最大の要因がメトリクスです。メトリクスは収集対象となるサーバや種類が増えれば、その分メッセージ量も大量になり、RabbitMQがこれをさばけなくなります。そして、この影響により、通常監視のメッセージ配送も遅延してしまい、アラートの発生が遅れるなどの弊害が出てきます。

　Yahoo! JAPANでも実際に起きたことですが、アラートの発生が数分遅れてしまい、障害に気が付かなかったという状況がありました。このため、現状のアラートとメトリクスを同じRabbitMQで配送するという構成はやめて、メトリクス用の配送パイプラインはSensuのRabbitMQから別のものへと切り替えました。

　現在のYahoo! JAPANでは、このような問題を回避するため、以下の図4のようなメトリクス用のパイプラインを運用しています。

図4　現在のYahoo! JAPANで運用しているメトリクス用のパイプライン

　通常のメトリクス収集用プラグインでは、標準出力にメトリクスを書き出し、それをSensuのRabbitMQに配送します。しかし、Yahoo! JAPANではこれでは問題があったため、標準出力にはアラートのメッセージのみを書き出し、メトリクスはSensuのRabbitMQとは別のRabbitMQへ配送するようにしました。そして、その先にいる「Relay Agent」（自作）が時系列DBやその他のシステムへメトリクスを配送する仕組みになっています。

　Relay AgentはYahoo! JAPANで自作したものですが、仕組みとしてはSensu ServerのようにメトリクスをRabbitMQから取り出し、その種類に応じて時系列DBや別のパイプラインに配送するというものになります。

　以上のように、Sensuでアラートの発生やメトリクスの収集を行ってはいますが、その配送パイプラインはアラート用とメトリクス用で完全に分離することで、大規模化を実現しています。

終わりに

　今回は、Sensuのメトリクス収集にフォーカスした事例ということで、メトリクスのパイプライン、そしてメトリクスを収集する上での注意点を紹介しました。

　注意点とは書きましたが、実は規模の小さい環境では全く気にする必要のないことでもあります。しかし、システムの規模が大きくなるにつれて、今回紹介したようなメッセージの遅延やRabbitMQのパフォーマンス問題が出てくると思います。その際に本稿の内容が役に立てれば幸いです。

　次回は再び堀内晨彦氏から、本連載のまとめとSensu勉強会の紹介をしていただきます。お楽しみに。

筆者紹介

北田 駿也（きただ しゅんや）

東京電機大学大学院卒（情報通信工学科）。2013年にヤフー株式会社に入社、プライベートクラウドチームに配属されてそのまま今に至る。業務領域としては、OpenStackの改修／構築／運用、OpenStackのCI／CD、OpenStackの監視・メトリクス収集、OpenStackのポータルサイト開発、その他周辺ツールの開発など、OpenStackを中心にさまざまな業務に従事。