알람 시스템에 메시지 큐 도입

[attlet]

메시지 큐 오픈소스 도입해서 알람 개선

• 현재는 단일 서버에서 애플리케이션을 구동한다는 전제로 concurrentHashMap에 emitter를 저장하고, 알람을 구현
• 다중 서버를 고려해 메시지 큐를 도입할 필요 있음.

기대 효과

• 서버 확장성 : 서버를 증설하기 쉬워짐
• 비동기 메시지 처리로 병목 현상 감소
• 데이터 유실 가능성 : concurrentHashMap과 달리 서버 재시작 시 데이터 손실되지 않음
• 메시지 처리 도중 장애 복구 : 장애 발생 시 replication 이나 파티션 등을 이용해 복구 가능

[attlet]

현재 알람 전송 방식

• 사용자가 subscribe --> 해당 사용자에 대한 SseEmitter 생성, 저장

• 알람 발생 시 notification 엔티티 저장 --> SseEmitter map에서 조회해서 알람 사용자에게 전송

위 방식의 문제점

• 다중 아키텍처 환경일 경우, 동일한 유저에 대한 SseEmitter가 한 서버에서만 관리되기 때문에 문제가 생긴다.
• 사용자 연결 끊김에 의한 메시지 손실 우려가 있다.
• 메모리에서 SseEmitter가 관리되고, 연결이 늘어나면 메모리 한계에 도달할 수도 있다.

[attlet]

메시지 큐 솔루션 선택

1. redis pub/sub

장점

• 설정이 단순하고, 빠른 응답 속도 가짐(메모리 기반이기에)
• redis를 캐시 기능을 위해 이미 도입했을 시 통합 용이

단점

• 확장성이 부족함
• 메시지 보존이 보장되지 않음

2. rabbitMq

장점

• 설정이 간단함(redis보다는 복잡함)
• 유연한 메시지 전달 방식 제공
• 메모리에서 처리하는 방식을 통해 빠른 속도를 제공
• 메시지 보존 가능

단점

• 대규모 아키텍처에서는 성능이 제한됨

3. apache kafka

장점

• 대규모 메시지 처리에 효과적
• 메시지 보존, 메시지 로그를 통해 안정성 보장
• 분산 아키텍처에서도 유용
• 메시지 순서 보장

단점

• 설정이 복잡함

• 메시지량이 적으면 비효율적

  -> 공부를 위해 redis pub/sub부터 시작해서 모두 적용할 수 있도록 하기

[attlet]

rabbitMQ 세팅

1. 설정

spring:
  profiles: dev
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
    queue: my_queue
  notification:
    broker: rabbitmq

build.gradle.kts에 의존성 추가

//rabbitMQ
    implementation("org.springframework.boot:spring-boot-starter-amqp")

2. producer, consumer 구현

• 인터페이스를 통해 실행환경에 따라 다른 메시지 큐 툴을 적용할 수 있도록 함.
• producer는 메시지 발생 시 rabbitMq에 메시지 전달을, consumer는 수신자들에게 메시지를 전달함

[attlet]

redis pub/sub 세팅

1. redis 설정

spring:
  redis:
    host: localhost
    port: 6379

build.gradle.kts에 의존성 추가

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-data-redis")
}

[attlet]

redis pub/sub 의 구현 과정에서 특이점

• redis pub/sub의 경우 producer에서 데이터 전송 시 notification 객체를 그냥 전송하면 오류 발생. json이나 문자열 등으로 직렬화가 필요.

                ex) notification.toJson() 사용

• redis consumer는 추가로 MessageLister를 상속받아서 onMessage 메서드를 구현