최근 MSA(Microservices Architecture)와 AI 기반 서비스가 급부상하면서, 대용량의 실시간 이벤트를 안정적으로 처리하는 능력이 새로운 화두로 떠오르고 있습니다. 사용자 인터랙션, 센서 데이터, 로그 스트림 등 다양한 형태의 데이터를 지연 없이 수집, 전파, 처리하는 것은 서비스의 응답성과 확장성을 결정짓는 중요한 요소입니다.
이러한 요구사항을 충족시키기 위해 Redis Pub/Sub과 Kafka는 대표적인 이벤트 브로커 솔루션으로 자리매김했습니다. 이 기술들은 대규모 분산 시스템에서 데이터 파이프라인의 핵심 축을 담당하며, 복잡한 서비스 간 통신과 데이터 동기화를 효율적으로 지원합니다. 본 글에서는 Redis Pub/Sub과 Kafka의 특성을 이해하고, 이 둘을 결합하여 고성능 실시간 이벤트 브로커 아키텍처를 설계하고 확장하는 실전 전략을 살펴봅니다.
아키텍처 분석: Redis Pub/Sub과 Kafka의 시너지
대용량 실시간 이벤트 브로커 아키텍처는 주로 두 가지 특성을 동시에 요구합니다. 첫째는 극도로 낮은 지연 시간으로 짧은 라이프사이클을 가지는 이벤트를 처리하는 능력이고, 둘째는 높은 처리량과 데이터 영속성을 보장하며 대규모 데이터 스트림을 안정적으로 관리하는 능력입니다. Redis Pub/Sub은 전자에 강하고, Kafka는 후자에 강점을 가집니다.
직관적으로 이해하면, 이 아키텍처는 Redis Pub/Sub을 사용하여 휘발성(transient)이고 지연에 민감한 이벤트를 신속하게 전파하고, Kafka를 통해 영구 저장(persistent)이 필요하거나 복잡한 스트림 처리, 백프레셔(backpressure) 관리, 그리고 높은 확장성을 요구하는 이벤트를 처리하는 하이브리드 접근 방식을 채택합니다. 데이터 흐름은 특정 애플리케이션에서 발생한 이벤트가 먼저 Redis Pub/Sub을 통해 관련 컨슈머에게 즉시 전달된 후, 필요한 경우 Kafka로도 전송되어 장기 저장 및 배치 처리, 또는 복잡한 스트림 분석에 활용될 수 있습니다.
핵심 컴포넌트는 이벤트 생성기(Producer), Redis Pub/Sub 브로커, Kafka 클러스터, 그리고 이벤트 소비기(Consumer)입니다. 이벤트 생성기는 이벤트의 특성에 따라 Redis 또는 Kafka로 직접 이벤트를 발행하거나, 통합 게이트웨이를 통해 두 시스템으로 분산 발행할 수 있습니다. 각 시스템의 소비기는 자신에게 필요한 이벤트를 구독하고 처리합니다.
Redis Pub/Sub의 동작 원리
Redis Pub/Sub은 Redis의 인메모리 특성을 활용하여 매우 낮은 지연 시간으로 메시지를 발행하고 구독하는 메커니즘을 제공합니다. 이는 '채널'이라는 개념을 중심으로 동작하며, 메시지 발행자는 특정 채널에 메시지를 발행하고, 구독자는 해당 채널을 구독하여 메시지를 수신합니다.
핵심 원리를 풀어보면, Redis 서버는 채널별로 메시지를 저장하지 않습니다. 메시지는 발행되는 즉시 해당 채널을 구독하고 있는 모든 클라이언트에게 전송됩니다. 이는 메시지의 영속성보다는 즉각적인 전파에 중점을 둡니다. 만약 구독자가 연결되어 있지 않다면, 그 메시지는 손실됩니다. 따라서 Redis Pub/Sub은 실시간 채팅, 알림, 그리고 임시적인 캐시 무효화 등 메시지 손실에 비교적 관대한 시나리오에 적합합니다.
간단한 Redis Pub/Sub 예시는 다음과 같습니다.
redis-cli PUBLISH my_channel "Hello, Redis Pub/Sub!"
구독자 (Subscriber) 터미널
redis-cli SUBSCRIBE my_channel
위 예시에서 'PUBLISH' 명령어는 'my_channel'에 메시지를 발행하고, 'SUBSCRIBE' 명령어는 해당 채널의 메시지를 실시간으로 수신합니다. 이처럼 Redis Pub/Sub은 직관적이며 가볍게 구현할 수 있습니다.
Kafka의 분산 처리 메커니즘
Kafka는 대규모 분산 환경에서 높은 처리량과 영속성을 가진 이벤트 스트림 처리에 특화된 플랫폼입니다. Redis Pub/Sub과 달리, Kafka는 메시지를 영구적으로 저장하고, 여러 소비자 그룹이 독립적으로 메시지를 소비할 수 있도록 설계되었습니다.
Kafka의 핵심 컴포넌트는 다음과 같습니다:
- Producer: 이벤트를 Kafka 토픽에 발행합니다.
- Consumer: Kafka 토픽에서 이벤트를 소비합니다. 'Consumer Group'을 형성하여 병렬 처리가 가능합니다.
- Broker: Kafka 서버로, 토픽의 파티션을 관리하고 메시지를 저장합니다.
- Topic: 메시지를 분류하는 논리적인 단위입니다.
- Partition: 토픽을 구성하는 최소 단위로, 메시지가 저장되는 로그의 순서를 보장합니다. 병렬 처리를 위해 여러 파티션으로 나뉩니다.
메시지는 파티션에 저장되며, 각 메시지에는 '오프셋(offset)'이라는 고유한 순서 번호가 부여됩니다. 소비자는 이 오프셋을 기반으로 메시지를 추적하고, 장애 발생 시에도 마지막으로 처리한 오프셋부터 다시 시작하여 메시지 손실 없이 복구할 수 있습니다. 이는 Kafka가 높은 안정성과 데이터 무결성을 제공하는 핵심적인 이유입니다.
Kafka 토픽 생성 및 메시지 발행 예시입니다.
kafka-topics --create --topic my-kafka-topic --bootstrap-server localhost:9092 --partitions 3 --replication-factor 1
kafka-console-producer --broker-list localhost:9092 --topic my-kafka-topic
> This is a Kafka message.
kafka-console-consumer --bootstrap-server localhost:9092 --topic my-kafka-topic --from-beginning
Kafka는 이처럼 분산된 환경에서 대규모 이벤트 스트림을 안정적으로 처리하며, 데이터의 영속성과 높은 처리량을 요구하는 비동기 통신에 최적화되어 있습니다.
하이브리드 아키텍처의 연동 전략
Redis Pub/Sub과 Kafka를 효과적으로 연동하기 위해서는 각 시스템의 강점을 최대한 활용하는 전략이 필요합니다. Redis Pub/Sub은 즉각적인 반응이 필요한 서비스 알림, 사용자 세션 동기화 등에 사용하고, Kafka는 중요한 비즈니스 이벤트 로깅, 데이터 분석 파이프라인, 그리고 장시간 처리가 필요한 작업 큐 등으로 활용할 수 있습니다.
구체적인 연동 방식으로는, 이벤트가 발생했을 때 먼저 Redis Pub/Sub을 통해 실시간 컨슈머에게 즉시 전파하고, 동시에 Kafka Producer를 통해 동일한 이벤트를 Kafka 토픽으로 발행하는 이중 발행(Dual Publishing) 패턴을 고려할 수 있습니다. 이 과정에서 통합 게이트웨이 또는 별도의 애플리케이션 서비스가 이중 발행 로직을 담당하게 됩니다. 또한, Kafka Connect와 같은 도구를 활용하여 Kafka의 특정 토픽 이벤트를 Redis로 동기화하거나, 반대로 Redis Stream을 Kafka로 연동하는 방안도 유연성을 제공합니다.
성능 비교: Redis Pub/Sub vs. Kafka
두 기술은 각각 다른 성능 특성과 사용 시나리오를 가집니다. 다음 표는 Redis Pub/Sub과 Kafka의 주요 성능 및 기능적 측면을 비교합니다.
| 특성 | Redis Pub/Sub | Kafka |
|---|
| 지연 시간 | 매우 낮음 (밀리초 미만) | 낮음 (수 밀리초) |
| 처리량 | 중간 ~ 높음 | 매우 높음 (초당 수십만 건 이상) |
| 메시지 영속성 | 없음 (클라이언트 미연결 시 손실) | 있음 (설정 가능, 디스크 저장) |
| 메시지 순서 보장 | 단일 채널 내 발행 순서 보장 | 단일 파티션 내 발행 순서 보장 |
| 확장성 | 클라이언트 수 증가에 따라 부하 증가 | 수평 확장 용이 (파티션/브로커 추가) |
| 복잡성 | 낮음 (단일 서버) | 높음 (분산 클러스터) |
이러한 비교를 통해, 짧은 생명주기와 빠른 응답성이 중요한 시나리오에는 Redis Pub/Sub이 유리하며, 대규모 데이터 스트림의 안정적인 처리와 분석이 필요한 경우 Kafka가 강력한 솔루션임을 알 수 있습니다.
실전 구성: 최적화와 튜닝 포인트
프로덕션 환경에서 Redis Pub/Sub과 Kafka를 구성할 때는 확장성, 안정성, 성능을 최적화하는 것이 중요합니다.
Redis Pub/Sub 설정
Redis Pub/Sub은 인메모리 특성상 메모리 사용량에 민감합니다.
maxmemory
설정을 통해 메모리 한도를 지정하고, maxmemory-policy
를 적절히 설정하여 OOM(Out Of Memory)을 방지해야 합니다. 또한, 클라이언트 연결 수가 많아질 경우 Redis 서버에 부하가 가해질 수 있으므로, 프록시 계층을 두거나 Redis Cluster를 활용하는 방안도 고려할 만합니다. client-output-buffer-limit pubsub
설정으로 느린 구독자를 관리하여 서버 자원 고갈을 방지하는 것이 좋습니다.
maxmemory 2gb
maxmemory-policy allkeys-lru
client-output-buffer-limit pubsub 32mb 8mb 60
위 설정은 Redis가 2GB 메모리를 초과하면 LRU(Least Recently Used) 정책으로 키를 제거하고, Pub/Sub 클라이언트 버퍼 제한을 두어 과도한 메모리 사용을 방지합니다.
Kafka 클러스터 설정
Kafka는 분산 클러스터 환경에서 운영되므로, 브로커, 토픽, 파티션 설정을 세밀하게 튜닝해야 합니다. 토픽 생성 시 파티션 수(
num.partitions
)는 병렬 처리량과 직접적인 연관이 있으므로, 예상되는 처리량과 컨슈머 그룹의 수를 고려하여 결정해야 합니다. 복제 계수(replication.factor
)는 데이터 안정성과 고가용성을 위해 최소 3 이상으로 설정하는 것이 일반적입니다.
# server.properties 예시
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.retention.hours=168 # 7일 저장
log.segment.bytes=1073741824 # 1GB 세그먼트
또한, 디스크 I/O 성능이 Kafka 처리량에 결정적인 영향을 미치므로, 빠른 스토리지를 사용하고, 운영체제 캐시 설정을 최적화하는 것이 중요합니다.
모니터링 및 운영
대용량 실시간 이벤트 브로커는 시스템 안정성 확보를 위해 지속적인 모니터링이 필수적입니다. 핵심 모니터링 지표로는 메시지 발행률(produce rate), 메시지 소비율(consume rate), 컨슈머 지연(consumer lag), 네트워크 대역폭, CPU 및 메모리 사용량 등이 있습니다.
Redis의 경우,
INFO
명령어를 통해 연결된 클라이언트 수, 메모리 사용량, 초당 처리 명령 수 등을 확인할 수 있습니다. Kafka는 JMX(Java Management Extensions)를 통해 브로커 및 토픽의 다양한 메트릭을 수집할 수 있으며, Prometheus와 Grafana를 연동하여 시각화된 대시보드를 구축하는 것이 일반적입니다.
운영 중 주의사항으로는 메시지 폭주로 인한 백프레셔 발생, 컨슈머 처리 지연, 브로커 장애 등이 있습니다. Redis Pub/Sub은 메시지 유실 가능성이 있으므로, 중요한 데이터는 Kafka와 같은 영속성 있는 시스템으로 이중화하는 것이 바람직합니다. Kafka 클러스터 장애 시에는 ZooKeeper(또는 KRaft) 클러스터의 상태를 확인하고, 브로커 로그를 분석하여 원인을 파악하며, 리더 파티션 재선거(Leader Election) 등의 복구 절차를 수행해야 합니다.
정리
Redis Pub/Sub과 Kafka를 활용한 대규모 실시간 이벤트 브로커 아키텍처는 현대의 대용량, 고성능 분산 시스템에서 핵심적인 역할을 수행합니다. Redis Pub/Sub은 낮은 지연 시간으로 휘발성 이벤트를 처리하는 데 강점을 가지며, Kafka는 높은 처리량과 영속성, 그리고 강력한 확장성으로 대규모 데이터 스트림 처리에 최적화되어 있습니다.
이러한 하이브리드 접근 방식은 각 기술의 장점을 극대화하여, 단일 솔루션으로는 해결하기 어려운 복합적인 실시간 데이터 처리 요구사항을 효과적으로 충족시킬 수 있습니다. 시스템의 특성과 데이터의 중요도에 따라 두 기술의 역할을 명확히 구분하고, 적절한 연동 전략을 수립하는 것이 성공적인 아키텍처 구현의 관건입니다.
대규모 분산 환경에서 실시간 이벤트 처리의 가능성은 무궁무진합니다. Redis Pub/Sub과 Kafka가 어떻게 발전하고, 또 어떤 새로운 기술과 결합되어 더욱 진화할지 지켜볼 필요가 있습니다. 실무 도입 시에는 지속적인 모니터링과 튜닝을 통해 시스템의 안정성과 성능을 확보하는 데 집중해야 합니다.
