13. 카프카 모니터링하기

카프카 어플리케이션은 작동에 대해 많은 측정값을 제공한다.(각 요청 타입, 토빅, 파티션 관련 지표들 등등)
이 장에서는 항상 모니터링할 필요가 있는 가장 중요한 지표로서 어떤 것이 있는지 살펴보자.

13.1 지표기초

13.1.3 지표는 어디에 있는가?

기본적으로 카프카 지표 보기에 앞서 자바 어플리케이션 모니터링에 대해 알아보자.
카프카의 모든 지푯값은 자바 관리 확장(JMX, Java Management Extesions) 인터페이스를 통해 사용할 수 있다. 외부 모니터링 시스템 입장에서 이를 사용하는 가장 쉬운 방법은 해당 모니터링 시스템에서 제공하는 메트릭 수집 에이전트를 가져다 카프카 프로세스에 붙이는 것이다.
모니터링 에이전트를 설정하는 방법에 대한 자세한 내용은 이 장이 다루는 범위를 벗어나고, 너무 많은 선택지가 있으므로 자세히 다뤄보지는 않겠다.
초기에는 카프카에 대한 지표(카프카가 어떻게 동작하는지)에 대해서만 살펴보다가 이후 목적성을 가지고 더 넓은 분야에 대하여 지표를 살펴볼 수도 있다.

13.1.2 어떤 지표가 필요한가?

해당 주제에 관한 질문은 누가 어떤 입장에서 해석하는지에 따라서 다르다. 만약 브로커 개발자가 눈여겨보는 지표와 SRE 엔지니어가 보는 지표는 확연히 다르다. 예를 들어, 문제에 대응하는 자동화 시스템이 있을 수 있지만, 복잡한 문제를 들여다보기 위해서 지표를 선정할 수도 있다.
위 예시와 같이 자동화로 대처를 하는지, 원인을 분석하기 위해 사람이 볼 것인지 등에 따라 살펴봐야할 지표가 다르다. 자동화는 해석이 필요없기 때문에 비교적 쉽지만, 사람이 볼때 지표가 많을 수록 지표에 압사당할 수 있다.

13.1.3 애플리케이션 상태 검사

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

• 외부 프로세스로 검사
• 카프카로부터 들어와야하는 지표가 잘 들어오는지 검사
  간단하게 포트 검사부터 직접 프로세스가 살아있는지 검사할 필요가 있다.

13.2 서비스 수준 목표

카프카와 같인 인프라 스트럭처 서비스에 있어서 모니터링이 다뤄야 할 특히 중요한 부분 중 하나가 서비스 수준 목표(SLO, service level objective)이다. 클라이언트는 카프카의 내부적인 동작보다는 어떻게 무엇을 할 수 있는지 투명한 시스템으로 다룰 필요가 있다.

13.2.1 서비스 수준 정의

SLO와 관련된 용어를 살펴보자
SLI: 서비스 수준 지표로서, 서비스 신뢰성을 대표하는 지표. (ex: 4XX 응답을 어느정도 비율)
SLT: 서비스 수준 한계로서, 서비스 수준 목표를 대표하는 지표. (ex: 요청 중 2XX 는 99퍼 이상 달성)
SLA: 서비스 제공자와 클라이언트 간 계약으로, SLA 를 준수하지 못했을때 서비스 제공자가 책임져야할 여러 개의 SLO 포함.

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

좋은 SLI는 서비스 사용자가 실제로 체감하는 신뢰성을 정확하게 반영해야 한다.

• 좋은 SLI의 조건

  • 사용자 관점이어야 한다
  • 내부 구현 세부 사항에 의존하지 않아야 한다
  • “서비스가 잘 동작하는가?”에 직접적으로 답할 수 있어야 한다

• 나쁜 SLI의 예

  • CPU 사용률
  • 디스크 I/O 대기 시간
  • GC 시간

• 좋은 SLI의 예

  • 가용성
  • 정확성
  • 지연율

13.2.3 경보에 SLO 를 사용하기

SLO는 주된 경보로 설정되어야한다. 일반적으로 문제가 사용자에게 영향을 미치지 않는다면 운영자를 깨울 필요가 없다. 즉, SLO 를 직접적인 경보 기준으로 사용하는게 아니라 충분한 기간을 두고 SLO 에 대한 소진율(burn rate)를 보는것이다.
예를 들어, 카프카가 매주 100만개 요청을 받는데 전체 요청의 99.9%를 10ms 안에 응답이 시작되어야한다 가정해보자. 이는 매주 1천개까지는 더 늦게 응답을 해도 문제가 없다는 얘기다. 즉, 1주일에 100만개의 요청이 주어지는 상황에서 한 시간에 한 개의 요청이라면 시간당 소진율은 0.1%가 된다.

즉, SLO 를 직접적인 목표로 잡지 말고 충분한 기간과 시간을 두고 본다. 예를 들어, 경보는 다음과 같은 질문에 답하도록 설계한다.

• 에러율이 빠르게 솟구치고 있는가?
• 현재 추세라면 SLO를 지킬 수 없는가?

13.3 카프카 브로커 지표

카프카 대부분 지표는 개발자들이 특정한 이슈 혹은 디버깅을 위해 만든 저수준 지표이다. 이번 장에서는 이러한 지표보다는 문제의 원인을 진단할 때 유용한 지표를 위주로 살펴볼 것이다.

감시자는 누가 감시하는가?

보통 많은 조직이나 회사는 중앙 모니터링 시스템에 카프카를 사용한다. 이것은 어플리케이션과 모니터링 시스템을 분리하는 좋은 방법이다. 그러나 만약 카프카 자체를 모니터링하는데 카프카가 고장난다면? 데이터 흐름 및 모니터링 모두 장애가 발생할 것이다. 이를 방지하기 위해 제 3의 시스템을 사용하거나 카프카 간 지표는 다른 데이터센터에 있는 카프카에 보내는 방법이 있다.

13.3.1 클러스터 문제 진단하기

카프카 클러스터에 문제가 있는 경우로서
1. 단일 브로커에서 발생하는 문제
2. 과적재된 클러스터에서 발생하는 문제
3. 컨트롤러 문제

개별 브로커에서 발생하는 문제는 진단 및 대응하기 쉽다.

그러나 하드웨어나 운영체제 수준에서 발생하는 문제를 제외하면 대게 클러스터에 데이터가 골고루 분포되지 않아 문제가 발생한다. 이를 방지하기 위해서는 크루즈 컨트롤과 같은 균형있게 분산시키는 툴을 사용하는 게 좋다. 만약 고르게 분산되지 않아 문제가 발생했다면, 선호 레플리카 선출을 돌렸는지 먼저 확인해보자. 카프카 브로커는 자동 리더 리밸런스 기능이 켜져있지 않은 한 자동으로 리더 자격을 원래 리더로 돌려놓지 않는다. 이로 인해 특정 브로커에 리더가 쏠려 과부하가 발생할 수 있다. 이러한 과적재 문제가 발생한다면 브로커 처리 지연 지표가 크게 오를것이다. 이는 특정 브로커에 요청이 과하게 몰리고 처리하기 벅찬 상태를 의미한다.

카프카 클러스터의 컨트롤러에 문제가 발생한다면 진단하기도 어렵고, 심지어 카프카 그 자체에 버그일 수도 있다. 예를 들어, 브로커 메타데이터 동기화가 끊어진다던지, 브로커는 멀쩡해보이는데 내부 레플리카가 오프라인 상태라던지 등이 있다. 컨트롤러를 모니터링하는 방법은 많지 않지만 대게 활성 컨트롤러 수나 컨트롤러 큐 크기와 같은 지표를 확인하여 진단할 수 있다.

13.3.2 블완전 복제 파티션 다루기

카프카 모니터링에 있어서 가장 많이 다루는 지표 중 하나는 불완전 복제 파티션이다. 이 측정값은 클러스터에 속한 브로커 단위로 집계되는데, 해당 브로커가 리더 레플리카를 잡고있는 파티션 중 팔로워 레플리카가 따라오지 못하고 있는 파티션 수를 의미한다. 만약 브로커가 내려갔다면 해당 브로커가 담당하는 레플리카도 모두 비활성화되어 불완전 복제 파티션 수가 늘어날 것이다. 또는 클러스터에 문제가 생겨 불완전 복제 파티션 수가 들락날락 할 수 있다. 대게 특정 브로커에 문제가 생겨 발생하는데 kafka-topics.sh 를 사용하여 토픽 내 파티션의 ISR 목록을 보고 어느 브로커에 문제가 생겼는지 확인해야한다.

URP(Under Replicated Partitions 를 경보지표로 사용하지 말자

URP 는 별거 아닌 상황에서 1 이상의 값을 가질 수 있다. 만약 경보지표로서 사용한다면 계속 경보가 울릴 수 있다.

클러스터 수준 문제

클러스터 문제는 부하 불균형, 자원 고갈 등의 이유로 발생한다. 만약 부하 불균형으로 인해 발생했다면, 파티션의 개수, 리더 파티션 수, 초당 들어오는 메시지 등 지표를 살펴봐야한다. 완전 균형있게 들어온다면 모든 브로커에 있는 파티션 수, 리더 파티션 수, 초당 들어오는 메시지 등 지표는 모두 비슷할 것이다.
만약 자원 고갈 등의 이유로 문제가 발생했다면, CPU, DISK 관련 지표를 살펴보는 것 좋다.

호스트 수준 문제

카프카 클러스터 전체가 아닌 특정 브로커들에게 문제가 있다면 해당 서버가 나머지 서버보다 네트워킹, 로컬 구성의 차이, 디스크 등 문제가 있을 수 있다. 하나의 브로커에서 문제가 발생한다면 클러스터 전반적으로 영향을 끼칠 수 있기에 빠르게 해결해야 한다. 따라서 SMART 등 툴을 이용해서 디스크를 모니터링하고(카프카는 디스크에 메시지를 직접 기록하기 때문에 많이 사용함) 만약 하드웨어 이슈가 아니라면 특정 프로세스(어플리케이션)이 자원을 많이 점유하고 있지 않은지 확인한다.

13.3.3 브로커 지표

앞서 불완전 복제 파티션은 주로 특정 브로커에 문제가 생겨서 발생하는 반면, 전체 브로커 수준에서 모니터링해야 하는 다른 지표들이 있다. 클러스터 내 브로커들에 관련된 지표들을 살펴보자

활성 컨트롤러 수

이 지표는 특정 브로커가 현재 클러스터의 컨트롤러 역할을 하는지를 의미한다. 1이면 컨트롤러 역할 담당하는 것이고 0이면 아닌것이다. 클러스터 내 컨트롤러 수가 세팅한 값만큼 적절하게 있는지 확인해야된다.

컨트롤러 큐 크기

이 지표는 현재 컨트롤러에서 브로커의 처리를 기다리고 있는 요청의 수를 가리킨다. 파티션 생성, 이동, 리더 변경 등 관리 작업이 수행됨에 따라 오르락내리락 할 수 있다. 이 값이 갑자기 튀어오르고 계속 올라간다면 컨트롤러에 문제가 생겼을 확률이 크다. 이때 컨트롤러 역할을 다른 브로커에게 옮겨야된다.

요청 핸들러 유휴 비율

카프카는 클라이언트 요청을 처리하기 위해 네트워크 스레드 풀과 요청 핸들러 스레드(I/O 스레드) 풀, 두 개의 풀을 사용한다. 네트워크 스레드는 네트워크를 통해 클라이언트와 데이터를 주고받는 역할을 한다. 따라서 네트워크 스레드가 당장 고갈되더라도 그리 우려할 만한 것은 못된다. 하지만 요청 핸들러 스레드는 메시지를 디스크에 쓰거나 읽어오는 역할을 한다(즉, 요청 핸들러 스레드는 요청 처리를 담당).

요청 핸들러 유휴 비율 지표는 요청 핸들러가 작동 중이지 않은 시간 비율을 가리킨다. 만약 해당 지표가 낮다면 브로커에 부하가 많이 걸려있음을 의미한다. 대게 20퍼 이하로 내려가면 잠재적인 문제가 있고, 10퍼 미만이면 성능 문제가 진행되고 있음을 암시한다. 일반적으로, 요청 핸들러 스레드의 수는 시스템의 프로세서 수와 같게 설정하고, 브로커 메시지 형식을 0.10 으로 바꿔 성능 향상을 가져온다면 요청 핸들러 스레드 사용률을 크게 감소시킬 수 있다.

전 토픽 바이트 인입

초당 바이트로 나타내어지는 전 토픽 바이트 인입 속도는 브로커가 프로듀서 클라이언트로부터 얼마나 많은 메시지 트래픽을 받는지에 대한 측정값으로서 유용하다. 해당 지표를 보고 트래픽 증가함을 확인하고 클러스터를 확장해야하는 경우, 어느 브로커에 트래픽이 많이 몰리는지 확인할 수 있다.

전 토픽 바이트 유출

전 토픽 바이트 유출은 초당 바이트 기준으로 브로커가 컨슈머에게 전달하는 데이터 양을 의미한다. 이 지표는 컨슈머 트래픽의 크기와 소비 패턴을 파악하는 데 유용하다. 바이트 유출이 급격히 증가하는 경우, 컨슈머 수 증가나 컨슈머 애플리케이션의 처리량 증가를 의심해볼 수 있다. 반대로 바이트 인입 대비 유출이 현저히 낮다면 컨슈머 지연이나 적체가 발생하고 있을 가능성이 있다.

전 토픽 메시지 인입

전 토픽 메시지 인입은 초당 수신되는 메시지 개수를 나타내며, 메시지 크기와 무관하게 트래픽 패턴을 이해하는 데 도움을 준다. 바이트 인입과 함께 분석하면, 메시지가 커진 것인지 아니면 메시지 수 자체가 늘어난 것인지 구분할 수 있다.

파티션 수

이 값은 브로커에 할당된 파티션의 전체 개수를 의미한다. 주로 이 값은 변하지 않지만, 만약 자동 토픽 생성 기능이 켜져 있다면 해당 지표를 유심히 살펴봐야 한다.

리더 수

리더 수는 각 브로커가 담당하고 있는 리더 파티션의 개수를 의미한다. 리더는 모든 읽기/쓰기를 처리하므로, 리더 수는 브로커 부하를 가늠하는 핵심 지표다. 리더 수가 특정 브로커에 편중되어 있다면 이 경우 선호 레플리카 선출이나 파티션 재할당을 통해 리더를 고르게 분산시키는 것이 필요하다.

오프라인 파티션

불완전 복제 파티션 수와 마찬가지로 오프라인 파티션 수는 모니터링할 때 매우 중요한 지표이다. 이 지표는 컨트롤러 역할을 담당하는 브로커에게만 보여지는데, 현재 리더가 없는 파티션의 개수를 의미한다. 주로 이 상황이 발생하는 경우는

• 레플리카를 보유하고 있는 모든 브로커가 다운되었을때
• (언클린 리더 선출 기능이 꺼져있는 상태에서) 저장된 메시지 개수가 모자란 탓에 리더 역할을 맡을 수 있는 인-싱크 레플리카가 없을 때

카프카 클러스터에서 오프라인 파티션은 퓨로듀서 클라이언트에 메시지 유실이나 어플리케이션에서의 백프레셔와 같은 문제를 야기할 수 있다.

요청 지표

카프카 프로토콜에는 많은 요청이 있다. 각 요청이 어떻게 수행되고 있는지에 대한 지표 역시 제공한다.

• 전체 시간 (Total Time)
  요청이 브로커에 도착해서 응답이 완전히 전송될 때까지의 총 시간

• 요청 큐 시간 (Request Queue Time)
  요청이 네트워크 스레드에서 받아진 후 요청 처리 스레드에서 처리되기 전까지 대기한 시간

• 로컬 시간 (Local Time)
  파티션 리더가 요청을 처리하는 데 필요한 작업 시간

• 원격 시간 (Remote Time)
  요청 처리가 완전히 끝나기 전 팔로워를 기다리는 시간

• 스로틀 시간 (Throttle Time)
  쿼터(quota) 설정으로 인해 요청이 의도적으로 지연된 시간

• 응답 큐 시간 (Response Queue Time)
  요청 처리가 끝난 뒤 응답을 네트워크 스레드로 보내기 전까지 대기한 시간

• 응답 전송 시간 (Response Send Time)
  응답을 전송하는 데 걸린 시간

카프카 요청 지표에서 초당 요청 수는 부하의 크기를, 전체 시간 평균은 시스템의 전반적 상태를, 높은 백분위수는 실제 클라이언트가 겪는 최악의 지연을 보여주기 때문에 모든 요청 유형에 대해 반드시 함께 수집해야 한다.

13.3.4 토픽과 파티션별 지표

카프카 브로커 지표 외에도 토픽 혹은 파티션에 국한된 지표들도 있다. 이들의 지표는 대규모의 클러스터라면 엄청나게 많을 것이기 때문에 모든 지푯값을 수집하기에는 어려움이 있다.

토픽별 지표

모든 토픽별 지표의 측정값은 앞에서 설명한 브로커 지표와 매우 비슷한다. 특정 토픽 이름을 지정하여 해당 토픽에 대한 관련 지표를 확인할 수 있다. 대게 클러스터의 트래픽을 급증시킨 토픽이 무엇인지 찾을 때 사용한다.

파티션별 지표

파티션별 지표는 토픽별 지표보다 덜 유용한 편이다. 예를 들어, 토픽의 데이터 양을 확인할 때 사용하는데, 만약 같은 토픽 내 두 파티션의 크기가 다르다면 메시지를 쓸 때 사용하는 메시지 키가 고르게 분산되어 있지 않다는 것을 보여준다. 또한 어떤 경우에는 파티션의 로그 시작과 끝 오프셋을 확인할 수도 있다.

13.3.5 JVM 모니터링

카프카 브로커에 의해 제공되는 지표외에도 자바 가상머신(JVM)을 포함한 모든 서버의 표준적인 측정값 역시 모니터링해야 한다. 가비지 수집 상태라던지 자바 운영체제 모니터링이 있다.

13.3.6 운영체제 모니터링

운영체제 자체에 대한 모니터링도 필요하다. 주로 눈여겨봐야 할 것은 CPU, memory, disk, disk I/O, network 등 지표가 있다. 특히 카프카는 디스크를 이용해서 데이터를 적재하기 때문에 디스크 관련 지표가 중요하다.

13.3.7 로깅

카프카 로깅으로부터 유용한 정보를 얻으려면 INFO 레벨로 로깅하는 것만으로도 브로커의 상태에 관한 엄청난 정보를 얻을 수 있다. 그러나 로그 파일이 좀 더 깔끔하게 떨어지게 하려면 몇 개의 로거는 분리하는 것이 좋다. 하나는 컨트롤러 로거(클러스터 컨트롤러 로그 및 선호 레플리카 선출이나 파티션 이동 등과 같은 클러스터 작업에 대한 로그 관련), 나머지 하나는 클라이언트 쿼터 로거(프로듀서 혹은 컨슈머 쿼터 작업에 관련된 로그)이다.
이외에도 로그 압착에 관련된 정보를 로깅을 하여 압착이 실패했는지 살펴보거나, 디버깅을 할 때 kafka-request.logger 를 DEBUG 또는 TRACE 레벨로 켜서 확인하는 경우도 있다.

13.4 클라이언트 모니터링

프로듀서, 컨슈머, 카프카 클라이언트 인스턴스를 생성하는 어플리케이션은 클라이언트에 국한된 지표를 갖는다.

13.4.1 프로듀서 지표

프로듀서 종합 지표는 메시지 배치 크기에서부터 메모리 버퍼 활용에 이르기까지 모든 것들을 나타내는 속성을 제공한다. 일부 지표를 살펴보자면,

record-error-rate: 항상 0이어야하고 그보다 크면 프로듀서가 브로커로 메시지를 보내는 와중에 누수가 발생함을 의미한다. 해당 속성은 반드시 경보 설정을 해야한다. 프로듀서는 백오프(backoff)를 해가면서 사전 설정된 수만큼 재시도를 하게 되어있는데, 만약 재시도 수가 고갈되면 메시지는 폐기된다.
request-latency-avg: 브로커가 쓰기 요청을 받을 때까지 걸린 평균 시간이다. 정상 작동 상태에서 이 지표의 기준값을 찾은 뒤, 기준값보다 큰 값으로 문턱값을 설정하면 된다. 만약 느려진다면 네트워크 또는 브로커 이상이 있는것이다.

이외에도 트래픽, 배치의 크기 등 관련된 지표가 몇몇 있다.
outgoing-byte-rate: 전송되는 메시지의 절대 크기를 초당 바이트로 표기
record-send-rate: 초당 전송되는 메시지의 수
request-rate: 브로커로 전달되는 쓰기 요청의 초당 수
request-size-avg: 브로커로 보내지는 쓰기 요청의 평균 크기

위와 같이 종합적인 상황을 보여주는 지표 외에도 브로커별, 토픽별 지표도 제공한다. 그러나 대부분은 디버깅할 때 주로 사용한다.

13.4.2 컨슈머 지표

컨슈머 클라이언트에서 중요한 지표들은 읽기 매니저 빈에 들어있기 때문에 컨슈머 종합 지표빈은 상대적으로 덜 유용하다. 컨슈머 종합 지표 빈은 저수준의 네트워크 작업에 관련된 지표들을 가지는 반면, 읽기 매니저 빈은 바이트, 요청, 레코드에 대한 지표를 갖는다. 따라서 앞서 프로듀서 종합지표와 달리 컨슈머 종합지표는 덜 유용하다.

읽기 매니저 지표에서는 모니터링 말고 경보 설정에 모두 사용할 수 있는 속성이 하나 있는데, 바로 fetch-latency-avg 이다. 프로듀서 클라이언트의 request-latency-avg 이다. 프로듀서와 마찬가지로 브로커로 읽기 요청을 보내는 데 걸리는 시간을 보여준다. 다만 해당 속성은 fetch.min.bytes 와 fetch.max.wait.ms 의 영향을 받는다. 어떤 경우엔 메시지가 준비되어 있어서 빨리 응답을 내놓지만 어떤 경우에는 메시지가 준비되지 않아서 fetch.max.wait.ms 만큼 기다리다 티런하는 식이다 보니 느린 토픽은 지연이 일정치 않다. 하지만 정기적으로 많은 메시지가 들어 잇는 토픽을 읽을 경우 이 지표는 살펴볼 만한 가치가 있다.

그리고 bytes-consumed-rate, records-consumed-rate 와 같이 컨슈머가 얼마나 많은 메시지 트래픽을 처리 중인지 볼 수 있는 지표가 있다. 그러나 문턱값을 설정해서 경보를 주는 것은 신중해야한다. 프로듀서가 제대로 작동하지 않는 경우에도 경보가 울릴 수 있기 때문이다.

컨슈머의 경우 컨슈머 랙 지표가 중요한데 읽기 매니저 빈의 records-lag-max 속성을 모니터링하라고 권장하지는 않다. 이러한 이유는 단 하나의 파티션에 대한 랙만을 보여주고, 컨슈머가 제대로 작동한다 가정하기 때문이다. 차라리 외부 랙 모니터링을 사용하는 것이 좋다.

이외에 브로커별, 토픽 별 지표도 제공하며, 코디네이터 지표를 통해서 그룹 멤버 관리를 모니터링할 수 있다.

13.4.3 쿼터

카프카는 하나의 클라이언트가 전체 클러스터를 독차리 하는 것을 막기 위해 스로틀링하는 기능을 갖고 있다. 이는 프로듀서, 컨슛머 양쪽 다 설정 가능하며, 해당 클라이언트 ID 에서부터 각 브로커까지 허용된 트래픽 형태로 표시된다.

13.5 랙 모니터링

컨슈머 랙의 정확한 정의는 프로듀서가 특정 파티션에 마지막으로 쓴 메시지와 컨슈머가 마지막으로 처리한 메시지 사이의 차이다. 앞서 말한거처럼 컨슈머 읽기 매니저 지표에서 제공하는 랙 지표에는 단점이 있기 때문에 외부 랙 모니터링을 사용하는 것이 좋다. 컨슈머 랙을 모니터링 할 때 선호되는 방법은 브로커의 파티션 상태와 컨슈머 상태를 둘 다 지켜봄으로써 마지막으로 쓰여진 메시지 오프셋과 컨슈머 그룹이 파티션에 대해 마지막으로 커밋한 오프셋을 추적하는 외부 프로세스를 두는 것이다. 이러한 확인 작업은 컨슈머 그룹이 담당하고 있는 모든 파티션에 대해 수행되어야 한다.

파티션들마다 어느 정도 수준의 랙이 존재하면 적당한지 알아야한다. 시간당 100개 메시지 받는 토픽과 시간당 100_000_000 개 메시지 받는 토픽은 문턱값이 달라야하기 때문이다. 이러한 복잡성을 줄이기 위해 링크드인에서 개발한 버로우 오픈소스 툴을 활용할 수도 있다.

버로우 오픈소스의 핵심 기능 요약

• 컨슈머 Lag 모니터링
  Kafka 토픽의 최신 오프셋과 컨슈머가 처리한 오프셋을 비교해 소비 지연을 파악한다.
• 스레숄드 불필요
  고정된 임계값 설정 없이 슬라이딩 윈도우 기반으로 컨슈머 상태를 평가한다.
• HTTP API 제공
  REST 엔드포인트로 그룹 상태, 오프셋 정보를 실시간으로 조회할 수 있다.
• 알림 연동 가능
  이메일/웹훅 등을 통해 상태 변화 알림을 보낼 수 있도록 구성할 수 있다.
• 멀티 클러스터 지원
  여러 Kafka 클러스터의 컨슈머를 동시에 모니터링할 수 있다.

13.6 종단 모니터링

컨슈머와 프로듀서 클라이언트는 지표를 갖고는 있지만 어떤 문제인지를 알려주지는 않는다. 지연 증가의 원인이 무엇인지, 클라이언트 탓인지, 네트워크 탓인지 등을 정확히 알 수 없다. 이를 판단하려면 모든 토픽에 대해 개별적으로 모니터링이 필요할 수 있다. 이렇게 하려면 모든 토픽에 관리용 트래픽을 밀어 넣어야하는데, 합리적이지 않다. 따라서 최소한 클러스터 안의 모든 브로커에 대해 관리용 트래픽을 밀어넣어서 메시지를 읽거나 쓸 수 있는지 여부를 확인할 수 있는데, 이 툴이 kafka Monitor이다. 클러스터의 모든 브로커에 걸쳐있는 토픽들에 대해서 계속해서 데이터를 쓰고 읽어서 브로커별 모니터링을 수행한다.

Kafka Monitor 핵심 기능 요갸

• Kafka 가용성 및 성능 모니터링
  지속적으로 테스트 메시지를 보내고 소비하여 Kafka의 가용성, 지연 시간, 메시지 손실 여부 등을 측정합니다.
• 엔드-투-엔드 지표 생성
  Produce/Consume 가능성, 오프셋 커밋 상태, E2E 지연, 메시지 손실률 등 운영에 중요한 지표를 도출합니다.
• 합성 트래픽 사용
  실제 애플리케이션 대신 합성(Synthetic) 워크로드를 만들어 테스트하므로 애플리케이션 변경 없이 Kafka 자체 상태를 점검할 수 있습니다.
• 멀티 클러스터 및 파이프라인 모니터링
  MirrorMaker 같은 구성도 모니터링 대상으로 설정해 클러스터 간 연동 상태도 확인할 수 있습니다.