DevOps 지식 허브
DevOps 지식 허브

Redis를 메시지 브로커로 언제 사용해야 할까요?

Redis의 두 가지 주요 기능인 Pub/Sub과 Streams를 활용하여 Redis를 메시지 브로커로 사용하는 이상적인 시나리오를 알아보세요. 이 종합 가이드에서는 Redis 메시징의 성능 이점, 낮은 지연 시간, 그리고 인프라 측면의 이점을 자세히 다룹니다. 일시적인(ephemeral) Pub/Sub과 영구적인(durable) Streams의 결정적인 차이를 배우고, Kafka와 같은 전용 브로커와 비교했을 때의 한계를 파악하며, 간단한 캐시 무효화부터 견고하고 경량의 태스크 큐에 이르는 실용적인 사용 사례들을 통해 비동기 통신 요구 사항에 적합한 도구를 선택하는 데 필요한 정보를 얻을 수 있습니다.

49 조회수

Redis를 메시지 브로커로 사용해야 하는 시점은?

Redis는 초고속 인메모리 데이터 저장소로 유명하며, 주로 캐싱 및 세션 관리에 사용됩니다. 하지만 Redis의 다재다능한 데이터 구조는 단순한 키-값 저장소를 훨씬 뛰어넘는 활용성을 제공합니다. Redis는 경량 메시지 브로커 역할을 효과적으로 수행할 수 있는 강력한 기본 요소, 즉 Redis Pub/Sub과 Redis Streams를 제공합니다.

Redis가 메시징 요구 사항에 적합한 선택인지 결정하려면 장단점을 이해해야 합니다. RabbitMQ 또는 Apache Kafka와 같은 전용 메시지 브로커는 강력한 보장, 복잡한 라우팅 및 뛰어난 내구성을 제공하는 반면, Redis는 비할 데 없는 단순성, 속도 및 낮은 지연 시간을 제공합니다. 이는 기존 인프라에 의존하는 것이 유리한 특정 고성능 사용 사례에 이상적입니다. 본 기사에서는 Redis 메시징의 메커니즘을 탐구하고, Redis가 탁월한 시나리오와 다른 대안을 찾아봐야 할 시나리오를 정의하는 데 도움을 줄 것입니다.

Redis 메시징 기본 요소 이해하기

Redis는 비동기 메시징을 위한 두 가지 개별 기능을 제공하며, 각 기능은 서로 다른 수준의 안정성과 복잡성에 적합합니다.

1. Redis Pub/Sub (발행/구독)

Redis Pub/Sub은 Redis가 제공하는 가장 단순한 형태의 메시징입니다. 이는 발행자가 채널에 메시지를 보내고 해당 채널을 구독하는 구독자가 메시지를 수신하는 '발사 후 망각(fire-and-forget)' 모델로 작동합니다.

메커니즘 및 특징:

  • 일시적 (Ephemeral): 메시지는 절대로 영구적으로 저장되지 않습니다. 구독자의 연결이 끊기거나 처리 속도가 느리면 그 시간 동안 발행된 모든 메시지를 놓치게 됩니다.
  • 무 응답 (Zero Acknowledgment): 메시지 승인 또는 보장된 전달을 위한 내장 메커니즘이 없습니다.
  • 낮은 지연 시간 (Low Latency): 단순한 인메모리 특성으로 인해 매우 빠릅니다.
  • 팬아웃 (Fan-out): 실시간 업데이트를 많은 리스너에게 동시에 브로드캐스팅하는 데 탁월합니다.

Pub/Sub 예시

이 간단한 명령어는 상호 작용을 보여줍니다:

# 터미널 1: 구독자가 리스닝 시작
REDIS> SUBSCRIBE updates:pricing

# 터미널 2: 발행자가 메시지 전송
REDIS> PUBLISH updates:pricing "Stock price updated to $150.00"

# 터미널 1 수신 내용:
1) "message"
2) "updates:pricing"
3) "Stock price updated to $150.00"

2. Redis Streams (XSTREAM)

Redis 5.0에서 도입된 Redis Streams는 정교하고 내구성이 있으며 영구적인 로그 형태의 데이터 구조를 제공하여, Redis가 안정적인 메시징 분야에서 기존 브로커와 더 직접적으로 경쟁할 수 있도록 합니다.

메커니즘 및 특징:

  • 영구성 (Persistence): 메시지(스트림 항목)는 Redis에 영구적으로 저장되므로, 소비자는 과거 데이터를 읽거나 연결 해제 후 놓친 메시지를 복구할 수 있습니다.
  • 소비자 그룹 (Consumer Groups): 스트림은 소비자 그룹을 지원하며, 이를 통해 여러 소비자가 스트림의 메시지를 동시에 처리하고 부하를 공유하며, 그룹 내에서 각 메시지가 단 하나의 소비자에게만 처리되도록 보장합니다 (경쟁 소비자 패턴).
  • 최소 1회 전달 (At-Least-Once Delivery): 스트림은 명시적인 메시지 승인(XACK)을 사용하여 메시지가 최소 한 번 처리됨을 보장합니다. 처리 실패 시, 메시지는 재처리를 위해 보류 상태로 유지됩니다.
  • 순서 보장 (Ordering): 메시지는 스트림 ID(타임스탬프와 시퀀스 번호)에 의해 엄격하게 순서가 지정됩니다.

Streams 예시 (생산자 및 소비자 그룹)

1. 항목 추가 (생산자): *는 Redis가 고유 ID를 생성해야 함을 나타냅니다.

XADD events:orders * item_id 42 user_id 99 amount 59.99

2. 소비자 그룹 생성:

XGROUP CREATE events:orders order_processors 0-0 MKSTREAM

3. 그룹에서 읽기 (소비자): >는 읽지 않은 새로운 메시지만 읽습니다.

XREADGROUP GROUP order_processors consumer_A COUNT 1 STREAMS events:orders >

Redis를 브로커로 사용할 때의 장점

Redis를 선택하는 것은 주로 성능과 인프라 통합 때문인 경우가 많습니다.

  1. 초저 지연 시간: 데이터의 즉각적인 배포가 필요한 애플리케이션(예: 라이브 스코어보드, 실시간 알림)의 경우, Redis의 인메모리 특성은 최소한의 오버헤드를 제공하며 비전문 솔루션에서 사용할 수 있는 가장 빠른 메시지 전달 속도를 보장합니다.
  2. 인프라 통합: 이미 캐싱 또는 세션 관리를 위해 Redis를 사용하고 있다면, 이를 경량 메시징에 활용함으로써 별도의 전용 브로커 클러스터(Kafka 또는 RabbitMQ와 같은)를 설정, 확장 및 유지 관리하는 복잡성과 운영 비용을 절감할 수 있습니다.
  3. Streams의 단순성: Streams는 Pub/Sub에 비해 복잡성을 도입하지만, Kafka와 같은 대규모 분산 로그 아키텍처보다 구성 및 관리가 여전히 단순하여 중소 규모의 메시징 워크로드에 이상적입니다.
  4. 트랜잭션 및 원자적 작업: Redis는 Redis 트랜잭션 또는 Lua 스크립트를 사용하여 메시지 발행/스트리밍 작업과 기타 원자적 데이터 수정(예: 카운터 업데이트 및 알림 전송)을 결합할 수 있습니다.

Redis 메시징 사용 시점: 정의된 사용 사례

Pub/Sub과 Streams 중 무엇을 선택할지, 그리고 Redis와 전용 브로커 중 무엇을 선택할지는 필요한 안정성과 규모에 전적으로 달려 있습니다.

Redis Pub/Sub 사용 사례 (일시적 메시징)

메시지 손실을 허용할 수 있고 속도가 가장 중요할 때 Pub/Sub을 사용하십시오.

  • 캐시 무효화: 특정 캐시 키가 업데이트되어 무효화되어야 함을 여러 애플리케이션 인스턴스에 걸쳐 알림으로 브로드캐스팅합니다.
  • 실시간 알림: 단순한 상태 업데이트, 기록 검색이 다른 곳에서 처리되는 채팅방 메시지, 또는 소비자가 가장 최신 값에만 관심 있는 라이브 데이터 피드.
  • 무상태 팬아웃: 수신 확인 없이 마이크로서비스에 구성 변경 또는 시스템 상태 확인을 배포합니다.

Redis Streams 사용 사례 (내구성 있는 메시징)

안정성, 영구성 및 동시 처리가 필요하지만 대규모 메시지 처리량이나 복잡한 라우팅이 필요하지 않을 때 Streams를 사용하십시오.

  • 단순 작업 큐: 작업 전달이 보장되어야 하는 백그라운드 작업자 큐 구현 (예: 이미지 처리, 이메일 전송). Streams는 작업 기록과 소비자 상태를 효과적으로 관리합니다.
  • 이벤트 소싱 (경량): 재생 가능성, 감사 또는 단순 상태 재구성을 위해 운영 이벤트의 영구적이고 순서가 지정된 로그를 저장합니다. 소규모 이벤트 볼륨에 적합합니다.
  • 서비스 간 통신 (마이크로서비스): 안정적인 데이터 교환을 위해 중앙 집중식의 영구적인 메시지 로그가 필요한 느슨하게 결합된 서비스를 연결하는 데 스트림을 사용합니다.
  • 속도 제한 (Rate Limiting): 빠른 분석 및 속도 제한 적용을 위해 사용자 작업 또는 API 호출과 관련된 시계열 데이터를 저장합니다.

한계점 및 전용 브로커를 선택해야 하는 시점

Redis Streams의 강력함에도 불구하고, 모든 시나리오에서 엔터프라이즈급 메시지 브로커를 대체할 수는 없습니다. 애플리케이션이 다음 범주에 속하는 경우, 종종 전용 솔루션이 필요합니다.

1. 높은 볼륨 및 데이터 내구성 요구 사항

Redis는 주로 인메모리 저장소입니다. Redis가 영속성(RDB 스냅샷 또는 AOF 로그)을 지원하지만, 이러한 메커니즘은 재시작 복구에 최적화되어 있으며, Kafka와 같은 솔루션의 지속적인 페타바이트 규모의 내구성 및 고도로 튜닝된 디스크 I/O를 위해 설계된 것은 아닙니다.

다음과 같은 경우 Kafka/Pulsar를 선택하십시오:
* 초당 수십만 개의 메시지에 걸쳐 보장된 전달이 필요합니다.
* 메시지 데이터 볼륨이 시스템 메모리를 초과하고, 효율적인 디스크 기반 저장소 및 계층화된 아카이빙이 필요합니다.
* 메시지 기록의 보존 기간이 매우 긴 경우(수개월 또는 수년)가 필요합니다.

2. 고급 브로커 기능

전용 브로커는 Redis에 기본적으로 없는 정교한 기능을 제공합니다.

기능 Redis Streams 전용 브로커 (예: RabbitMQ, Kafka)
데드 레터 큐 (DLQ) 애플리케이션 로직을 통해 수동으로 구현해야 합니다. 실패한 메시지를 자동으로 라우팅하는 기본 지원 기능.
복잡한 라우팅/필터링 기본 필터링은 클라이언트 측에서 수행되어야 합니다. 고급 라우팅을 위한 교환 유형 (RabbitMQ) 또는 복잡한 토픽 분할 (Kafka).
트랜잭션 기능 Redis 인스턴스 내로 제한됩니다. 메시지 전송 및 데이터베이스 업데이트 전반에 걸친 분산 트랜잭션 지원.
보안 및 모니터링 기본 ACL 및 일반 메트릭. 세분화된 권한, 전문 모니터링 도구 및 엔터프라이즈급 감사.

3. 큐 관리

Redis 리스트(LPUSH/RPOP)가 기본 큐 역할을 할 수 있지만, 이는 FIFO 방식에 불과하며 BRPOP 및 사용자 지정 로직과 결합되지 않으면 영속성을 보장하지 않습니다. Streams가 더 낫긴 하지만, 전용 브로커는 더 진보된 큐 관리 전략(예: 우선 순위 큐, 메시지 TTL)을 제공합니다.

요약 및 모범 사례

운영의 단순성과 놀랍도록 빠른 성능이 복잡한 기능 및 페타바이트 규모의 영속성 요구 사항보다 중요할 때, Redis는 메시지 브로커로서 탁월한 선택입니다.

시나리오 메시징 기본 요소 모범 사례
실시간 브로드캐스트/캐시 동기화 Redis Pub/Sub 구독자가 손실된 메시지를 정상적으로 처리하도록 보장합니다.
경량 작업 큐 Redis Streams 소비자 그룹과 엄격한 XACK을 사용하여 최소 1회 처리를 보장합니다.
대용량 데이터 파이프라인 전용 브로커 (Kafka/Pulsar) 메시지가 여러 TB의 데이터에 걸쳐 안정적으로 영속화되어야 하는 경우 Redis를 사용하지 마십시오.
기존 Redis 인프라 활용 Redis Streams 기존 Redis 클러스터를 사용하여 설정 오버헤드를 절감합니다.

경고: Redis Streams를 사용할 때 스트림 항목이 메모리를 소모한다는 점을 기억하십시오. 과도한 메모리 사용을 방지하기 위해 XTRIM을 사용하여 (예: 길이 또는 ID를 기준으로) 오래된 항목을 정리하는 정책을 구현하십시오. 특히 처리량이 많은 스트림에서 중요합니다.