こんにちは。Gunosyの石橋と申します。 最近よくSerfとかConsulの名前を見かけるのですが正直よくわかっていなかったのでこれでは駆逐されると思い公式サイトを尋ねました。

さて、これらのツールはよくわかってないうちから

• vangant/packerを提供しているhashicorpが作っている => なんかかっこいい！
• Goで書かれてるのでコンパクトで配置も楽ちん => なんかかっこいい！
• 非集中型、分散型のオーケストレーションを可能にする => なんかかっこいい！
• Raft Consensus AlgorithmとかGossip Protocolを使っている => なんかかっこいい！

とJ-POPアーティストに憧れる中学生のそれの如きトキメキを提供してくれます。 いや今どきの中学生はニコ動とかで憧れを醸成させたりするんですかね。わかんないけど。

Serf

“Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant.”

Serfは「軽量で」「可用性が高く」「障害耐性も高い」「サービス検出とオーケストレーションのための」「非集中型ソリューション」とあります。 かいつまんで以下のことができます。

メンバーシップ管理/イベント処理

Serfを動かしてるノード同士で簡単にメンバー情報を共有できます。またクラスタへのノード追加削除のイベントから動くスクリプトを設定できます。 複数ノードで構成されたクラスタに新しいノードを追加しかつ「追加時にはこのスクリプトを実行」みたいなことを行うにはもってこいの仕組みです。

障害/リカバリ検出

意図的な追加削除だけではなく障害の発生しているノードを検知し、残りのサーバに対して通知を行うのもSerfの機能です。ここでも特定のスクリプトを仕込むことが可能です。また障害が発生したノードに対しては定期的なチェックを行い復帰も検知できます。

カスタムイベント通知

ノード追加/削除や障害/復帰だけではなく任意のイベントを全メンバーに通知することが可能です。

Consul

“Service discovery and configuration made easy. Distributed, highly available, and datacenter-aware.”

対してConsulは「サービス検出/設定を容易にする」「分散型の」「可用性の高い」「データセンターを意識した」ものとあります。サービス検出がSerfと被ってますね。

サービス検出/問い合わせへの対応

Serfのサービス検出がサービスというよりはノードレベルに近かったのに対しConsulはもう少し抽象化された「Webフロントエンド」「データベース」などのサービスレベルまでの管理も行います。またSerfと異なりConsulはhttpやdnsインターフェースを通して「このサービスはどこ？」と問い合わせると答えてくれます。

ヘルスチェック

上記サービス検出とヘルスチェックを組み合わせると、落ちてるホストへの接続を回避する振る舞いが可能です。エージェントの死活を見るだけのSerfと異なり独自のヘルスチェッカ(特定httpエンドポイントを叩くとかメモリを監視するとか)を組み込めるので監視は様々な方法で行えます。

Key-Valueストア

動的構成に使うためのシンプルなKey-Valueストアが入っています。Serfではイベントで渡したデータを各ノードが独自に保持する必要がありましたがConsulではこのストア前提でシステムを構成できます。etcdみたいなもんですよね。

マルチデータセンタ対応

複数データセンタ間でも複雑な設定なくかつ効率よく振る舞うよう設計されており、このあたりがサービスレジスリの先輩であるZookeeperや最近よく目にするetcdとの設計思想の大きな違いのようです。

UI

データセンタごとにサービスの状態を確認できるUIがついてます。どうゆうものを管理したいツールなのかよくわかります。デモがここで見れます。

使い方の違い

ノードベースのメンバーシップ構成および追加や削除イベントからの処理を行えるSerfは自前でノード構成管理を作るときのツールキットとして便利です、一方でデータセンタ-サービス-ノードの抽象化とヘルスチェックがクラスタに参加させるだけで可視化できるConsulはヘルスチェッカさえ書いてしまえばすぐ使えて良いです。

SerfはCAPでいうところのAP(可用性のために一貫性を犠牲にしている)なのに対し一貫したカタログを抱えているConsulはCP(一貫性のために可用性を犠牲にしている)です。 どこかで何かおきてもそれとなく動き続けるSerfと定足数を構成できないとサービスが停止するConsul、目的が異なるのでトレードオフが異なります。 参考1:Consulリリース時のHNのスレ 参考2:Consul vs. Serf(公式)

また一貫性のためだと思いますがConsulはagentがサーバーとクライアント両方のモードがあって合意を形成するサーバを数台で構成して残りはそれに従うクライアントにしろとあります。Serfと違ってサーバ/クライアントを意識した構成にする必要があります。参考3:Agent - Consul(公式)

Serfがサービス検出を行えないかというとそうでもなくって、Serfでは各ノードがタグ情報を定義できるので例えばmembersでリストしたノードの「role=webというタグのものがWebサーバ」みたいことなら特に問題なくできます。ただヘルスチェック等のカスタマイズはConsulにしかない機能なのでサービス層はの障害検出はこちらの機能を使うのが楽でしょう。

より高レベルなサービス解決/マルチデータセンタ構成をどこまで使うかがConsulを使う判断になると思うんですが名前引いたりするとこ等クリティカルな場所が多いのでビビりながら影響の小さいとこでテストをすすめております。そのあたりは次回に続きます。

Gunosyでは構成管理をエキサイティングにしてくれる（いい意味で）エンジニアを募集してます！

参考にさせていただきました

https://news.ycombinator.com/item?id=7607035　Consulリリース時のHNのスレ

http://www.consul.io/intro/vs/serf.html　Consul vs. Serf (SerfのサイトにもConsulのサイトにも他ツールとの比較があって読むとおもしろいです)

http://www.consul.io/docs/agent/basics.html Agent - Consul (Consulのサーバ/クライアントについての説明が書いてあります)

http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/ Open-Source Service Discovery　(Consulこそ入ってないけどSerfの他ツールとの差を知るのに良いまとめです)

http://pocketstudio.jp/log3/2014/04/19/translation_consul_related_documents/Consul関連文書の参考訳、Serfとの違い等 (公式が日本語訳されてます)