Serf/Consulで管理を自動化! ~実践的な手法を紹介~

第4回 Consulのサービス検出と様々なインターフェース

この記事を読むのに必要な時間:およそ 3.5 分

前回までの連載は,Serfを使ったクラスタの構築や,イベントハンドラを使って一斉にコマンドを実行する方法を見てきました。今回からはSerfではなく,Consulを用いたクラスタの管理や,サービスの監視,自動処理のしかたを学んでいきます。

ConsulはSerfと同じく,面倒な手作業を自動化または省力化するための役割を持っています。ですが,両者の機能や使い方には様々な違いがあります。今回はSerfとConsulの違いと,Consulの基本的な機能・特徴について扱います。

Consulの主な機能と特徴

Consulは,Serfと同様にHashiCorpがオープンソースとして公開・開発しているソフトウェアです。Serfより後の2014年春に初リリースされ,以降はGitHubやIRCを通して議論・開発が行われています。

Consulの機能の1つに,クラスタのメンバー管理機能があります。これはSerfと同じ機能であり,Consulはクラスタ管理機能の一部に,Serfのモジュールを内包しています。Serfはクラスタ内のメンバー管理機能と,コマンドを同時実行するオーケストレーション機能を提供するためにも,Serfエージェント間の通信を土台としています。

リリース当初のConsulは,Serfの一部機能(メンバー管理)しか使えませんでした。現時点(v.0.5)では,イベント同時実行のオーケストレーション機能を含め,Serfが提供する機能の大部分はConsulに統合されています。

機能だけでなく,SerfとConsulはコマンドライン上での操作も部分的に似ています(例:メンバーの一覧を表示するconsul members)。ですが,Consulの機能はSerfのメンバー管理やオーケストレーションだけではありません。

Serfでできなかったサービス監視を実現

SerfとConsulの違いは何でしょうか。両者の一番大きな違いは,サービス監視の有無です。ConsulはWebサーバやデータベースの状況変化をトリガとして,様々な自動処理に応用することができます。

Serfが自動実行するイベントの発生タイミングは,あくまでSerfエージェント間の通信状況か,ユーザ自身によるイベント実行が必要です。そのため,もしSerfエージェントが正常に動いていたとしても,Webサーバやデータベースに問題が発生している場合もあり,それを直接Serfエージェントが知ることができません。

このSerfの弱点を解決するのが,Consulです。Consulは,Serfと同様の機能に加え,任意のサービスに対する状態監視を行うことができます。Consulにおけるサービスとは,Consulの中でApache HTTP Server・NginxのようなWebサーバ,MySQLやPostgreSQLのデータベース,各種デーモン等の稼働状況を定義するものです。

図1 SerfとConsulで異なるクラスタ範囲

図1 SerfとConsulで異なるクラスタ範囲

Consulはそれぞれのサービスに対する正常性の確認(ヘルスチェック)を行います。また,監視対象はサーバの中だけに限りません。ネットワーク機器に対するpingや,クラウド上のサービスAPIをアクセスした結果に対してもサービスとして定義できます。

そして,そのサービス状態はConsulのインターフェースを通して参照できます。Web UIを通せば,人によって視覚的にサービス状態を参照できます。DNSインターフェースであれば,サービスの正常性とDNSの名前解決をリアルタイムに同期します。HTTPインターフェースはREST APIを通してサービス状態を参照できるだけでなく,その変化に応じて任意のコマンドの自動実行も可能となります。

Consulの主な機能

Consulの主な機能は,次の通りです。

  • サービス検出機能と障害検知
  • キーバリューストレージ機能と複数のインターフェース
  • マルチデータセンター対応
  • 周辺ツールとの連携

これらのConsulが提供する機能群は,Serfと同様に,何らかのシステム変化に対する自動的な処理機能を提供するものです。以下では,それぞれの機能について詳しく見ていきます。

サービス検出機能(service discovery)

サービス検出とは,Consulクラスタが稼働するシステム全体において,どのサーバ上でどのようなサービスが稼働しているか,そして,それらは正常か異常かどうかを確認する機能です。

Consulクライアントは,主にサーバ上のデーモン(NginxやMySQL等)をサービスとして定義します。サービスの定義はエージェント起動時にJSON形式の書式で定義するか,後述するREST APIを通して行います。以下はサービスの定義例です

Webサーバを監視する定義

{
  "service": {                                      # サービスの定義開始
    "name": "web",                                  # サービス名称を「web
    "port": 80,                                     # ポート番号は「80
    "check": {                                      # ヘルスチェックの定義開始
      "script": "curl localhost:80 >/dev/null 2>&1",# curlでローカル環境の監視
      "interval": "10s"                             # 監視間隔
    }
  }
}

定義されたサービスに対して,Consulクライアントは定期的にヘルスチェックを実行します。ヘルスチェックはサービス毎に任意の秒数で指定します。

Consulクライアントはサービス毎に正常か異常かを把握し,この情報に変化があれば直ちにConsulサーバに通知します。また,このサービスはREST APIを使った登録も可能です。

サービスの情報はConsulサーバ上のKVSに格納され,この情報はWeb UIやDNS・HTTPの各インターフェースから参照できます。

図2 Consulのサービス検出と参照

図2 Consulのサービス検出と参照

著者プロフィール

前佛雅人(ぜんぶつまさひと)

クリエーションライン株式会社 Technology Evangelist

ホスティングサービスで運用保守サポートに携わった後,現職へ。サポート業務や新技術検証・開発業務を行う。趣味で監視や自動化に関するOSS検証や翻訳を行うのが好き。辛口の日本酒が大好き。

Twitter:@zembutsu

コメント

コメントの記入