아파치 카프카(Apache Kafka) 컨슈머 랙(Lag)이 계속 증가할 때: 파티션 확장과 컨슈머 그룹 재조정으로 데이터 처리 지연을 해결하는 튜닝 가이드
반갑습니다, 여러분. 15년 차 백엔드 엔지니어이자, 오늘도 수많은 데이터 파이프라인과 치열하게 씨름하고 있는 여러분의 동료입니다. 아마 이 글을 검색해서 들어오신 분이라면, 지금 당장 그라파나(Grafana)나 데이터독(Datadog) 같은 모니터링 대시보드에서 붉게 치솟는 'Consumer Lag' 그래프를 보며 식은땀을 흘리고 계실지도 모르겠네요. "분명 컨슈머 서버를 두 배로 늘렸는데 왜 처리 속도가 그대로지?", "왜 리밸런싱만 일어나면 전체 시스템이 멈추는 거야?"라는 답답한 의문을 품고 계신가요? 저도 정확히 그 자리에 있어 봤습니다. 처음 대규모 트래픽을 처리하는 이커머스 결제 시스템에 카프카를 도입했을 때, 블랙 프라이데이 이벤트 시작 10분 만에 랙이 300만 건까지 치솟아 3일 밤낮을 사무실에서 지새웠던 악몽 같은 기억이 납니다. 그때 마신 카페인만 아마 치사량에 가까웠을 겁니다. ☕
카프카는 현대 분산 시스템의 심장이지만, 그만큼 '제대로' 튜닝해서 쓰기는 정말 쉽지 않습니다. 단순히 서버를 늘린다고(Scale-out) 해결되는 선형적인 문제가 아니기 때문입니다. 오늘은 제 15년의 경험과 수많은 장애 보고서(Post-mortem)를 갈아 넣어, 컨슈머 랙을 잡기 위한 파티션 확장 전략과 컨슈머 그룹 튜닝의 정수를 이야기해보려 합니다. 교과서적인 이론만 나열하는 건 사양하겠습니다. 실전에서 즉시 적용하여 효과를 볼 수 있는, 피와 땀이 섞인 노하우를 아주 깊이 있게 풀어보겠습니다. 자, 이제 모니터링 알람을 잠시 끄고(아니, 해결하고 꺼야겠죠?), 깊이 있는 튜닝의 세계로 들어가 봅시다.
1. 도대체 'Consumer Lag'은 왜 발생하는가? (심층 원인 분석)
적을 알고 나를 알아야 백전백승입니다. 컨슈머 랙(Lag)이란 정확히 무엇일까요? 아주 직관적으로 비유하자면, '설거지감'입니다. 프로듀서(Producer)가 식사를 마치고 싱크대(Topic Partition)에 그릇을 계속 쌓아둡니다. 컨슈머(Consumer)는 고무장갑을 끼고 열심히 설거지를 하는 사람이죠. 랙(Lag)은 싱크대에 쌓여있는, 아직 씻지 못한 그릇의 개수입니다. 이 개수가 줄어들지 않고 계속 늘어난다면? 결국 싱크대는 넘치고 주방은 물바다가 될 것입니다. 이것이 바로 서비스 지연이자 장애입니다.
많은 엔지니어들이 랙이 증가하면 무작정 "컨슈머 서버를 더 띄워!"라고 외칩니다. 하지만 이는 반은 맞고 반은 틀린 말입니다. 제가 겪었던 A사의 사례를 구체적으로 들려드리죠. A사는 초당 5,000건(TPS)의 주문 데이터가 들어오는 시스템을 운영 중이었습니다. 랙이 발생하자 운영팀은 컨슈머 인스턴스를 3개에서 10개로 급격히 늘렸습니다. 결과는 어땠을까요? 놀랍게도 처리 속도는 단 1%도 빨라지지 않았습니다. 오히려 컨슈머 간의 연결 비용으로 리소스 낭비만 심해졌죠. 왜 그랬을까요? 바로 '파티션(Partition)의 개수'라는 물리적 한계를 간과했기 때문입니다.
카프카의 가장 중요한 대원칙 중 하나는 "하나의 파티션은 컨슈머 그룹 내의 단 하나의 컨슈머만 연결된다"는 것입니다. 이 원칙을 이해하지 못하면 어떤 튜닝도 무용지물입니다. 파티션이 3개인데 컨슈머를 100개로 늘려봤자, 실제로 일하는 컨슈머는 3개뿐이고 나머지 97개는 '유휴 상태(Idle)'로 놀고 있게 됩니다. 마치 고속도로 톨게이트는 3개뿐인데 요금 수납원을 100명 고용한 것과 같습니다. 97명은 부스에 들어가지도 못하고 뒤에서 구경만 하고 있는 꼴이죠. 따라서 확장을 위해서는 반드시 파티션 수와 컨슈머 수를 함께 고려해야 합니다.
또한, 랙이 발생하는 원인은 단순히 파티션 부족만이 아닙니다. 컨슈머 내부의 비즈니스 로직 처리 속도가 느려서일 수도 있습니다. 데이터를 가져와서(poll) DB에 저장하는데 인덱스가 없어 쿼리가 2초씩 걸린다면? 외부 결제 API를 호출하는데 타임아웃이 빈번하게 발생한다면? 이는 카프카 자체의 문제라기보다는 컨슈머 애플리케이션의 성능 병목일 확률이 90% 이상입니다. 따라서 랙을 줄이기 위해서는 '카프카 설정(Configuration) 튜닝'과 '애플리케이션 코드 최적화'가 동시에 이루어져야 합니다. 한쪽만 봐서는 절대 근본적인 해결이 되지 않습니다.
제 경험상, 랙이 폭발적으로 증가하는 시나리오는 크게 세 가지 패턴이 있습니다. 첫째, 프로듀서의 데이터 유입량이 이벤트나 마케팅으로 인해 갑자기 10배 이상 폭증할 때입니다. 둘째, 컨슈머 로직에 변경이 배포되었는데, 처리 시간이 건당 10ms에서 50ms로 미세하게 늘어났을 때입니다(이게 쌓이면 눈덩이처럼 불어납니다). 셋째, 컨슈머 그룹의 리밸런싱(Rebalancing)이 빈번하게 발생하여 컨슈머들이 일을 멈추는(Stop-the-world) 시간이 길어질 때입니다. 특히 세 번째, 리밸런싱 이슈는 많은 개발자들이 놓치는 '숨겨진 암살자'와 같습니다.
📊 랙 발생 원인과 증상 상세 비교
| 원인 | 증상 | 주요 로그 및 지표 확인 | 해결 난이도 | 핵심 해결 방향 |
|---|
| 파티션 부족 | 컨슈머를 증설해도 처리량(Throughput) 변화 없음 | Consumer Count > Partition Count 상태 지속 | ★★☆☆☆ | 파티션 개수 확장 후 컨슈머 추가 투입 |
| 컨슈머 로직 병목 | CPU/Memory 사용량은 낮은데 처리가 느림, DB 부하 | DB Connection Pool Full, API Timeout Exception | ★★★★☆ | 로직 최적화, 비동기(Async) 처리, 배치 사이즈 조절 |
| 잦은 리밸런싱 | 처리량이 톱니바퀴처럼 들쑥날쑥하며 멈춤 현상 발생 | RebalanceInProgress, JoinGroup, SyncGroup 로그 다수 | ★★★★★ | session.timeout.ms 증가, max.poll.interval.ms 조정 |
| GC(Garbage Collection) | 특정 시간마다 모든 처리가 멈춤 (Stop-the-world) | JVM Full GC 로그 발생, Heap Memory 사용량 급증 | ★★★☆☆ | JVM Heap 메모리 증설, G1GC 적용, 객체 생성 최소화 |
2. 파티션 확장: 무조건 늘리는 게 답일까? (전략적 확장 가이드)
파티션 확장은 카프카 튜닝의 가장 기본이면서도 가장 강력한 무기입니다. 병렬 처리량을 늘리는 유일한 방법이기 때문이죠. 하지만 이 무기는 매우 날카로운 양날의 검입니다. 가장 중요한 사실은, 한번 늘린 파티션은 절대 다시 줄일 수 없습니다. (기술적으로 불가능한 건 아니지만, 토픽을 새로 생성해서 데이터를 마이그레이션 해야 하므로 운영 중인 라이브 서비스에서는 불가능에 가깝습니다.) 그래서 파티션 확장은 신중, 또 신중해야 합니다. "일단 100개로 늘리고 보자!"라고 했다가 나중에 리소스 관리 비용 때문에 땅을 치고 후회하는 경우를 너무 많이 봤습니다.
그렇다면 적절한 파티션 개수는 어떻게 산정해야 할까요? 저는 다음과 같은 공식을 실전에서 사용하여 산정합니다. 목표 파티션 수 = 목표 처리량(Target Throughput) / 단일 컨슈머의 처리량(Single Consumer Throughput). 예를 들어보겠습니다. 여러분의 시스템에 피크 타임 기준 초당 10,000건의 메시지가 들어옵니다. 성능 테스트 결과, 컨슈머 하나가 1초에 안정적으로 처리할 수 있는 메시지가 1,000건이라고 가정해봅시다. 그렇다면 이론적으로 최소 10개의 파티션과 10개의 컨슈머가 필요합니다. 하지만 이건 이상적인 수치이고, 실제로는 장애 상황이나 네트워크 지연을 대비해 1.5배에서 2배 정도의 여유를 두는 것이 좋습니다. 즉, 15~20개 정도가 적당하겠죠.
여기서 정말 중요한 실전 팁이 있습니다. 파티션을 늘릴 때 '메시지 순서 보장(Ordering)' 문제를 반드시 고려해야 합니다. 카프카는 파티션 내부에서는 순서를 보장하지만, 파티션 간에는 순서를 보장하지 않습니다. 만약 여러분이 메시지 키(Key)를 사용하여 특정 사용자(User ID)의 데이터를 특정 파티션으로 보내고 있었다면, 파티션을 늘리는 순간 해시(Hash) 알고리즘의 결과가 달라져서 같은 사용자의 데이터가 다른 파티션으로 가게 될 수 있습니다. 이는 '주문 생성'보다 '주문 취소'가 먼저 처리되는 끔찍한 데이터 정합성 오류를 초래할 수 있습니다.
실제로 B 금융사 프로젝트를 할 때였습니다. 거래 내역을 처리하는 토픽의 파티션을 운영 중에 30개에서
댓글
댓글 쓰기