1.2. etcd 성능 이해

복제된 노드의 클러스터로 작동하는 일관된 분산 키-값 저장소인 etcd는 한 노드를 리더로, 다른 노드를 팔로워로 선출하는 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의 기본 하트비트 간격이 100ms인 경우, 제어 평면 노드 간의 권장 RTT는 33ms 미만이며, 최대값은 66ms 미만입니다(66ms x 1.5 = 99ms). 네트워크 지연 시간이 길어지면 서비스에 영향을 미치는 이벤트와 클러스터 불안정이 발생할 수 있습니다.

네트워크 지연 시간은 구리, 광섬유, 무선 또는 위성과 같은 전송 네트워크의 기술, 전송 네트워크의 네트워크 장치 수와 품질 및 기타 요소를 포함한 요소에 의해 결정됩니다.

정확한 계산을 위해 네트워크 지터와 네트워크 지연 시간을 고려하세요. 네트워크 지터 는 네트워크 지연 시간의 변화 또는 수신 패킷의 지연 시간의 변화입니다. 네트워크가 효율적인 환경에서는 지터가 0이어야 합니다. 네트워크 지터는 etcd의 네트워크 지연 시간 계산에 영향을 미칩니다. 왜냐하면 시간에 따른 실제 네트워크 지연 시간은 RTT에 지터를 더하거나 뺀 값이기 때문입니다.

예를 들어, 최대 지연 시간이 80ms이고 지터가 30ms인 네트워크는 지연 시간이 110ms가 되는데, 이는 etcd가 하트비트를 놓치는 것을 의미합니다. 이러한 조건으로 인해 요청 시간 초과 및 일시적인 리더 손실이 발생합니다. 리더 손실 및 재선출 동안 Kubernetes API는 서비스에 영향을 미치는 이벤트와 클러스터 불안정성을 유발하는 요청을 처리할 수 없습니다.

etcdctl CLI를 사용하면 etcd가 합의에 도달하는 데 걸리는 지연 시간을 관찰할 수 있습니다. etcd 포드 중 하나를 식별한 다음 엔드포인트 상태를 검색해야 합니다.

Etcd 피어 왕복 시간은 Etcd가 모든 Etcd 멤버 간에 클라이언트 요청을 복제하는 데 걸리는 지연 시간을 보여주는 지표입니다. OpenShift Container Platform 콘솔은 다양한 etcd 메트릭을 시각화하는 대시보드를 제공합니다. 콘솔에서 관찰 대시보드를 클릭합니다. 드롭다운 목록에서 etcd를 선택합니다.

etcd 피어의 왕복 시간을 요약한 플롯은 etcd 대시보드 페이지의 끝 부분에 있습니다.

etcd 데이터베이스의 크기는 네트워크 파티션이 일정 기간 동안 제어 평면 노드를 격리하고 통신이 재설정된 후 제어 평면을 동기화해야 하는 경우 고려해야 할 요소입니다.

etcd 데이터베이스의 크기를 제어하기 위한 옵션은 시스템의 운영자와 애플리케이션에 따라 달라지므로 최소한의 옵션만 존재합니다. 시스템이 작동하는 대기 시간 범위를 고려할 때 etcd 데이터베이스 크기별로 동기화나 조각 모음의 효과를 고려하세요.

효과의 규모는 배포에 따라 다릅니다. 조각 모음을 완료하는 데 걸리는 시간으로 인해 etcd 멤버가 조각 모음 프로세스 동안 업데이트를 수락할 수 없으므로 트랜잭션 속도가 저하됩니다. 마찬가지로, 높은 변경률을 지닌 대규모 데이터베이스의 etcd 재동기화에 걸리는 시간은 시스템의 트랜잭션 속도와 트랜잭션 지연 시간에 영향을 미칩니다. 계획해야 할 영향의 유형에 대해 다음 두 가지 예를 살펴보세요.

데이터베이스 크기에 따른 etcd 조각 모음 효과에 대한 첫 번째 예는 1GB의 etcd 데이터베이스를 초당 80MB의 속도로 느린 7200RPM 디스크에 쓰는 데 약 1분 40초가 걸린다는 것입니다. 이런 시나리오에서 조각 모음 프로세스는 적어도 조각 모음을 완료하는 데 이 정도 시간이 걸립니다.

etcd 동기화에 대한 데이터베이스 크기의 영향에 대한 두 번째 예는 제어 평면 노드 중 하나가 연결 해제되는 동안 etcd 데이터베이스의 10%가 변경되면 동기화에서 최소 100MB를 전송해야 한다는 것입니다. 1Gbps 링크를 통해 100MB를 전송하는 데 800ms가 걸립니다. 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