Consul関連文書の参考訳、Serfとの違い等

Consul について、自分の中の理解を深めるために関連ドキュメントの参考訳を作成しました(4/19現在)。せっかく作ったのに、自分の引き出しの中にしまっておくだけでは勿体ないと思い、公開します。Consul や Serf に興味を持っている方の参考になれば幸いです。

Consul の意味は、’領事’や’執政官’です。Serf は’農奴’ ですから、まるで、農民(Serf)を支配し、使役するお代官様(Consul)のような関係がイメージされます。実際のところ、Consul は内部の Serf クラスタ上に構築されていますが、Consul の機能や役割は、Serf の持つものとは異なるように見えます（現時点の公開情報では）。詳しくは、ドキュメントをご確認ください。

実際に使いたい！という場合は、先日の投稿 Consul を使ってみた、をご覧下さい。

当ページのドキュメントについては、あくまで参考程度に、というもので正確性を保証するものでもなく（たぶんに所どころ怪しい・・・）、また、何ら私の権利を主張するものでもありません。

※4/19 23:07追記　qpstudy で Consul ネタも含めた発表の機会をいただきましたm(__)m
Serf2Excel – Serf を実運用に活かす話 + Consul もあるよ
http://www.slideshare.net/zembutsu/serf-to-excel-and-consul-qpstudy

■ blog 投稿記事
http://www.hashicorp.com/blog/consul.html

Consul

今日、私たちは Consul、サービス検出と設定のためのソリューションを発表します。Consul は完全に分散し、高い可用性があり、複数のデータセンタにまたがる数千台のノードやサービスにスケールすることができます。

Consul が解決する具体的な問題は、障害が起こっているサービスが利用されないように、サービスアプリケーションが必要とするもの（データベース、キュー、メールサーバ等等）を監視し、ウェブアプリケーションのメンテナンスモードを有効にするなど、サービスの設定をキーバリュー情報を用いて設定を行います。これらは、Consul によって解決できる重要な問題の一部です。

Consulは、サービス検出と設定の問題を解決します。Consul は厳密な学術研究の基盤をもとに構築されているため、データを安全に保持し、大きなインフラ（基盤）でも動作します。Consul は現在の流行/慣行を受け入れており、既存の DevOps ツールともフレンドリーです。

Consul は複数のデータセンタにまたがる非常に大きな基板上で既に利用されており、数ヶ月間、プロダクション（製品）として動作していました。このように公開できることに、私たちはとても興奮しています。詳しくは引き続き以下をお読みください。

動作内容

このセクションでは、Consul がどのように利用され、動作しているかを簡単に説明します。概要は、Consul がいかに簡単で強力かを説明するものです。詳細については、ドキュメントに完全な解説がありますので、多くの技術的な詳細は敢えて省略します。

Consul はサーバとクライアントの２つのコンポーネントを持ちます。サーバとクライアントによって、１つの Consul クラスタを形成します。サーバとクライアントとの唯一の違いは、サーバはデータを格納して、データを複製する唯一のコンポーネントです。Consul クラスタのメンバは、少なくとも１つの既存メンバの IP アドレスを明示することで、自動的にお互いを発見します。Consul に内蔵している自動検出機能を使えば、オペレータはハードコードされた IP アドレスを知る必要はなく、動的なインフラ（基盤）のサポートが簡単に行えます。Consul クラスタにメンバが参加すると、読み書きが出来るようになります。

Service は設定ファイルを用いて登録されるか、クラスタ内の何らかのエージェント（クライアントかサーバ側）の HTTP API を経由して登録します。登録されたサービスとノードは、DNS インターフェースか HTTP インターフェースを用いて問い合わせることができます。DNS インターフェースは、既存のサービスを変更することなく簡単に使う事ができます（ホスト名の名前解決を行うために、bind-utils の dig コマンドを使い、Consul サーバを DNS サーバのように使えます）。

$ dig web-frontend.service.consul. ANY
...

;; QUESTION SECTION:
;web-frontend.service.consul. IN ANY

;; ANSWER SECTION:
web-frontend.service.consul. 0 IN A 10.0.3.83
web-frontend.service.consul. 0 IN A 10.0.1.109

Consul はヘルスチェック機能が統合されているので、クエリインターフェースでは、正常なノード( healthy node) と正常なサービス ( healthy service ) のみ応答します。HTTP API は、全サービスのエンドポイントを見つけるだけでなく、全サービスのヘルス状態を見ることもできます。

設定データは HTTP API を通して取り出すことができます。API は敢えてシンプルにしてあるので、クライアントは簡単にアクセスできます。

$ curl -X PUT -d 'bar' http://localhost:8500/v1/kv/foo
true
$ curl http://localhost:8500/v1/kv/foo
[
 {
 "CreateIndex": 100,
 "ModifyIndex": 200,
 "Key": "foo",
 "Flags": 0,
 "Value": "YmFy"
 }
]

強力な基盤

分散メッセージングやリーダー選挙、セキュリティ、データストレージは、だれもがスクラッチ（ゼロ）から構築しないであろうコンポーネントです。Consul は、これらサブシステムの基盤として、学術研究に基づいた論文、多く引用され査読済みのものを使用しています。

メッセージング ( Messaging ) は、UDP と TCP 接続による gossip 通信で用います。gossip を構築するのは Serf であり、SWIM を基にしています。Serf は世界中に展開され、数千台のマシンによる gossip 通信の原動力となります。gossip を採用したのは、軽量かつコンパクトなためです。TCP が用いられるのは、ネットワーク帯域上で高い信頼性が求められるときです。

リーダー選出 ( Leader election ) は、Raft というスタンフォード大学で開発されたコンセンサス・アルゴリズムを使用します。強固なコンセンサス・アルゴリズムによる Consul の自動修復性能 ( auto-healing nature ) は、オペレータ（運用担当者）にとって嬉しいものです。

セキュリティ ( Security ) は、基盤ツールに対する重要な懸念事項です。Consul は多面的なアプローチを持ちます。gossip メッセージングは、Serf によって提供されており、強い対称性を持つ暗号を使用して安全を確保します。詳細はこちらで学ぶことが出来ます。TCP 上で行われる RPC 通信を安全にするため、クライアントとサーバは、オプションで TLS 認証を用いることもできます。

データストレージ ( Data storage ) は、UMDB を用います。LMDB は完全に ACID 対応で、MVCC を提供します。Consul が稼働している間は、Consul のデータは安全な性質を保ち続けます。

HashiCorp による構築

HashiCorp （ Vagrant や Serf 等の作者である Mitchell Hashimoto 氏の所属する会社）は、DevOps 問題において、技術的かつ使うのが楽しくなるソリューションを構築します。私たちが選ぶ技術はショートカット（近道）を用いません。また、重要なのは、私たちのツールを使うにあたってもショートカットは用いません。そうすることで、HashiCorp 製のツールは安定し、スケーラブルで、使いやすく、運用しやすいものになります。

Consul は、私たちが開発した4番目のツールです。これまでに Vagrant、Packer、Serf を作成しました。Consul は私たちの他のツールとも動作しますが、依存関係はなく、単体で利用出来ます。

Mitchell Hashimoto と Armon Dadger は、来週開催の GopherCon に参加します。Consul を含む自社製品のステッカーを持っていきます。私たちを見つけることができれば、どのツールについても満足に話すことが出来るでしょう。

より深く学ぶために

Consul について深く学ぶためには、ウェブサイトを訪れてください。特に以下のページは、次のための良いステップになるでしょう。

Intro – 導入セクションでは、より詳細な解説を行っています。Consul とは何か、どのように動作するか、どのように始めたら良いかを、自分自身のマシンで簡単に動作する方法を学べます。
Internals – 内部に関する高度なトピックですが、興味を持っている方のために、Consul が内包する全ての技術について詳細を取り扱います。Consul を使う上では必読ではありません。Consul の背景技術について興味がありましたら、お読みください。
Comparison to other software – Consul が、その他の手法やツールとどのように違うかを知りたい場合、差異について詳細を記述したこちらのページをお読みください。
GitHub – Consul に飛び込みたいなら、GitHub 上にソースコードを展開しています。Consul がどのように動作するか理解を深めることは、実装の上で大いに役立ちます。コードの海に飛び込む前に、まずはドキュメントを読み進めること薦めます。

■ Serf vs. Consul
http://www.serfdom.io/intro/vs-consul.html

Consul は、サービス検出と設定のためのツールです。Consul は高いレベルの機能、たとえば、サービス検出、ヘルスチェック、キーバリュー・ストレージ(KVS) を提供します。また、データセンタを管理するために、グループは強い一貫性を持つサーバを用います。

Serf はサービス検出とオーケストレーションのために使用することも出来ます。実際の所、一貫した Gossip モデル上に、中央サーバ無しに構築されます。Serf は、グルーブのメンバーシップや障害検出、イベント一斉通知 ( broadcast ) やクエリ機構などを含む、多くの機能を持ちます。しかしながら、Serf は Conul の高水準機能は何も提供しません。

実際の所、Consul に内蔵されている内部の gossip プロトコルは、Serf ライブラリによって提供されています。Consul は、メンバーシップや障害検知機能に、Serf ライブラリを使用します。

Serf によるヘルスチェックは、非常に低いレベルのもので、エージェントが生きているかどうかを知るだけのものです。Consul はこれを拡張子、リッチなヘルスチェックシステムを提供します。生存確認に加えて、任意のホストに対するサービスレベルでのチェックを行います。ヘルスチェックは、中央のカタログ ( central catalog ) と統合されることで、オペレータは簡単にクラスタに対して状況の問い合わせを行う事が出来ます。

Serf が提供するメンバーシップはノードレベルであるのに対し、Consul はサービスレベルでの抽象化に特化しています（１つのノード管理から、複数のサービスモデルへ）。この機能は、Serf では tag を使う事でシミュレーションすることはできますが、限定的であり、高度なクエリインターフェースは提供されません（ DNS クエリや HTTP API ）。Consul が強い一貫性のカタログを用いることに対し、Serf はイベント一貫性のみを持ちます。

Consul はサービスレベルの抽象化と改善されたヘルスチェックに加え、キーバリューストアと複数のデータセンタをサポートします。Serf は WAN を跨がって動作することもできますが、性能が劣化してしまいます。Consul は複数の gossip プールを使用するので、複数のデータセンタをまたぐ WAN の場合でも、Serf を LAN 上で扱うのと同様の性能が保持されます。

Serf がより柔軟で汎用的に使えるのに対し、Consul は独断的な処理をおこないます。Consul は CP アーキテクチャを用いるので、可用性より一貫性を重視します。Serf は AP システムなので、一貫性を可用性のために犠牲にします。この意味するところは、Serf は殆どすべての状況下で機能するのに対し、Consul は中央サーバが Quorum (クォーラム) を作る事が出来なければ動作しません。

■ Introduction to consul / Consul 導入
http://www.consul.io/intro/index.html

Consul 導入ガイドにようこそ！　このガイドは Consul を始めるにあたって最高の場所です。ここでは、Consul とは何かや、どんな問題を解決するか、既存のソフトウェアとどう違うのか、そして、Consul をすぐに使い始める方法を扱います。もし、既に Consul の基本を知っている場合は documentation にある文章を読む事で、利用可能な全ての機能について知ることが出来ます。

Consul とは何か？

Consul は複数のコンポーネントを持ちますが、全体的にはインフラ（基盤）におけるサービス検出と設定のためのツールです。いくつかの主要な機能は、以下の通りです。

Service Discovery ( サービス検出 ) : Consul のクライアントは「api」や「mysql」等の名前を持つ service （サービス）を提供し、他のクライアントは、これらサービスを検出するために Consul を用いることができます。DNS か HTTP を使用すれば、アプリケーションは Consul が検出しているサービスを簡単に見つけることが出来ます。
Health Checking ( ヘルスチェック ) : Consul クライアントは、いくつものヘルスチェックを提供するだけでなく、提供されるサービス（ウェブサーバの HTTP コードが 200 OK = 正常を返す）や、ローカル上のノード（メモリ使用率は 90% 以下である）と連携することができます。この情報を用い、オペレータはクラスタ上のヘルス状況を監視することができますし、また、サービス検出コンポーネントを用いて、障害ホストに対するトラフィックを迂回させることも出来ます。
Key/Value Store ( キーバリュー・ストア ) : アプリケーションは Consul の階層的なキーバリュー・ストアを以下の用途に使用します。例えば、動的な構成変更だったり、フラグを建てるために使ったり、調整や、リーダー選出です。その他、キーバリュー・ストアを様々な目的に利用出来ます。シンプルな HTTP API によって、これら機能を簡単に使う事ができます。
Multi Datacenter ( 複数データセンタ ) : Consul は box によって複数のデータセンタ利用をサポートします。Consul の利用者は、アプリケーションが複数のリージョンを使うまで成長したとしても、これらは Consul が抽象化することによって、スケールについて心配する必要はありません。

Consul は DevOps コミュニティとアプリケーション開発者にとってフレンドリーになるよう設計していますので、完全にモダンな（いまどきで）柔軟なインフラ（基盤）となり得ます。

Consul の基本アーキテクチャ

Consul は分散型の高可用性システムです。詳細なアーキテクチャ概要のページがありますが、このセクションでは、Consul がどのように動くか理解することを目的とし、基本部分を取り扱います。なお、概要やアーキテクチャを素早く学ぶため、詳細は敢えて省略しています。

サービスを Consul に提供するあらゆるノードでは、Consul エージェントが実行されています。ほかのサービスを検出したり、キー／バリューデータを取得・セットするためには、エージェントを実行する必要がありません（ HTTP API や DNS インターフェースを通して状況の確認が出来るので）。Consul エージェントは対照ノード上のサービス（ Consul の利用者が、設定ファイルで定義する ‘service’ の事）に対するヘルスチェックだけでなく、ノード自身に対する責任を持ちます。

エージェントは１つまたは複数の Consul サーバと通信します。Consul サーバは、データが保管され、複製される役割を持ちます。サーバは自分たち自身でリーダー選出を行います。Consul は1台でも動作しますが、データ損失という事態を避けられるよう、3～5台での運用を推奨します。また、Consul サーバのクラスタは、データセンタ毎に置くことを推奨します。

インフラ（基盤）のコンポーネントが他のサービスやノードを検出する必要があるとき、Consul サーバや Consul エージェントに対して問い合わせることが出来ます。エージェントは自動的にクエリを forward (転送) します。

各々のデータセンタでは、Consul サーバのクラスタを走らせます。サービス検出や設定リクエストがデータセンタをまたがって発生した場合、ローカル側の Consul サーバはリモート側のデータセンタにある Consul に対してリクエストを行い、結果を受け取ります。

次のステップ

他のソフトウェアとの違いに関するページで、既存のインフラ（基盤）で利用可能かどうか知ることが出来るでしょう。あるいは、getting started guide では、簡単に動かし、どのように動作するか分かります。

■ CONSUL ARCHITECTURE / Consul のアーキテクチャ
http://www.consul.io/docs/internals/architecture.html

Consul は、多くの稼働パーツを持つ複合システムです。Consul の利用者と開発者にとって、どのように動作するかというメンタルモデルを作る事を支援するため、このページではシステムのアーキテクチャを文書化します。

※ 高度な内容！：このページで鳥敦子とは Consul の内部詳細技術です。Consul を使う場合や、効率的に運用する場合であれば、このページを読む必要はありません。これらの詳細説明は、ソースコードという洞窟の奥深くを探検したい方向けのものです。

Glossary ( 用語 )

アーキテクチャを説明する前に、私たちは議論されている内容を明確化できるよう、用語集を提供します。

Agent ( エージェント ) – エージェントは Consul クラスタの各々のメンバにおいて、長く実行し続けるデーモンです。’consul start’ と実行するとエージェントは稼働します｡エージェントは、クライアントモードかサーバモードとして動作します。全ての Consul ノードにおいてエージェントを実行しなくてはいけませんので、ノードがクライアントであるかサーバであるかを決める必要があります。ただし、エージェントには別の役割もあります。全てのエージェントは、DNS か HTTP インターフェースを動作させることができ、チェックを行う事やサービスの同期が続くようにする役割があります。
Client ( クライアント ) – クライアントは、全ての RPC をサーバに送り届けるエージェントです。クライアントは、比較的ステートレスであり、情報を保持しません。クライアントが実行する唯一のバックグラウンドでの働きは、LAN における gossip プールへの参加のみです。ここでは、最小のリソースを使い、ネットワーク帯域も少しだけ消費します。
Server ( サーバ ) – サーバモードで動作するエージェントのことです。サーバモードで動作する時は、信頼性が拡張された状態となります。Raft グループにおいて、クラスタ状況の管理や、RPC クエリに対して応答したり、他のデータセンタに対する WAN gossip や、クエリをリモート上のデータセンタにいるリーダに対して送ったりします。
Datacenter ( データセンタ ) – データセンタの定義は一見すると明確なようですが、EC2 における multiple availability zone のように表現が微妙な場合がアリマス。私たちはデータセンタの定義を、低いレイテンシと帯域幅の広いネットワーク環境であるとします。ただし、一般的なインターネット上（パブリックな環境）を横断する通信については除外します。
Consensus ( コンセンサス, 合意 ) – コンセンサスという用語を私たちの文章で扱うときは、リーダ選出やトランザクション（業務）の順位付けに関する一致に対する合意、という意味で使用します。コンセンサスは Wikipedia に解説があるほか、実装についてはこちらで述べています。
Gossip ( ゴシップ ) – Consul は Serf を基に作られており、複数の目的に使うため完全なゴシップ・プロトコルを提供します。Serf はメンバシップ、故障検出と、イベントの一斉送信メカニズム（ブロードキャスト）を提供します。どのような場合に使うかは、gossip に関連するドキュメントで述べています。通常は、ゴシップとは、主に UDP 上で、ランダムなノード間で総合通信を行う際に必要な手順となるもの、と知っておけば十分です。
Lan Gossip – ノードが全て同じ LAN かデータセンタ内に存在しており、そこにあるノード間で構成されるゴシップ・プールがある時に用います。
WAN Gossip – Consul サーバが、主に異なるデータセンタ間でゴシップ・プールを構成するときに用いられ、相互通信を行うにはインターネットをまたがるか、WAN を通らなくてはいけません。
RPC – RPC は Remote Procedure Call （リモート・プロシージャ・コール）の略語です。これは、request / response (リクエスト/応答) の仕組みであり、サーバとクライアント間での通信に用います。

10,000 フィート（高度3km）からの眺め

10,000 フィートの高度からは、Consul のアーキテクチャは下図のように見えます。

構成図

図の各々の部分をブレイクダウンして説明しましょう。まずはじめに、２つのデータセンタ、１と２がある事がわかります。Consul は複数のデータセンタに対するファーストクラスのサポートを持っており、この図が一般的な構成例であると予想しています。

各々のデータセンタでは、クライアントとサーバが含まれています。台数は3～5台と予想します。可用性と障害時におけるパフォーマンスとのバランスについては、マシンを追加することによって可用性が高まりますが、 consensus を得る時間が、次第に遅くなります。しかしながら、クライアントに対する制限はありません。クライアントは数千から数万までスケールさせることができます。

データセンタにある全てのノードは、ゴシッププロトコルに参加します。この意味する所は、ゴシッププールとは、所定のデータセンタの中にある全てのノードを含むものです。これは、いくつかの理由にかないます。第一に、サーバの IP アドレスをもとにクライアントを設定する必要が無いため、発見は自動的に行われます。第二に、ノード障害を見つける機能はサーバにあるのではなく、分散しています。この意味するところは、故障検出のために単純なハートビート的な仕組みよりも、非常にスケーラブル（拡張可能）なものとなります。第三に、リーダ選出のような重要なイベントが行われるとき、通知のためのメッセージング層として使用します。

各々のデータセンタにあるサーバは、1つの Paft peer セットの一部となります。つまり、リーダ選出の際には一緒に動作しますし、追加で義務も発生します。リーダは、全ての問い合わせ(query)とトランザクション(業務)を処理する役割を果たします。とらんざくしょんは、コンセンサス・プロトコルの一部として、全ての peer にも情報を複製しなくてはいけません。この必要条件のため、リーダではないサーバが RPC リクエストを受け取ったら、クラスタのリーダに forward (転送) を行います。

サーバノードも、WAN ゴシップの一部として動作します。WAN プールは LAN プールとは異なり、インターネットの高いレイテンシのために最適化されており、他の Consul サーバやノードがある事を予想するため（期待するため）だけに使用します。このプールの役割は、データセンタを、割と原始的な手法で、お互いを発見させるためです。新しいデータセンタをオンラインにすることは、既存の WAN ゴシップに加わるのと同様にクリアで簡単です。全てのサーバがこのプールで動作しているので、データセンタをまたいだ要求も有効です。サーバが異なるデータセンタに対するリクエストを受け取ると、正しいデータセンタにあるランダムなサーバに対してデータを送り届けます。あるいは、対象サーバがローカルであれば、ローカルのリーダに対して転送するでしょう。

データセンタ間の結合が非常に低い場合がありますが、故障検出や接続のキャッシング、多重化によって、データセンタをまたがるリクエストも比較的速くて信頼出来るものです。

—-

ここから先は、より詳しい情報が Consul のサイトに記載されています。

—-

続きを書きました。

Consul関連ドキュメント(参考訳)Part2
http://pocketstudio.jp/log3/2014/04/23/consul_docs_part2/