[STUDY] 동기 vs 비동기 - RabbitMQ로 비동기 이벤트 처리하기

🧠 동기 · 비동기와 블로킹 · 논블로킹

동기 vs 비동기

• 동기(Synchronous) : 호출자와 요청자의 결과 확인이 동시에 일어남
• 비동기(Asynchronous) : 호출자와 요청자의 결과 확인이 동시에 일어나지 않아도 됨

블로킹 vs 논블로킹

• 블로킹(Blocking) : 호출자가 요청에 대한 결과가 나올 때까지 요청자에게 제어권을 돌려주지 않는 것
• 논블로킹(Non-Blocking) : 호출자가 요청에 대한 결과가 나오지 않더라도 요청자에게 제어권을 돌려줌

동시성 vs 병렬성

• 동시성(Concurrency) : 싱글 코어에서 여러 작업을 번갈아 가며 처리하는 방식
• 병렬성(Parallelism) : 멀티 코어가 각 작업을 물리적으로 동시에 처리하는 방식

예를 들어, 아래 코드는 메시지를 수신할 때 동시에 최대 3개의 메시지를 처리할 수 있도록 concurrency = "3" 설정을 해두었다.

이때 Spring은 내부적으로 멀티스레드 풀을 활용해 메시지를 병렬로 처리하려고 시도한다. 만약 이 코드가 단일 CPU 환경에서 실행된다면 실제로는 3개의 스레드가 반갈아 실행되며 각각의 메시지를 처리하게 되는데, 이 때 발생하는 것이 동시성 처리다.

📨 메시징 시스템이란?

메시지 큐의 역할과 구조

• 메시지 큐(Message Queue, MQ) : 메시지 지향 미들웨어(Message Oriented Middleware, MOM)의 일종으로, 서로 독립적인 애플리케이션 간에 메시지를 주고받으며 비동기적으로 작업을 처리할 수 있도록 해주는 시스템이다.

메시징 시스템의 가장 기본적인 구조는 아래와 같이 생산자(Producer)가 메시지를 Message Queue에 넣고, 소비자(Consumer) 가 이를 꺼내 처리하는 구조이다. Producer와 Consumer가 비동기적으로 분리되어 있다는 것이 핵심이다. 

• 메시지 큐의 특징
  • 비동기 처리로 응답 지연 해소
    • Producer와 Consumer가 시간적으로 분리되어 요청-응답 병목 없이 빠른 사용자 응답 가능
  • 버퍼링과 부하 완충
    • 큐에 메시지를 일시 저장함으로써, 트래픽 폭주나 처리 지연 상황에서도 안정적인 흐름 유지 가능
  • 재처리 및 신뢰성 보장
    • 처리 실패 시 메시지를 DLQ 등으로 이동 후 재시도 가능 → 데이터 유실 없이 안정적인 메시지 처리

🚦 왜 메시지 기반 비동기 처리가 필요한가?

동기 처리의 한계

아래 코드는 메시지 큐를 도입하기 전, 이벤트 오픈 시 알림을 직접 전송하던 방식이다. openEventsIfDueBefore() 메서드는 DB에서 오픈 대상 이벤트를 조회한 뒤, 해당 이벤트에 참여한 사용자 목록을 가져와 notificationService.createNotification()을 직접 호출해 알림을 전송한다. 이때 알림 전송은 동기적으로 처리되며, 유저 수가 많아질수록 for문 내부 처리 시간이 길어지고, 전체 트랜잭션이 지연될 가능성이 크다.

 

동기 처리의 한계는 다음과 같이 정리할 수 있다.

• 모든 처리가 하나의 흐름에 묶여 있다.
  • 이벤트 오픈부터 사용자 알림 전송까지 하나의 메서드/트랜잭션 안에서 모두 처리
• 사용자 수 증가 시 선형적으로 지연된다.
  • for문으로 유저를 하나씩 순회하며 동기적으로 알림 전송 → 이 모든 작업이 반환될 때까지 대기
  • 알림 전송 처리량이 늘수록, 전체 오픈 로직 지연이 심해짐
• 장애 복원력이 없다.
  • 실패한 메시지를 따로 저장하거나, 재처리할 수 있는 구조가 없음 → 유저는 알림을 받지 못하고, 개발자는 실패한 알림이 뭔지 알기 어려움

메시지 큐 도입 전후 비교

MQ를 적용하지 않은 기존 구조의 흐름은 다음과 같다. 알림 전송까지 한 트랜잭션에서 처리되어 응답 지연이 발생할 확률이 높았고, 실패 시 전체 흐름이 중단될 수 있었다.

[Scheduler 실행 (주기적)]
       │
       ▼
[DB에서 READY 이벤트 조회]
       │
       ▼
[이벤트 상태 OPEN으로 변경]
       │
       ▼
[유저 조회 → 알림 직접 전송 (동기)]
       │
       ▼
[완료]

 

MQ 도입 후엔 알림 로직이 메시지 큐를 통해 비동기로 처리되며, Scheduler는 메시지를 발행만 하고, 알림 전송은 Consumer가 병렬로 처리하게 되었다. 구조는 복잡해졌지만, 시스템 확장성과 안정성 측면에선 명확한 개선이 있었다.

[이벤트 등록 시]
       │
       ▼
[Redis ZSET에 Event 메시지 저장]
       │
       ▼
[Scheduler 실행 (주기적)]
       │
       ▼
[Redis ZSET에서 오픈 대상 조회]
       │
       ▼
[DB 상태 OPEN으로 변경]
       │
       ▼
[RabbitMQ로 오픈 메시지 발행]
       │
       ▼
[Consumer가 알림 비동기 전송]
       │
       ▼
[완료]

🐇 RabbitMQ 기반 알림 처리 전략

Exchange 타입

📌 Exchange란?
RabbitMQ에서 메시지를 수신하고, 적절한 Queue로 라우팅하는 역할을 하는 구성 요소.
Producer가 보낸 메시지는 먼저 Exchange로 도착하고,
Exchange는 메시지의 RoutingKey나 설정된 규칙을 기반으로 어떤 Queue로 메시지를 보낼지 결정한다.

• Direct : 정확히 일치하는 RoutingKey로 메시지를 전달
• Fanout : RoutingKey 없이, 바인딩된 모든 Queue에 메시지를 전파
• Topic : 패턴 기반 RoutingKey 매칭, 라우팅 패턴 간의 와일드카드(*) 혹은 해시(#)가 일치해야 매칭
• Headers : 메시지의 헤더 값을 기반으로 라우팅

프로젝트에서는 이벤트 오픈 시, 알림을 설정한 모든 유저에게 알림을 보내야 했기 때문에 Fanout 으로 설정했다.

DLQ  ·  DLX 구조

• DLQ(Dead Letter Queue) : 메시지 소비에 실패한 경우를 대비해 메시지를 별도로 저장하고 추후 재처리하거나 로그로 확인할 수 있게 해주는 구조
• 실패한 메시지는 DLX → DLQ로 이동, 이후 수동 재처리 또는 Retry Queue로의 자동 재처리 기반

TTL 기반 Retry 처리

• DLQ에 쌓인 메시지를 자동으로 재시도하기 위해 TTL(Time To Live)과 Retry Queue를 활용
• 실패한 메시지는 DLQ에서 다시 Retry Queue로 전송
• 해당 Queue에는 TTL이 설정되어 있어 일정 시간 뒤 원래 Exchange로 재전송