Zabbixサーバーの負荷を圧倒的に下げた話

AWS運用自動化サービス「Cloud Automator」
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。

初めまして今年入社した長谷川です。
新入社員として最初の仕事である、Zabbixサーバの負荷を下げた話を書きたいと思います。
実はこのプロジェクトは、まだ新人研修を行っている入社1ヶ月目の時に、Rubyが得意?という理由でアサインされ、1週間で構築と実装しました。以上自慢です。

構築したシステムは、CloudWatch経由でしか監視ができないRDSやSQSなどのサービスのメトリクス(監視データ)を大量にZabbix取り込む場合の解決方法の一つだと思います。今後同じ問題に直面した方々の参考になれば幸いです。

従来のシステムの状況

従来のシステムは、Zabbixサーバがインストールされている1台のEC2インスタンスが、CloudWatchから値を取得しているだけのシンプルな構成でした。

ZabbixサーバーはCloudWatchから各サービスのメトリクスを取得するRubyスクリプトを実行し、その結果を取り込んでいました。この処理は5分毎に約6000回Rubyスクリプトが実行されていました。

そのため、CPU使用率は常時100%でした。
 

構築したシステム

監視対象が増えた場合でも対応できるように、スケールアウトする構成をElastiCacheとSQSを使って構築しました。

Zabbixサーバから実行されるRubyスクリプトは、ElastiCacheに格納されているCloudWatchから取得したメトリクスをZabbixサーバに取り込むだけのスクリプトです。実際にCloudWatchから取得する処理は別のインスタンスで実行することで、Zabbixサーバの負荷を軽減しています。

ElastiCacheからデータを取得した後に、そのデータの有効期限を設定します。これは、使われなくたなった値を自動的に消去するための仕組みです。

また、ElasticCacheのキーと値の使い方が実装上のミソで、キーが実行すべきコマンドの文字列で、値がその実行結果という使い方をしています。これによって、ElasticCacheのキーの一覧を取得することで、次の処理で実行すべきコマンド一覧がわかるようになっています。

ElastiCacheに格納されていコマンド一覧は、cronで5分毎に取得しをSQSに送信します。AutoscaleするEC2インスタンス達は、SQSから常時ポーリングして取得したコマンドを実行してその結果をElastiCacheに格納しています。

構築後の状況

CPU利用率が10%以下になりました。ElastiCacheとSQSを有効活用することで簡単に負荷分散システムを構築することができました。

今後の展望

ZabbixのLLDを使うことで、ElastiCacheを経由するのではなく、CloudWatchから取得したメトリクスをZabbixサーバに直接送信する仕組みを実装(ほぼできた)して、よりスリムな構成に移行していきます。

Zabbixすき

Zabbixはこのプロジェクトで初めて触ったのですが、LLDやAPIなどプログラマブルな要素が色々とあって面白いプロダクトだと感じました。好きです。

AWS運用自動化サービス「Cloud Automator」