[ 이슈 사항 ]
- 카프카의 특정 레코드가 많이 쌓이는 특정 토픽에 대해서 레코드가 제대로 처리되지 못하고 적체됨.
- Consumer Group LAG(미처리 토픽 레코드 개수) 숫자가 지속적으로 증가함
- 해당 증상은 Consumer 애플리케이션을 구동 시 바로 발생하지 않고 시간이 지나고 어떤 특정 시점부터 LAG가 쌓이는 증상이 발생함.
[ 증상 ]
- 카프카 컨슈머 그룹이 지속적으로 리밸런싱 되면서 해당 토픽과 관련된 컨슈머가 레코드를 처리하지 못함.
[ 원인 분석 ]
1. Thread Dump 분석
1004lucifer
- 쿠버네티스 컨테이너 안에 Java Thread Dump (jstack) 생성툴이 없어서 'kill -3 pid' 명령어를 이용해 덤프를 생성하려 했으나 Log4J가 아닌 Java Output 으로 생성되는 로그가 어디에 출력되는지 알 수 없어 Thread Dump 로그 추출 실패
- 와탭 모니터링 툴이 설치 되어있다고 전달받아 해당 웹페이지 접속하여 순간의 Thread를 모니터링 함
- 대부분의 쓰레드가 아래의 두가지 상태를 유지함.
1. AbstractCoordinator$HeartbeatThread.run(AbstractCoordinator.java:1397)
2. AbstractCoordinator$HeartbeatThread.run(AbstractCoordinator.java:1354)
2. Kafka - Jar 소스 디컴파일 및 분석
1) AbstractCoordinator.java:1397
- "하트비트가 실패하거나 코디네이터의 연결이 끊긴 경우 재시도 백오프를 기다린 후 다시 폴링" 내용과 Thread wait 수행 시 대기 시간을 주어 TIMED_WAITING 상태로 만드므로 특별히 문제가 없어보임.
2) AbstractCoordinator.java:1354
- 대기시간 없는 Thread wait 가 수행됨.
- 예상하는 것으로는 컨슈머 리밸런싱이 완료 되었을 때 notifyAll 로 깨우지 않을까 생각함.
- 그렇게되면 해당 Thread(컨슈머)는 리밸런싱이 완료 되기 전까지 동작하지 않을 것으로 예상됨.
1004lucifer
3) 2번의 enabled를 false로 작업하는 곳 확인
- 백그라운드로 수행되는 하트비트 쓰레드가 비활성화 된경우로 보여짐.
3. 다시 Thread Dump 확인
1) 위와 같은 코드인경우 컨슈머 쓰레드들이 점차 (메뉴)2-1 => 2-2 상황의 쓰레드로 변할 것으로 예상함.
2) 와탭에서 (메뉴)2-1 과 같은 쓰레드의 상태를 갱신 시 모두 (메뉴)2-2 상황으로 변함 (서버에서는 컨슈머 리밸런싱 상태)
4. 리밸런싱 조건 확인 및 조치 가능한 사항 확인
- 리밸런싱 조건 (아래의 기준을 봤을 때 2번의 상황이 의심됨)
- 'max.poll.records' 의 기본값음 500이라고 함.
- 위 값이 기본값인경우 하나의 컨슈머에서 최대 500개까지의 레코드를 수행완료 후 카프카에 오프셋 업데이트를 수행하는데 그전에 poll interval 시간이 되어 리밸런식을 할 수 있다는 가능성이 있다고 생각함.
5. 서버 리밸런싱 모니터링
1004lucifer
1) 서버에서 watch 명령어로 컨슈머 그룹 상태를 지속적으로 확인
- watch './kafka-consumer-groups.sh --bootstrap-server 카프카서버 --describe --group 토픽명'
2) 리밸런싱 상태에서 중간중간 컨슈머가 붙음. 그리고 LAG 개수가 적은 것은 한두번 업데이트 되다가 다시 리밸런싱 상태로 돌아감.
- LAG 개수가 많은것은 개수가 줄지 않고 개수가 적은것만 줄어듬
[ 원인분석 결과 및 조치사항 ]
- 위의 증상을 확인 시 카프카의 max.poll.records, max.poll.interval.ms 설정의 조정으로 이슈가 해결될 수 있지 않을까 예상이 된다.
- 아래와 같은 내용이 있는 것으로 보아 max.poll.records 옵션만 줄이더라도 성능에 이슈가 해결될 수 있을것 같음 (값을 1로 변경해 보는것을 권장하는 글도 있음)
위 분석결과에 따라 max.poll.records 의 설정값을 1로 변경 후 더이상 리밸런싱 이슈가 발생하지 않음
(다만 서버 배포의 경우 컨테이너가 교체가 되면서 그때는 리밸런싱이 발생함)
PS.
이후에 시간이 좀 지나고 LAG가 적체되는 증상이 발생했었는데 증상 및 조치사항은 다음과 같았다.
- 리밸런싱을 발생하지 않고있음
- Consumer 애플리케이션 1건 처리속도가 40~60초 정도로 퍼포먼스가 너무 떨어짐
(평소 1건 처리속도 0.1~0.3초 정도 걸림)
- DB 확인 시 insert / update 하는 주 테이블이 Lock이 걸려서 발생한 이슈였음.
(DB Lock이 풀리고 LAG는 다시 줄어들어 정상화 됨)
- DB Lock을 최소화 하기 위해 이후 추가 조치를 수행함.
참고 URL
- https://techblog.gccompany.co.kr/카프카-컨슈머-그룹-리밸런싱-kafka-consumer-group-rebalancing-5d3e3b916c9e
- https://huisam.tistory.com/entry/kafka-consumer?category=849126
댓글
댓글 쓰기