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

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

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

従来のシステムの状況

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

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

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

構築したシステム

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

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

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

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

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