데이터의 홍수 속에서 살아남기: 카프카 컨슈머 랙(Lag)과의 전쟁
안녕하세요, 15년 차 백엔드 개발자이자 기술 서적을 집필하며 여러분과 소통하는 멘토입니다. 오늘은 커피 한 잔의 여유를 즐기려다가 모니터링 알림 폭탄을 맞고 정신이 번쩍 들었던 경험, 아마 여러분도 한 번쯤 있으시죠? ☕ 특히 대용량 트래픽을 처리하는 시스템의 심장부, 아파치 카프카(Apache Kafka)를 다루다 보면 "컨슈머 랙(Consumer Lag)"이라는 녀석은 정말 피할 수 없는 숙명과도 같습니다. 단순히 처리량이 늦어지는 것을 넘어, 비즈니스의 손실로 이어지는 이 무시무시한 지표 앞에서 우리는 어떻게 대처해야 할까요?
저도 주니어 시절, 블랙 프라이데이 이벤트 때 카프카 랙이 기하급수적으로 늘어나는 걸 보고 등줄기에 식은땀이 흘렀던 기억이 생생합니다. 당시 초당 3,000건이던 주문이 50,000건으로 폭증하면서 랙이 수백만 건까지 쌓였고, "서버를 늘리면 해결되겠지?"라고 단순하게 생각했다가, 파티션 개념을 제대로 이해하지 못해 3일을 밤새우며 고생했던 뼈아픈 실패담이 있습니다. 오늘은 그 시절의 저처럼 고군분투하고 계실 여러분을 위해, 단순한 이론이 아닌 현장에서 피와 땀으로 얻은 컨슈머 랙 분석 및 파티션 확장 튜닝 가이드를 아주 깊이 있게 풀어보려 합니다.
이 글을 다 읽으실 때쯤이면, 여러분은 단순히 "랙이 걸렸다"라고 당황하는 개발자가 아니라, "아, 이 패턴이면 파티션을 2배로 늘리고 fetch 사이즈를 조정하면 약 40%의 성능 향상이 있겠군"이라고 판단하는 시니어 아키텍트의 시야를 갖게 되실 겁니다. 자, 그럼 데이터의 파도 속으로 함께 들어가 볼까요? 🌊
1. 컨슈머 랙(Lag), 도대체 너는 누구냐? (심층 분석)
우리가 흔히 말하는 '랙(Lag)'은 사전적 의미로 지연을 뜻합니다. 하지만 카프카에서 랙은 시스템의 건강 상태를 나타내는 가장 정직하고 무자비한 지표입니다. 기술적으로 정의하자면, 프로듀서(Producer)가 보낸 메시지의 최신 오프셋(Log End Offset)과 컨슈머(Consumer)가 처리를 완료하고 커밋한 오프셋(Current Offset) 사이의 차이를 말합니다. 이는 곧 '처리되지 못하고 대기 중인 메시지의 개수'를 의미합니다.
💡 핵심 공식:
Consumer Lag = Log End Offset (프로듀서가 쓴 마지막 위치) - Current Offset (컨슈머가 읽은 마지막 위치)
이 숫자가 0이라면, 프로듀서가 데이터를 넣자마자 컨슈머가 실시간으로 처리하고 있다는 뜻입니다. 이상적이죠. 하지만 현실 세계에서 랙이 0인 경우는 거의 없습니다. 네트워크 지연(Latency), 가비지 컬렉션(GC), DB 쓰기 지연 등 수만 가지 이유로 미세한 랙은 항상 존재합니다. 문제는 이 랙이 '허용 가능한 수준'을 넘어서서 '지속적으로 증가'할 때 발생합니다. 마치 카드값과 같습니다. 조금 쌓이는 건 갚으면 되지만, 버는 돈(처리량)보다 쓰는 돈(유입량)이 많아지면 결국 파산(장애)에 이르게 되니까요.
랙이 증가하는 근본적인 메커니즘 2가지
랙이 증가하는 상황은 크게 두 가지 시나리오로 나뉩니다. 첫째, 프로듀서의 데이터 유입 속도가 갑자기 폭증하는 경우(Burst Traffic)입니다. 예를 들어, 선착순 이벤트가 시작되어 초당 100건 들어오던 주문이 초당 10,000건으로 100배 늘어난다면, 기존 컨슈머가 아무리 열심히 일해도 랙은 쌓일 수밖에 없습니다. 이는 보통 '일시적인 랙'일 가능성이 높고, 이벤트가 끝나면 해소될 수 있습니다. 하지만 이 랙이 해소되는 데 걸리는 시간이 비즈니스 허용 범위를 넘는다면 문제가 됩니다.
둘째, 컨슈머의 처리 속도가 저하되는 경우(Consumer Slowdown)입니다. 이게 훨씬 더 무섭고 빈번합니다. 데이터 유입량은 평소와 같은데, 컨슈머 로직 내부에서 외부 API를 호출하다가 타임아웃이 발생하거나, DB에 데드락(Deadlock)이 걸려 처리가 늦어지는 상황입니다. 제 경험상, 전체 장애의 70% 이상은 이 두 번째 케이스에서 발생했습니다. "어제까진 잘 돌았는데 왜 이러지?" 싶을 때, 대부분 컨슈머가 의존하는 하위 시스템(DB, Redis, 외부 API)에 병목이 생긴 경우가 많았습니다.
실제 사례를 들어보겠습니다. A사에서 결제 처리 시스템을 운영할 때였습니다. 평소 랙이 100건 미만으로 유지되다가 갑자기 50,000건까지 치솟았습니다. 프로듀서 유입량은 정상이었죠. 원인을 파헤쳐보니 컨슈머가 결제 완료 문자를 발송하는 외부 SMS 서비스의 응답 속도가 평소 0.1초에서 3초로 느려진 것이었습니다. 단일 스레드로 동작하던 컨슈머가 응답을 기다리느라 멈춰있는 동안, 뒤따라오는 수만 건의 결제 요청이 카프카에 쌓여버린 것이죠. 이처럼 랙은 단순한 숫자가 아니라, 시스템 전체의 병목 구간을 알려주는 가장 확실한 '경고등'입니다.
2. 파티션(Partition)과 컨슈머의 관계: 병렬 처리의 핵심
카프카 성능 튜닝의 알파이자 오메가는 바로 '파티션(Partition)'입니다. 많은 분들이 이 부분을 헷갈려하십니다. 카프카의 토픽(Topic)은 하나의 거대한 큐가 아니라, 여러 개의 파티션으로 쪼개져 있습니다. 그리고 가장 중요한 규칙이 하나 있습니다. "하나의 파티션은 동일한 컨슈머 그룹 내의 오직 하나의 컨슈머와만 연결된다"는 것입니다. 이를 1:1 매핑 원칙이라고 부르기도 합니다.
이것이 왜 중요할까요? 바로 '병렬 처리의 한계(Parallelism Limit)'를 결정하기 때문입니다. 만약 여러분의 토픽이 파티션 3개로 구성되어 있다고 가정해 봅시다. 그런데 랙이 쌓여서 컨슈머 서버를 10대로 늘렸습니다(Scale-out). 결과는 어떨까요? 놀랍게도 3대의 컨슈머만 일을 하고, 나머지 7대는 '유휴 상태(Idle)'로 놀게 됩니다. 파티션 개수보다 많은 컨슈머는 할당받을 파티션이 없어서 무용지물이 되기 때문입니다. 이것 때문에 서버 비용만 날리고 성능은 그대로인 경우를 정말 많이 봤습니다.
파티션 확장이 필요한 순간 판단하기
그렇다면 언제 파티션을 늘려야 할까요? 단순히 랙이 생긴다고 무작정 늘리는 것은 위험합니다. 파티션은 한 번 늘리면 다시 줄일 수 없기 때문입니다. (기술적으로 불가능에 가깝습니다). 따라서 신중한 판단이 필요합니다. 저는 다음과 같은 기준을 사용합니다.
- 첫째, 단일 컨슈머의 튜닝 한계 도달 시: 로직 최적화, 배치 사이즈 조정 등을 다 해봤는데도 물리적인 한계(CPU, Memory, Network I/O)에 부딪혔다면, 이제는 도로(파티션)를 넓혀서 차선(병렬성)을 확보해야 할 때입니다.
- 둘째, 트래픽의 베이스라인 상승 시: 일시적인 스파이크가 아니라, 비즈니스 성장으로 인해 평균 트래픽 자체가 올라갔다면, 미래를 위해 파티션을 선제적으로 확장해야 합니다. 예를 들어, 월간 사용자(MAU)가 2배로 늘었다면, 기존 파티션 수로는 감당하기 어려울 수 있습니다.
실제 프로젝트에서 B사의 로그 수집 시스템을 개선할 때였습니다. 초당
댓글
댓글 쓰기