第3章 信頼性の高い etcd のパフォーマンスとスケーラビリティーの確保
etcd で最適なパフォーマンスを確保するには、ノードのスケーリング、リーダーの選択、ログレプリケーション、チューニング、レイテンシー、ネットワークジッター、ピアラウンドトリップ時間、データベースサイズ、Kubernetes API トランザクションレートなど、パフォーマンスに影響を与える条件を理解することが重要です。
3.1. etcd のリーダーの選択およびログレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
etcd は、複製されたノードのクラスターとして動作する、一貫性のある分散型のキーと値のストアです。Raft アルゴリズムに従って、etcd は 1 つのノードをリーダーとして選択し、残りのノードをフォロワーとして選択します。リーダーは、システムの最新の状態を維持し、フォロワーが最新の状態であることを確認します。
リーダーノードはログのレプリケーションを実行します。クライアントからの受信書き込みトランザクションを処理し、Raft ログエントリーを書き込み、それをフォロワーにブロードキャストします。
kube-apiserver
などの etcd クライアントが、値の書き込みなど、クォーラムを必要とするアクションを要求する etcd メンバーに接続すると、etcd メンバーがフォロワーに送信される必要があることを示すメッセージを返します。
etcd クライアントがリーダーからクォーラムを必要とするアクションを要求すると、リーダーは、ローカル Raft ログを書き込みながらクライアント接続を開いたままにして、ログをフォロワーにブロードキャストし、フォロワーの大部分が失敗なしにログがコミットされたことを確認するのを待ちます。その後のみ、リーダーが確認を etcd クライアントに送信し、セッションを閉じます。フォロワーから障害通知を受信し、過半数がコンセンサスに到達できなかった場合、リーダーはエラーメッセージをクライアントに返してセッションを閉じます。