1. 도입을 희망하는 기술

<aside>

RabbitMQ - 오픈소스 메시지 브로커 및 AMQP 구현체

AMQP (Advanced Message Queuing Protocol) - 메시지 지향 미들웨어를 위한 개방형 표준 프로토콜

</aside>

2. 기술 설명

<aside>

RabbitMQ는 AMQP 0-9-1 프로토콜을 구현한 오픈소스 메시지 브로커로, 애플리케이션 간 비동기 메시지 통신을 제공한다. 현재 프로젝트의 Spring 이벤트 시스템을 고도화하여 메시지 큐 기반의 이벤트 처리를 구현할 수 있게 해준다.

AMQP는 메시지 지향 미들웨어의 표준 프로토콜로, 메시지의 라우팅, 큐잉, 배달 보장 등을 정의하여 상호 운용성과 확장성을 보장한다.

</aside>

1. 기술 장점

<aside>

3.1 RabbitMQ vs Apache Kafka

• 설정 및 운영 복잡도: RabbitMQ는 웹 기반 관리 콘솔과 간단한 설정으로 빠른 도입과 운영이 가능하다.
  • Kafka는 복잡한 설정과 운영이 필요하며, Zookeeper 의존성과 높은 학습 곡선으로 인해 팀 도입 비용이 크다.
  • 현재 프로젝트 규모(설문 조사 API)에서는 Kafka의 고성능이 과도하며, RabbitMQ의 적절한 성능과 간단함이 더 적합하다.
• 메시지 보장: RabbitMQ는 ACK 기반의 메시지 배달 보장으로 메시지 손실을 방지한다.
  • Kafka는 at-least-once 배달만 보장하여 중복 처리 가능성이 있다.
  • 설문 응답, 사용자 포인트 적립 등 데이터 정합성이 중요한 비즈니스 로직에는 RabbitMQ의 신뢰성이 우수하다.

3.2 RabbitMQ vs Redis Streams

• 메모리 효율성: RabbitMQ는 디스크 기반 저장으로 메모리 제약 없이 대용량 메시지 처리 가능하다.
  • Redis Streams는 메모리 기반으로 메모리 크기에 따른 처리량 제한이 있다.
  • 설문 데이터가 대량으로 증가할 수 있는 환경에서는 RabbitMQ의 확장성이 유리하다.
• 메시지 라우팅: RabbitMQ는 Exchange와 Binding을 통한 복잡한 라우팅 패턴을 지원한다.
  • Redis Streams는 단순한 Consumer Group만 지원하여 세밀한 메시지 분배가 어렵다.
  • 설문 생성, 수정, 삭제 등 다양한 이벤트 타입을 효율적으로 분류하여 처리할 수 있다.

3.3 AMQP vs 기타 메시징 프로토콜

• 표준화 및 상호 운용성: AMQP는 OASIS 표준으로 다양한 언어와 플랫폼에서 지원된다.
  • JMS는 Java 전용이며, Spring Cloud Stream은 Spring 생태계에 종속된다.
  • AMQP의 개방성으로 향후 다른 기술 스택과의 연동이 용이하다.
• Spring 통합: Spring AMQP를 통해 Spring Boot와 완벽한 통합이 가능하다.
  • @RabbitListener, RabbitTemplate 등 Spring 친화적인 API로 기존 코드 변경 최소화가 가능하다. </aside>

4. 단점 / 한계점 / 주의사항

<aside>

• 성능 한계: Apache Kafka 대비 처리량 제한이 있어, 초당 수십만 건 이상의 메시지가 필요한 경우에는 부적합할 수 있다.
  • 하지만 현재 설문 조사 API의 이벤트 발생 빈도를 고려하면 충분한 성능을 제공한다.
• 메모리 사용량: 메시지 큐와 인덱스를 메모리에 유지하므로, 대용량 메시지 처리 시 메모리 사용량이 증가할 수 있다.
  • 적절한 큐 크기 제한과 TTL 설정으로 메모리 사용량을 제어해야 한다.
• 클러스터 복잡성: 고가용성을 위한 클러스터 구성 시 설정과 운영이 복잡해질 수 있다.
  • 초기에는 단일 인스턴스로 시작하여 점진적으로 클러스터 확장하는 전략이 필요하다.
• 메시지 순서 보장: 여러 Consumer에서 메시지를 처리할 때 메시지 순서가 보장되지 않을 수 있다.
  • 설문 생성 → 질문 생성과 같은 순서 의존성이 있는 이벤트는 단일 큐 또는 메시지 그룹으로 처리해야 한다. </aside>

1. 도입 배경과 필요성

<aside>

현재 프로젝트는 Spring의 ApplicationEventPublisher를 사용한 동기식 이벤트 시스템을 구축하고 있지만, 다음과 같은 한계점과 문제점이 발생하고 있다:

5.1 현재 시스템의 문제점

• 성능 병목: 이벤트 핸들러가 순차적으로 실행되어 API 응답 지연 발생
• 메모리 부하: 대량의 이벤트 발생 시 JVM 메모리 부족 위험
• 장애 전파: 이벤트 처리 실패가 메인 트랜잭션에 영향을 주어 시스템 불안정성 초래
• 확장성 제한: 단일 애플리케이션 인스턴스에서만 이벤트 처리 가능

5.2 RabbitMQ & AMQP 도입 필요성

• 비동기 이벤트 처리: 설문 생성, 수정, 삭제 등의 이벤트를 백그라운드에서 비동기 처리하여 API 응답 시간 단축
• 시스템 안정성 향상: 이벤트 처리 실패가 메인 서비스에 영향을 주지 않아 전체 시스템 안정성 향상
• 수평적 확장: 여러 애플리케이션 인스턴스에서 이벤트를 분산 처리하여 시스템 처리량 증대
• 메시지 지속성: 디스크 기반 저장으로 애플리케이션 재시작 시에도 메시지 유지

5.3 비즈니스 가치

• 사용자 경험 개선: 설문 생성 시 즉시 응답으로 사용자 대기 시간 단축
• 시스템 신뢰성: 메시지 재처리와 장애 복구로 데이터 정합성 보장
• 운영 효율성: 웹 기반 관리 콘솔로 실시간 모니터링 및 문제 진단 가능
• 미래 확장성: 마이크로서비스 아키텍처 전환 시 서비스 간 통신 기반 제공

5.4 구체적 적용 사례

• 설문 생성 이벤트: 설문 생성 API 응답 후 백그라운드에서 질문 생성 및 MongoDB 동기화
• 사용자 포인트 적립: 설문 종료 시 비동기적으로 사용자 포인트 증가 처리
• 공유 링크 생성: 프로젝트 멤버 추가 시 공유 링크 자동 생성 및 알림 발송
• 통계 데이터 집계: 설문 응답 시 실시간 통계 계산 및 대시보드 업데이트

이를 통해 설문 조사 API의 성능과 안정성을 획기적으로 향상시키고, 사용자 경험 개선과 시스템 운영 효율성 증대를 달성할 수 있다.

</aside>