Yahoo! JAPANがSensuを選んだ「5つの理由」：Sensuで始めるクラウド時代のシステム監視（8）

新たなクラウド監視ツールとして注目され始めている「Sensu」の活用方法を解説する本連載。今回は、Yahoo! JAPANがSensuを採用した経緯と活用状況を紹介します。

[渡邉貴志，ヤフー株式会社]

連載目次

なぜ、Yahoo! JAPANは監視基盤にSensuを選んだのか？

　Yahoo! JAPANでは、2013年にプライベートクラウドとして「OpenStack」運用を開始しました。そして、そのプライベートクラウドの監視基盤として、日々の運用を支えているのが「Sensu」です。今回は、Yahoo! JAPANにおけるSensu採用の経緯から、現在に至るまでのケーススタディーを紹介します。

　Yahoo! JAPANではOpenStackの導入前は、プライベートクラウド基盤を独自に開発して運用していました。そして、その独自プライベートクラウドの監視基盤は、社内で標準的に使われていた独自拡張を施した「Nagios」でした。

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

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

　一方、OpenStack環境は計画の段階で、この独自プライベートクラウドを大きく上回る規模になることが分かっていました。そこで、監視の運用負荷を減らすためにスケーラビリティと柔軟性を備える監視基盤の選定を行い、最終的に次の5つの理由からSensuを選択しました。

理由（1）：コミュニティーが活発で将来性が見込める

　私たちが最も重視したのは「ツールの将来性」です。どれだけ優秀な設計や豊富な機能を備えていても、コミュニティーが盛り上がっていなければ継続的な開発が見込めず、採用リスクが伴います。

　採用当時、Sensuは「バージョン 0.11」でしたが、開発者が積極的にプロモーション活動を行っていたこともあって日本でも認知度が高まりつつあったこと、そして、Sensu本体の他にサードパーティーのプラグイン開発も活発だったことなどから、将来性に関しては問題なしと判断しました。

理由（2）Nagiosのプラグイン資産を流用できる

　Sensuは、Nagiosのプラグイン資産を流用できることも大きな魅力でした。社内基準に準拠するためのNagiosのプラグインを複数運用していたことから、これらの移植コストをかけずに済むのは大きなメリットでした。

理由（3）監視対象の増加に自動で対応できる

　Sensuでは監視対象の増加が自動で完了するというのも大きな利点でした。OpenStackのクラスタを追加するときには、一気に数百台のサーバを監視対象にしなければなりません。それを設定ファイルを編集することなく完了できるというのは、オペレーションコストの大きな削減につながります。

理由（4）：Chefなどの構成管理ソフトウェアと連携できる

　Sensu自体の環境構築は、公式に用意されているChefの「cookbook」でほとんど完結させることができます。

理由（5）：Web APIが用意されている

　Web APIが用意されていれば、さまざまなオペレーションをソフトウェアでコントロールしたり、Sensuが持つ監視履歴などのデータを活用したりしやすくなります。

Sensu導入の経緯――どのように導入を進めたか

　Sensuの導入を始めたのは2013年9月ごろで、既存のNagiosと並走させる形で徐々に導入を進めていきました。その変化を世代順に分けて追っていきたいと思います。

第1世代――Nagiosと並行稼働

　Sensu導入の最初期は、OpenStackの規模がそこまで大きくなかったことから、既存のNagiosと並行稼働する形で、以下の図1のような構成で導入しました。

図1　第1世代のSensuの構成。既存のNagiosと並行して稼働

　Sensuの構成は、Nagiosの構成イメージをそのまま持ってくるような形で、全てのコンポーネントを1つのサーバに収める「オールインワン」構成としていました。

　約10項目を60秒間隔で監視し、通知は1日1回の頻度でメールと社内チャットに流れるように設定していました。その際のサーバのスペックは以下の通りです。

【Sensuサーバのスペック（第1世代）】

• CPU：Intel Xeon L5630 2.13GHz×2CPU
• メモリ：48GB
• ディスク：SAS HDD 300GB×4台／RAID 1+0構成×1ボリューム
• NIC：1Gbps

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

第2世代――構成を補強

　第2世代は第1世代と大きな差はなく、基本的に冗長化されていなかった部分を補強した構成になります。「RabbitMQ」は3台でクラスタ構成として冗長化させ、キューをミラーリングしてSensu Clientの接続を振り分けていました（図2）。Redisに関しては冗長化をしておらず、使われないものはコールドスタンバイとして待機させていました。

図2　第2世代のSensuの構成。RabbitMQを3台でクラスタ構成にして冗長化。キューはミラーリングして、Sensu Clientの接続を振り分けている

　第2世代ではクライアント数が約1000台まで増えていましたが、引き続き安定して動作しました。

第3世代――単体での監視を本格化

　Nagiosとの並行稼働を停止して、Sensu単体での監視に本格的に移行したのが現行の運用構成となる第3世代です。ハイパーバイザー数の急激な増加に加え、ハイパーバイザー以外の監視も開始するなどで負荷が増大したため、処理性能の向上を主眼に構成がアップデートされています（図3）。

図3　第3世代のSensuの構成。Nagiosとの並行稼働を止め、Sensu単体での監視体制に移行。処理性能の向上を目的に構成もアップデート

　Sensuの各コンポーネントを別サーバへと切り出して要件を満たすよう構成したものをクラスタとし、これを2セット運用しています。

　2014年の秋ごろにこの構成へとシフトしてから今に至るまで、台数の増減などはあるものの、安定した運用が続いています。現在監視しているクライアント数は約9000台弱になります。第3世代の構成のポイントは以下の通りです。

• 性能をあまり必要としないAPIやダッシュボード（Uchiwa）はVM（仮想マシン）上で稼働させる
• Sensu ServerはVM上で稼働させ、クラスタの処理能力に応じてスケールアウトしていく
• RabbitMQはクラスタ構成とするが、キューのミラーリングは行わない
• Sensu Clientは「Multiple RabbitMQ broker」機能でバランシングする

　どのようなハンドラを使うかにも多少左右されますが、Sensu Serverは基本的にCPUバウンドな処理が大半を占めます。VMのサイジングでは、この点を考慮するとよいでしょう。

　RabbitMQのキューのミラーリングに関しては当初は有効にしていたのですが、監視対象が4000を超えたころからメッセージの配送遅延などの影響が出始めたため、現在は無効にしています。

　Sensu Client側では、Multiple RabbitMQ brokerを使用するように設定しています。この設定にしておくと、接続先のRabbitMQがダウンしてもすぐに別のノードに接続し直してくれることや、その際のメッセージロストは許容できるレベルで監視への影響も少なくて済みます。

　監視項目と台数の掛け算次第ですが、ある程度のクライアント台数を監視するのであれば、最初から「キューのミラーリングをしない」というポリシーで運用することを検討しましょう。

　また、現在は主にVMを活用して構築していますが、今後はステートレスなAPI、Uchiwa、Sensu Serverから始め、Kubernetesへと移行させていくことを検討中です。

Web APIを積極活用

　SensuはWeb APIを備えているので、さまざまなオペレーションをソフトウェアによって制御することができます。私たちはこれを主に「ChatOps」に活用しています。

　Yahoo! JAPANの社内には「MYM」と呼ぶSlackのような内製チャットシステムがあり、これと「Errbot」というフレームワークを組み合わせてbotを開発、運用しています。この仕組みにより、運用者はチャットから各ホストのアラートを制御できるようにしています。

　その他、各サーバに「Fabric」でコマンドを発行する際に、Sensuが持つ情報を用いてアクティブなサーバをリストアップして利用する機構を組み込むことなどにも活用しています。

　また、requestエンドポイントを活用すると、普段は実行させずに必要なタイミングでのみ、特定のコマンドを実行させるようなスキームを実現することも可能です。

　Sensuの公式ドキュメントの「Pro Tips」にあるように、「publish: false」で設定したcheckをあらかじめ各Sensu Clientに仕込んでおき、必要なタイミングでAPIからリクエストを送ることで実現できます。

　これにより、例えばあるcheckで異常が検知されたときに、ハンドラでこれをフックして対象のホストに自己修復を試行させたり、より詳細な調査報告をさせたりするなどの活用が可能になります。

終わりに

　今回は、Yahoo! JAPANにおけるSensuの導入経緯と、どのように運用、活用しているかを紹介させていただきました。小規模な構成から始めて、要件に応じて柔軟にスケールアウトしたことがお分かりいただけたと思います。

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

　2017年7月12日、Sensuは長年の開発を経てついに「バージョン 1.0」となりました。リリースを記念するブログ記事によると、今後はSensu自体の「Scheduled Maintenance」機能やインシデント発生時にSensu Client側で自己修復手順を実行させるための「Check Hooks」機能の追加、公式Dockerイメージの提供などを予定しているようです。

• Sensu Core version 1.0 is now available!［英語］（The Sensu Blog）

　2017年8月15日、16日には米国ポートランドで「Sensu Summit 2017」が開催され、今後のさらなる盛り上がりと発展が期待されます。Sensu Summit 2017のWebサイトによると、YelpやGE、GoDaddyといった企業もSensuを活用してことが紹介されています。

　筆者は残念ながら参加できそうにないのですが、現地の様子がネットに上がってくるのを楽しみに待つ予定です。特に注目しているのが「sensu-go」とされるSensuバージョン2.0のロードマップ公開です。

　最後になりましたが、本稿がSensuの導入を検討している方々の役に立てば幸いです。次回はメトリクスの収集事例について、弊社北田から紹介させていただきます。

筆者紹介

渡邉 貴志（わたなべ たかし）

2010年 青山学院大学大学院卒・修士（情報工学）。同年ヤフー株式会社入社。Webサービス運用や広告研究開発を経て、2013年からサーバハードウェア／OS／OpenStackなど、インフラ領域の業務に従事。趣味は、旅行・飲酒・ドライブなど。