1.2. etcd のパフォーマンスについて

etcd は、レプリケートされたノードのクラスターとして動作する一貫性のある分散キー値ストアとして、1 つのノードをリーダーとして、他のノードをフォロワーとして選択する Raft アルゴリズムに従います。リーダーはシステムの現在の状態を維持し、フォロワーが最新の状態であることを確認します。

リーダーノードはログのレプリケーションを実行します。クライアントからの受信書き込みトランザクションを処理し、Raft ログエントリーを書き込み、それをフォロワーにブロードキャストします。

kube-apiserver などの etcd クライアントが、値の書き込みなどのクォーラムを必要とするアクションを要求している etcd メンバーに接続すると、etcd メンバーがフォロワーである場合は、トランザクションをリーダーに送信する必要があることを示すメッセージを返します。

etcd クライアントが、値の書き込みなど、クォーラムを必要とするアクションをリーダーに要求すると、リーダーはクライアントの接続を開いたままにして、ローカルの Raft ログを書き込み、そのログをフォロワーにブロードキャストし、過半数のフォロワーからログが正常にコミットされたことを確認するまで待機します。リーダーは etcd クライアントに確認応答を送信し、セッションを閉じます。フォロワーから障害通知が届き、コンセンサスが得られない場合、リーダーはエラーメッセージをクライアントに返し、セッションを終了します。

- name: ETCD_ELECTION_TIMEOUT 
  value: "1000"
  ...
- name: ETCD_HEARTBEAT_INTERVAL 
  value: "100"

- name: ETCD_ELECTION_TIMEOUT 

  value: "1000"
  ...
- name: ETCD_HEARTBEAT_INTERVAL 

  value: "100"

これらのパラメーターは、コントロールプレーンまたは etcd のすべての情報を提供するわけではありません。etcd クラスターは、ディスクのレイテンシーの影響を受けます。etcd は提案をログに保持する必要があるため、他のプロセスからのディスクアクティビティーによって fsync 待ち時間が長くなる可能性があります。その結果、etcd がハートビートを逃し、要求のタイムアウトや一時的なリーダーの喪失が発生する可能性があります。リーダーの喪失と再選出の間、Kubernetes API は、サービスに影響を与えるイベントやクラスターの不安定性を引き起こす要求を処理できません。

次の例に示すように、最終レポートでディスクが etcd に適切であると分類されていることを確認します。

...
99th percentile of fsync is 5865472 ns
99th percentile of the fsync is within the suggested threshold: - 20 ms, the disk can be used to host etcd

...
99th percentile of fsync is 5865472 ns
99th percentile of the fsync is within the suggested threshold: - 20 ms, the disk can be used to host etcd

高レイテンシーのディスクが使用されている場合、次の例に示すように、そのディスクは etcd には推奨されないというメッセージが表示されます。

...
99th percentile of fsync is 15865472 ns
99th percentile of the fsync is greater than the suggested value which is 20 ms, faster disks are suggested to host etcd for better performance

...
99th percentile of fsync is 15865472 ns
99th percentile of the fsync is greater than the suggested value which is 20 ms, faster disks are suggested to host etcd for better performance

クラスターのデプロイメントが、推奨されるレイテンシーを満たさない etcd 用ディスクを使用している多くのデータセンターにまたがっている場合、サービスに影響を及ぼず障害が発生する可能性があります。さらに、コントロールプレーンが許容できるネットワークレイテンシーも大幅に低下します。

ハートビート間隔の値は、メンバー間の平均往復時間 (RTT) の最大値にほぼ等しく、通常は往復時間の約 1.5 倍になります。OpenShift Container Platform のデフォルトのハートビート間隔は 100 ミリ秒であるため、コントロールプレーンノード間の推奨 RTT は 33 ミリ秒未満で、最大値は 66 ミリ秒未満 (66 ミリ秒 x 1.5 = 99 ミリ秒) になります。ネットワークレイテンシーがこれより大きいと、サービスに影響を与えるイベントが発生し、クラスターが不安定になる可能性があります。

ネットワークレイテンシーは、銅線、光ファイバー、無線、衛星などの伝送ネットワークの技術、伝送ネットワーク内のネットワーク機器の数や品質、その他の要因によって決まります。

正確な計算を行うには、ネットワークジッターを含むネットワークレイテンシーを考慮してください。ネットワークジッター とは、ネットワークレイテンシーのばらつきや、受信パケットの遅延時間の変動のことを指します。効率的なネットワーク状況では、ジッターはゼロになるはずです。ネットワークジッターは etcd のネットワークレイテンシーの計算に影響します。これは、時間の経過に伴う実際のネットワークレイテンシーは RTT にジッターを加算または減算したものになるためです。

たとえば、最大レイテンシーが 80 ミリ秒でジッターが 30 ミリ秒のネットワークでは、レイテンシーが 110 ミリ秒になり、etcd はハートビートを逃すことになります。この状態により、要求がタイムアウトし、リーダーが一時的に失われます。リーダーの喪失と再選出の間、Kubernetes API は、サービスに影響を与えるイベントやクラスターの不安定性を引き起こす要求を処理できません。

etcdctl CLI を使用すると、etcd が経験するコンセンサスに達するまでのレイテンシーを監視できます。etcd Pod の 1 つを識別し、エンドポイントのヘルス情報を取得する必要があります。

etcd ピアの往復時間は、etcd がすべての etcd メンバー間におけるクライアント要求のレプリケートを完了するまでのレイテンシーを示すメトリクスです。OpenShift Container Platform コンソールは、さまざまな etcd メトリクスを視覚化するためのダッシュボードを提供します。コンソールで、Observe Dashboards をクリックします。ドロップダウンリストから、etcd を選択します。

etcd Dashboard ページのほぼ最後に、etcd ピアの往復時間をまとめたグラフがあります。

etcd データベースのサイズは、ネットワークパーティションによってコントロールプレーンノードが一定期間分離され、通信が再確立された後にコントロールプレーンを同期する必要がある場合に考慮すべき要素です。

etcd データベースのサイズはシステム内の Operator とアプリケーションに依存するため、そのサイズを制御するためのオプションは最小限しかありません。システムが動作するレイテンシー範囲を検討するときは、etcd データベースのサイズごとに同期またはデフラグの影響を考慮してください。

その影響の大きさは、デプロイメントごとに異なります。デフラグが完了するまでの時間は、etcd メンバーがデフラグ処理中に更新を受け入れることができないため、トランザクションレートの低下を引き起こします。同様に、変更率の高い大規模データベースの etcd 再同期にかかる時間は、システム上のトランザクションレートとトランザクションレイテンシーに影響します。計画が必要な影響の種類は、次の 2 つの例を検討してください。

データベースサイズに基づいた etcd デフラグの影響に関する最初の例は、1 GB の etcd データベースを 80 Mb/秒の低速 7200 RPM ディスクに書き込むのに約 1 分 40 秒かかることです。このようなシナリオでは、デフラグが完了するまでに、デフラグプロセスに少なくともこれだけの時間がかかります。

データベースサイズが etcd 同期に与える影響の 2 番目の例は、コントロールプレーンノードの 1 つが切断されている間に etcd データベースの 10% が変更された場合、同期では少なくとも 100 MB を転送する必要があるということです。1 Gbps リンクで 100 MB を転送するには 800 ミリ秒かかります。Kubernetes API を使用した定期的なトランザクションを実行するクラスターでは、etcd データベースのサイズが大きくなるほど、ネットワークの不安定性が増し、コントロールプレーンの不安定性も生じます。

OpenShift Container Platform では、etcd ダッシュボードに etcd データベースのサイズを報告するグラフがあります。または、etcdctl ツールを使用して CLI からデータベースサイズを取得することもできます。

oc get pods -n openshift-etcd -l app=etcd

# oc get pods -n openshift-etcd -l app=etcd

NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h

NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h

oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4

# oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4

https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB

https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB