[Spring Boot] 실시간 알림 SSE(Server-Sent Events)로 구현하기

🚀 개요

프로젝트에서 실시간 알림 기능을 구현해야 했다.

 

초기에 고민하던 중

 

주기적으로 서버에 요청을 보내는 방식을 택했는데

 

나중에 알고보니 Short Polling 이라고 불리는 방식이었다.

 

웹 통신 방식엔 Long Polling과 웹 소켓 방식도 있는데 이 글에서 설명하진 않는다.

 

⭐ Short Polling

출처: fakerdeft

계속 요청과 응답을 반복하는 흔한 방식이다.

 

주기적으로 요청을 보낸다니 대체 어느 간격으로?

 

내가 생각한 방법은 5초마다 알림 조회 요청을 보내는 것이었다.

 

바보가 아닌 이상

 

이 방법은 동시 사용자가 늘어날수록 요청이 기하급수적으로 비례해 늘어날 것이다.

 

길게 보면 누가봐도 리소스를 많이 먹는 구조이다.

 

나는 이렇게 이벤트가 발생해도 바로 안 보내지고

 

주기적으로 조회해야 하는 방법보다는

 

서버에서 이벤트가 발생하는 순간에 알림을 보내고 싶었다.

 

방법을 계속 생각하다 보니 웹 소켓도 생각했었다.

 

하지만 소켓은 러닝커브가 있어서 부담스러웠다.(언젠간 해야겠지?)

 

그러다 정말 내가 원하던 방식을 찾았다.

 

⭐ SSE(Server-Sent Events)

출처: fakerdeft

SSE는 한 번 요청을 통해 구독하면 연결이 지속된다.

 

서버에서는 클라이언트와 매핑되는 SSE 통신 객체를 만든다(SseEmitter).

 

SseEmitter는 서버에서 클라이언트로 비동기적으로 이벤트 스트림을 전송할 수 있게 해주는 스프링의 클래스이다.

 

연결되어 있는 동안 이벤트 발생시 해당 객체가

 

EventSource를 클라이언트에게 전송하면서 데이터가 전달되는 방식이다.

 

무한 요청을 해결할 수 있다니...

 

정말 내가 생각하던 방식하고 완전 찰떡이어서 바로 적용하기로 했다.

 

🚀 SSE 적용하기

⭐ Controller

NotificationController

현재 프로젝트가 JWT 로그인으로 이루어져 있어서

 

클라이언트에서는 액세스 토큰을 담아서 보내준다.

 

따라서 UserDetails를 통해 사용자 식별이 가능하다.

 

lastEventId 파라미터는 만약 해당 사용자에 대한 미수신 알림이 있다면 보내주기 위함이다.

 

그리고 요청의 Accept 헤더가 "text/event-stream"을 포함하고 있는 경우에만, 이 메서드가 요청을 처리하게 됨을 의미한다.

 

⭐ Repository

알림을 위해 현재 총 3개의 DB를 운용하고 있다.

• emitterMap : SseEmitter 객체 저장용
• eventCache : 연결이 끊겨있는 동안 발생하는 이벤트 객체 저장용
• tbl_notification : 모든 알림 엔티티 저장용 - MySQL

EmitterRepository

ConcurrentHashMap 은 멀티스레드 환경에서 사용하기 좋은 thread-safe한 자료구조이다.

 

동시 사용자가 존재할 경우 유용하다고 알고 있다.

 

⭐ Service

connect method

1. 첫 연결 시 eventId를 생성한다.

특이한 점은 eventId에 현재 시간을 포함하는데 이유는 다음과 같다.

Last-Event-Id = 3

{3, data1}
{3, data2}
{3, data3}

=> 어떤 데이터까지 제대로 전송되었는지 알 수 없다.

Last-Event-Id = 3_1631593143664

{3_1631593143664, data1}
-------연결 끊김-------
{3_1731593143664, data2}
{3_1831593143664, data3}

=> data1 까지 제대로 전송되었고, data2, data3을 다시 보내야한다.

다음과 같이 3이라는 ID를 가진 회원의 이벤트 중 뒤의 시간을 기준으로 구분할 수 있게 된다.

어떠한 이유로 클라이언트와 서버 간 연결이 끊겼고 그 시점 이후로 발생한 이벤트들은 클라이언트로 가지 않고 쌓인다.

 

재연결 시, 어떤 이벤트부터 다시 보내줘야 할 지 구분하기 위해서 eventId를 사용한다.

 

클라이언트는 연결 요청 헤더에 Last-Event-Id 를 담아서 보내면 된다.

 

2. SseEmitter 객체 생성 후 Map에 저장한다.

SseEmitter 타임아웃 시간은 우리 토큰 유효기간에 맞게 설정했다.

 

3. onCompletion 및 onTimeout 설정

SseEmitter 의 전송 완료 혹은 타임아웃, 에러로 인한 전송 불가 시 sseEmitter를 삭제한다.

 

4. 연결 시 응답을 보내지 않으면 503 에러가 발생하므로 최초 연결 시 더미 이벤트를 전송한다.

 

5. 클라이언트가 미수신한 Event 목록이 존재할 경우 전송하여 Event 유실을 예방한다.

연결 요청 헤더에 Last-Event-Id가 있다면 여기서 사용된다.

 

전송되지 않고 쌓인 Event들을 찾아서 보내기 위해 사용되는 것이다.

 

send method

다른 서비스 클래스에서 이벤트가 발생했을 때 이 send() 메서드를 호출해서 알림을 보낸다.

 

1. 먼저 알림을 DB에 저장한다.

 

2. eventId를 만든다.

 

3. '알림을 받을 대상'의 이벤트 객체를 가져온다.

예를 들어, 내가 남긴 질문에 다른 사람이 답변을 달면 '알림을 받을 대상'은 곧 자신이다.

 

클라이언트로 직접 보내는 method

이 메서드를 통해 비로소 서버 측 이벤트가 클라이언트로 직접 간다.

 

🚀 결과

⭐ 무한 재귀 문제 발생 및 해결

해당 오류가 계속 났었다.

 

처음에 원인 파악을 못하고 있다가

 

한 곳 한 곳 열심히 로그 찍어가며 찾아보니

 

Caused by: com.fasterxml.jackson.databind.JsonMappingException: Infinite recursion (StackOverflowError)

 

이런 녀석이 보였는데 알고보니

 

엔티티 간의 양방향 관계를 직렬화할 때 발생하는 무한 재귀 문제라고 한다.

 

@JsonManagedReference 및 @JsonBackReference 애노테이션을 활용해 잘 해결했다.

 

추후에 따로 트러블 슈팅 글로 작성할 예정이다.

 

이제 테스트를 위해 내 질문에 (원래 안되지만)내가 답변을 달면

 

실시간으로 알림이 가는 모습이다.

실시간으로 알림이 온다!

쉬울 줄만 알았던 sse도 구현하는 과정이 생각보다 어려웠다.

 

그래도 잘 구현한 것 같아 만족한다.

 

이제 프론트님들하고 상의해서

 

실시간 알림 UI를 어떻게 보여줄지가 관건이다.

 

- 끝 -