[기술적 선택] SSE 웹 기술을 활용한 이유 (알림 기능)

HTTP 프로토콜은 기본적으로 클라이언트가 요청을 보내고 서버에서 응답을 보내주면 연결을 끊어버린다.

채팅과 같은 서비스에서 계속 연결을 유지하고 응답 데이터가 지속적으로 이루어져야한다면? 

서버가 전송하고 싶어도 연결이 되어있지 않기 때문에 보낼 수 없는 상황이 발생할 것이다. 

 

그래서 이러한 문제점을 해결하기 위해 폴링, 긴 폴링, 소켓, SSE의 방식이 도입이 된 것이다.

 

 

Polling

 

 

 

클라이언트가 주기적으로 서버에게 요청을 보내는 방식을 폴링이라고 한다.

 

즉, 일정시간마다 클라이언트가 서버에게 데이터가 새로 생겼는지 확인하고 새로운 데이터가 있으면 응답을 받는 것이다. 

정말 단순한 방식이다. 

 

하지만 단순한만큼 계속 요청을 한다는 점에서 리소스 낭비가 발생한다. 필자의 생각은 알림이 발생하지 않는 상황에서 클라이언트가 서버에서 지속적으로 요청을 보낸다면 의미없는 낭비가 계속될 것이라고 판단되어 알림 서비스로 구현하기엔 적합하지 않은 방식이라고 생각된다.  

 

 

Long Polling

 

 

 

앞서 언급한 폴링 방식과 조금의 차이점이 있는데 유지 시간을 조금 더 길게 갖는다는 점이다. 

즉, 요청을 보내고 서버에서 변경이 일어날 때까지 대기하는 방법이다. 긴 폴링 방식을 사용한다면 지속적으로 요청을 보내지 않기 때문에 Polling 방식보다 부담이 덜 하게된다. 

 

하지만 지속적으로 연결이 되어있어서 다수의 클라이언트에게 동시에 이벤트가 발생하면 순간적으로 부담이 급증하게 된다. 그래서 이 방식 또한, 알림 서비스로 적합하지않다고 생각되었다. 

 

 

 

WebSocket

 

 

 

웹 소켓은 웹 브라우저와 웹 서버간의 양방향 실시간 통신을 가능케 하는 프로토콜이다. 

클라이언트와 서버 간에 양방향으로 데이터를 주고받을 수 있으며, 이로 인해 실시간성이 요구되는 애플리케이션에 적합하다. 실시간 채팅처럼 양방향 통신이 필요한 서비스를 구현한다면 적합한 기술이라고 생각되지만 알림과 같은 서비스는 한쪽에서 데이터를 수신하면 되기때문에 단방향이 유지되는 것이 적합하다고 생각했다.  

 

전이중 통신으로 알림을 구현하면 빠른 실시간성을 보장하는 대신 웹소켓이라는 자체적인 기능에 리소스를 많이 할당해야한다. 즉, 서버와 클라이언트 간의 Socket 연결을 유지한다는 것 자체가 비용이 드는 일. 특히나 트래픽양이 많은 서버 같은 경우에는 CPU에 큰 부담이 될 수 있다는 결론이다.  

 

 

 

SSE (Server-Sent Events)

 

 

 

SSE는 HTTP 스트리밍을 통해 서버에서 클라이언트로 단방향의 푸시 알림을 전송할 수 있는 HTML5 표준기술이다. 

 

웹 소켓 방식이 서버와 클라이언트 간의 연결을 유지해야하는 반면 SSE는 http 연결만 되어있으면 클라이언트 요청없이도 서버에서 클라이언트로 데이터를 보낼 수 있다. 

 

SSE를 이용하면 별도의 복잡한 기술이 필요없이 HTTP 프로토콜을 기반으로 서버에서 클라이언트로 실시간 푸시 알림을 전송할 수 있다. 클라이언트의 요청에 의해 한 번 연결이 맺어지면 서버가 원하는 시점에 클라이언트에게 원하는 메세지를 전송할 수 있다. 이런한 특징 덕분에 최소의 오버헤드로 모니터링 시스템의 그래프 갱신, 채팅 및 메신저 등의 비지니스에 광범위하게 적용할 수 있다. 

 

알림 서비스를 구현하기에 적합한 웹 기술이라고 판단되어 해당 기술을 채택하여 프로젝트를 진행하기로 하였다.