[Kafka] 카프카 lag(랙) 간단한 설명 (Consumer Lag, Burrow)

[Kafka] 카프카 lag(랙) 간단한 설명 (Consumer Lag, Burrow)

 

 

카프카 lag(랙)이란?

 

프로듀서는 토픽 내의 파티션에 데이터를 차곡차곡 넣는 역할을 한다. 이 파티션에 데이터가 하나씩 들어갈 때마다 각 데이터에는 오프셋이라는 숫자가 붙게 된다.

 

컨슈머는 파티션의 데이터를 하나씩 읽어오는 역할을 한다. 컨슈머가 데이터를 어디까지 읽었는지 확인하기 위해 오프셋을 남겨둔다.

 

오프셋에 대한 설명은 아래 글을 참고하면 된다.

[Kafka] 카프카 기본 개념_1 (브로커, 프로듀서, 컨슈머, 메시지 + 주키퍼)

 

 

프로듀서가 데이터를 넣는 속도가 컨슈머가 가져가는 속도보다 빠른 경우, 이때 생기는 프로듀서가 넣은 데이터의 오프셋과 컨슈머가 가져간 데이터의 오프셋의 차이 또는 토픽의 가장 최신 오프셋과 컨슈머 오프셋의 차이를 kafka consumer lag이라 부른다.

 

 

프로듀서와 컨슈머의 오프셋은 파티션을 기준으로 한 값이므로, 토픽에 여러 파티션이 존재하는 경우라면 lag은 여러 개 존재할 수 있다. 만약 컨슈머 그룹이 1개이고 파티션이 2개인 토픽에서 데이터를 가져간다면 lag은 2개가 측정될 수 있다. 이렇게 여러 개 존재하는 lag 중에서 가장 높은 숫자를 갖는 lag을 records-lag-max라고 부른다.

 

 

 

카프카 lag(랙)을 활용한 모니터링

 

카프카 lag(랙)은 카프카를 운영함에 있어서 아주 중요한 모니터링 지표 중 하나이다. lag은 작을 수도 있고 클 수도 있다. 이 lag 숫자를 통해, 해당 토픽에 대한 파이프라인으로 연계되어 있는 프로듀서와 컨슈머의 상태에 대해 유추할 수 있다. 주로 컨슈머의 상태를 분석할 때 사용하므로, 컨슈머 랙(consumer lag)이라고 부르기도 한다.

 

 

일례로, lag이 상승하고 있다면 아래의 이슈 중 하나에 해당할 것이므로, 정확한 원인을 파악하여 이에 대응하기 위한 모니터링 작업이 필요하다.

1. consumer의 성능에 비해 producer가 순간적으로 많은 record를 보내는 이슈
2. consumer의 polling 빈도 수가 느려지는 이슈 (polling 이후 처리 속도로 인해)
3. Network 지연 이슈
4. Kafka broker 내부 이슈
5. 기타 이슈

 

 

 

Burrow를 활용한 카프카 lag 모니터링

카프카 랙을 모니터링 하는 것은 여러 모로 좋은 점이 많긴 하지만, 컨슈머 단위에서 lag을 모니터링 하는 것은 아주 위험하며 운영요소 또한 많이 들어간다. 컨슈머 로직단에서 lag을 수집하게 되면 컨슈머 상태에 dependency가 걸리기 때문이다. 컨슈머가 비정상적으로 종료되게 된다면 컨슈머는 더 이상 lag 정보를 보낼 수 없고, lag을 측정할 수 없게 된다. 또한 컨슈머가 새롭게 추가될 때마다 해당 컨슈머에 lag 정보를 특정 저장소에 저장할 수 있게 하는 로직을 새로 개발해야 한다. 만약 컨슈머 lag을 수집할 수 없는 컨슈머라면, lag을 모니터링 할 수 없으므로 운영이 매우 까다로워진다.

 

컨슈머 lag을 모니터링 하기 위해서는 카프카 외부 애플리케이션을 이용해야 한다. 가장 유명한 것은 Apache에서 제공하는 Burrow라는 오픈소스로, 카프카의 컨슈머 lag을 효과적으로 모니터링 할 수 있도록 도와주는 프로그램이다.

 

 

 

Burrow 특징

1. 멀티 카프카 클러스터 지원
   - 카프카를 이용한다면 대부분이 2개 이상의 카프카 클러스터를 운영할 것이다. 이 경우 burrow 애플리케이션 1개를 설치함으로써 여러 개의 카프카 클러스터를 모니터링 할 수 있다.
2. sliding window를 통한 consumer의 status 확인
   - burrow에서는 sliding window를 통한 consumer의 status를 ERROR, WARNING, OK로 알려주므로, 실제 컨슈머가 문제가 있는지를 확인할 수 있다.
   - ex)
   1. WARNING: 데이터양이 일시적으로 증가하여 consumer offset이 증가하고 있는 경우
   2. ERROR: 데이터양이 많아지고 있지만 consumer가 데이터를 가져가지 않고 있는 경우 실제로 consumer가 문제가 있음을 알 수 있다.
3. HTTP API 제공
   - 위와 같은 정보들은 burrow에서 정의한 http api를 통해 조회할 수 있다. 프로토콜 중에서 가장 범용적으로 사용하는 http 프로토콜을 제공함으로써 burrow는 다양한 추가 생태계를 구축할 수 있게 되었다. http api를 호출해서 response 받은 데이터를 시계열DB와 같은 곳에 저장하는 애플리케이션을 만들어서 활용할 수도 있다.

 

 

(출처: 유튜브 데브원영 DVWY)