実行時再構成の設計

実行時再構成は、分散システム、とりわけetcdのようにコンセンサスに基づくシステムで、実装が最も難しく、誤りが生じやすい機能の1つです。

ここでは、etcdの実行時再構成コマンドの設計と、これらの問題への取り組みを説明します。

2段階の構成変更でクラスターの安全性を確保

etcdでは、安全性のため、すべての実行時再構成を2段階 で行う必要があります。たとえばメンバーを追加する場合は、まず新しい構成をクラスターに通知し、その後に新しいメンバーを起動します。

第1段階 - 新しい構成をクラスターに通知

etcdクラスターにメンバーを追加するには、APIを呼び出して、新しいメンバーの追加をクラスターに要求します。既存のクラスターに新しいメンバーを追加する方法はこれだけです。構成変更にクラスターが合意すると、API呼び出しが戻ります。

第2段階 - 新しいメンバーを起動

新しいetcdメンバーを既存のクラスターに参加させるには、正しいinitial-clusterを指定し、initial-cluster-stateをexistingに設定します。メンバーは起動時にまず既存のクラスターに接続し、現在のクラスター構成がinitial-clusterに指定された期待する構成と一致することを確認します。新しいメンバーが正常に起動すれば、クラスターは期待する構成に到達しています。

処理を明確な2段階に分けることで、ユーザーはクラスターメンバーの変更を明示的に行う必要があります。これにより、実際には柔軟性が増し、動作も把握しやすくなります。たとえば、etcdクラスターの既存メンバーと同じIDを持つ新しいメンバーを追加しようとすると、第1段階ですぐに失敗し、稼働中のクラスターには影響しません。誤って新しいメンバーを追加することも、同様の仕組みで防ぎます。クラスターが構成変更を受け入れる前に新しいetcdメンバーが参加しようとしても、クラスターは受け入れません。

クラスターメンバーの変更に明示的な手順がなければ、etcdでは意図しないメンバー変更が起こり得ます。たとえばsystemdなどのinitシステムの管理下でetcdを実行している場合、メンバーシップAPIで削除されたetcdが再起動し、起動時にクラスターへの再参加を試みます。障害時にetcdを再起動するようsystemdを設定していると、APIでメンバーを削除するたびにこのサイクルが繰り返され、意図しない動作になります。

実行時再構成は頻繁には行わない操作を想定しています。構成の安全性を確保し、明示的な管理の下でクラスターを常に円滑に稼働させるため、ユーザーが主導する明示的な操作としました。

クォーラムを恒久的に失った場合は新しいクラスターが必要

クラスターが過半数のメンバーを恒久的に失った場合、以前の状態をリカバリーするには、古いデータディレクトリから新しいクラスターを起動する必要があります。

障害が発生したメンバーを既存のクラスターから強制的に削除してリカバリーすることは、技術的には可能です。ただし、この方法は通常のコンセンサスによるコミット段階を迂回してしまい安全でないため、サポートしないことにしました。削除するメンバーが実際には停止していない場合や、同じクラスターの異なるメンバーを通じて強制削除した場合、同じclusterIDを持つクラスターの状態が分岐してしまいます。これは非常に危険で、後から原因を調査して修復することも困難です。

正しく配置されていれば、過半数を恒久的に失う可能性は非常に低くなります。それでも、特別な配慮が必要なほど重大な問題です。etcdを本番運用する前に、災害復旧のドキュメント を読み、過半数の恒久的な喪失に備えることを強く推奨します。

実行時再構成に公開ディスカバリーサービスを使わない

公開ディスカバリーサービスは、クラスターのブートストラップにのみ使用することを推奨します。既存のクラスターにメンバーを参加させるには、実行時再構成APIを使用してください。

ディスカバリーサービスは、すべてのメンバーのIPアドレスが事前にわからないクラウド環境で、etcdクラスターをブートストラップするために設計されています。クラスターのブートストラップが完了すると、すべてのメンバーのIPアドレスがわかるため、技術的にはディスカバリーサービスは不要になるはずです。

公開ディスカバリーサービスにはすべてのクラスター構成情報があるため、実行時再構成にも使うと便利に思えます。しかし、公開ディスカバリーサービスに依存すると、次の問題が生じます。

1. ブートストラップ時だけでなく、クラスターのライフサイクル全体に外部依存が生まれます。クラスターと公開ディスカバリーサービスの間でネットワークの問題が発生すると、クラスターも影響を受けます。

2. 公開ディスカバリーサービスは、ライフサイクル全体を通じてクラスターの正しい実行時構成を反映しなければなりません。不正な操作を防ぐセキュリティーの仕組みが必要で、その実現は困難です。

3. 公開ディスカバリーサービスは、数万のクラスター構成を保持する必要があります。私たちの公開ディスカバリーサービスのバックエンドは、その負荷に対応できる状態ではありません。

実行時再構成に対応するディスカバリーサービスが必要な場合は、専用の非公開サービスを構築するのが最適です。