etcdは2013年にCoreOS社（当時の創業者はアレックス・ポルヴィ氏とブランドン・フィリップス氏）が公開した、分散システム向けの軽量な鍵値ストアです。Raftというコンセンサスアルゴリズムを内部に組み込み、複数台のサーバーに同じ値を強整合で複製する点が特徴で、Kubernetesのコントロールプレーンに採用されたことで一気に広く知られるようになりました。クラスタ全体の構成・Pod一覧・Secret・ServiceAccountといった「真実の情報源」がこのストアに格納されるため、etcdの可用性とバックアップ戦略はクラスタ運用の生命線とも言える要素です。
この記事の目次
- Raftコンセンサスが支える強整合
- CoreOSからKubernetesへの橋渡し
- 本番運用で気をつけるポイント
- ZooKeeper・Consulとの位置取り
- まとめ
Raftコンセンサスが支える強整合
etcdは3台・5台といった奇数台でクラスタを組み、Raftアルゴリズムを使って1台のLeaderと残りのFollowerを選び分けます。書き込みはLeader1台に集約され、Leaderはログとして受け付けた変更を全Followerに複製していき、過半数（クォーラム）が同意した時点で初めてコミット扱いとなる仕組みです。Raftの提案者はスタンフォード大学のディエゴ・オンガロ氏とジョン・オースタハウト氏で、Paxosと比べて理解しやすいことを主眼に2014年の論文で提示されました。
強整合の代償として、ネットワーク分断時には少数派側のノードが書き込みを拒否します。これは「データを失わない代わりに、いつでも書ける可用性は犠牲にする」というCAP定理上の選択であり、5台構成なら2台までの障害に耐えられる一方、3台中2台を同時に失うとクラスタ全体が一時的に書き込み不能になります。そのためetcdは別データセンターをまたぐ広域展開には向かず、同一リージョン内の低遅延ネットワーク前提で配置するのが基本です。
CoreOSからKubernetesへの橋渡し
etcdは2013年8月、当時CoreOS Linuxを開発していたCoreOS社が分散ロックや構成共有用途のために公開しました。Google社内で開発が始まったKubernetesは2014年に外部公開された際、状態保存先としてこのetcdを採用し、ApiServerが受け付けたPod・Service・ConfigMapなどの定義を全てetcdに書き込む構造を採りました。結果としてKubernetesクラスタの寿命はetcdクラスタの健全性に等しい、と言われるほどの位置づけになりました。
プロジェクトは2018年12月にCNCF（Cloud Native Computing Foundation）へ寄贈され、2020年11月にはCNCFの最上位ステータスであるGraduated（卒業）プロジェクトに昇格しました。v2系からv3系への移行ではAPIをgRPC化し、MVCCベースのストレージエンジンに刷新したことで性能が大きく改善されました。現在はRed Hatに加わった元CoreOSメンバーや、AWS・Google・Alibabaなど多数の企業エンジニアが共同で開発を続けています。
本番運用で気をつけるポイント
etcdを本番で運用する際は、まず奇数台での配置と地理的に近いノード構成が出発点です。Kubernetesクラスタが大きくなるとetcdに対する書き込みが増えるため、ディスクのfsync遅延が直接APIの応答遅延に跳ね返ります。推奨はNVMe SSDなどIOPSとレイテンシに余裕のあるディスクで、磁気ディスクや遠隔ストレージは避けるのが定石です。etcdctlコマンドのsnapshotサブコマンドで定期的に取得したスナップショットは、災害復旧の最後の砦になります。
セキュリティ面ではTLS証明書によるピア間通信の暗号化と、クライアント証明書認証の有効化が必須級です。etcdの中にはKubernetes Secretをはじめ機微情報がそのまま入るため、保存時の暗号化（Encryption at Rest）も検討対象になります。監視ではheartbeat失敗回数・書き込み遅延（disk_wal_fsync_duration_seconds）・リーダー切替頻度を見ておくと、性能劣化やネットワーク不調の兆候を早期に検知できます。クラスタが大規模化したらSize Quotaの引き上げと不要キーのコンパクションも忘れずに実施します。
ZooKeeper・Consulとの位置取り
強整合の分散KVSというカテゴリには、Apache ZooKeeperやHashiCorp Consulといった先行・並走プロダクトがあります。ZooKeeperは2007年にYahoo!で開発されたJava製のコーディネータで、KafkaやHBaseが長らく依存先として採用してきました。ConsulはHashiCorpが2014年に公開したGo製で、サービス発見・ヘルスチェック・DNSサーバー機能を最初から備えるのが個性です。etcdはこれらに比べてKubernetesエコシステムへの統合度が突出している点が選定理由になりやすい一方、サービス発見や設定配布だけが欲しい場合はConsulの方が運用しやすい場面もあります。
Redisも鍵値ストアとして広く使われますが、こちらはレプリケーションが非同期で強整合を前提とせず、キャッシュやセッション保存といった可用性重視の用途に向きます。「失わずに確実に書く」のがetcdとZooKeeperとConsul、「速くて消えてもよい」のがRedisやMemcached、と整理すると棲み分けが見えやすくなります。Kubernetesと組み合わせる前提なら、まずetcdをそのまま使い倒すのが最も摩擦の少ない選択肢です。
まとめ
etcdは2013年にCoreOSが公開し、Raftによる強整合な鍵値ストアとしてKubernetesの心臓部に据えられました。クラスタ全体の状態を預かるため、奇数台配置・SSD・スナップショット・TLSといった運用基本を押さえることが安定運用の前提です。ZooKeeperやConsulと棲み分けながら、クラウドネイティブ時代の「真実の情報源」として今も中心的役割を担っています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント