背景：Apache ZooKeeper
Apache ZooKeeperが特別な紹介を必要とすることはまずありませんが、それでもJavaベースのKey-Value（KV）リポジトリです。 階層的な名前空間が異なり、分散アプリケーションのアプリケーションに焦点を合わせています。分散アプリケーションでは、構成やその他のサービス情報を保存するための集中サービスとして機能します。
ZooKeeperの作成者によると、このプロジェクトは、分散システムの開発者が独自のリポジトリを作成しようとする繰り返しの試みに対する応答として（当初はHadoop内で）登場し、常に新しい課題とサポートの困難をもたらしました。 そして、私はその存在の10年にわたって、ZooKeeperが市場で足場を獲得し、Apache Drill、Apache Hadoop YARN、Apache HBase、Apache Kafka、Apache Solr、Mesos、Norbertなどのオープンソースプロジェクトの重要なコンポーネントになったことを認めなければなりません （ところで、最終的にZooKeeperを放棄した人の例があります：JujuおよびNeo4j 。）もちろん、分散KVストレージを必要とするクローズドシステムおよびアプリケーションの開発者もZooKeeperを選択しました。 最後に、このソリューションはマイクロサービスの世界で人気があり、 サービスを検出するためのサービスとしても使用されますが 、これには問題がないわけではありません 。
そしてここにetcd？
もちろん、Apache ZooKeeperがニッチの唯一のソリューションではありません。 たとえば、KVストレージを提供し、前述のService Discoveryに特に重点を置いているConsul 、および高可用性（スケーラビリティとパフォーマンスを損なう）に焦点を当てたDoozerもあります。この記事の主な「性格」はetcdです。 （これらのソリューションの違いに関心のある方は、HashiCorpの記事「 ConsulとZooKeeper、doozerd、etcd 」 、CoreOSの 「 etcd、Zookeeper、Consul Consistent Key-value Datastoresのパフォーマンスの調査 」の記事が役立ちます。）
etcdリポジトリは、分散システムの重要なデータ用にCoreOSで作成され、Go言語で書かれており、a）シンプルさ（gRPCを介してアクセスできるシンプルなAPI）、b）セキュリティ（自動TLS）、c）パフォーマンス（著者は10,000の操作を約束します） 1秒あたりの記録）、d）信頼性（ Raftコンセンサスアルゴリズムのおかげ）。 これらすべては、CoreOSの関心と熱意に慣れており、新しいソリューションにある程度の重みを与えることができました。etcdがKubernetes REST APIオブジェクトの永続的なリポジトリになったことに言及してください。
CoreOSのさらなる進歩は驚くことではありません。世界中の多くの人々がZooKeeperを使用しており、競合製品を宣伝することに関心がある場合は、できるだけシンプルに移行してください。そして、データモデルとクライアントプロトコルなどはZooKeeperはこの互換性のために変更されることはありません。解決策は明らかです。ZooKeeperにアクセスしているすべてのアプリケーション要求をetcdクラスターにリダイレクトするレイヤーをリリースします。 幸いなことに、「etcd v3のかなり表現力豊かなAPIにより、通常のプロキシを使用してクライアント側でZooKeeperデータモデルをエミュレートできました。」 開発者にとって便利な点は、アプリケーションをまったく変更する必要がないことです。ZooKeeperインストールをetcdに置き換え、その前に新しいプロキシサーバー（同じzetcd）を追加するだけです。
Zetcdの基本
プロジェクトの発表と小さな実用的な実験は、そのデバイスを理解するのに役立ちます。 そのため、ZetcKeeperに送信されたアプリケーションリクエストを受信し、それらをetcdデータモデルに対応する操作に変換し、このリポジトリで実行するために、zetcd（etc自体のようにGoで記述）が作成されました。
zetcdを実行するには、Goコンパイラーのみが必要です。 etcdとzetcdをインストールします。
$ go get github.com/coreos/etcd/cmd/etcd $ go get github.com/coreos/zetcd/cmd/zetcd
注 ：Ubuntuのさまざまなバージョンへのインストールの経験から、Go1.8をインストールすることをお勧めします（CoreOS Gitリポジトリからすべてのアプリケーションの最新バージョンをインストールすること）。これは、16.04ではppa：longsleep / golang-backportsから取得できます。
etcd（デフォルトはlocalhost：2379）およびzetcdの実行：
$ etcd & $ zetcd -zkaddr localhost:2181 -endpoints localhost:2379 &
zkctl（ZooKeeperでの簡単な操作のためのCLIユーティリティ）とトライアルコマンドのインストール：
$ go install github.com/coreos/zetcd/cmd/zkctl $ zkctl watch / & $ zkctl create /abc "test" $ zkctl get /abc 2017/05/23 21:57:44 Connected to 127.0.0.1:2181 2017/05/23 21:57:44 Authenticated: id=7587822333160445481, timeout=1000 [116 101 115 116] Stat: &{Czxid:3 Mzxid:14 Ctime:1495550621626193 Mtime:1495551461984432 Version:1 Cversion:1 Aversion:0 EphemeralOwner:0 DataLength:4 NumChildren:1 Pzxid:7}
明らかに、ZooKeeper（
abc
）ツリーのルートに新しいノードが作成され、それに文字列
test
関連付けられました（
116 101 115 116
何が起こったかを確認するユニコード文字番号）。 しかし、これはZooKeeperの用語ですが、etcdで何が起こったのでしょうか？
Zetcd内部デバイス
この質問に答えるには、zetcdが階層的なZooKeeperデータモデルをetcdが理解できる形式に変換する方法をよりよく理解する必要があります。 ZooKeeperのツリー構造は、メタデータを持つKVペアが各レコードに対して作成されるようにフラットなKV空間に適合します。キーのフルパスは、パラメーター名とネストレベルも含まれます：
/zk/[param]/[depth]/[full path]
。 したがって、ZooKeeper（
getChildren
）でディレクトリ別にキーを表示することは、etcd（
Range
）で間隔別にキーのリストを表示することに対応し、完全なZNodeビューを形成する追加情報がetcd内に格納されます。
つまり、ZooKeeperのキーごとに、そのリビジョン、バージョン、およびアクセス権に関するメタデータが保存されます。 etcdの詳細（ツリー内のディレクトリ自体の欠如、ACLの代わりのロールベース認証など）により、元のZNodeと比較して単純化されていますが、ノードを完全に記述しています。 例：
-
/zk/key/001/abc
/abc
キーの値を保存します（ZooKeeperツリーのネストの最初のレベル）。 -
/zk/mtime/002/abc/xyz
キー変更時間/abc/xyz
（ネストの第2レベル）。
コンソールクライアントetcdctlを使用して、実行中のデータの物理的な構成を確認できます。
$ go get github.com/coreos/etcd/etcdctl $ export ETCDCTL_API=3 $ etcdctl get --prefix /zk /zk/acl/001/abc - ACL PermsScheme ID >worldanyone /zk/count/001/abc /zk/ctime/001/abc ބ /zk/cver/001/ /zk/cver/001/abc /zk/err-node 1 /zk/key/001/abc test /zk/mtime/001/abc ބ /zk/ver/001/abc
注 ：ZNodeデータがetcdにどのように保存されているかを自分で確認するために最後の操作を繰り返したい場合は、-tags path_debugで
-tags path_debug
を収集する必要があります（つまり
go get -u -v -tags path_debug github.com/coreos/zetcd/cmd/zetcd
）、また、 問題＃52で私の好奇心の結果として作成された最新のプルリクエスト＃54を組み込んだGitリポジトリのバージョンが必要になります。
Zetcdのパフォーマンス
パフォーマンスが最初の必要性ではなく、zetcdの成功の重要な要素であることを考慮して、開発者はシンプルなベンチマークユーティリティzkboomの作成を担当しました。 それにより、CoreOSは、ZooKeeper 3.4.10とetcdのdevブランチのパフォーマンスを128バイトのKVペアの書き込みと読み取りで比較し、リクエストの数を1秒あたり2500に制限し、同時クライアントの数を増やしました。 これはすべて、「ギガビットスイッチで接続された2つの最新のLinuxマシンで行われました。 1つはプロキシとサーバーソフトウェアが起動され、もう1つはクライアントリクエストを生成しました。」
ご覧のとおり、キーを作成すると、zetcdの遅延はZooKeeperの2〜3倍、読み取りでは1,5倍になります。 これは壮大な結果とは言えません（むしろ、ZNodeメタデータをエミュレートするために多くの追加キーを操作する必要があるため、非常に理解しやすい）。しかし、宛先プロキシサーバーの詳細を考えると、本当に悪いとは言えません。
ちなみに、ZooKeeper自体のパフォーマンスをテストするように設計された他のユーティリティは、バンドルetcdおよびzetcdで既に動作するはずです。これにより、独立した実験および結論のための大きな分野が開かれます。
おわりに
zetcdの最初の公開リリース-v0.0.1-は先週行われました。 著者によると、zetcdのパフォーマンスにはまだ改善の余地がありますが、この製品はすぐにさまざまなアプリケーションでZooKeeperの既製の代替品になり、有名なプロジェクトに加えて、社内開発、何らかの理由で、ZooKeeperを終了し、少し血を流します。 最後に、このような置換の興味深い機能は、Kubernetesのetcd Operatorを使用するコンテキストで表示されます。この機能は、このZooKeeper互換リポジトリに自動更新、バックアップ、およびその他の機能を追加します。