SSE 알림 시스템 개선기

문제 상황

사용자에게 실시간 알림을 제공하기 위해 SSE를 사용하고, 알림 전송 로직은 Spring Event를 통해 구현했습니다. 하지만 1000명이 연결이 되어 있는 상태에서 1000명의 사용자가 10만개의 데이터를 전송하는 부하 테스트 결과, 응답 시간에 심각한 지연과 오류가 발생했습니다. 게다가 알림 메세지 처리 과정에서 오류가 발생하면, 이벤트를 발생시킨 원본 트랜잭션까지 롤백되는 문제가 확인되었습니다. 

 

문제 분석

HikariCP Connection Pool (Pending 되는 스레드 수가 많음)

문제의 원인을 찾기 위해 모니터링 결과, 부하 발생 시 HikariCP의 Active 커넥션 수치가 최대치에 도달하고, DB 커넥션을 할당받기 위해 대기하는 Pending 스레드의 수가 급증하는 현상을 확인했습니다. 이는 DB 커넥션이 장기간 점유되어 후속 요청들이 처리되지 못하고 병목 현상을 겪고 있음을 확인했습니다. 

 

근본 원인

문제의 핵심 원인은 Spring Event의 동기적 실행 방식과 트랜잭션 범위에 있었습니다. 

 

@Component
@RequiredArgsConstructor
public class NotificationEventListener {
	
	private final NotificationService notificationService;
	private final SseService sseService;
	
	@EventListener
	public void handleNotificationEvent(NotificationEvent event) {
		notificationService.createNotification(event);
		sseService.send(event);
	}
	
}

현재 코드에서는 애플리케이션 레이어에서 @EventListener를 사용해 추가적인 작업을 호출하고 있었습니다. 이때 별도의 설정을 하지 않으면 @EventListener는 기본적으로 이벤트를 발생시킨 부모 스레드에서 동기적으로 실행됩니다. 이로 인해 이벤트 리스너는 부모 메서드의 트랜잭션에 그대로 참여하게 됩니다. 

 

이러한 구조 때문에, 부모 트랜잭션은 이벤트 리스너 내부의 모든 로직(SSE 알림 전송, 알림 저장)이 완료 될때까지 종료되지 않고 DB 커넥션을 계속 점유하게 됩니다. 이로 인해 커넥션의 점유 시간이 불필요하게 길어지면서, 커넥션 풀 고갈을 초래했습니다. 

 

결과적으로, 후속 요청을 처리해야 할 다른 스레드들이 커넥션을 할당받지 못하고 대기하는 시간이 급증하여, 응답 지연과 병목 현상이 발생했습니다. 

 

개선 방안

1차 개선

@Component
@RequiredArgsConstructor
public class NotificationEventListener {
	
	private final NotificationService notificationService;
	private final SseService sseService;
	
	@Async("notificationExecutor")
	@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
	public void handleNotificationEvent(NotificationEvent event) {
		notificationService.createNotification(event);
		sseService.send(event);
	}
	
}

위의 문제를 해결하기 위해 @EventListener를 @TransactionalEventListener(phase = AFTER_COMMIT)으로 변경하여, 부모 트랜잭션이 성공적으로 커밋된 이후에만 이벤트가 처리되도록 보장하였고 @Async 어노테이션을 추가하여 이벤트 처리가 별도의 스레드 풀에서 비동기적으로 실행되도록 변경하였습니다. 

 

1차 개선 결과

1차 개선을 통해 애플리케이션 로직과 알림 처리 로직의 스레드와 트랜잭션을 분리함으로써 DB 커넥션을 점유하는 시간을 줄여 API 응답 시간은 개선되었지만, 이는 문제의 일부만을 해결했을 뿐이며, 여전히 아래와 같은 문제들이 남아있었습니다. 

 

1차 개선 문제점

개선된 방식은 다수의 스레드를 생성하고 관리하는 과정에서 발생하는 컨텍스트 스위칭 오버헤드로 인해, 동기 방식에 비해 더 높은 CPU 사용량을 보였습니다. 또한, 알림 요청이 집중될 경우, API 서버의 CPU 리소스가 과도하게 소모되는 현상이 발생했습니다. 

 

1000명이 연결되어 있는 상태에서 1000명이 API를 요청한 상황

또한, SSE 연결은 API 서버의 Tomcat 커넥션을 장기간 점유합니다. 이러한 상황에서 다수의 SSE 클라이언트가 연결을 유지하고 있을 때, 그 만큼 연결할 수 있는 커넥션이 줄어들게 되고, 비동기 알림 처리까지 증가한다면, 가용 스레드가 고갈되어 새로운 API 요청을 처리하지 못하는 장애로 이어질 수 있었습니다. 

 

2차 개선

1차 개선으로 API 응답 속도는 개선했지만, 서버의 CPU 및 스레드 고갈에 대한 위험은 여전히 남아있었습니다. 이를 해결하기 위해 알림 처리 시스템을 API 서버로부터 완전히 분리하는 아키텍처 변경을 결정하였습니다. 

 

두 시스템을 안정적으로 연결하기 위한 핵심 기술로 메세지 큐를 도입했고, 여러 선택지 중 RabbitMQ를 최종 선택하게 되었습니다. 

 

RabbitMQ를 선택한 이유

메세지 큐 도입을 결정했을 때, RabbitMQ와 Kafka 중 어떤 것을 선택할 지 고민했습니다. 저희의 요구사항은 SSE 서버에 알림을 실시간으로 전송하는 것이었기 때문에, 각 시스템의 특서오가 장단점을 비교한 후 결정했습니다. 

 

RabbitMQ는 Smart Broker 모델로, 브로커가 메세지 컨슈머에게 적극적으로 밀어주는 Push 방식입니다. 이는 메세지가 도착하는 즉시 처리해야하는 요구사항과 부합했지만, Kafka는 Dumb Broker 모델로, 컨슈머가 주기적으로 브로커에게 새 메세지를 요청해야 하는 Pull 방식으로 대용량 데이터의 일괄 처리에 더 최적화된 모델이라고 판단했습니다. 

 

결론적으로 지연 시간이 핵심인 SSE에는 RabbitMQ가 더 적합하다고 판단했습니다. 

 

아키텍처

API 서버는 비즈니스 로직 처리 후, 알림에 필요한 정보를 Spring Event로 넘기고 알림 데이터를 저장한 후 RabbitMQ로 발행합니다. SSE 서버에서는 해당 큐를 구독하고 있다가 저장된 메세지가 큐에 전송되게 되면, 이를 가져와 데이터를 조회한 후, 해당 사용자에게 SSE 연결을 통해 알림을 전송하게 됩니다. 

 

개선 결과

• RPS: 697 → 951 (36.4% 증가)
• 응답 시간 (median): 910.49ms → 56.32ms (93.8% 감소)
• 응답 시간 (mean): 1.08s → 83.73ms (92.2% 감소)
• 응답 시간 (p90): 1.83s → 104.47ms (94.3% 감소)
• 응답 시간 (p95): 2.60s → 159.16ms (93.9% 감소)

이번 개선을 통해 SSE 알림 기능이 전체 시스템 성능에 미치는 부담을 근본적으로 제거할 수 있었고, 안정성과 확장성을 동시에 확보할 수 있었습니다. 특히 API 서버와 SSE 서버를 분리하여 SSE에 대한 부하가 증가하더라도 다른 서비스에 영향을 주지않고 독립적으로 확장할 수 있는 기반이 마련되었습니다.