[CodeChef - 트러블 슈팅] 실시간 알림의 비밀: RabbitMQ로 댓글 알림 시스템 구축하기

[내가 구현한 기능]

사용자들이 게시글에 댓글을 작성할 때, 해당 댓글이 게시글 작성자에게 실시간으로 알림으로 전달되는 기능을 제공하기 위하여, 댓글 알림 기능을 WebSocket + Redis Pub/Sub에서 RabbitMQ와 WebSocket을 활용하여 실시간으로 전송하는 시스템을 구현했습니다.

 

[주요 로직]

댓글 생성 시 알림 발행: 댓글이 작성되면 해당 댓글 정보와 함께 게시글 작성자에게 알림을 보내도록 메시지를 발행합니다. RabbitMQ를 통한 메시지 라우팅: 댓글 알림 메시지는 RabbitMQ의 Direct Exchange를 통해 commentQueue에 라우팅됩니다. RabbitMQListener를 통해 WebSocket 전송: RabbitMQ의 commentQueue를 구독하는 RabbitMQListener가 메시지를 수신하여, WebSocket을 통해 게시글 작성자에게 실시간으로 알림을 전송합니다.

 

[배경]

기존의 알림보다 안정적인 알림 전송이 필요했습니다. 메시지 유실을 방지와, 장애 발생 시에도 데이터를 복구할 수 있는 것을 안정적인 알림 전송이라고 생각해, 이 점을 충족할 수 있는 개선 방법이 필요했습니다. 현재는 실시간성은 있지만, 데이터 유실 위험이 존재하며 메시지 전달의 안정성을 보장하지 못하는 한계가 있었습니다.

 

[요구사항]

실시간 알림: 댓글 생성 시, 게시글 작성자에게 알림을 즉시 전달해야 합니다. 메시지 전송의 안정성: 알림이 누락되지 않고 게시글 작성자에게 전달되는 것이 중요합니다.

 

[선택지]

Pub/Sub를 통한 단순 알림 구현: 구독-발행 방식을 통해 게시글 작성자가 실시간으로 알림을 받을 수 있도록 구현. RabbitMQ를 통한 메시지 큐 시스템 적용: RabbitMQ의 Direct Exchange를 활용하여 메시지를 특정 사용자에게 라우팅. Kafka로의 고도화 가능성 고려: 일단은 RabbitMQ를 사용하되, 최종적으로 Kafka를 도입하여 대규모 트래픽 처리와 메시지 영속성을 강화할 계획.

 

[의사결정/사유]

RabbitMQ를 우선적으로 도입한 이유는 다음과 같습니다.

단계적 고도화 전략: 최종 목표는 Kafka와 같은 메시지 스트리밍 플랫폼을 활용하여 높은 트래픽과 확장성을 요구하는 상황에도 대비하는 것입니다. 하지만 Kafka는 설정 및 운영의 복잡도가 높아 초기 도입에 부담이 있기 때문에, 상대적으로 설정과 사용이 간단한 RabbitMQ를 우선 도입하여 실시간 알림 기능을 구현했습니다.

구독-발행 구조의 유연성: 구독-발행 모델을 사용하는 RabbitMQ는 각 메시지를 사용자 큐에 맞춰 라우팅할 수 있습니다. 이를 통해 댓글 작성 시 게시글 작성자에게만 알림을 보낼 수 있어, 초기 요구사항을 충족하기에 적합하다고 판단했습니다. 확장성 있는 구조: RabbitMQ는 Direct Exchange, Fanout Exchange 등 다양한 메시지 전송 방식을 지원하여 확장성이 높은 구조로 전환할 수 있습니다. 또한 Kafka로의 전환 시에도 Pub/Sub 구조가 유지되므로 큰 변경 없이 쉽게 고도화할 수 있습니다. 이와 같은 이유로, RabbitMQ를 먼저 도입한 후 향후 Kafka로 고도화하는 전략을 채택했습니다.

 

[회고]

기술의 장단점 RabbitMQ의 장점: 단순성과 설정의 용이성: RabbitMQ는 설정과 사용이 비교적 간단하며, 다양한 Exchange 타입을 통해 메시지를 손쉽게 큐에 라우팅할 수 있습니다.

데이터 안전성과 신뢰성 확보: RabbitMQ는 메시지를 큐에 저장하므로, 서버 장애가 발생해도 메시지를 잃지 않습니다. 이를 통해 알림 시스템의 신뢰성을 확보할 수 있습니다. 예를 들어, 선착순 이벤트 공지에서 메시지가 손실되면 공지 내용이 일부 사용자에게만 전달되는 문제를 방지할 수 있었습니다. 또한 Consumer가 가져갈 때까지 보관할 수 있어 안정적인 알림 전송이 가능합니다.

유연한 메시지 라우팅: RabbitMQ는 구독-발행 모델을 지원하여, 예를 들어 게시물 댓글 알림 시 작성자만 타겟팅하거나, 이벤트 공지 시 모든 사용자에게 메시지를 효율적으로 라우팅할 수 있었습니다.

 

RabbitMQ의 단점: 확장성의 한계: RabbitMQ는 고속 데이터 스트림 처리 및 대규모 트래픽에 한계가 있을 수 있어, 대용량 메시징 처리에는 Kafka보다 적합하지 않습니다.

복잡한 메시지 영속성 관리: Kafka는 기본적으로 메시지를 디스크에 저장하여 안정적인 메시지 영속성을 지원하지만, RabbitMQ는 Queue에 메시지를 저장하기 때문에 별도의 설정이 필요할 수 있습니다.

 

다시 시도한다면?

다시 구현한다면, 다음과 같은 사항을 고려할 것입니다. Kafka로의 전환: 높은 트래픽 처리와 메시지 영속성을 고려하여 RabbitMQ에서 Kafka로 메시징 시스템을 전환해볼 수 있습니다. Kafka는 대규모 데이터 스트리밍을 효율적으로 처리할 수 있으며, 다양한 분석 및 실시간 데이터 처리가 가능합니다. 모니터링과 장애 대응 강화: RabbitMQ 또는 Kafka와 같은 메시징 시스템에 장애가 발생할 경우를 대비해 추가적인 모니터링 시스템을 구축하여 알림 전송의 신뢰성을 높이는 방안을 추가로 고려할 수 있습니다.