1. 현상
진행 중인 프로젝트에서 메시지의 중복 처리를 막기 위해서 멱등적 프로듀서 및 transaction mode를 적용했다. 이럴 경우 2가지 현상이 나타난다.
- 브로커에 쓰는 메시지가 2개씩 생성됨
- 한 번도 메시지가 쌓이지 않았을 때는 consumer의 offset lag이 0이지만, 한 번 쌓이기 시작하면 offset lag이 1로 유지된다.
- 2번 현상 이후, AWS MSK에서 Estimated Max Time Lag은 30초 정도까지 계속 올랐다 내렸다를 반복한다.
이 중 1번 항목은 널리 알려진 사실이지만, 2번 항목은 offset lag이 올라가서 경고를 받을 수 있음에도 불구하고 잘 알려지지 않은 것 같다. AWS Cloud Watch나 Datadog과 같은 툴에서 offset lag의 경보 알림 설정을 1 이상으로 설정하느냐, 2 이상으로 설정하느냐하는 문제가 될 수 있는 것이기 때문이다. 물론 사용자가 아주 많은 서비스라서 consumer lag이 어느 정도 계속해서 유지되는 서비스일 경우엔 해당되지 않겠지만 consumer 사용량이 피크였다가 offset lag이 해소되었는데도 1로 계속해서 남아있고 툴에서도 경고가 온다면 관리자 입장에서는 무슨 문제가 있는 것으로 오해할 수도 있을 것 같다.
참고로 프로젝트에서 동료의 테스트 결과에서 AWS Cloud Watch에서의 Estimated Max Time Lag 값은 Lag이 1로 유지될 때 증가하는 것으로 확인되었다.
2. 이유 및 결론
이유도 딱히 없고, 결론은 그냥 무시하면 된다 정도로 정리된다. 카프카는 트랜잭션 모드를 유지하기 위해서 uncommitted 처리된 메시지를 브로커에 남겨두는 것 같은데, 트랜잭션 모드에서는 read_committed 옵션을 주어 consumer가 commit된 메시지만 읽어가도록 설정하므로 해당 메시지를 consumer가 읽을 수가 없어서 lag = 1 상태로 남아있게 되는 것이다.
아래 참고 문서들에서 해당 내용들을 확인할 수 있다.
https://github.com/spring-projects/spring-kafka/issues/1587
https://issues.apache.org/jira/browse/KAFKA-10683
apache 카프카에서도 굳이 중요하지 않은 이슈로 다루고 있는 것 같다. 다만 멱등적 프로듀서를 설정하고 사용하는 사람들을 위해 이렇게 될 수 있다는 가이드 문서나 레퍼런스들이 좀 많아졌으면 좋겠다.
원인을 조사하고 공유해주신 회사 동료 ljh님께 감사드린다. 더 많은 사람들이 이 내용을 알았으면 좋겠다. 혹시 틀린 내용이라면 댓글을 부탁드린다.
'Programming-[Backend] > Kafka' 카테고리의 다른 글
[카프카 핵심가이드] 3. 프로듀서 (2) | 2024.11.09 |
---|---|
[카프카 핵심 가이드] 1. 카프카 시작하기 (1) | 2024.11.07 |
카프카 멱등성(Idempotence) 설정, Retry 및 DLT 설정 시 유의사항 (2) | 2024.07.23 |
Consumer Lag 남아있는 것 제거하기(docker kafka container shell tool 활용) (0) | 2024.07.17 |
[TIL] 카프카 로그 압축 정보 local container에서 확인 방법(kafka-run-class, DumpLogSegments) (0) | 2024.06.24 |