Kubernetes（K8s）という巨大なシステムを動かしている「心臓部」、それがetcd（エトシーディー）です。
こんにちは！インフラの世界に飛び込んだばかりのあなたへ。
「Kubernetesってなんだかすごそうだけど、裏側でどうやってデータが管理されているんだろう？」そんな疑問を持ったことはありませんか？
Podが増え、設定が変更され、デプロイが繰り返されるたび、そのすべての「状態（State）」を正確に、一瞬たりとも漏らさずに記録し続けているのがこのetcdです。いわば、Kubernetesクラスタの「脳であり、記憶装置」。
もしここが詰まったり、壊れたりしたら？――そう、クラスタ全体の機能が完全に停止してしまいます。
今回は、このetcdの役割から、大規模環境で陥りがちな罠、そして現場で役立つ実践的なチューニングとリカバリの手法まで、一緒に優しく丁寧に紐解いていきましょう。これをマスターすれば、Kubernetesのトラブルシューティングに怯える必要はなくなりますよ！
—
1. etcdってそもそも何をするツールなの？（役割の直感的な理解）
初心者の方がまず押さえておきたいのは、「etcdはリレーショナルデータベース（MySQLやPostgreSQLなど）とは似て非なるもの」という点です。
etcdは、分散KVS（Key-Valueストア）です。
Kubernetesにおいて、`kubectl apply` でマニフェストを流し込むと、そのデータは最終的にすべて etcd に `/registry/pods/` や `/registry/deployments/` といった階層構造のキーとして保存されます。
特徴：なぜRDBではなくetcdなのか？
1. Raftコンセンサスアルゴリズム：複数台（通常3台や5台などの奇数）でデータを同期し、リーダーが1台死んでも自動で新しいリーダーを選んで生き残り続けます。
2. Watch機能：「このキーの値が変わったら教えて！」という監視（Watch）が極めて高速に動作します。これが、K8sの「状態を常に望ましい状態に保つ（コントローラーパターン）」の根幹を支えています。
—
2. インストールと最も重要な基礎セットアップ
通常、K8sクラスタを構築するツール（kubeadmなど）を使うと、etcdはコントロールプレーン上で自動的に立ち上がります。しかし、その内部構造を理解するために、単体での起動や設定のキモを見ておきましょう。
ここでは、本番環境で絶対に避けるべき罠を踏まえた、精度高いセットアップのポイントを解説します。
最重要：etcdのハードウェア要件とストレージ設計
etcdのパフォーマンスを決定づけるのは、CPUでもメモリでもなく、「ディスクのI/O速度（特にFsyncのレイテンシ）」です。
etcdはデータが書き込まれるたびに、ディスクへの同期書き込み（fsync）を要求します。もしディスクが遅いと、書き込み完了を待つ間にタイムアウトが発生し、クラスタ全体がフリーズします。
- ベストプラクティス：
- etcd専用の超高速なSSD（NVMe推奨）を用意する。
- OSの他のプロセスとディスクI/Oを競合させない。
- スワップ（Swap）は絶対に無効化する。
動作確認：etcdに触れてみよう（Hello World）
etcdの操作には `etcdctl` というCLIツールを使います。
現代のetcd（v3 API）では、セキュリティのために証明書認証（TLS）が必須です。以下のコマンドで、クラスタの健康状態（ヘルスチェック）を確認してみましょう。
etcdのエンドポイントと証明書を指定して、クラスタメンバーの状態を確認する
ETCDCTL_API=3 etcdctl \
–endpoints=https://127.0.0.1:2379 \
–cacert=/etc/kubernetes/pki/etcd/ca.crt \
–cert=/etc/kubernetes/pki/etcd/server.crt \
–key=/etc/kubernetes/pki/etcd/server.key \
member list
出力例（正常時）：
8e9e05c52164694d, started, control-plane-01, https://192.168.1.10:2380, https://192.168.1.10:2379, false
これが返ってくれば、あなたとetcdの通信は成功です！
—
3. 大規模クラスタで陥る罠：なぜetcdは重くなるのか？
クラスタの規模が大きくなると、必ずと言っていいほどetcdのパフォーマンス問題に直面します。よくある「罠」とそのメカニズムを見てみましょう。
罠1：不要なデータの肥大化と「デフラグ（Defrag）」の欠如
etcdはデータを追記型（Append-only）で保存します。Kubernetesでは、Podの作成・削除、ConfigMapの更新などが頻繁に行われるため、古いデータ（リビジョン）がどんどんゴミとして蓄積されます。
etcdのデータファイルサイズ（DB size）は自動で縮小しません。これがデフォルトの制限である2GB（または設定した上限）に達すると、「etcdserver: mvcc: database space exceeded」という恐怖のエラーが発生し、クラスタへの書き込みが一切できなくなります。
対策：定期的なデフラグの実行
データ容量を物理的に削るために、デフラグを定期的に行う必要があります。
データの断片化を解消し、ディスク容量を解放するデフラグコマンド
ETCDCTL_API=3 etcdctl \
–endpoints=https://127.0.0.1:2379 \
–cacert=/etc/kubernetes/pki/etcd/ca.crt \
–cert=/etc/kubernetes/pki/etcd/server.crt \
–key=/etc/kubernetes/pki/etcd/server.key \
defrag
※注意：デフラグ中は対象ノードのetcdの負荷が上がるため、クラスタ全体ではなく1台ずつローリング方式で実施するのが鉄則です。
罠2：アラート（Alarm）の放置
ストレージ容量の制限を超えてしまうと、etcdは「NOSPACE」アラートをトリガーします。このアラートが発報されている間は、デフラグを行っても書き込みブロックが解除されません。
解除の手順：
1. スペースを空ける（不要なデータの削除やスナップショットからの復旧）
2. アラートを明示的にクリアする
ETCDCTL_API=3 etcdctl alarm disarm \
–endpoints=https://127.0.0.1:2379 \
–cacert=/etc/kubernetes/pki/etcd/ca.crt \
–cert=/etc/kubernetes/pki/etcd/server.crt \
–key=/etc/kubernetes/pki/etcd/server.key
—
4. 障害復旧：コンセンサス崩壊からのバックアップ・リストア
「もし、誤ってデータを消してしまったら」「ハードウェアが吹っ飛んだら」――そんな最悪の事態に備えるのがSREの腕の見所です。etcdのバックアップとリストアは、実は非常にシンプルですが、手順を間違えると二度と復旧しなくなります。
ステップ1：スナップショットの取得（日々のルーチン）
まずは、現在のetcdの状態をスナップショットとしてファイルに保存します。
現在のetcdの状態をスナップショットファイルとして保存する
ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd-snapshot-$(date +%Y%m%d).db \
–endpoints=https://127.0.0.1:2379 \
–cacert=/etc/kubernetes/pki/etcd/ca.crt \
–cert=/etc/kubernetes/pki/etcd/server.crt \
–key=/etc/kubernetes/pki/etcd/server.key
これをCron等で定期実行しておくことが、夜安心して眠るための第一歩です。
ステップ2：バックアップからのリストア（復旧作業）
もしクラスタが破損した場合、保存したスナップショットからデータを復元します。
リストアを行う際は、既存のetcdデータディレクトリ（通常 `/var/lib/etcd`）をクリーンな状態にし、新しいクラスタメンバーとして復元コマンドを実行します。
スナップショットから新しいデータディレクトリへリストアを行う
ETCDCTL_API=3 etcdctl snapshot restore /var/backups/etcd-snapshot-20231025.db \
–data-dir=/var/lib/etcd \
–initial-cluster=control-plane-01=https://192.168.1.10:2380 \
–initial-cluster-token=etcd-cluster-1 \
–initial-advertise-peer-urls=https://192.168.1.10:2380
このコマンドを実行後、コントロールプレーンの静的マニフェスト（kube-apiserverなど）が新しいデータを参照するように起動すれば、クラスタは完全に元の状態へと蘇ります！
—
5. まとめと先輩からのメッセージ
今回は、Kubernetesの心臓部であるetcdのパフォーマンスと障害復旧について、現場のリアルな視点でお伝えしました。
- ディスクI/Oの速さが正義（専用の高速SSDを使う）
- デフラグと容量監視を怠ると、突然システムが止まる
- 定期的なスナップショットこそが最強の保険
最初は難しく感じるかもしれませんが、仕組みを理解してしまえば、etcdは非常にロジカルで頼もしい相棒です。「これをマスターすれば、毎日の作業が劇的に楽になりますよ」。
トラブルが起きたときにも、慌てずに「あ、etcdの状態とストレージを確認しよう」と思える余裕が持てるはずです。
さあ、今日からあなたのKubernetesライフを、より堅牢で安心なものにアップデートしていきましょう！