미들웨어 트러블슈팅 가이드: Redis, RabbitMQ, Kafka 중 어디부터 볼까
Dev
마지막 업데이트

미들웨어 트러블슈팅 가이드: Redis, RabbitMQ, Kafka 중 어디부터 볼까

캐시, 큐, 이벤트 파이프라인이 함께 있는 시스템에서는 고치는 방법보다 먼저 “지금 어느 계층을 디버깅하고 있는가”를 아는 일이 더 중요할 때가 많습니다. Redis, RabbitMQ, Kafka가 한 서비스 안에 같이 있을수록 제품 이름보다 눈앞의 실패 패턴으로 들어가는 편이 훨씬 빠릅니다.

이 글은 이 블로그의 미들웨어 트러블슈팅 허브입니다. 아래 질문에 답하도록 구성했습니다.

  • 지금 보이는 장애가 Redis, RabbitMQ, Kafka 중 어디에 더 가까운지
  • 첫 10분 안에 무엇을 보면 다음 글을 빨리 고를 수 있는지
  • 서로 비슷해 보이는 미들웨어 장애를 어떻게 구분할지

프로덕션에서 “Kafka가 느려요”라는 보고가 왔는데, 실제로는 Kafka가 아니라 Redis connection pool이 고갈되어 consumer가 처리를 못 하고 있었던 적이 있습니다. 미들웨어 장애는 원인과 증상이 다른 컴포넌트에서 나타나는 경우가 특히 많습니다.

결론부터 말하면 미들웨어 장애는 “가장 먼저 깨진 사용자 체감 증상”을 기준으로 분기하는 편이 가장 빠릅니다.

이 허브가 필요한 순간

  • key가 만료되지 않거나 cache 상태가 이상하다
  • queue에는 메시지가 쌓이는데 처리가 끝나지 않는다
  • consumer lag가 계속 증가하거나 stream progress가 멈춘다
  • publisher는 살았는데 downstream 처리가 밀린다
  • 어떤 미들웨어부터 봐야 할지 팀 안에서도 의견이 갈린다

이 단계에서는 완벽한 진단보다 첫 분기 선택이 더 중요합니다.

첫 10분 체크

아래처럼 각 계층의 대표 신호를 아주 짧게 보는 것만으로도 다음 글을 고르기 쉬워집니다.

redis-cli INFO memory
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers
kafka-consumer-groups --bootstrap-server <broker:9092> --describe --group <group>

이 명령들의 목적은 해결이 아니라 라우팅입니다.

  • Redis에서 memory, eviction, key shape 신호가 먼저 튄다: Redis 축
  • RabbitMQ에서 ready 또는 unacked가 비정상적으로 쌓인다: RabbitMQ 축
  • Kafka에서 lag, partition 할당, group 상태가 먼저 흔들린다: Kafka 축

먼저 묻는 질문

1. 먼저 깨진 것이 상태인가, 대기열인가, 스트림 진행인가

cache나 state drift가 먼저면 Redis에 가깝고, queued work가 drain되지 않으면 RabbitMQ에 가깝고, 소비 진도가 멈췄다면 Kafka에 더 가깝습니다.

2. 증상이 저장 상태 문제인가, 전달 문제인가

Redis는 상태와 만료, 메모리, key shape 쪽이 강하고, RabbitMQ는 전달과 ack 흐름, Kafka는 소비 진도와 group 안정성 쪽이 강합니다.

3. 문제의 중심이 한 키 또는 한 큐인가, 소비 그룹 전체인가

one-key hotspot이나 TTL drift는 Redis에 가깝고, 특정 큐 backlog는 RabbitMQ에, 그룹 단위 lag 증가는 Kafka에 더 가깝습니다.

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 문제는 ready와 unacked를 나누고, producer pressure와 consumer delay를 분리하는 순간 훨씬 선명해지는 경우가 많습니다.

Kafka 축으로 들어가야 할 때

아래에 가깝다면 Kafka부터 보는 편이 좋습니다.

  • consumer lag가 계속 증가한다
  • 레코드는 생산되는데 소비되지 않는다
  • group이 불안정하거나 rebalance가 잦다
  • producer retry가 이상하게 많다
  • restart 이후에도 broker heat가 고르지 않다

여기서 시작하면 좋습니다.

Kafka 이슈는 broker 자체보다 poll timing, partition assignment, rebalance churn, producer retry timing에서 시작하는 경우도 많습니다.

자주 하는 오진

backlog만 보이고 있어서 무조건 Kafka라고 생각하는 경우

실제론 RabbitMQ queue drain 문제인데 “메시지가 밀린다”는 공통 증상만 보고 Kafka로 들어가는 경우가 많습니다.

stale state를 queue 문제로 오해하는 경우

사용자는 “최신 상태가 안 보인다”라고 말하지만, 실제로는 Redis TTL이나 캐시 invalidation이 먼저 흔들린 경우가 많습니다.

broker 지표만 보고 애플리케이션 소비 루프를 놓치는 경우

Kafka와 RabbitMQ 모두 broker health가 전부가 아닙니다. consumer 측 poll, ack, concurrency 모델이 실제 원인일 수 있습니다.

아주 빠른 분기표

  • 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 state store
  • RabbitMQ는 burst traffic 흡수용 queue
  • Kafka는 durable event flow와 downstream consumer 분리용 stream

그래서 제품 이름보다 증상 기준 트러블슈팅이 더 유용합니다. 한 서비스 안에 셋 다 있어도 눈에 보이는 실패 패턴은 가장 빠른 진입점을 알려줍니다.

FAQ

Q. Redis, RabbitMQ, Kafka를 각각 깊이 알아야 이 글이 도움이 되나요?

아니요. 이 글은 각 시스템을 깊이 알기 전에 가장 가까운 첫 트러블슈팅 글로 들어가게 도와주는 허브입니다.

Q. 문제가 여러 시스템에 걸쳐 보이면 어떻게 해야 하나요?

사용자에게 가장 가까운 증상부터 시작하고, 그다음 링크를 따라 인접 계층과 비교하면 됩니다.

Q. 이 글은 설치 가이드인가요?

아니요. 증상 기준으로 어디부터 디버깅할지 고르는 허브 글입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.

광고

관련 글

이 카테고리의 다른 글