etcdとは

etcdはオープンソースとして配布されているキーバリュー・ストアであり、配布されたシステムが実行し続けるために必要不可欠な情報を保持、管理するために使用されます。最も顕著なのは、構成データ、状態データ、および人気のコンテナ・オーケストレーションプラットフォームであるKubernetesのメタデータの管理です。

すべての分散されたワークロードと同様に、コンテナ化されたワークロードは、ワークロードが拡張されるほど複雑性を増す複雑なマネジメント要件を持ちます。 Kubernetesは、複数箇所の複数のマシン上で実行できる作業（構成、導入、サービスディスカバリー、負荷平準化、ジョブ・スケジューリング、および全てのクラスター上の正常性モニタリング）を統制することで、ワークロード管理のプロセスを簡素化します。

しかし、この統制を達成するために、Kubernetesはシステム（そしてそれに含まれるクラスターやポッドやアプリケーション・インスタンス）の状態の真理についての、唯一かつ一貫性のあるソースを任意のタイミングで提供できるデータストアを必要とします。 etcdはこのバージョンの真理の作成と保守に使用されるデータ・ストアです。

etcdは、オープンソースでマルチクラウドのPlatform-as-a-Service（PaaS）であるCloud Foundry （ibm.com外部リンク）と同様の役割を果たし、重要なシステムやメタデータを分散アプリケーションのクラスター間で統制するための有力な選択肢です。「etcd」という名前は、Linuxディレクトリー構造内の命名規則に由来します：UNIXでは、シングルシステム用のすべてのシステム構成ファイルは/etcというフォルダに含まれ、「d」は「分散（distributed）」の略です。

さらなる詳細については、「etcdとは？」という動画をご参照ください（英語、6:09）：

etcdを選ぶべき理由

データのバックボーンとして分散されたワークロードの実行を支えることは容易な作業ではありません。しかし、etcdはこのタスクを実現するため、次のように設計されています：

完全複製：etcdクラスターのすべてのノードは、フルデータ・ストアへのアクセス権限を持ちます。
高い可用性：etcdは単一障害点を持たないように設計されており、ハードウェア障害およびネットワーク・パーティションを適切に許容します。
信頼できる一貫性：すべてのデータ「読み取り」は、すべてのクラスターにわたる最新のデータ「書き込み」を返します。
高速：etcdは、1秒あたり1万回の書き込みでベンチマークされています。
安全：etcdは、自動的Transport Layer Security（TLS）とオプションSecure Sockets Layer（SSL）クライアント証明書認証をサポートしています。 etcdは非常に重要で機密性の高い構成データを保管するため、管理者は役割ベース権限コントロールを導入時に実装し、仕事を行うためにetcdに関わるチームメンバーの数が最低限となるように、権限のアクセス・レベルを制限すべきです。
シンプル：単純なウェブアプリから、Kubernetesなどの高度に複雑なコンテナ・オーケストレーション・エンジンに至るまで、どんなアプリケーションも標準的なHTTP/JSON ツールを用いてetcdにデータを読み書きできます。

なお、etcdのパフォーマンスはストレージ・ディスク・スピードに大きく依存するため、etcd環境ではSSDの使用を強くお勧めします。これとその他のetcdストレージ要件についてより深く知るには、「Fioを使用して、ストレージがetcdに十分な速度であるかどうかを確認する」をご参照ください。

Raftコンセンサス・アルゴリズム

etcdはクラスター内のすべてのノードでデータ・ストアの一貫性を保つために、Raftコンセンサス算法の上に構築されています。これはフォールト・トレラント分散システムにとって最低限必要な条件です。

Raftは、選出されたリーダーノードを介してフォロワーと呼ばれるクラスター内の他のノードの複製を管理し、一貫性を実現します。リーダーはクライアントからの要求を受け入れ、その後フォロワー・ノードに転送します。フォロワー・ノードの大多数が新しい要求をログ・エントリーとして保存他のをリーダー・ノードが確認すると、ローカル・ステート・マシンにエントリーを適用して実行の結果（書き込み）をクライアントに返します。もしフォロワーがクラッシュしたりネットワークのパケットが破損した場合、リーダーは全てのフォロワーがログ・エントリーを一貫して保存するまで再試行します。

フォロワー・ノードが一定時間リーダーからのメッセージの受け取りに失敗した場合、新しいリーダーを選出する選挙が行われます。フォロワーが自身を候補者と宣言し、他のフォロワーは可用性に応じて各候補ノードに投票します。新しいリーダーに選出されると、そのノードは複製の管理を始め、そのプロセスが繰り返されます。このプロセスはすべてのetcdノードに、可用性が高く一貫して複製されるデータ・ストア処理の保持を可能にします。

etcdとKubernetes

etcdはKubernetesのコア・コンポーネントに含まれており、機能するフォールト・トレラントKubernetesクラスターを作成するための優先的なキーバリュー・ストアとしての役割を果たします。 Kubernetes APIサーバーは各クラスターの状態データをetcd内に保存します。 Kubernetesはetcdの「監視」機能を用いてこのデータをモニターし、変更が発生したときは自身を再構成します。「監視」機能はクラスターの実際と理想的な状態を表す値を保存し、それらが分岐した時に応答を開始できます。

Kubernetesがどのようにして、クラスター、サービス、そしてワーカーノードを管理するかの詳しい概説については、私たちの動画「Kubernetesの仕組み」を参照してください：

CoreOS、そしてetcdの歴史と管理

etcdは、大規模なスケールでの実行と管理が可能で広く普及しているコンテナオペレーティング・システム、CoreOS Container Linuxのデザインを行ったチームによって作られました。彼らはもともと、アプリケーションが中断されない稼働時間を確保するため、Container Linuxの複製をいくつも統制しようとして、Raft上にetcdを作りました。

2018年12月、チームはクラウドネイティブコンピュータ財団（CNCF）にetcdを寄贈しました。この組織は中立の非営利組織であり、etcdのソースコード、ドメイン、ホスティングサービス、クラウド・インフラストラクチャー、および他のプロジェクト権利を、コンテナ・ベースのクラウド開発コミュニティーに向けたオープンソース・リソースとして維持しています。 CoreOSは、RedHatと統合されました。

etcdとZooKeeperとConsul

その他のデータベースは、分散アプリケーション・クラスター間の座標系情報を管理するために開発されました。 etcdと最もよく比較されるのは、ZooKeeperとConsulの2つです。

ZooKeeper

ZooKeeperはもともと、Apache Hadoopクラスター間の構成データとメタデータを統制するために作られました。（Apache Hadoop （ibm.com外部のリンク）はオープンソース・フレームワーク、またはアプリケーションの集まりであり、コモディティー・ハードウェアのクラスター上の大容量データの保管と処理に使用されています。） ZooKeeperはetcdよりも古く、ZooKeeperから学んだ教訓はetcdの設計に影響を与えました。

その結果、etcdにはZooKeeperにはない重要な機能がいくつかあります。例えばetcdでは、ZooKeeperとは異なり、次のことができます：

クラスター・メンバーシップの動的再構成の許可。
高負荷下で読み取り/書き込みを行っても安定性を失わない。
マルチバージョンの並行性制御データ・モデルの維持。
通知なくイベントをドロップしない、信頼性の高いキー・モニタリングの提供。
セッションから接続分離する並行性プリミティブの使用。
幅広い言語やフレームワークのサポート（ZooKeeperは限定的な言語バインディングをサポートする自身のカスタムJute RPCプロトコルを持ちます）。

Consul

Consulは分散システムのためのネットワーキングソリューション・サービスであり、etcdとKubernetesのIstioサービス・メッシュの中間に位置する機能を持ちます。 etcdのように、Consul（ibm.com外部へのリンク）にはRaftアルゴリズムに基づく分散キーバリュー・ストアが含まれ、HTTP/JSONアプリケーション・プログラミング・インタフェース（APIs）をサポートします。どちらも動的クラスター・メンバーシップ構成を提供していますが、Consulは並行したバージョンの複数の構成データに対してそこまで強くはコントロールせず、作業する最大データベースサイズはより小さくなります。

etcdとRedis

etcdと同じく、Redisはオープンソース・ツールですが、その基本機能は異なっています。

Redisはメモリー内のデータ・ストアであり、データベース、キャッシュ、またはメッセージ・ブローカーとして機能します。 Redisは、etcdよりも多くのデータ・タイプやデータ構造をサポートしており、はるかに速く読み取り/書き込みを行います。

しかし、etcdはより高い耐障害性、強いフェイルオーバー、継続的なデータ可用性機能を持ちます。そして最も重要なのは、etcdが速さを犠牲にしてまで信頼性と一貫性の保証のためにすべての保管データをディスクで持続させているということです。これらの理由から、Redisはデータ保管や分散システム構成情報よりも、分散メモリー・キャッシュ・システムに適していると言えます。