etcdとは？

すべての分散ワークロードと同様に、コンテナ化されたワークロードには複雑な管理要件があり、ワークロードの規模が大きくなるにつれてさらに複雑になります。Kuberneteは、複数の場所の複数のマシンで実行できるすべてのクラスターにわたって構成、展開、サービス検出、負荷分散、ジョブのスケジュール設定、ヘルス・モニタリングなどのタスクを調整することで、これらのワークロードを管理するプロセスを簡素化します。

しかし、この調整を実現するには、任意の時点でのシステムの状態（すべてのクラスターとポッド、およびそれらの中のアプリケーション・インスタンス）に関する単一の一貫した真実のソースを提供するデータ・ストアがKuberneteには必要です。etcdは、この真実のバージョンを作成および維持するために使用されるデータ・ストアです。

etcdは、オープンソースのマルチクラウド Cloud Foundry（オープンソースのマルチクラウド Platform-as-a-Service（PaaS））で同様の役割を果たし、分散型アプリケーションのクラスター間で重要なシステムとメタデータを調整するための実行可能なオプションです。「etcd」という名前は、Linuxディレクトリー構造内の命名規則に由来しています。UNIXでは、単一システムのすべてのシステム構成ファイルは「/etc」というフォルダーに含まれており、「d」は「distributed」の頭文字となっています。

分散ワークロードを実行し続けるためのデータ・バックボーンとして機能するのは、決して簡単なことではありません。しかし、etcdはこのタスク用に構築されており、以下の品質を念頭にゼロから設計されています。

• 完全に複製：etcdクラスター内のすべてのノードは完全なデータ・ストアにアクセスできます。
  
  
• 高可用性：etcdは単一障害点がなく、ハードウェア障害やネットワーク・パーティションに問題なく耐えられるように設計されています。
  
  
• 信頼性の高い一貫性：すべてのデータの「読み取り」は、すべてのクラスターにわたって最新のデータの「書き込み」を返します。
  
  
• 高速：etcdは1秒あたり10,000 回の書き込みでベンチマークされています。
  
  
• 安全性：etcdは、自動トランスポート層セキュリティー（TLS）とオプションのセキュア・ソケット層（SSL）クライアント証明書認証をサポートします。etcdは重要かつ機密性の高い構成データを保存するため、管理者はデプロイメント内でロール・ベースのアクセス制御を導入し、etcdを操作するチーム・メンバーがジョブの実行に必要な最小限の権限レベルのアクセスに制限されるようにする必要があります。
  
  
• シンプルさ：シンプルなWebアプリからKuberneteなどの非常に複雑なコンテナ・オーケストレーション・エンジンまで、あらゆるアプリケーションで標準のHTTP／JSONツールを使用してetcdにデータを読み書きできます。

etcdのパフォーマンスはストレージ・ディスクの速度に大きく依存するため、etcd環境ではSSDを使用することを強くお勧めします。

etcdは、クラスター内のすべてのノード間でデータ・ストアの一貫性を確保するためのRafコンセンサス・アルゴリズムに基づいて構築されています。これは、フォールト・トレラントな分散システムの基本的な要件です。

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

フォロワー・ノードが指定された期間内にリーダーからのメッセージを受信できない場合、新しいリーダーを選択するための選挙が行われます。フォロワーは自分自身を 候補者 であると宣言し、他のフォロワーは可用性に基づいてそのノードまたは他のノードに投票します。新しいリーダーが選出されると、レプリケーションの管理が開始され、プロセスが繰り返されます。このプロセスにより、すべてのetcdノードは、データ・ストアの可用性が高く、一貫して複製されたコピーを維持できるようになります。

etcdはKuberneteのコア・コンポーネントに含まれており、機能的でフォールト・トレラントなKuberneteクラスターを作成するための主要なキー値ストアとして機能します。Kubernete API サーバーは、各クラスターの状態データをetcdに保存します。Kuberneteはetcdの「watch」機能を使用してこのデータを監視し、変更が発生したときに自身を再構成します。「監視」機能は、クラスターの実際の状態と理想的な状態を表す値を保存し、それらが異なる場合に応答を開始できます。

Kuberneteがクラスター、サービス、ワーカー・ノードを管理する方法の概要については、ビデオ「Kuberneteの説明」をご覧ください。

etcdは、大規模に効率的に実行および管理できる、広く使用されているコンテナ用オペレーティング・システムであるCoreOS Container Linuxの設計を担当した同じチームによって作成されました。当初チームは、アプリケーションの稼働が中断されないように、Container Linuxの複数のコピーを同時に調整するために、Raf上にetcdを構築しました。

2018年12月には、etcdをCloud Native Computing Foundation（CNCF）に寄贈しました。CNCFは、etcdのソース・コード、ドメイン、ホスト・サービス、クラウド・インフラストラクチャー、およびその他のプロジェクト・プロパティーをコンテナー・ベースのクラウド開発コミュニティーのオープンソース・リソースとして管理する中立的な非営利団体です。CoreOSはRed Hatと合併しました。

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

ZooKeeperはもともと、Apache Hadoopクラスター全体の構成データとメタデータを調整するために作成されました。（Apache Hadoop は、市販のハードウェアのクラスター上で大量のデータを保存および処理するためのオープンソース・フレームワーク、またはアプリケーションのコレクションです。ZooKeeperはetcdよりも歴史が古く、ZooKeeperでの作業から得られた教訓がetcdの設計に影響を与えています。

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

• クラスター・メンバーシップの動的な再構成を可能にする。
  
  
• 高負荷状態でも読み取り／書き込み操作を実行しながら安定性を維持できる。
  
  
• マルチバージョンの同時実行制御データ・モデルを維持する。
  
  
• 通知せずにイベントをドロップしない、信頼性の高いキー監視を提供する。
  
  
• 接続をセッションから切り離す同時実行プリミティブを使用する。
  
  
• 幅広い言語とフレームワークをサポートします（ZooKeeperには、限定された言語バインディングをサポートする独自のカスタムJute RPCプロトコルがあります）。

Consul は、分散システム向けのサービス ネットワーキング・ソリューションであり、その機能はetcdとKuberneteのIstioサービス・メッシュの中間に位置します。etcdと同様に、Consulには、Rafアルゴリズムに基づく分散キー値ストアが含まれており、HTTP／JSON アプリケーション・プログラミング・インターフェース（API）をサポートしています。どちらも動的なクラスター・メンバーシップ構成を提供しますが、Consulは複数の同時バージョンの構成データに対してそれほど強力に制御せず、確実に動作する最大データベース・サイズも小さくなります。

etcdと同様に、Redisはオープンソース・ツールですが、基本的な機能は異なります。

Redisはメモリ内データ・ストアであり、データベース、キャッシュ、またはメッセージ・ブローカーとして機能します。Redisはetcdよりも幅広いデータ型と構造をサポートし、読み取り／書き込みパフォーマンスがはるかに高速です。

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