etcdとは？ Kubernetesとクラスター

Etcdの概要

分散システムを扱ううえで、押さえておきたい概念がいくつかあります。その中でも、とりわけ重要なのが分散キーです。これは分散システムをつなぐうえで欠かせない役割を担います。etcdは、この分散キーが存在する場所に組み込まれ、高い実用性を備えた分散キー・バリューストアとして機能します。

これはオープンソースのストアで、分散システムを稼働させるために必要なあらゆるデータや情報を保管・管理する上で重要な役割を担います。一般的には、K8sにおけるステートやメタ、そして設定データなどを扱います。

コンテナ化されたワークロードでも分散型のワークロードでも、スケールが増すほど管理が複雑になりがちです。そこでKubernetesは優れた選択肢となります。ロードバランシングやヘルスチェック、ジョブスケジューリング、サービス発見などの主要オペレーションを効果的に連携させることで、リソース管理を簡単にしてくれます。

これらを扱いながら、Kubernetesは関係するすべてのPodやクラスターを単一の情報源として容易に管理し、システムの即時の状態を示します。そのために必要なのがetcdです。Kubernetesが分散ネットワークでの連携を実現するうえで必要とするあらゆる情報は、etcdによって支えられています。

Kubernetesだけでなく、Cloud Foundryでもetcdは同様の役割を果たし、システム全体に分散したクラスターメタデータ間で常に連携が必要となる他のあらゆる分散システムにも問題なく対応できます。  

なお、この名称にある「d」は“distributed”を意味しています。Linuxのディレクトリ構造に由来しており、「/etc」に構成ファイルが格納されることから、etcdという名前になりました。 

etcdにはチューニングの初期設定があり、低遅延のローカルネットワーク上での導入をサポートします。一方、高遅延なネットワークでetcdを使う場合は、内部タイムアウトやハートビート間隔の調整が必要です。Docker環境では、etcdのDockerサーバーはコンテナ内で稼働し、etcdクライアントからアクセスできます。 

‍

なぜetcdなのか？

etcdだけが選択肢なのか、と思われるかもしれません。しかしetcdについて詳しく知ると、これが分散システムの要と呼ばれる理由がよくわかります。その理由としては次のような点が挙げられます。

• 高いレプリケーション性を備えており、関係するすべてのノードが例外なくデータベースにアクセスできるようになっています。
• ダウンタイムがほとんどなく、可用性が高いです。いかなる状況でも停止せず、ハードウェアやネットワーク障害が発生しても動作し続けるように設計されています。
• Kubernetes上のetcdを使えば、常に最新の情報のみを取り扱えます。データの読み取り時には更新済みの情報が返されます。しかも、この更新データは単一のクラスタから書き込まれるため、一貫性があります。  
• 非常に高速なリソースで、1秒あたり1万件のデータ書き込みが可能とされています。  
• K8s上でetcdを使う限り、APIのセキュリティを気にする必要はありません。SSLやTLS暗号化に対応しているため、データ漏えいを抑えられます。さらにデータを守る必要がある場合は、アクセス制御を簡単に導入できます。
• etcdは非常にシンプルなため、Webアプリやモバイルアプリ、コンテナオーケストレーションエンジンの一部として広く採用されています。SPAの開発でもKubernetesの利用でも、標準的なツールからデータの読み書きが簡単にできます。このシンプルさのおかげで、開発者の技術レベルを問わず扱いやすいのです。  

ただし、利用を検討する際には、ストレージについて一つ押さえておくべき点があります。ディスクの速度はetcdのパフォーマンスに大きく影響するため、ディスク速度が速ければ性能も上がります。したがって、SSDの使用が強く推奨されます。

CoreOSの歴史とetcdのサポート

CoreOSは同じチームが開発したという経緯から、etcdと深い関わりがあります。当初、etcdはRaftをベースに開発されており、複数のContainer Linuxを連携させてアプリを継続的に稼働させるための容易な調整を目的としていました。  

その後、etcdはCNCFに引き渡され、コンテナベースのクラウド開発をより多くの人にとって簡単にするための枠組みが整えられました。一方、CoreOSはRed Hatに統合されました。

‍

etcdとKubernetes 

先述のとおり、etcdはKubernetesの多くの基盤要素の一つです。ここでは、従来からあるキー・バリューストアとして機能し、高性能なKubernetesクラスターを構築する際に大きく役立ちます。具体的には、各クラスターの状態情報はk8s APIサーバー経由でetcdに格納されます。

Kubernetesはetcdの「watch」機能を使ってデータを監視します。また、なにか変更があった際のKubernetesでの再設定にも、この「watch」機能が活躍します。

‍

etcd Operatorについて

これは、Kubernetes上でetcdをより使いやすくするための運用知識を活用した仕組みです。さらにコンテナプラットフォーム上でも動作し、Operator Frameworkのガイドラインに沿ってetcdの管理や設定の複雑さを取り除くことを目的としています。

ワンコマンドでのインストールが可能なetcd Operatorは、統一された宣言的な設定を使います。そして、以下のような機能を備えています。

• バックアップ

etcd Operatorは一定の間隔で継続的にバックアップを取得します。ただし、その間隔や要件は利用者が必要に応じてバックアップポリシーを設定する必要があります。

• 作成/削除

etcd Operatorでは、クラスターのサイズを一度指定すれば、統一された設定を適用できます。

• リサイズ

設定で仕様を変更するだけでリサイズが可能で、開発・破棄・再設計といった変更内容が容易に適用できます。

• アップグレード

ダウンタイムなしでetcdをアップグレードできるのも、etcd Operatorの特長です。

Operatorの動き

etcd Operatorを使うことで、これまで以上にetcdを簡単に扱えます。これはどう実現しているのでしょうか。基本的には、以下のアプローチに基づいています。

まず「観察（Observation）」では、Kubernetes APIを用いて現在のクラスター状態を詳細に監視します。

「差分検出（Differentiating）」では、過去と現在のクラスター状態の違いを見つけます。  

最後に「実行（Act）」では、APIをはじめ、k8s APIやetcdクラスターの 管理API などを活用して、差分を解消します。

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

etcdは、複数のノード間でデータストレージの一貫性を確保するために、Raftコンセンサスアルゴリズムを基盤としています。ここでは、etcdにおけるRaftアルゴリズムのコアな動作を簡単に見ていきましょう。  

クラスター内で選出されたリーダーノードが、フォロワーノードへのレプリケーションを作成・管理します。リーダーはクライアントから要求を受け取り、関連するフォロワーに転送します。各フォロワーノードはログを記録し、リーダーは大多数のノードが最新のデータを反映したと判断すると、そのデータをクライアント側に書き込みます。  

クラッシュやネットワークのパケット損失などが発生した場合、各フォロワーノードが最新のログを備えるまで、リーダーはアクティブになりません。

一定時間リーダーからのメッセージを受け取れない場合、アルゴリズムはリーダーに障害が起こったとみなし、新たなリーダーを選出するための選挙を開始します。

該当するフォロワーノードもリーダー候補として立候補し、新しいリーダーが決まると再びレプリケーション管理が行われ、この動作を繰り返します。 

こうして、etcdの連続稼働が保証されます。

‍

etcdとRedisの比較

どちらも有名なオープンソースリソースですが、それぞれ異なる機能を持ちます。たとえばRedisはインメモリデータも扱えますが、etcd（Kubernetesなどで利用）はクラスターにとって重要なデータを保管します。より深いレベルでは、Redisはメッセージブローカー、キャッシュ、データベースとしても機能しますが、etcdは常に分散システム向けのキー・ストアです。

拡張性の面では多様なデータ型や構造をサポートするRedisのほうが柔軟性があります。一方、障害耐性という観点では、etcdのほうが優れています。さらに、etcdは継続的にデータが利用できるようにもなっています。

両者は使用目的が異なります。分散メモリキャッシングシステムを構築するならRedis、そして分散システムを対象とするならKubernetesのetcdが適しています。

‍

ZooKeeperとConsulとetcdの比較 

これら3つはすべて分散システムの構成要素であるため、機能が重なる部分も少なくありません。ここでは、主な違いを整理してみます。  

ZooKeeperの開発当初は、Apache Hadoopクラスターのメタデータや設定データを調整することが主な目的でした。これはetcdよりも先に登場し、etcdの開発にも大きな影響を与えました。 

Zookeeperから得られた知見がetcdクラスターの構築要素となったとも言われており、etcdはZookeeperの発展版とされることが多いです。ただしZookeeperはApache向け、etcdは主にKubernetes向けという違いがあります。 

etcdでは動的な再設定が容易ですが、Zookeeperにはそれがありません。安定性の面では、etcdのほうが高負荷トラフィック時にも安定して動作します。  

Zookeeperは独自のJute RPCプロトコルを一部しかサポートしていませんが、etcdは多くのフレームワークや言語と連携できるため、柔軟性が高いです。 

次にConsulとetcdの比較です。Consulはサービスネットワーキング専用のソリューションで、Istioよりも多くの機能を備えているともいえます。一方でetcdはより効率的に動作し、制御面でも優れています。

ConsulもRaftアルゴリズムに基づき、キー・バリューストアを備えてはいますが、制御力という面ではetcdほど強力ではありません。 

結論 

分散システムの利用が急増したことで、ソフトウェア開発には新たな方向性が生まれました。Kubernetesや数多くの分散システムで活躍するetcdは、分散型のキー・ストアとして機能し、分散されたシステム同士をつなぐ重要な役割を担います。

etcdは高速かつ高いセキュリティを備え、いつでも利用しやすいリソースです。こうした特性から、etcdのGitHubコミュニティは活発に成長しています。オープンソースで学習コストも低めなので、さまざまな開発者が分散システムの開発プロジェクトに活用できます。