Redis Queue와 Kafka Queue는 장애를 어떻게 다르게 전파할까

같은 문제인데 전혀 다른 결과가 나타나는 이유

Redis Queue와 Kafka Queue는 장애를 어떻게 다르게 전파할까

예를 들어 Consumer 처리 속도가 갑자기 절반으로 감소했다고 가정해보겠습니다.

Producer는 초당 10,000개의 이벤트를 계속 생성합니다.

하지만 Consumer는 초당 5,000개밖에 처리하지 못합니다.

이 상황에서 Redis와 Kafka는 전혀 다르게 반응합니다.

Redis는 즉시 영향을 받기 시작합니다.

반면 Kafka는 처음에는 정상처럼 보입니다.

장애를 받아들이는 방식 자체가 다르기 때문입니다.

Redis는 장애를 즉시 드러낸다

Redis Queue는 기본적으로 메모리 기반입니다.

메시지가 들어오고 빠르게 소비되는 것을 전제로 설계되었습니다.

Consumer 처리 속도가 느려지기 시작하면 큐 길이가 빠르게 증가합니다.

메모리 사용량도 함께 증가합니다.

운영자는 비교적 빠르게 이상 징후를 발견할 수 있습니다.

다음과 같은 현상이 나타납니다.

• Queue Length 증가
• Memory Usage 증가
• Consumer 처리 지연
• 응답 속도 저하
• 메시지 유실 가능성 증가

특히 Pub/Sub 구조에서는 Consumer가 연결되어 있지 않으면 메시지를 받지 못합니다.

즉, 장애가 발생하면 문제가 즉시 노출됩니다.

좋게 말하면 빠르게 발견됩니다.

나쁘게 말하면 완충 장치가 부족합니다.

Kafka는 장애를 숨기면서 누적시킨다

Kafka는 접근 방식이 다릅니다.

메시지를 메모리가 아니라 디스크에 저장합니다.

Consumer가 느려져도 Producer는 계속 데이터를 전송할 수 있습니다.

처음에는 아무 문제도 없어 보입니다.

서비스 응답도 정상입니다.

Producer도 정상입니다.

Broker도 정상입니다.

하지만 내부에서는 Consumer Lag가 계속 쌓이고 있습니다.

예를 들어 초당 5,000개의 메시지가 계속 밀린다면,

1분 후에는 30만 건

10분 후에는 300만 건

1시간 후에는 1,800만 건이 대기 상태가 됩니다.

운영자가 Lag를 모니터링하지 않는다면 장애를 늦게 발견할 수 있습니다.

Kafka는 장애를 즉시 보여주지 않습니다.

대신 장애를 저장합니다.

Redis에서는 메모리가 먼저 터진다

실제 Redis 운영 환경에서 가장 자주 보는 문제는 메모리 압박입니다.

Consumer 장애가 길어지면 Queue 데이터가 계속 증가합니다.

메모리 사용량도 함께 증가합니다.

결국 다음 중 하나가 발생합니다.

• Eviction 발생
• Redis 응답 지연
• OOM 발생
• Redis 재시작

문제는 이 시점부터 시스템 전체가 영향을 받는다는 점입니다.

Redis를 캐시로도 사용하고 있었다면 Queue 문제가 캐시 장애로까지 확산될 수 있습니다.

Kafka에서는 Lag가 시스템 전체로 번진다

Kafka는 메모리가 아니라 Lag가 문제입니다.

Consumer가 밀리기 시작하면 다운스트림 서비스도 영향을 받습니다.

예를 들어 주문 처리 시스템을 생각해보겠습니다.

주문 이벤트는 정상적으로 들어옵니다.

Kafka에도 저장됩니다.

하지만 Consumer가 느려집니다.

결제 완료 이벤트가 늦게 처리됩니다.

재고 업데이트도 늦어집니다.

알림 발송도 늦어집니다.

사용자는 주문을 했지만 결과를 받지 못합니다.

장애가 아니라 지연처럼 보입니다.

그래서 더 위험합니다.

Backpressure는 다르게 전파된다

Redis와 Kafka의 가장 큰 차이는 Backpressure 전달 방식입니다.

Redis는 비교적 직접적입니다.

Queue가 가득 차기 시작하면 Producer가 영향을 받습니다.

메모리가 부족해지고 처리 속도가 떨어집니다.

결국 생산자도 느려집니다.

Kafka는 조금 다릅니다.

Producer와 Consumer가 강하게 분리되어 있습니다.

Consumer가 아무리 느려져도 Producer는 계속 이벤트를 발행할 수 있습니다.

따라서 Backpressure가 즉시 전파되지 않습니다.

대신 Lag 형태로 축적됩니다.

운영자는 이를 “보이지 않는 부채”라고 부르기도 합니다.

실제 운영에서 중요하게 보는 지표

Redis 환경에서는 다음 지표를 가장 먼저 확인합니다.

• Queue Length
• Memory Usage
• Consumer Throughput
• Eviction Count
• Command Latency

Kafka 환경에서는 다음 지표가 훨씬 중요합니다.

• Consumer Lag
• Consumer Throughput
• Partition Lag
• Rebalance Count
• Processing Latency

특히 Kafka에서는 CPU보다 Lag를 먼저 보는 경우가 많습니다.

CPU는 정상인데 Lag만 증가하는 상황이 매우 흔하기 때문입니다.

흔한 오해

오해 1. Kafka는 장애에 강하다

부분적으로만 맞습니다.

Kafka는 데이터를 잃지 않는 데 강합니다.

하지만 Consumer Lag가 무한정 증가하는 문제는 여전히 존재합니다.

오해 2. Redis는 대규모 시스템에 적합하지 않다

그렇지 않습니다.

실시간성이 중요한 시스템에서는 Redis가 Kafka보다 훨씬 적합한 경우도 많습니다.

문제는 규모가 아니라 요구사항입니다.

오해 3. Kafka를 도입하면 Queue 문제는 해결된다

Kafka는 Queue 문제를 없애지 않습니다.

문제를 다른 형태로 바꿉니다.

메모리 문제를 Lag 문제로 전환할 뿐입니다.

어떤 상황에서 어떤 선택이 유리할까

실시간 알림

채팅

세션 관리

초저지연 처리가 중요하다면 Redis가 유리합니다.

반대로 다음과 같은 경우에는 Kafka가 강력합니다.

• 이벤트 저장
• 로그 수집
• 데이터 파이프라인
• 이벤트 소싱
• 대규모 비동기 처리

특히 메시지 재처리가 필요한 환경이라면 Kafka가 사실상 표준에 가깝습니다.

마무리

Redis와 Kafka는 모두 훌륭한 큐 시스템입니다.

하지만 장애가 발생했을 때 문제를 전파하는 방식은 완전히 다릅니다.

Redis는 문제를 빠르게 드러냅니다.

Kafka는 문제를 저장하고 누적시킵니다.

Redis에서는 메모리를 주의 깊게 봐야 하고, Kafka에서는 Lag를 가장 먼저 확인해야 합니다.

실제 운영 환경에서 중요한 것은 어떤 기술이 더 우수한가가 아닙니다.

장애가 발생했을 때 어떤 형태로 나타나고, 어떤 방식으로 전파되는지를 이해하는 것입니다.

그 차이를 이해하는 순간 Queue는 단순한 데이터 전달 도구가 아니라 시스템 안정성을 설계하는 핵심 구성 요소가 됩니다.