카프카핵심가이드 13장 - 카프카 모니터링하기

전체 트래픽과 같은 단순한 지표에서 부터 시시각가으로 달라지는 가 요청 타입별, 토픽별, 파티션별 상세 지표에 이르기까지 다양한 지표를 모니터링을 진행함

지표 기초

자바 애플리케이션 모니터링의 기본적인 사항들과 모니터링, 경보 설정의 모범사례들을 살펴보자.

지표는 어디에 있는가?

카프카의 모든 지푯값은 JMX(자바 관리 확장 인터페이스)를 통해 사용할 수 있음

• 비애플리케이션 지표

  카프카에서 나오지 않는 지표도 있음.

종류	설명
애플리케이션 지표	카프카 자체의 JMX에서 나온 지표
로그	로그. 텍스트 혹은 구조화된 데이터이기 때문에 추가 처리가 좀 더 필요
인프라스터럭처 지표	카프카의 앞 단에 위치하면서, 내가 제어할 수 있는 시스템의 지표 (ex 로드밸런서)
특수 클라이언트 지표	카프카 모니터와 같은 외부 모니터링 툴 등에서 나오는 제어 가능한 클라이언트의 지표
일발 클라이언트 지표	카프카 클러스터에 접속한 카프카 클라이언트에서 나온 지표

어떤 지표가 필요한가?

카프카를 얼마나 사용해봤는지, 데이터를 수집하는데 사용되는 툴이 무엇인지, 어떤 데이터를 사용하는지에 따라 어떤 지표가 필요한지가 다름

• 경보냐 디버깅이냐?

  카프카에 문제가 발생하였을때 경보를 보낼것이냐, 발생한 문제를 디버깅할것이냐.

  경보를 보내기 위한 지표는 문제에 대응하는데 거리는 시간이 짧은 경우 유용

  디버깅이 주 목적인 지표는 복잡한 문제 등 의 경우 유용

• 자동화가 목적인지, 사람이 볼 것인지?

  자동화의 경우 대략의 메트릭을 사용해서 아주 세세한 부분까지 데이터를 수집해도 무방. ⇒ 어짜피 자동화해서 분석할것이기 때문

  사람이 보는 경우는 오히려 너무 많은 양의 메트릭은 피로감에 빠질 수 있음 ⇒ 적당히.

애플리케이션 상태 검사

카프카로부터 어떠한 지표를 수집하던 간에 간단한 health check를 통해 애플리케이션 프로세스가 살아있는지의 여부를 모니터링 할 수 있어야함.

• 브로커가 살아 있는지의 여부를 알려주는 외부 프로세스를 사용
• stale metrics(카프카 브로커로 들어와야 하는 지표)가 수집되지 않을때 경보를 보냄

서비스 수준 목표

• SLO(service level objective) : 서비스 수준 목표로써 SLA를 충족하기 위해 달성하고자 하는 내부적인 목표

서비스 수준 정의

• SLI(service level indicator) : 실제로 SLO와 SLA를 모두 충족시키는 데 얼마나 근접했는지 측정하는 데 사용하는 지표. 목표 지향적이면 좋음 ex) 전체 이벤트에 대한 성공적인 이벤트의 비율 측정
• SLT(service leve threshold) : 서비스 수준 한계로써, SLI에 목표값을 결합한것. ex) 7일간 웹서버에 대한 요청중 99%가 2xx 여야함
• SLA(service level agreement) : 서비스 제공자와 클라이언트 사이의 계약으로, 대개 측정방식, 보고방식, 지원 을 받을 수 있는 방법, SLA를 준수하지 못했을 때 서비스 제공가자 져야하는책임이 명시된 SLO를 포함함 ex) 서비스 제공자가 SLO 수주의 작동을 제공하지못한다면 비용을 환불해줘야함.

이러한 목표를 정해야 클라이언트 입장에서는 카프카가 어떻게 작동할 것인지에 대한 추측이 가능.

좋은 서비스 수준 지표를 위해서는 어떠한 지푯값을 써야하는가?

SLI에 연관된 지표는 카프카 브로커 외부에 어딘가에서 수집되어야함.

SLO는 사용자의 만족 여부를 가리켜야하는 것이며, 주관적인 것인 만큼 측정할 순 없음.

가장중요한 점은 사용 자 입장에서의 전체적인 경험. ⇒ SLI 기준으로 볼 때 인프라 스트럭쳐 지표는 사용해도 괜찮고, 특수 클라이언트 지표는 좋은 수준, 일반 클라이언트 지표가 가장 좋은 지표

• SLI 종류

종류	설명
availability	클라이언트가 요청을 보내고 응답을 받을 수 있는가?
latency	응답이 얼마나 빨리 리턴되었는가?
quality	응답의 내용이 적절한가?
security	요청과 응답이 적절히 보호되는가? 권한이나 암호화 측면에서도?
throughput	클라이언트가 충분한 속도로 데이터를 받을 수 있는가?

SLI는 SLO 문턱값 아래에 있는지 개별적으로 확인할 수 있어야 하므로 quantile 값은 좋은 SLI가 될 수없음.

⇒ 예를 들어 전체 이벤트의 90%가 주어진 값 아래에 있다는 것만 알려줄 뿐, 그 값을 제어할 수 있게 해주는 것은 아니기 때문. but 수집된 구간별로 분류하는 것은 요긴하게 사용할 수 있음.(10ms 이하, 10~50ms…)

경보에 SLO를 사용하기

slo는 주된 경보로 설정되어있어야함.

⇒ 사용자 관점에서 문제를 기술하는 것이고 운영하는 사람 입장에서는 가장 먼저 고려해야하기 때문

slo는 장기간을 기준으로 할때가 가장 좋으나 직접적인 경보 기준으로 사용하는 것이 매우 어려움.(책의 예시)

카프카 브로커 지표

카프카 브로커에는 디버깅에 사용할 목적으로 만든 저수준의 지표들을 포함하여 수 많은 지표들이 있음.

카프카 클러스터에 발생한 문제의 원인을 진단하는 대략적인 작업 흐름에 대하여 설명.

클러스터 문제 진단하기

카프카 클러스터에 문제가 생긴 경우는 크게 3가지의 문제로 나뉨

• 단일 브로커에서 발생하는 문제

  대응하기 쉬움. 대체로 고장난 저장장치나 시스템 내의 다른 애플리케이션으로 인한 자원 제한으로 발생. 저장장치, 운영체제 사용률 등을 모니터링해야함.

• 과적재된 클러스터에서 발생하는 문제

  하드웨어나 운영체제 수준의 문제가 아니라면 대부분은 카프카 클러스터 안에서 요청이 몰려서 발생.

  클러스터 안의 데이터를 최대한 고르게 분포되지 않아서 생기는 문제. 외부 툴(cruise control)을 사용해서 클러스터의 균형을 항상 유지하는 것이 권장됨.

• 컨트롤러 문제

  브로커 메타데이터 동기화가 끊어진다든가, 레플리카가 오프라인이던가. 토픽이 제대로 안만들어졌다던가 카프카 그 자체 아에서의 문제일 수 있기에 원인을 찾기 힘듦.

  활성 컨트롤러 수나 컨트롤러 큐 크기와 같은 지표를 모니터링하여 찾을 수 있음.

불완전 복제 파티션 다루기

불완전 복제 파티션 metric : 클러스터에 속한 브로커 단위로 집계되는데, 해당 브로커가 리더 레플리카를 잡고 있는 파티션 중 팔로워 레플리카가 따라오지 못하고 있는 파티션 수를 나타냄.

다수의 브로커가 일정한 수의 불완전 복제 파티션을 가지고 있다는 것은 보통 클러스터의 브로커 중 하나가 내려가 있다는 것을 의미하는 경우가 많음.

불완전 복제 파티션의 수가 오르락내리락 하거나, 수는 일정한데 내려간 브로커가 없다면 대개 클러스터의 성능 문제가 원인임.

• 클러스터 수준 문제

  • 부하 불균형

    찾기는 쉽지만 해결은 어려움. 파티션의 개수, 리더 파티션 수, 전 토픽에 있어서 초다 들어오는 메시지 수, 초당 input/output 바이트등을 모니터링 해야함.

    만약 선호 파티션 선출을 이미 실행했는데도 편차가 심하면, 클러스터에 들어오는 트래픽이 불균형하다는 의미. ⇒ 부하가 많은 브로커의 파티션을 적은 브로커로 재할당 필요. (kafka-reassign-partitions.sh 사용)

  • 자원 고갈

    브로커에 들어오는 요청이 처리 가능한 용량을 넘어가는 경우. cpu, 디스크 IO, 네트워크 처리량 등이 원인.

    cpu 사용율, inbound/outbound 네트워크 속도, 평균 디스크 대기 시간, 디스크 평균 활용률 등을 모니터링해야함. ⇒ 하나라도 자원고갈되면 불완전 복제 파티션이 발생

• 호스트 수준 문제

  카프카 클러스터 전체가 문제가 아니라 한두개의 브로커만 문제라면 다른 서버와 무엇이 다른지 살펴봐야함

  • 하드웨어 장애

    메모리 일부가 문제가 발생한 것일 수도 있음. 이런 하드웨어 문제가 발생하면 해당 세그먼트를 우회함(사용 가능한 전체 메모리가 줄어듦)

    cpu 장애가 발생할 수 있음. dmesg를 사용해서 커널링 버퍼를 살펴보며 확인해야함

  • 네트워킹

    케이블 문제, 네트워크 속도 문제, 네트워크 버퍼 크기가 너무 작거나 운영체제 문제일 수 있음. “네트워크 인터페이스 에러수” 체크 필수

  • 다른 프로세스와의 충돌

    다른 애플리케이션이 많은 자원을 많이 사용해 카프카 브로커에 부담이 되지 않는지 확인 필요.

  • 로컬 구성의 차이

    브로커 혹은 시스템 설정 변경의 문제일 가능성도 존재

브로커 지표

불완전 복제 파티션 외에도 전체 브로커 수준에서 모니터링 해야하는 지표를 소개.

• 활성 컨트롤러 수 (0 or 1)

  특정 브로커가 현재 클러스터의 컨트롤러 역할을 맡고 있는지를 나타냄. 1이면 현재 브로커가 컨트롤러.

• 컨트롤러 큐 크기 (0 이상의 int)

  현재 컨트롤러에서 브로커의 처리를 기다리고 있는 요청의 수.

  브로커의 요청이 들어오고 관리 작업(파티션 생성, 이동, 리더 변경 등..)이 수행됨에 따라 계속 오르락내리락.

• 요청 핸들러 유휴 비율(0< x <1 float)

  브로커에서 요청 핸들러 스레드가 유휴 상태로 보낸 시간의 비율.

• 전 토픽 바이트 인입(초당 인입률은 double, 갯수는 int)

  브로커가 프로듀서 클라이언트로부터 얼마나 많은 메시지 트래픽을 받는지에 대한 측정값

• 전 토픽 바이트 유출(초당 인입률은 double, 갯수는 int)

  브로커가 프로듀서 클라이언트로부터 얼마나 많은 메시지 트래픽을 쓰는지에 대한 측정값. 컨슈머가 메시지를 읽는 속도.

• 전 토픽 메시지 인입(초당 개수는 double, 갯수는 int)

  메시지 크기와 무관하게 초당 들어오는 메시지 수.

  (바이트 인입/유출 속도는 바이트 수를 기준으로 브로커 트래픽을 보여줌)

• 파티션 수(0이상 int)

  브로커에 저장된 모든 레플리카를 포함한 파티션 전체 개수

• 리더 수(0이상 int)

  브로커가 현재 리더를 맡고 있는 파티션의 개수. 클러스터 안의 모든 브로커에 걸쳐 균등해야함.

• 오프라인 파티션(0이상 int)

  리더가 없는 파티션의 개수. 리더가 없는 경우는 레플리카를 보유하고 있는 모든 브로커가 다운 되었거나 언클린 리더 선출 기능이 꺼져 있는 상태에서 저장된 메시지 개수가 모자란 탓에 리더 역할을 맡을 수 있는 인-싱크 레플리카가 없을 때 발생함.

• 요청 지표

  각자 알아보기.

토픽과 파티션별 지표

토픽 혹은 파티션에 국한된 지표로써 클라이언트에 연관된 특정한 문제를 디버깅할 때 유용.

예) 토픽 지표는 클러스터의 트래픽을 급증 시킨 토픽이 무엇인지 찾을 때 용이

• 토픽별 지표

  지정된 토픽에 국한된 지표.

• 파티션별 지표

  토픽별 지표보다는 덜 유용한편. 왜냐면 토픽이 수백개면 파티션은 수천개가 되기 쉽상임.

  파티션 크기 지표는 해당 파티션에 대해 현재 디스크에 저장된 데이터 양을 바이트 단위로 보여주는데, 이 값들을 합산하면 하나틔 토픽에 저장된 데이터양을 알 수 있음.

  같은 토픽에 속하는 두 파티션의 크기가 다를 경우, 메시지쓸 때 사용되는 메시지 키가 고르게 분산되어 있지 않다는 것을 의미.

JVM 모니터링

카프카 브로커에 의해 제공되는 지표 외에도 JVM을 포함한 모든 서버의 표준적인 측정값 또한 모니터링 해야함.

• 가비지 수집

• 자바 운영체제 모니터링

운영체제 모니터링

cpu 사용, 메모리 사용, 디스크 사용, 디스크 IO, 네트워크 사용량 등 운영체제 자체 지표도 수집해야함.

• cpu

  카프카 브로커는 요청을 처리하기 위해서 cpu를 많이 사용.

• memory

  상대적으로 작은 크기의 JVM heap을 사용해서 작동하기에 메모리는 덜 중요하지만 다른 애플리케이션이 브로커가 사용할 자원을 갉아먹지 않도록 하기 위해 메모리 사용률은 모니터링 필요.

• disk IO

  모든 메시지가 디스크에 저장되기에 디스크 성능에 크게 의존.

• network IO

  컨슈머 요청을 제외할 때, 카프카 브로커에 인입되는 비트 수에 토픽의 복제 팩터를 곱한 만큼의 비트 수가 유출됨으로 네트워크 사용량 또한 모니터링 필요.

로깅

적절한 레벨로 켜는 것이 중요. 아래 2개의 로거는 INFO 레벨로 별로듸 디스크 파일로 떨궈서 깔끔하게 떨구자.

• kafka.controller 로거: 클러스터 컨트롤러에 대한 메시지
• kafka.ClientQuotaManager로거 : 프로듀서 혹은 컨슈머 쿼터 작업에 관련된 메시지

그 외에도 많은 로거들이 있음.

• kafka.log.LogCleaner, kafka.log.LogCleanerManager : 로그 압착 스레드의 상태에 관한 정보
• kafka.request.loger: 브로커로 들어오는 모든 요청에 대한 정보 기록(debug일 경우 endpoint, 요청 시각, 요약 등을 보여주며 trace는 토픽과파티션 정보를 포함한 메시지 내용물을 제외한 거의 모든 정보를 보여줌) ⇒ 너무 많은 정보를 기록하므로 디버깅하지않을것이라면 켜지않는 것을 권장.

클라이언트 모니터링

인스턴스를 생성하는 애플리케이션은 클라이언트에 국한된 지표를 갖음.

프로듀서 지표

모든 프로듀서 지표는 빈 이름에 프로듀서 클라이언트 ID를 갖음.

JMX MBean 아래 속성에 들어가 있음.

• 프로듀서 종합 지표
  디버깅 및 정기적 모니터링하고 경보 설정해야하는 지표들을 포함함.
  ~avg로 끝나는 지표는 평균, ~max로 끝나는 지표는 최대값을 의미

  • record-error-rate : 이 지표는 반드시 0이어야 하며, 0보다 크다면 프로듀서가 브로커로 메시지를 보내는 와중에 누수가 발생하고있음을 의미.
  • request-latency-avg : 브로커가 쓰기 요청을 받을 때까지 걸린 평균 시간. 요청에 대한 지연이 증가한다는 것은 쓰기 요청이 점점 느려짐을 의미. => 브로커 혹은 네트워크의 문제 가능성
  • outgoing-byte-rate : 전송되는 메시지의 절대 크기를 초당 바이트 형태로 나타냄.
  • record-send-rate : 트래픽을 초당 전송되는 메시지 수의 크기
  • request-rate : 브로커로 전달되는 쓰기 요청의 수를 초단위로 나타냄
  • request-size-avg : 브로커로 보내지는 쓰기 요청의 평균 크기를 바이트 단위로 나타냄
  • record-size-avg : 레코드의 평균 크기를 바이트 단위로 나타냄
  • request-queue-time-avg : 애플리케이션이 메시지를 전송한 뒤 실제로 카프카에 쓰여지기 전까지 프로듀서에 대기하는 평균 시간(ms기준) => 메시지를 쓰는데 걸리는 시간.

• 브로커별 지표
  카프카 브로커로의 연결에 대한 정보 등의 지표를 포함

  • lrequest-latency-avg: 메시지 배치가 안정적일 경우 변화가 없지만, 특정 브로커로의 연결에 문제가 있을 경우 변함

• 토픽별 지표
  메시지가 쓰여지고 있는 각각의 토픽에 대한 정보 등의 지표를 포함. 프로듀서가 2개 이상의 토픽에 쓰고 있는 경우에만 유용.
  특정한 문제의 원인을 찾는데 가장 많이 사용.
  너무 많기에 모든 지표를 살펴보고, 적당한 문턱값을 설정하는 것은 힘듦

  • record-send-rate: 초당 Kafka로 전송되는 레코드 수
  • record-error-rate: 당 Kafka로 전송된 레코드 중 오류가 발생한 비율
  • byte-rate: 초당 Kafka로 전송된 데이터의 총 바이트 크기

컨슈머 지표

컨슈머 지표

• 읽기 매니저 지표
  fetch manger 빈 안에 들어가 있으며 바이트, 요청, 레코드에 대한 지표를 갖음

  • fetch-latency-avg : 브로커로 읽기 요청을 보내는데 걸리는 시간. fetch.min.bytes와 fetch.max.wait.ms의 영향을 받기 때문에 지연이 발생할 수 있음 => 경보 설정을 걸어놓는것이 애매할 수 있음.(경보 값에 대한???)
  • bytes-consumed-rate : 초당 읽은 바이트 수. 카프카 클라이언트가 얼마나 많은 메시지 트래픽을 처리중인지 알 수 있음.
  • record-consumed-rate 초당 읽은 메시지 수. 카프카 클라이언트가 얼마나 많은 메시지 트래픽을 처리중인지 알 수 있음.
  • fetch-rate : 컨슈머가 보내는 초당 읽기 요청 수
  • fetch-size-avg : 읽기 요청의 평균 크기(바이트수)
  • records-per-request-avg : 각 읽기 요청의 결과로 주어진 메시지 수의 평균값

• 브로커별 지표
  브로커 연결이나 읽는 토픽에 대한 지표 제공

  • incomming-byte-rate: byte-consumed-rate 지표를 각각 브로커별 초당 바이트 수로 세분화
  • request-rate: record-consumed-rate 지표를 각각 브로커별 초당 요청 수로 세분화

• 토픽별 지표
  1개 이상의 토픽에서 읽어 오고 있을 때 유용.

  • bytes-consumed-rate: 특정 토픽에서 초당 읽은 바이트수
  • records-consumned-rate: 특정 토픽에서 초당 읽은 메시지수
  • fetch-size-avg: 해당 토픽에 대한 읽기 요청의 평균 크기

• 컨슈머 코디네이터 지표
  컨슈머 코디네이터는 컨슈머 클라이언트의 일부로서 컨슈머 그룹 관련된 작업을 수행하며, 자체적인 지표를 유지 관리함.

  • sync-time-avg: 그룹코디네이터가 동기화 작업에 들어간 평균 시간(ms단위)
  • sync-rate: 초당 그룹 동기화 수. 컨슈머 그룹이 안정적일 경우 대부분의 시간동안 0임.
  • commit-latency-avg: 오프셋 커밋에 걸린 평균 시간
  • assigned-partitions: 특정 컨슈머 클라이언트에게 할당된 파티션의 개수. 그룹 전체에 부하가 고르게 분배되었는지 확인 가능

쿼터

카프카는 하나의 클라이언트가 전체 클러스터를 독차지 하는 것을 방지하기 위해 클라이언트 요청을 스로틀링 하는 기능을 가지고 있음.

스로틀링(Throttling)이란?
스로틀링(Throttling)은 시스템 자원의 사용량을 제어하여 과도한 부하를 방지하거나 공정한 리소스 배분을 보장하기 위해 속도를 제한하는 메커니즘.

1. 프로듀서 스로틀링 (Producer Throttling) 브로커가 너무 많은 데이터를 처리하지 못할 경우, 프로듀서가 데이터를 전송하는 속도를 제한.
   프로듀서가 브로커로 데이터를 보내는 동안 produce.request.throttle.time.ms를 통해 제한 시간을 통지받음.
   주요 목적: 브로커 과부하 방지 및 데이터 수집 속도 조절.
2. 컨슈머 스로틀링 (Consumer Throttling)
   컨슈머가 데이터를 너무 빠르게 읽어서 브로커의 리소스가 고갈될 위험이 있는 경우 적용됨.
   컨슈머가 데이터를 읽는 속도를 제한하여 브로커의 안정성을 보장함.
3. 복제 스로틀링 (Replication Throttling)
   클러스터 간 데이터 복제 또는 ISR(복제 세트) 동기화 중, 복제 트래픽이 지나치게 많아 브로커의 네트워크 대역폭을 초과하지 않도록 속도를 제한함
   • replica.replication.throttled.rate
   • leader.replication.throttled.rate
4. 쿼터 기반 스로틀링 (Quota based Throttling)
   Kafka는 쿼터(Quota)를 설정하여 클라이언트(프로듀서, 컨슈머) 또는 사용자/애플리케이션별로 특정 리소스 사용량을 제한할 수 있음.
   • producer_byte_rate: 프로듀서가 전송할 수 있는 최대 바이트 수.
   • consumer_byte_rate: 컨슈머가 읽을 수 있는 최대 바이트 수.
   • request_percentage: 요청 처리량 제한.

프로듀서와 컨슈머 양쪽다 설정 가능하며, 각 클라이언트ID 에서부터 각 브로커까지 허용된 트래픽 형태로 표시.

모든 클라리언트에 적용되는 기본값은 브로커 설정에 하지만, 클라이언트별 override 가능.

랙 모니터링

카프카 컨슈머에 있어서 가장 중요하게 모니터링 되어야함.

컨슈머 랙 지표는 외부 모니터링을 사용하는 것이 클라이언트 자체적으로 제공하는 것보다 훨씬 나은 경우임.

이 지표는 가장 지연이 심한 하나의 파티션만 나타내기 때문에 컨슈머가 얼마만큼 뒤쳐져 있는지 정확하게 보여주지 않음.

종단 모니터링

카프카 클러스터의 작동 상태에 대한 클라리언트의 관점을 제공하는 종단 모니터링 시스템.

카프카 클러스터에 문제가 있음을 나타낼 수 있지만 원인(네트워크, 클라이언트, 카프카 자체 등)에 대해서는 알려주지 않음.

아래는 종단 모니터링의 핵심

1. 카프카 클러스터에 메시지를 쑬 수 있는가?
2. 카프카 클러스터에서 메시지를 읽어 올 수 있는가?

요약

모니터링은 카프카를 원활히 운영하는데 핵심적인 측면