메시지 큐 도입기 - 비동기 로깅 처리 및 알림 기능 (RabbitMQ, Kafka, Redis Pub/Sub 비교)

https://f-lab.kr/insight/message-queue-system-comparison

메시지 큐 시스템 비교: Kafka, RabbitMQ, Redis Pub/Sub

본 글을 보고 정리한 내용입니다.

 

메시지 큐 도입기

왜 도입을 하는가?

 

 서비스의 확장성과 성능 최적화를 위해 메시지 큐(Message Queue)를 도입하여 비동기 로깅 처리 및 알림 기능을 구현하려고 한다.

기존 로그 저장 방식은 (Logback → 파일)로 저장하였다.

 

로그가 서버에서 Logback을 통해 파일(server.log, error.log)에 저장하고 Promtail로 보내는 식이다.

하지만 단점이 존재한다.

 1. 로그가 로컬 파일에 저장되기 때문에 실시간 분석이 어렵다.

 2 Loki가 로그를 파일에서 읽어오는 데 시간이 걸릴 수 있다.

 3. Message Queue를 이용하면 검색/필터링 기능을 쉽게 적용할 수 있다는 장점이 존재한다.

 4. 서버가 장애가 나거나 컨테이너가 재시작되면 로그 파일이 유실된 가능성이 있다.

 

 

 

MQ + FCM을 이용한 알림 시스템이 필요한 이유

1. FCM 서버가 일시적으로 장애가 발생하면 알림이 유실될 수 있음

2. 트래픽이 급격히 증가하면 서버가 순간적으로 부하를 받을 가능성이 있음.

3. 만약 FCM 호출이 실패하면, MQ에서 다시 읽어서 재시도 가능 (재시도 로직 적용 가능) 장애가 발생해도 알림이 유실되지 않는다는 장점이 있다.

 

여러가지 메시지 큐 비교

메시지 큐도 여러가지가 존재한다. Kafka, RabbitMQ, Redis Pub/Sub 세가지 메시지 큐가 존재한다.

따라서 프로젝트에 적용하기 위해서 어떤 메시지 큐를 써야하는지 서로 비교해보자.

 

Kafka의 특징과 장점

Apache Kafka는 대용량의 실시간 데이터 처리에 적합한 메시지 큐 시스템이다. 분산 환경에서 높은 처리량과 확장성을 제공한다.

Kafka는 분산 스트림 처리 시스템으로 설계되어있다. Kafka는 토픽을 기반으로 메시지를 분류하며, 각 토픽은 하나 이상의 파티션으로 나눠진다. 이는 데이터의 병렬 처리를 가능하게 하며, 처리 속도를 향상 시킨다.

파티션 단위로 데이터를 분산 저장하고, 처리하기 때문에 확장성과 처리량이 크게 향상 된다.

복제 메커니즘을 통해 데이터 손실 위험을 최소화하며, 시스템 장애 시에도 메시지 손실 없이 처리를 계속할 수 있다.

 

RabbitMQ의 특징과 사용 사례

RabbitMQ는 AMQP(Advanced Message Queuing Protocol)을 구현한 오픈 소스 메시지 브로커이다.

복잡한 라우팅, 메시지 순서 보장, 메시지 확인 등 고급 메시징 기능을 제공한다.

왜냐하면 RabbitMQ는 메시지를 유연하게 라우팅할 수 있는 다양한 교환기(exchange) 타입을 지원하며, 메시지를 받은 순서대로 처리할 필요가 있는 애플리케이션에 적합하다.

메시지가 성공적으로 처리되었는지 확인하고, 처리되지 않은 메시지를 다시 큐에 넣는 등의 기능을 통해 메시지 손실 위험을 줄인다.

왜냐하면 RabbitMQ는 메시지의 배달 확인과 메시지 상태 관리 기능을 제공한다.

 특히 메시지의 순서와 신뢰성이 중요한 금융, 전자상거래 등의 분야에서 선호된다.

 

Redis Pub/Sub의 특징과 한계

Redis Pub/Sub은 Redis의 내장 기능 중 하나로, 간단한 메시지 브로커 기능을 제공합니다.

실시간 채팅, 라이브 스트리밍 등 실시간 메시지 전송이 필요한 애플리케이션에 적합하다.

왜냐하면 Redis Pub/Sub은 메모리 기반의 데이터 스토리지를 사용하여 빠른 메시지 전송 속도를 제공한다.

메시지가 전송되면 소비자가 메시지를 받지 못한 경우 메시지를 복구할 방법이 없다.

따라서, 메시지의 신뢰성과 내구성이 중요한 시스템에서는 Redis Pub/Sub보다는 Kafka나 RabbitMQ와 같은 다른 메시지 큐 시스템을 고려하는 것이 좋다.

 

실시간 알림 (FCM, 웹소켓)
→ RabbitMQ or Redis Pub/Sub
→ Redis Pub/Sub이 빠르지만, 메시지 유실 가능성이 있어서 RabbitMQ를 쓰려고 한다.
(RabbitMQ는 메시지를 확실하게 전달하고 재시도 기능도 제공)

 

로그 수집 & 분석 (Loki, ELK)
→ Kafka
✔ Kafka는 대량의 로그 데이터를 안정적으로 처리하고 분석 시스템과 연결하기 좋다.
✔ 디스크 저장으로 장애 발생 시에도 데이터 유실이 거의 없기 때문에 Kafka를 쓰려고 한다.

 

[최종 모니터링 예상도]

1. kafka로 인한 실시간 error/warn 로깅 파일 전달

2. info/debug는 정적 파일로 로깅 파일 전달

3. Spring Boot Actuator는 서버의 부하를 검사하는 툴