Server Side Event (SSE)

WebSocket과 달리, SSE 는 http를 그대로 이용하며, 단방향 통신을 한다. 따라서 서버 -> 클라이언트 로 일방적인 전송을 한다. 

Http 를 이용하는것이 좋은게, 왠만한 방화벽은 Http는 허용하기 때문이다. WebSocket의 경우 Http Upgrade를 이용하므로 방화벽 설정을 별도로 해 줘야 할 수도 있다. 

 

기본적으로 Async를 통해 실행되는게 좋으므로, Task Executor 설정 등을 별도로 해주는게 좋다.

 

SSE 특징

• 연결 정보(SseEmitter)를 메모리에 저장해 놓고 있고, 유실 시 복구가 불가능 하다.
  • Emitter 자체는 복구가 불가능 하나, 이벤트는 DB 혹은 kafka 등을 통해 복구 가능하다.
• 연결이 끊기면 웹브라우저에서 재접속을 자동으로 요청한다.
• SSE는 웹 뿐아니라 앱도 지원 한다.
• 별도의 map 에서 연결정보(SseEmitter) 를 관리해야 하고, 미전송 이벤트 관리 등을 수동으로 구현해야 한다. 
• Text 방식으로 주고 받는다.
  • data, event, id, retry로 로 구성
  • 클라이언트가 재 연결시, 어디까지 이벤트를 수신하였는지 Last-Event-ID 를 같이 서버로 보내준다.
    • 서버는 이를 받아 수동으로 미전송 데이터를 다시 보내야 한다
• 알림, 주식 데이터 같은 실시간 push 용도로 많이 사용 한다. 
• 메모리에 저장을 하다 보니, 데이터 유실 및 메모리 사용량을 유의해야 한다.
  • 연결 수 제한 필요
  • 타임아웃 등 주기적으로 스케줄링을 통해 연결을 제거할 필요 

 

동작 요약

• 클라이언트가 서버로 연결 요청
• 서버가 SseEmitter을 생성하여 리턴
• 서버에서 필요할 때 마다 SseEmitter을 이용하여 클라이언트에 전송
  • 전송 내용을 미리 클래스로 정의

 

클라이언트 요청시

• media-type 가 Text Event Stream 이어야 한다.
• http 연결 정보를 끊지 않고 keep-alive를 통해 유지하게 된다.
• cache control은 no-cache 이어야 한다.
• 서버에서는 ResponseEntity가 아니라 SseEmitter 형을 리턴하게 된다.

 

서버에서 클라이언트로 내용 전송

• 별도로 저장한 SseEmitter 를 이용하여 send 메서드 호출
• data 항목에 전송할 데이터를 전달
• 기능을 분리하여 전송을 담당하는 서비스를 호출하는 방식이 좋다.

 

SseEmitter 기능분리 관련

SseEmitter 관리

• 다수의 SseEmitter 를 관리하는 주체가 있는것이 좋다. 
• map을 통해 전체 SseEmitter 를 저장, 관리한다.
• SseEmitter 생성 및 이벤트 콜백 등록
  • 생성시 기존 연결 정보가 있는지 확인 후 있다면 정리 필요
  • 생성시 최대 접속 count 라면 연결 불가 처리 필요
  • onCompletion, onTimeout, onError 시 map 에서 삭제
• 스케줄러를 통해 주기적으로 heartbeat 전송 및 접속 정리

 

전송 필터링

• 클라이언트가 서버로 연결시, 어느 알림 혹은 어느 데이터를 받을지 명시하여, 서버가 선택적으로 필터링하여 필요한 클라이언트에게만 전달 되도록 해야 한다.

 

전송

• 필터링을 통해 전달받은 SseEmitter 를 이용해 실제 메세지를 전송한다.
• 우선순위가 만일 있다면 , PriorityQueue 자료형을 활용 할 수 있다.

 

메세지 재전송을 위한 내용 저장

• SseEmitter 는 저장이 불가능 하지만, 전송될 내용, 전송 결과 등은 DB에 저장이 가능하다.
• 연결이 끊겨 재연결시 클라이언트는 Last-Event-ID 를 보내는데, 이를 통해 이어서 내용 전달이 가능해야 한다.

 

다중 서버 환경을 고려

• SSE는 서버 상태(Stateful)을 가지므로, 다중서버 환경에서는 Redis Pub/Sub, Kafka 등 메세지브로커와 함께 사용해야 한다.