개요

컨트롤 플레인에서 주요하게 노출하는 메트릭들을 알아보자.

성능에 영향을 미치는 요소

먼저 컨트롤 플레인의 성능에 영향을 미치는 요소는 다음과 같이 정리할 수 있다.

• 변경 속도 - 변경 속도가 빠를수록 데이터 플레인을 동기화하기 위해 더 많이 처리
• 할당된 리소스 - 프로세스는 당연히 컴퓨팅 자원에 영향 받음..
• 업데이트할 워크로드 개수 - 업데이트할 워크로드가 많을 수록 네트워크 대역폭과 처리 능력 필요
• 설정 크기 - 엔보이 설정 파일이 클 수록 처리 능력과 네트워크 대역폭이 필요

성능이라 했을 때 가장 연관되는 지표가 시간 관련 지표라 바로 표시(참고로 pilot_ 접두사 붙음)했다.
이밖에도 제공되는 메트릭이 많다.^[1]
주요한 메트릭들을 황금 신호에 기반해 나누어서 살펴보자.

지연 시간

위 그림에서 본 메트릭들이 이를 측정하기 위한 메트릭이다.

1. pilot_debounce_time - 채널에서 받은 이벤트가 큐에 들어갈 때까지 걸린 시간
2. pilot_proxy_convergence_time - 대기열에 들어간 푸시 요청이 워크로드에 적용되는 시간
3. pilot_proxy_queue_time - 대기열에 머무른 시간
4. pilot_xds_push_time - 설정이 푸시되는데 들어간 시간
   1. 전송 데이터양이 영향을 미치기에 네트워크 대역폭의 영향을 받는다.
   2. 설정 업데이트 크기, 대상 워크로드 개수를 최적화하여 개선할 수 있다.

왜인지 모르겠지만 최신 이스티오 그라파나 대시보드에서는 시간에 대한 버킷을 히트맵으로 표시하더라..
이건 버킷의 증가량에서 99분위까지의 값을 히트맵으로 표시한 것이다.
다른 실험을 하면서 열심히 해봤는데 내 로컬에서는 아무리 해도 푸시 시간을 늘리는 것이 쉽지 않아서 그냥 위 사진 정도로 남겨둔다.
만약 푸시 타임이 100ms나 1s를 넘어가는 사례가 99분위 안에 들었다면 현재 표시된 칸 위에도 색이 칠해졌을 것이다.
10ms로 푸시가 이뤄진다면 아주 좋고, 1s를 넘어가는 것들이 있다면 성능에 대한 분석해봐야한다.

sum(rate(pilot_xds_push_time_bucket{}[1m])) by (le)

99분위 히스토그램으로 내는 안쪽 쿼리만 쿼리를 꺼냈다.
하나의 선으로 보이지만 모든 선이 똑같은 값을 가지고 있어서 그런 것이다.

그라파나 쪽에선 잘 모르겠지만 프로메테우스로 보면 stacked를 체크해서 다 같은 값이어도 겹쳐있는 것을 조금 더 확실하게 확인할 수 있다.

포화도

컨트롤 플레인에 대해서 포화도는 리소스 사용량으로 보면 된다.
관련한 메트릭에 대해 istiod에서 직접적으로 노출하는 것은 없지만, 쿠버네티스 환경에서는 메트릭 서버 등을 활용해 쉽게 컨테이너의 자원 사용량을 체크할 수 있다.

sum (irate(container_cpu_usage_seconds_total{container="discovery",pod=~"istiod-.*"}[1m])) by (pod) 

istiod에서 예민한 자원은 cpu로 cpu의 사용량을 기준으로 보면 된다.
노드 차원에서 수집하여 볼 수 있는 통계로는 위처럼 볼 수 있는데, istiod는 Go로 작성됐기에, go에서 메트릭 세팅할 때 제공되는 다른 메트릭을 활용할 수도 있다.

irate(process_cpu_seconds_total{app="istiod"}[1m])

이스티오의 자원 사용량은 특정 타이밍마다 증가하는데, 서비스나 생길 때 관련한 설정들을 갑자기 만들어서 전달해야 하기 때문에 그렇다.
평소에는 idle 상태를 유지하다가 특정 타이밍마다 많이 생기게 되기 때문에 적절한 스케일링 전략을 고려하는 것이 도움이 될 것이다.
가령 배포가 많이 일어날 시기에는 미리 스케일링을 하는 식으로 조절할 수 있다.

전체적으로 메트릭을 보면 특정 순간에만 치고 올라오는 현상을 많이 보게 될 것이다.
이는 설정이 들어갈 때만 연산량이 많아지기 때문에 발생하는 현상으로, 보통은 이게 자연스러운 상황이다.
즉 istiod는 특정 타이밍에만 자원을 버스트하는 속성을 가지고 있다.

트래픽

그렇다면 단위 요청 수는 얼마나 되는가?
이스티오의 컨트롤 플레인의 트래픽 단위는 수신받는 이벤트, 푸시하는 설정을 들 수 있겠다.
각각의 지점이 병목 포인트가 될 수 있으며 저마다 최적화할 전략이 있기 때문에 둘 다 염두해둘 필요가 있다.
여기에 대해 그라파나 시각화가 전부 다 돼있진 않지만, 메트릭으로는 여러 개 볼 수 있는 지점이 있다.

수신 관련

pilot_inbound_updates

istiod 인스턴스마다 업데이트를 수신한 횟수 카운터이다.
istiod에서 이벤트라고 인지한 것들의 개수를 말하는 것으로, 이 값을 통해 istiod가 받는 수신 트래픽의 양을 짐작할 수 있다.

pilot_push_triggers

많은 이벤트를 받을 텐데 실제로 이 중에서 푸시를 트리거한 것들의 개수를 나타내는 메트릭이다.
이 값은 조금 더 세분화돼있는데, 푸시된 이유(reason)를 조금 더 상세하게 라벨로 구분시켜보여준다.
큐에 들어가는 이벤트들이 무엇인지 분석할 때 용이하다.

발신 관련

pilot_xds_pushes

실제로 엔보이에 적용한 모든 종류의 XDS api 횟수를 말한다.
sum by (type) (irate(pilot_xds_pushes[$__rate_interval]))
순간 ops/s라고 써져있어서 자연스럽게 속도를 나타내는 건가 싶었는데, 위 그래프는 얼마나 자주 푸시가 일어나는지를 담고 있다.
초당 푸시 수 정도로 보면 되겠다.

pilot_xds
이건 동기화를 할 대상들의 수를 말한다.
정확하게는 커넥션 수를 말한다.

pilot_xds_config_size_bytes_bucket

xds 설정 파일 크기를 나타낸 메트릭.

이건 설정 별로 크기가 얼마나 되는지 나타낸다.
envoy_cluster_upstream_cx_tx_bytes_total, envoy_cluster_upstream_cx_rx_bytes_total을 통해서도 비슷한 정보를 볼 수 있다.

이것들은 기본적으로는 엔보이에서 노출하는 메트릭 정보로, 각 엔보이가 컨트롤 플레인과 통신하며 주고 받은 설정 파일 크기, 동기화 트래픽 등을 나타낸다.

keti debug -- curl localhost:15020/metrics | grep envoy_cluster 

각 엔보이에 쿼리를 날려서 확인해볼 수 있다.

엔보이가 노출하는 메트릭 정보는 굉장히 많은데,[^4] 이스티오는 이중에서 극히 일부를 기본 메트릭으로 노출한다.[^5]
위 cluster.xds-grpc 키가 프로메테우스 메트릭 상으로는 라벨로 들어간다.

기타

pilot_services, pilot_virt_services

이스티오에서 추적하고 있는 버츄얼 서비스, 서비스 개수를 나타낸다.
서비스 개수도 클러스터 내에 있는 것만큼 다 가지고 있는데, 이는 컨트롤 플레인이 제멋대로 모든 네임스페이스를 추적하고 있다는 말과 같다!
불필요한 리소스를 추적한다는 건 엔보이에 적용할 설정 파일의 크기를 불필요하게 늘리게 되는 상황을 야기하기에 이를 개선할 필요가 있다.

오류

istiod가 포화 상태에 이르렀을 때 커넥션 수가 넘치거나 큐가 지나치게 쌓이며 에러가 발생할 수 있다.
(현재는 간단한 테스트만 하느라 에러가 발생할 일이 없..)
이와 관련된 주요한 메트릭들은 이 정도가 있다.

• pilot_xds_rejects - 설정 푸시 거부 횟수
• pilot_xds_push_context_errors - 푸시하다 에러 난 횟수
• pilot_xds_write_timeout - 설정 변환에서 타임아웃 난 횟수
• pilot_total_xds_internal_errors - 에러 총합

이 정보들은 어떤 설정이 많이 거부되는지, 어떤 부분이 취약하여 향후 어떤 장애로 이어질지 예측하는데 도움을 준다.
가령 CDS 설정에서 에러가 많이 발생하는 걸 포착해 서비스 레지스트리 최적화가 필요하다고 짐작해볼 수 있다.
그런데 istiod에 에러가 발생한다는 것 자체가 사실 심각한 문제라, 기왕이면 에러가 발생하기 이전에 다른 지표들을 통해 발생할 병목 요인을 탐색하는 게 베스트일 거라 본다.
아래에서 보겠지만, istiod는 포화 상태가 되더라도 이를 즉각적으로 대응하는데 살짝 제약 사항이 있다.
그러므로 최대한 에러가 발생하지 않도록, 포화도를 미리 선제적으로 잘 관측할 필요가 있다.

관련 문서

지식 문서, EXPLAIN

기타 문서

참고