Sensu、Uchiwa、Redis、RabbitMQを本番利用に向けて冗長化する：Sensuで始めるクラウド時代のシステム監視（7）（1/2 ページ）

新たなクラウド監視ツールとして注目され始めている「Sensu」の活用方法を解説する本連載。今回は、Sensuを本番（プロダクション）環境で使うための冗長化について解説します。

[堀内晨彦，＠IT]

連載目次

Sensuの監視環境を冗長化するには

　前回は、「Sensu」でプラグインを使ってメトリクスを収集する方法と、その結果を「InfluxDB」に保存し、「Chronograf」で可視化するまでの流れを説明しました。

　今回は、Sensuを本番（プロダクション）環境で使うための冗長化について解説します。「sensu-server」「Redis」「RabbitMQ」をそれぞれ2系統ずつ構築することで、耐障害性を高めます。ここでは、Sensu、Redis、RabbitMQをインストールしたホストを2台用意し、SensuとRabbitMQはアクティブ−アクティブ、Redisはマスター（Master）−スレーブ（Slave）として構成します（図1）。

図1　今回のSensuの冗長化構成。SensuとRabbitMQはアクティブ−アクティブ、Redisはマスター−スレーブで構成する

　なお、Sensu、Redis、RabbitMQをインストール方法については、以下の本連載の過去記事をご覧ください。

• Sensuを支えるミドルウェア「Redis」と「RabbitMQ」の環境を構築する（本連載 第3回）
• SensuとUchiwaのインストールと基本設定のポイント（本連載 第4回）

Redisのレプリケーションを構成する

　今回の構成では、Redisはマスター−スレーブ形式で冗長化されて、データがレプリケーションされるようになっています。スレーブはマスターから非同期でデータをコピーしており、マスターの“完全なコピー”となります。Redisのレプリケーションに関する細かい仕組みや設定は、以下の公式ドキュメントを参照してください。

• Replication - Redis

　今回は、以下のSensuの公式ドキュメントに従って、2台のRedisでマスター−スレーブを構成します。

• Sensu | Redis Configuration | High-availability configuration

　まずは、マスター側（ここでは「sensu-one.hico.io」）の設定を行います。マスター側では複数のsensu-serverから接続できるように、ローカルホスト以外からの接続も受け入れるように設定します。併せて、接続時にはパスワード認証を行うようにします（「your_redis_password」は適宜ご自身の環境に置き換えてください）。

# ローカルホスト以外からの接続を受け入れる
$ sudo sed -i 's/^bind 127\.0\.0\.1$/# bind 127.0.0.1/g' /etc/redis/redis.conf
# パスワード認証を有効化（your_redis_passwordは適宜置き換えてください）
$ sudo sed -i 's/^# requirepass foobared$/requirepass your_redis_password/g' /etc/redis/redis.conf
# Redisのサービス（デーモン）を起動
$ sudo /etc/init.d/redis-server start

▲マスター（sensu-one.hico.io）の設定（bash）

　次に、スレーブ側（ここでは「sensu-two.hico.io」）の設定を行います。マスターと同様にローカルホスト以外からの接続の受け入れと、パスワード認証の設定を行います。自身が“マスターのスレーブであること”と、マスターのパスワードを設定すれば、スレーブとして動作します。

# ローカルホスト以外からの接続を受け入れる
$ sudo sed -i 's/^bind 127\.0\.0\.1$/# bind 127.0.0.1/g' /etc/redis/redis.conf
# パスワード認証を有効化（your_redis_passwordは適宜置き換えてください）
$ sudo sed -i 's/^# requirepass foobared$/requirepass your_redis_password/g' /etc/redis/redis.conf
# Master(sensu-one.hico.io)のレプリケーションを設定
$ sudo sed -i 's/^# slaveof <masterip> <masterport>$/slaveof sensu-one.hico.io 6379/g' /etc/redis/redis.conf
# Masterのパスワード認証を設定（requirepassと対応）
$ sudo sed -i 's/^# masterauth <master-password>$/masterauth your_redis_password/g' /etc/redis/redis.conf
# Redisのサービス（デーモン）を起動
$ sudo /etc/init.d/redis-server start

▲スレーブ（sensu-two.hico.io）の設定（bash）

　最後に、レプリケーションが構成されたことを「redis-cli」コマンドで確認します。マスターがスレーブに接続していること、スレーブがマスターに接続していることが確認できます。

# Masterでconnected_slaves:1であることを確認
$ redis-cli -h sensu-one.hico.io -a your_redis_password INFO | grep -A 2 role
role:master
connected_slaves:1
slave0:ip=150.95.150.153,port=6379,state=online,offset=603,lag=0
# Slaveでmaster_link_status:upであることを確認
$ redis-cli -h sensu-two.hico.io -a your_redis_password INFO | grep -A 3 role
role:slave
master_host:sensu-one.hico.io
master_port:6379
master_link_status:up

▲「redis-cli」コマンドでレプリケーション構成を確認する（bash）

　ここまでの設定で、Redisのレプリケーション（マスターとスレーブのデータ同期）が設定できました。

　ただ、この構成ではマスター側に障害が発生したときの「スレーブの昇格（フェイルオーバー）」まではサポートされていません。公式の監視およびフェイルオーバー用ツールとしては「Sentinel」が提供されています。SensuでもSentinelをサポートしているので、興味のある方は試してみてください。

• Redis Sentinel Documentation - Redis

　他にも、「Consul」などのサービスディスカバリ系ツールを使っている事例もあります。筆者の職場ではConsulを使っており、マスターの監視に失敗すると、スレーブでスクリプトを実行してマスターに昇格させるといった運用を行っています。ConsulはDNS（Domain Name System）の機能を持っており、常にマスターのIPアドレスを引けるようになっているので便利です。