新たなクラウド監視ツールとして注目され始めている「Sensu」の活用方法を解説する本連載。JAPANがSensuを採用した経緯と活用状況を紹介します。JAPANでは、2013年にプライベートクラウドとして「OpenStack」運用を開始しました。そのプライベートクラウドの監視基盤として、日々の運用を支えているのが「Sensu」です。JAPANにおけるSensu採用の経緯から、現在に至るまでのケーススタディーを紹介します。JAPANではOpenStackの導入前は、プライベートクラウド基盤を独自に開発して運用していました。その独自プライベートクラウドの監視基盤は、社内で標準的に使われていた独自拡張を施した「Nagios」でした。監視対象の増加に対しては、Nagiosクラスタを新規構築して増加分の監視をまかなうというシンプルな手法を採用していました。この手法でも運用は問題なくできていましたが、監視対象が増加するにつれ、スケーラビリティの観点から限界を感じることも多くなりました。監視する対象が数百台になると、どうしてもNagiosの設定ファイルでは内容が煩雑化してしまいます。それを何セットも運用するのは、幾つかのユーティリティーを駆使してもオペレーションが難しく、職人芸のようになっている状況でした。ホストから収集されたメトリクスは各Nagios上にストアされていましたが、統合的な活用がうまくできていない状況でもありました。OpenStack環境は計画の段階で、この独自プライベートクラウドを大きく上回る規模になることが分かっていました。そこで、監視の運用負荷を減らすためにスケーラビリティと柔軟性を備える監視基盤の選定を行い、最終的に次の5つの理由からSensuを選択しました。理由(1):コミュニティーが活発で将来性が見込める私たちが最も重視したのは「ツールの将来性」です。どれだけ優秀な設計や豊富な機能を備えていても、コミュニティーが盛り上がっていなければ継続的な開発が見込めず、採用リスクが伴います。0.11」でしたが、開発者が積極的にプロモーション活動を行っていたこともあって日本でも認知度が高まりつつあったこと、そして、Sensu本体の他にサードパーティーのプラグイン開発も活発だったことなどから、将来性に関しては問題なしと判断しました。理由(2)Nagiosのプラグイン資産を流用できるSensuは、Nagiosのプラグイン資産を流用できることも大きな魅力でした。社内基準に準拠するためのNagiosのプラグインを複数運用していたことから、これらの移植コストをかけずに済むのは大きなメリットでした。理由(3)監視対象の増加に自動で対応できるSensuでは監視対象の増加が自動で完了するというのも大きな利点でした。OpenStackのクラスタを追加するときには、一気に数百台のサーバを監視対象にしなければなりません。それを設定ファイルを編集することなく完了できるというのは、オペレーションコストの大きな削減につながります。理由(4):Chefなどの構成管理ソフトウェアと連携できるSensu自体の環境構築は、公式に用意されているChefの「cookbook」でほとんど完結させることができます。APIが用意されていれば、さまざまなオペレーションをソフトウェアでコントロールしたり、Sensuが持つ監視履歴などのデータを活用したりしやすくなります。Sensu導入の経緯——どのように導入を進めたかSensuの導入を始めたのは2013年9月ごろで、既存のNagiosと並走させる形で徐々に導入を進めていきました。その変化を世代順に分けて追っていきたいと思います。第1世代——Nagiosと並行稼働Sensu導入の最初期は、OpenStackの規模がそこまで大きくなかったことから、既存のNagiosと並行稼働する形で、以下の図1のような構成で導入しました。第1世代のSensuの構成。既存のNagiosと並行して稼働Sensuの構成は、Nagiosの構成イメージをそのまま持ってくるような形で、全てのコンポーネントを1つのサーバに収める「オールインワン」構成としていました。約10項目を60秒間隔で監視し、通知は1日1回の頻度でメールと社内チャットに流れるように設定していました。その際のサーバのスペックは以下の通りです。1+0構成×1ボリュームNIC:1Gbpsかなりシンプルな構成ですが、この状態で約500台のクライントに対して安定して動作しました。第2世代は第1世代と大きな差はなく、基本的に冗長化されていなかった部分を補強した構成になります。Clientの接続を振り分けていました(図2)。Redisに関しては冗長化をしておらず、使われないものはコールドスタンバイとして待機させていました。第2世代のSensuの構成。RabbitMQを3台でクラスタ構成にして冗長化。Clientの接続を振り分けている第2世代ではクライアント数が約1000台まで増えていましたが、引き続き安定して動作しました。第3世代——単体での監視を本格化Nagiosとの並行稼働を停止して、Sensu単体での監視に本格的に移行したのが現行の運用構成となる第3世代です。ハイパーバイザー数の急激な増加に加え、ハイパーバイザー以外の監視も開始するなどで負荷が増大したため、処理性能の向上を主眼に構成がアップデートされています(図3)。第3世代のSensuの構成。Nagiosとの並行稼働を止め、Sensu単体での監視体制に移行。処理性能の向上を目的に構成もアップデートSensuの各コンポーネントを別サーバへと切り出して要件を満たすよう構成したものをクラスタとし、これを2セット運用しています。2014年の秋ごろにこの構成へとシフトしてから今に至るまで、台数の増減などはあるものの、安定した運用が続いています。現在監視しているクライアント数は約9000台弱になります。第3世代の構成のポイントは以下の通りです。Serverは基本的にCPUバウンドな処理が大半を占めます。VMのサイジングでは、この点を考慮するとよいでしょう。RabbitMQのキューのミラーリングに関しては当初は有効にしていたのですが、監視対象が4000を超えたころからメッセージの配送遅延などの影響が出始めたため、現在は無効にしています。brokerを使用するように設定しています。この設定にしておくと、接続先のRabbitMQがダウンしてもすぐに別のノードに接続し直してくれることや、その際のメッセージロストは許容できるレベルで監視への影響も少なくて済みます。監視項目と台数の掛け算次第ですが、ある程度のクライアント台数を監視するのであれば、最初から「キューのミラーリングをしない」というポリシーで運用することを検討しましょう。Serverから始め、Kubernetesへと移行させていくことを検討中です。APIを備えているので、さまざまなオペレーションをソフトウェアによって制御することができます。私たちはこれを主に「ChatOps」に活用しています。JAPANの社内には「MYM」と呼ぶSlackのような内製チャットシステムがあり、これと「Errbot」というフレームワークを組み合わせてbotを開発、運用しています。この仕組みにより、運用者はチャットから各ホストのアラートを制御できるようにしています。その他、各サーバに「Fabric」でコマンドを発行する際に、Sensuが持つ情報を用いてアクティブなサーバをリストアップして利用する機構を組み込むことなどにも活用しています。requestエンドポイントを活用すると、普段は実行させずに必要なタイミングでのみ、特定のコマンドを実行させるようなスキームを実現することも可能です。Clientに仕込んでおき、必要なタイミングでAPIからリクエストを送ることで実現できます。これにより、例えばあるcheckで異常が検知されたときに、ハンドラでこれをフックして対象のホストに自己修復を試行させたり、より詳細な調査報告をさせたりするなどの活用が可能になります。JAPANにおけるSensuの導入経緯と、どのように運用、活用しているかを紹介させていただきました。小規模な構成から始めて、要件に応じて柔軟にスケールアウトしたことがお分かりいただけたと思います。Clientが立ち上がると自動で監視が開始する点です。監視対象の追加時に“サーバ側の設定を変更する必要がない”というのは、想像以上にオペレーションコストの削減に寄与してくれました。これまで運用してきたNagiosのプラグイン資産を無駄にせずにできたことも大きく、パワフルな環境にスムーズに移行することができました。1.0」となりました。Hooks」機能の追加、公式Dockerイメージの提供などを予定しているようです。2017」が開催され、今後のさらなる盛り上がりと発展が期待されます。2017のWebサイトによると、YelpやGE、GoDaddyといった企業もSensuを活用してことが紹介されています。筆者は残念ながら参加できそうにないのですが、現地の様子がネットに上がってくるのを楽しみに待つ予定です。注目しているのが「sensu-go」とされるSensuバージョン2.0のロードマップ公開です。最後になりましたが、本稿がSensuの導入を検討している方々の役に立てば幸いです。次回はメトリクスの収集事例について、弊社北田から紹介させていただきます。同年ヤフー株式会社入社。Webサービス運用や広告研究開発を経て、2013年からサーバハードウェア/OS/OpenStackなど、インフラ領域の業務に従事。趣味は、旅行・飲酒・ドライブなど。運用監視をはじめ、多くの企業が取り入れているOSS(オープンソースソフトウェア)。目的に応じて最適なものを選択し、うまく使いこなせば強力な武器となるが、それができなければかえって手間や混乱の原因にもなりかねない。本連載では注目のOSSをピックアップして実際に検証し、基本的な優位性、劣位性を明確化した。OSSを選ぶ際の参考にしてほしい。近年の「先が見えない」市場環境の中、ビジネス要請へのスピーディな対応が求められるシステム運用管理にも新しいアプローチが求められている。本特集『クラウド/OSS時代の「業務を止めない」運用ノウハウ』では、そのアプローチを一つ一つ掘り下げていく。運用管理者が知っておきたい監視・ジョブ管理向けOSS構成例4つの比較まとめシステム運用の上で重要な「監視」と「ジョブ管理」について、効率的な実現方法を解説。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。