# 障害の種類

> 障害の種類とetcdの耐障害性

---

LLMSインデックス: [llms.txt](/ja/llms.txt)

---

大規模なマシン環境では、障害は珍しくありません。ハードウェアやソフトウェアの不具合によって、マシンに障害が発生します。停電やネットワークの問題では、複数のマシンに同時に障害が発生します。異なる種類の障害が同時に起きることもあるため、起こり得る障害をすべて列挙することはほぼ不可能です。

このセクションでは障害を分類し、etcdがそれらに耐えるためにどのように設計されているかを説明します。ほとんどのユーザーは、個々の障害をいずれかの種類に当てはめられます。まれな障害や[リカバリー不能な障害][unrecoverable]に備え、etcdクラスターを必ず[バックアップ][backup]してください。

## 少数のフォロワーの障害 {#minor-followers-failure}

フォロワーに障害が発生しても、障害が発生したメンバーがクラスター全体の半数未満で、リーダーが引き続き利用可能であれば、etcdクラスターは大きな支障なくリクエストを受け付け、処理を継続できます。たとえば、5メンバーのetcdクラスターでは、2つのフォロワーの障害はクラスターの動作に影響しません。ただし、クライアントは障害が発生したメンバーとの接続を失います。読み取りリクエストについては、クライアントライブラリがほかのメンバーに自動的に再接続し、ユーザーがこの中断を意識せずに済むようにすることを推奨します。運用担当者は、再接続によってほかのメンバーのシステム負荷が増加することを見込んでおく必要があります。

## リーダーの障害 {#leader-failure}

リーダーに障害が発生すると、etcdクラスターは新しいリーダーを自動的に選出します。障害直後に選出されるわけではありません。障害検出がタイムアウトに基づくため、新しいリーダーの選出には選挙タイムアウトとほぼ同じ時間がかかります。

リーダー選出中、クラスターは書き込みを処理できません。選出中に送られた書き込みリクエストは、新しいリーダーが選出されるまで処理キューで待機します。

古いリーダーに送信済みでも、まだコミットされていない書き込みは失われる可能性があります。新しいリーダーは、以前のリーダーの未コミットエントリーをすべて書き換えることができます。ユーザーから見ると、新しいリーダーの選出後に一部の書き込みリクエストがタイムアウトすることがあります。ただし、コミット済みの書き込みが失われることはありません。

新しいリーダーは、すべてのリースのタイムアウトを自動的に延長します。この仕組みにより、古いリーダーが付与したリースでも、付与されたTTLより前に期限切れになることを防ぎます。

## 過半数の障害 {#majority-failure}

クラスターの過半数のメンバーに障害が発生すると、etcdクラスターは機能しなくなり、それ以上の書き込みを受け付けられません。

etcdクラスターが過半数の障害からリカバリーできるのは、過半数のメンバーが利用可能になってからです。過半数のメンバーがオンラインに戻れない場合、運用担当者は[災害復旧][unrecoverable]を開始してクラスターをリカバリーしなければなりません。

過半数のメンバーが稼働すると、etcdクラスターは新しいリーダーを自動的に選出し、正常な状態に戻ります。新しいリーダーは、すべてのリースのタイムアウトを自動的に延長します。この仕組みにより、サーバーが利用できないことによるリースの期限切れを防ぎます。

## ネットワーク分断 {#network-partition}

ネットワーク分断は、少数のフォロワーの障害やリーダーの障害に似ています。分断によってetcdクラスターは、過半数のメンバーを持つ側と少数のメンバーを持つ側の2つに分かれます。過半数側は利用可能なクラスターとなり、少数側は利用できなくなります。etcdでは、メンバーの追加と削除を明示的に行い、その都度、現在の過半数のメンバーが変更を承認するため、「スプリットブレイン」は発生しません。

リーダーが過半数側にいる場合、過半数側から見ると少数のフォロワーの障害に相当します。リーダーが少数側にいる場合は、リーダーの障害に相当します。少数側のリーダーは退任し、過半数側が新しいリーダーを選出します。

ネットワーク分断が解消すると、少数側は過半数側のリーダーを自動的に認識し、自身の状態をリカバリーします。

## ブートストラップ中の障害 {#failure-during-bootstrapping}

クラスターのブートストラップは、必要なすべてのメンバーが正常に起動した場合にのみ成功します。ブートストラップ中に何らかの障害が発生した場合は、すべてのメンバーのデータディレクトリを削除し、新しいcluster-tokenまたは新しいディスカバリートークンでクラスターを再度ブートストラップしてください。

もちろん、稼働中のクラスターと同様に、ブートストラップに失敗したクラスターをリカバリーすることも可能です。ただし、リカバリーするデータがないため、そのクラスターをリカバリーするより、新しいクラスターをブートストラップするほうが、ほぼ常に時間もリソースも少なくて済みます。

[backup]: /ja/docs/etcd/op-guide/maintenance/#snapshot-backup
[unrecoverable]: /ja/docs/etcd/op-guide/recovery/