【参考訳】Consul 0.6 | Pocketstudio.jp log3

Consul のメジャー・アップデートがありました。Blog 記事があがっていましたので、例によって参考程度にどうぞ。

Consul 0.6 – HashiCorp
https://hashicorp.com/blog/consul-0-6.html

—-ここから

■ Consul 0.6

私たちは Consul 0.6 のリリースにワクワクしています。今回は多くの新機能や改良が追加されたメジャー・アップデートです。Consul とは最新のデータセンタ・ランタイムです（訳者注：HashiCorpでは、いわゆるネットワーク・システムのことをデータセンタとして表現しています。日本語の物理的なデータセンタとは概念が少し異なります）。Consul は扱いやすい Go 言語のバイナリであり、サービス・ディスカバリ、設定、オーケストレーションの各機能があります。分散と高い可用性、そして、複数のデータセンタにまたがるサービスを、一万ノードに至るまでスケールできます。

今回のリリースは、準備のために数ヶ月かかりました。これは、コアに対する改良を行ったからです。全体を新しいインメモリ・データベースへの移行と、新しいネットワーク・トモグラフィー・サブシステム（network tomography subsystem；ネットワーク断層サブシステム）という複数の内部階層化（internal layers）です。大規模な変更にもかかわらず、Consul 0.5.2 から通常のアップグレードのように、単に新しいバイナリでエージェントの再起動をするだけでアップグレードできるよう、私たちは注力してきました。

Consul 0.6 では非常に多くの機能の追加、バグ修正、改良を行いました。また、Consul は 100% Go 言語で書かれているので、構築やデプロイがより簡単になります。以下は、機能の主な見所です。

ネットワーク・トモグラフィ（Network Tomography）
新しいインメモリ・データベース（In-Memory Database）
事前クエリ（Prepared Queries）
ACL の拡張
TCP と Docker コンテナのヘルスチェック
ローレベルなネットワーク堅牢性の改良（Low-Level Network Robustness）

Consul 0.6 はこちらからダウンロードできます。あるいは changelog （変更点の一覧）をご覧ください。

0.6 の主な新機能について学ぶには、このまま読み進めてください。

■ ネットワーク・トモグラフィ（Network Tomography）

Consul の基礎となるのは、Serf が提供するゴシップ・プロトコルです。これにより、クラスタ内の全てのノードが、他のノードに対して定期的にランダムに調査（probes）する機能を持つので、ノードの障害を検知できます。この利点は、調査を効率的に行えます。理由は、ノードは各々の調査間隔により、ネットワークのラウンドトリップタイム（round trip time；往復遅延時間）を計測できるためです。Consul 0.6 はこれらの測定を、ネットワーク・トモグラフィ・サブシステムを通して得られる利点があります。この基礎となっているのは、ビバルディ（Vivaldi）という学術研究のアルゴリズムによります。

ビバルディ・アルゴリズムは、システム上のノードがバネ（springs）によってつながれたものとし、それを物理シミュレーションするのと類似した方法で動作します。開始時点では、各ノードは起源（origin）の１ヶ所に集まっています。しかし、時間が経てば相互の距離（の情報）を得られます。そして、ばねに保存されるエネルギーが最小になるよう、位置を調整します。このシミュレーションによって得られる結果が「ネットワーク座標（network coordinates）」のセットです。これを使えば、クラスタ上の２つのノード間の RTT 推定を、とても簡単な計算で行えるようにします。

次のアニメーションは、ビバルディ・アルゴリズムによって作成したものです。シミュレーション上の人工的なノードによって形成されるクラスタは、RTT のグリッド・パターン（格子状）に収束します。

Consul 0.6 では、ネットワーク座標に関する新しいコマンドと API エンドポイントを追加しました。既存のエンドポイントの中に、強力な手法で織り込んでいます。以下は新しい「consul rtt」コマンドであり、オペレータは RTT の推定をインタラクティブに問い合わせできるようになります。

# 現在のノードから他に対する RTT の推定
$ consul rtt nyc3-server-1
Estimated nyc3-server-1 <-> nyc3-server-2 rtt: 1.091 ms (using LAN coordinates)

# ２つのノード間の RRT を、第三のノードから推定
$ consul rtt nyc3-server-1 nyc3-server-3
Estimated nyc3-server-1 <-> nyc3-server-3 rtt: 1.210 ms (using LAN coordinates)

# 現在のサーバに対する RTT を、別のデータセンタから推定
$ consul rtt -wan sfo1-server-1.sfo1
Estimated sfo1-server-1.sfo1 <-> nyc3-server-2.nyc3 rtt: 79.291 ms (using WAN coordinates)

先の最後のコマンドについて補足すると、ネットワーク座標は WAN プールのサーバでも利用可能です。これは、ローカルのデータセンタに利用可能なサービスがなければ、最も近いデータセンタにアプリケーションをフェイルオーバするような場合に便利です。

Consul 0.6 に「?near=」クエリ・パラメータを追加しました。既存の多くの API よりも、ネットワーク・トモグラフィが有利な点です。以下は、いくつかの例です。

# 正常な「redis」サービスを提供しているノードの一覧を表示する
# そのとき、ノードを RTT でソートする
$ curl localhost:8500/v1/health/service/redis?passing&near=nyc3-server-2

# 全ノード一覧を RTT でソートして表示
$ curl localhost:8500/v1/catalog/nodes?near=nyc3-server-2

最後に、Consul 0.6 は外部のアプリケーションが利用可能な、 raw（訳者注：そのままのデータの意味）ネットワーク座標に対応した HTTP API を実装しました。これにより、新しく置き換えたり、フェイルオーバや、RTT に基づくアルゴリズムを用いて他の強力な処理を行えます。次の例は、ネットワーク座標を表示しています。

$ curl localhost:8500/v1/coordinate/nodes?pretty
[
  {
    "Node": "nyc3-server-1",
    "Coord": {
        "Vec": [
            0.01566849390443588,
            -0.041767933427767884,
            -0.039999165076651244,
            -0.03846615252705054,
            -0.028208175963693814,
            0.021521109674738765,
            -0.03259531251031965,
            0.0392771535734132
        ],
        "Error": 0.2093820069437395,
        "Adjustment": 0.00038434248982906666,
        "Height": 1.8735554114160737e-05
  }
},
...

以上のほかにも、ネットワーク座標に対応した多くのコンポーネントがあり、RTT 推定の計算が非常に簡単です。どのように計算が行われているかや、RTT 推定計算の向上のため Consul が内部でどのような処理をしているかを知るには、Consul と Serf のネットワーク座標に関するページをご覧ください。

■ 新しいインメモリ・データベース（In-Memory Database）

これまでのバージョンの Consul は、インメモリ・データベースに LMDB を使っていました。ここには Consul サーバが扱うデータの全て、たとえばカタログ、キーバリュー・ストア、セッションが保管されていました。LMDB は性能が良く、とても安定しています。ですが、基数ツリー（radix trees）を基盤としたインメモリ・データベースに移行します。これは Consul がまさに必要とするコンポーネントを仕立てるためであり、Consul 0.6 における複数の重要な利点をもたらします。

クエリの読み込み時に順番に並べられていない（deserialize）データを読み込む必要がないよう、データが直接基数ツリーを参照できるようにしたデータベース設計です。この劇的な改良により、Consul サーバの読み込み性能を向上し、ガベージ・コレクションの苦痛を減らします。直接参照（direct references）は、Go 1.5.1 で導入されたガベージ・コレクション性能の改善によるもので、Consul サーバは、一般的に大きく余裕の無いクラスタにおける、高い読み込み負荷時にも安定します。

他の利点としては、Consul の LMDB は最新の「cgo」に依存していました。これを 100% 純正の Go 言語コードに移行することで、構築のプロセスを簡単にし、Consul を新しいプラットフォーム向けに構築するのも簡単にします。

最後に、新しいデータベースは Consul の将来バージョンにおいて、ブロッキング・クエリの粒度高めるための基礎となります。これはデータベース自身のサポートを追加し、基数ツリー構造を取り込むことになりました。

インメモリ・ストアはステート・スナップショット（state snapshot）と起動時の Raft ログから構築されます。そのため、新しいインメモリ・データベースのアップグレードのために、特別な手順を必要としません。しかしながら、Consul バージョン 0.5.1 以下では、LMDB 依存性を削除する必要があるため、Raft ログの移行を自動で行えません。詳細は更新手順に関するドキュメント（英語）をご覧ください。

■ 事前クエリ（Prepared Queries）

Consul の DNS インターフェースとは、既存のアプリケーションとの統合が簡単なので、Consul の良く知られている機能です。一般的な要望は、DNS 機能を経由して、複数のタグを用いた検索ができるようにしたい、というものです。また、私たちは新しいネットワーク・トモグラフィ・システムを DNS を経由しても使えるようにしたいと思っています。残念ながら、DNS クエリの構文では、複雑な新機能を追加することに限界があります。

Consul 0.6 では事前クエリ（prepared queries）機能を導入しました。これは新しい HTTP API エンドポイントを使い、複雑なクエリを定義できるようにします。そして、これは DNS からも参照可能になります。以下は事前クエリ（prepared queries）を使い、いくつかの機能を表示するクエリ定義の例です。

$ curl -X POST -d \
'{
  "Name": "redis-with-failover",
  "Service": {
    "Service": "redis",
    "Failover": {
      "NearestN": 3
    },
    "Tags": ["master", "!experimental"]
  },
  "DNS": {
    "TTL": "10s"
  }
}' localhost:8500/v1/query

{"ID":"5e1e24e5-1329-f86f-18c6-3d3734edb2cd"}

この事前クエリを Consul に登録すると、「redis-with-failover.query.consul」の DNS 名前解決を、次の手順で行います。

1. ローカル・データセンタ内の正常な「redis」サービスのインスタンスを検索
2. インスタンス一覧から「master」のタグを持っているものをフィルタする、ただし、「experimental」のタグを持つものは除外
3. ローカルのデータセンタに利用可能なインスタンスが無ければ、ネットワーク・トモグラフィの RTT データに基づき、最も近い３つのリモート・データセンタを検索
4. TTL 10 秒で DNS の結果を返す

上記の例では、シンプルな「redis-with-failover.query.consul」事前クエリによって、様々な手法による多くの機能を提供します。実用的ではなかった DNS クエリをエンコード（符号化）することになるでしょう。事前クエリの他の設定項目としては、サービス・ディスカバリの ACL サポート、セッション統合、フェイルオーバー時のユーザ定義データセンタ・リストがあります。設定済みの事前クエリは、Consul エージェントの設定変更が不要で、オン・ザ・フライ（訳者注；無停止または即時の意味）に更新できます。

事前クエリは将来の拡張を見越した設計です。Consul 自身の改良で新しい機能が追加されたとしても、DNS をサポートし続けるようにします。クエリ結果は新しい HTTP エンドポイントを使って利用できるため、その他のアプリケーションとも統合できます。

より詳細については事前クエリの HTTP エンドポイント・ドキュメントをご覧ください。

■ ACL の拡張

Consul の利用者は、多くの場合異なったチームで同じ基盤を共有しています。そのため多く寄せられた要望が、混在した環境における高度な ACL のサポートでした。このような場合に使えるよう、Consul 0.6 では複数の拡張 ACL をサポートしました。

サービス ACL は、サービス・ディスカバリを扱う拡張ですが、サービス登録用ではありません。read ACL を有効にすると、HTTP クライアントはサービス情報を読み込むために適切なトークンを必要とします。適切なトークンで事前クエリを登録しておけば、セキュアな事前クエリ ID を使い、クライアント、サービス・ディスカバリ、read ACL を DNS インターフェースを通しても利用可能になります。

新しい ACL により、ユーザのアクセス制御無効化イベントと、キーリング操作機能をもたらしました。

新しい ACL で「anonymous」トークンが利用可能になりました。そのため、 Consul 0.6 に更新時には新しいポリシーの検討が重要になります。これは以前の同様な設定「acl_default_policy」が「deny」（拒否）になるからです。Consul 0.6 の ACL ポリシーは、これまでの Consul のバージョンのものと似たような書き方です。

service "" {
  policy = "read"
}

event "" {
  policy = "write"
}

keyring = "write"

より詳細は ACL ドキュメンテーションや更新手順のドキュメンテーションをご覧ください。

■ TCP と Docker コンテナのヘルスチェック

Consul 0.6 は新しい２種類のヘルスチェック・タイプを導入しました。TCP チェックは定期的に単純な接続を確認します。以下は定義例です。

{
  "check": {
    "id": "ssh",
    "name": "SSH TCP on port 22",
    "tcp": "localhost:22",
    "interval": "10s",
    "timeout": "1s"
  }
}

Docker チェックはコンテナの中で定期的にスクリプトを実行します。オプションのシェルを指定できますが、指定が無ければデフォルトで「/bin/sh」を使います。以下は定義例です。

{
 "check": {
 "id": "mem-util",
 "name": "Memory utilization",
 "docker_container_id": "f972c95ebf0e",
 "shell": "/bin/bash",
 "script": "/usr/local/bin/check_mem.py",
 "interval": "10s"
 }
}

より詳細についてはヘルスチェック・ドキュメンテーションをご覧ください。

■ ローレベルなネットワーク堅牢性の改良

Consul 0.6 では、Consul が設定ミスやネットワーク不調時も安定性をませるよう、多くのローレベルな変更を行いました。

TCP フォールバック調査（fallback probe）は、Serf のノード障害検出により、オペレータが一般的な設定ミスの原因を突き止める手助けとなります。これは、UDP が許可されていなくても TCP トラフィックが利用可能であれば使えます。ログメッセージがオペレータに対して問題をアラートしても、ノードがまだ生きている状態であれば、ゆるい（flappy）障害検知と予測します。これにより、ノード間でより信頼できる代替経路を検討しますので、短時間で多くのパケットロスが発生しても乗り切れます。

Consul マルチプレクサ（多重送信）の流れとコネクション・プールの論理によって、ネットワーク復帰時のオーバヘッドを減らします。それだけでなく、接続がない状態ではメモリ使用を減らします。内部の RPC メカニズムにより、更新時の Consul サーバのオーバヘッドも減らします。これらの変更は、高負荷時やネットワークが不安定でも、Consul をより安定させるものです。

■ アップグレードの詳細

Consul 0.6 はサーバもクライアントも「バージョンアップ」を自動的に行えるように設計しています。これはネットワーク・トモグラフィの利点と、 TCP フォールバックのような新しいプロトコルの機能によるものです。作業のほとんどは、エージェントを新しいバイナリで再起動するだけです。

事前クエリは新しい内部コマンドです。使うためには全てのサーバをバージョン 0.6.0 に更新する必要があります。

Consul バージョン 0.5.1 以下から更新する場合は、Raft ログデータを手動で移行する手順が必要です。詳細については更新手順のドキュメントをご覧ください。

先ほど述べたとおり、あらゆるユーザの「acl_default_policy」は「deny」になります。アップグレード前に、サービスに対する影響を検討し、適切なポリシーに書き換える必要があります。そうしないと、サービス・ディスカバリは ACL によって拒否されてしまいます。新しいイベントや ACL の keyring タイプをｈが追加されましたが、これらが使えるのはアップグレード後です。そのため、これらの機能を使うつもりであれば、事前に検討が必要になるでしょう。

より詳細については、更新手順をご確認ください。