캐시, 큐, 이벤트 파이프라인이 동시에 들어간 시스템에서는 고치는 것보다 먼저 “지금 어느 계층을 디버깅하고 있는가”를 알아내는 일이 더 어려울 때가 많습니다. Redis, RabbitMQ, Kafka가 한 서비스 안에 같이 있을수록 제품 이름보다 눈앞의 실패 패턴으로 들어가는 편이 훨씬 빠릅니다.
이 글은 이 블로그의 미들웨어 트러블슈팅 묶음으로 들어가기 위한 허브입니다. 지금 보이는 증상이 Redis 쪽인지, RabbitMQ 쪽인지, Kafka 쪽인지 먼저 가르고 가장 가까운 가이드로 들어가면 됩니다. 완벽한 진단이 아니라 가장 가능성이 높은 첫 분기만 잡아도 충분합니다.
제품 이름보다 증상부터 보세요
실전에서는 제품 이름보다 눈앞의 증상을 먼저 맵핑하는 편이 좋습니다.
먼저 이런 질문을 해보세요.
- key가 만료되지 않거나 memory가 이상하게 늘어나는가
- queue에 메시지가 쌓이는데 처리가 끝나지 않는가
- consumer가 stream을 따라가지 못하거나 아예 못 읽는가
이렇게 시작하면 Kafka를 디버깅하는 줄 알았는데 실제로는 RabbitMQ ack 흐름 문제인 경우나, RabbitMQ처럼 보였지만 Redis data shape 문제인 경우를 빨리 걸러낼 수 있습니다.
Redis부터 봐야 할 가능성이 큰 증상
아래처럼 보이면 Redis 쪽부터 들어가는 편이 맞습니다.
- key가 만료되지 않음
- memory usage가 예상보다 빠르게 증가
- 특정 key 주변에서 latency spike 발생
OOM command not allowed- cache나 state store에서 connection refused
여기서 시작하면 좋습니다.
Redis 이슈는 TTL drift, oversized key, 조용히 비싸진 data shape에서 시작하는 경우가 많습니다.
RabbitMQ부터 봐야 할 가능성이 큰 증상
아래처럼 보이면 RabbitMQ 쪽이 더 가깝습니다.
- 메시지가
unacked에 쌓임 - queue가 계속 커지는데 drain되지 않음
- publisher가 resource alarm 때문에 blocked됨
- consumer는 연결되어 있는데 delivery를 못 받음
여기서 시작하면 좋습니다.
- RabbitMQ Messages Stuck in unacked
- RabbitMQ Queue Keeps Growing
- RabbitMQ Connection Blocked
- RabbitMQ Consumers Not Receiving Messages
RabbitMQ 문제는 ready와 unacked를 나누고, producer pressure와 consumer delay를 분리하고, flow control과 실제 broker failure를 구분하는 순간 훨씬 선명해지는 경우가 많습니다.
Kafka부터 봐야 할 가능성이 큰 증상
아래처럼 보이면 Kafka 쪽이 맞을 가능성이 큽니다.
- consumer lag가 계속 증가
- 레코드는 생산되는데 소비되지 않음
- group이 불안정하거나 rebalance가 잦음
- producer retry가 이상하게 많아짐
- restart 이후에도 broker heat가 고르지 않음
여기서 시작하면 좋습니다.
- Kafka Consumer Lag Increasing
- Kafka Messages Not Consumed
- Kafka Rebalancing Too Often
- Kafka Producer Retries Too Much
Kafka 이슈는 겉으로는 broker 문제처럼 보여도 poll timing, partition assignment, rebalance churn, producer retry timing, uneven leadership에서 시작하는 경우가 많습니다.
빠르게 고르는 간단한 지도
헷갈릴 때는 아래 정도만 기억해도 충분합니다.
- key TTL, memory, eviction, one-key hotspot: Redis부터
- queue backlog, ack behavior, blocked publisher: RabbitMQ부터
- lag, offset confusion, poll loop, group instability, producer retries: Kafka부터
완벽한 진단이 먼저 필요하지는 않습니다. 가장 가능성이 높은 첫 갈래만 고르면 됩니다.
cross-system 혼란을 줄이는 질문 하나
사용자 눈에 보이는 장애가 왔다면 아래 중 무엇이 먼저 깨졌는지 물어보세요.
- state나 cache behavior가 먼저 흔들렸는가
- queued work가 먼저 drain되지 않았는가
- stream consumer가 먼저 advancing을 멈췄는가
이 질문 하나가 아키텍처 다이어그램보다 빠르게 올바른 시스템에 들어가게 해주는 경우가 많습니다.
왜 실제 시스템에서는 자꾸 헷갈릴까
현실의 아키텍처에서는 이런 계층들이 자주 같이 들어갑니다.
예를 들면:
- Redis는 cache이면서 동시에 lightweight buffer
- RabbitMQ는 burst traffic 흡수용
- Kafka는 durable event flow용이고 downstream consumer가 무거운 처리를 담당
그래서 제품 이름보다 증상 기준 트러블슈팅이 더 유용합니다. 한 서비스 안에 셋 다 있어도 눈에 보이는 실패 패턴은 가장 빠른 진입점을 알려줍니다.
FAQ
Q. Redis, RabbitMQ, Kafka를 각각 깊이 알아야 이 글이 도움이 되나요?
아니요. 이 글은 각 시스템을 깊이 알기 전에 가장 가까운 첫 트러블슈팅 글로 들어가게 도와주는 허브입니다.
Q. 문제가 여러 시스템에 걸쳐 보이면 어떻게 해야 하나요?
사용자에게 가장 가까운 증상부터 시작하고, 그다음 링크를 따라 인접 계층과 비교하면 됩니다.
Q. 이 글은 설치 가이드인가요?
아니요. 증상 기준으로 어디부터 디버깅할지 고르는 허브 글입니다.
Read Next
- 지금 문제를 cache나 state drift로 보고 있다면 Redis Memory Usage High를 보세요.
- 지금 문제를 message backlog로 보고 있다면 RabbitMQ Queue Keeps Growing를 보세요.
- 지금 문제를 stream delay나 consumer backlog로 보고 있다면 Kafka Consumer Lag Increasing를 보세요.
- Kafka 증상이 backlog보다 group churn에 가깝다면 Kafka Rebalancing Too Often를 보세요.
Related Posts
- Redis Memory Usage High
- RabbitMQ Queue Keeps Growing
- Kafka Consumer Lag Increasing
- Kafka Rebalancing Too Often
- Kafka Producer Retries Too Much
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.