항해99의 파이널 프로젝트 당시 구현한 기능 중 실시간 알림 기능이 있었다. .서버 > 클라이언트 단방향 통신을 실시간으로 제공하면서 구현이 간단했기 때문에, 알림 기능은 SSE 를 사용하기로 했고 실제 SSE 로 구현되었다. 당시 SSE 를 사용하기로 결정한 가장 큰 이유는 [실시간으로 단방향 통신이 가능하다는 점 + 구현의 간단함] 이었다.
프로젝트 이후에 "Websocket 기능이 잘 작동한다면 실시간 알림 또한 socket 을 사용해서 할 수 있었을텐데 왜 굳이 SSE 를 새로 도입해서 작성했는가" 하는 질문이 있었는데, 이에 대한 대답으로 "SSE가 Websocket 보다 경량의 통신을 제공하기 때문에 리소스를 절약할 수 있다" 는 말이 떠올랐지만(SSE 를 공부하면서 구글링하여 얻은 정보), "SSE 가 Websocket 보다 경량의 통신을 제공하는 이유가 무엇인가?" 에 대한 근거를 대답할 수 없어 이 부분에 대해 공부가 더 필요하다고 생각했다. 해서 Websocket과 SSE 의 차이와 간단한 통신 스펙, SSE 를 선택한 이유에 대해 간단히 정리해 보겠다. 나아가 알림 기능을 구현하기 위해 고려되었던 기술들인 폴링, 롱 폴링에 대해서도 정리해 보고자 한다.
폴링(Polling)
폴링은 클라이언트가 서버의 실시간 응답을 얻기 위해 사용해 왔던 전통적인 방법으로, 클라이언트 측에서 짧은 간격으로 서버에 계속해서 요청을 보내고 서버의 변경사항을 응답으로 받아오는 방법이다. 폴링은 서버에 지속적으로 Http 요청을 보내는 방식이기 때문에 실시간성을 높이기 위해서는 요청을 보내는 주기가 짧아져야 하고, 이 과정에서 리소스 낭비와 성능저하가 불가피하다. 서버 부하를 줄이기 위해 요청 주기를 길게 하면 실시간성이 떨어지는 문제가 있다.
롱 폴링(Long-Polling)
롱 폴링은 폴링의 이러한 문제들을 개선한 방식이다. 서버는 요청에 대해 즉각적으로 응답하지 않으며, 서버의 변경사항이 발생할 때(event) 에만 응답을 전송한다. 클라이언트는 응답을 받으면 다음 이벤트를 받기 위한 요청을 보낸다. 폴링 방식에 비해 요청이 줄어들고 실시간성을 확보하였지만, 서버 데이터의 변경사항이 빈번한 경우 폴링과 비교했을 때 큰 이득을 얻지는 못한다.
또한 다수의 사용자가 동시에 사용하는 서비스인 경우, 서버의 응답에 대해 다수의 요청이 동시에 발생해 서버 부하가 커질 수 있기 때문에 롱 폴링 대신 폴링을 고려하기도 한다. 따라서 롱 폴링이 폴링보다 항상 좋은 선택지는 아니며, 서비스의 성격에 따라 적절한 방법을 사용하는 것이 좋다.
SSE(Server-Sent Event)
sse 는 단방향 실시간 통신을 지원하는 웹 기술이다. Http 표준 규약을 따르기 때문에 별도의 프로토콜이 필요하지 않고, 구현이 간단하여 서버에서 실시간 이벤트를 푸시하는 데 많이 사용된다. 클라이언트에서 서버로 sse 연결을 요청하면 지정한 시간 동안 Http 연결이 유지되고, 연결이 끊어지면 서버에서 자동으로 재연결 요청을 보낸다. Http 연결이 유지되는 동안 서버에서 클라이언트로 이벤트를 푸시할 수 있다.
폴링, 롱 폴링과의 차이점은 응답을 받는 과정에서 요청 없이 실시간으로 데이터 전송이 가능하다는 점이다. 폴링과 롱 폴링은 실시간으로 응답을 받기 위해 한번의 요청을 보내는 과정이 필요한데, sse를 사용하면 서버사이드에서 클라이언트로 바로 데이터를 푸시해 준다.
웹소켓(Web Socket)
웹 소켓은 서버와 클라이언트 간 웹 소켓 Connection 을 유지해서 실시간으로 양방향 통신이 가능하게끔 하는 기술이다. 클라이언트가 서버로 웹소켓 핸드셰이크를 통해 웹소켓 연결을 시작하면 Http에서 Websocket 으로 프로토콜이 업그레이드되며 실시간으로 양방향 통신이 가능하게 된다.
별도의 Websocket 프로토콜을 사용하므로 서버 측 인프라가 추가되거나 구현의 복잡성이 증가될 수 있고, 전이중 연결을 계속 유지해야 하기 때문에 서버 부하가 커질 가능성이 있다.
기술적 의사결정(SSE)
알림 기능을 구현하기 위해 SSE 를 선택했던 가장 큰 이유는 실시간으로 서버측에서 데이터를 푸시할 수 있는 간단한 Http 기반 기술이라는 것과 WebSocket 에 비해 구현이 간단하다는 점 때문이었다. 폴링과 롱 폴링은 이벤트마다 Http 요청을 생성해야 한다는 한계 때문에 고려 대상에서 일찌감치 제외되었다.
이미 웹 소켓으로 채팅 프로그램이 구현되어 있는 서비스에 실시간 알림을 위해 웹 소켓을 사용하지 않고 SSE를 새로 도입한 이유는, 알림 기능을 위해서는 웹 소켓보다 SSE 를 사용하는 것이 서버 측 부하를 줄이고 리소스를 절약할 수 있는 방법이기 때문이다. 웹 소켓을 사용하여 푸시 알림 기술을 구현하려면 접속한 사용자 모두에 대해 웹소켓 연결을 유지하기 위해 많은 리소스를 사용하고 이로 인한 서버 부하가 커질 것이다. SSE는 많은 사용자가 동시에 접속해 있더라도 Http연결만 유지되면 실시간 데이터를 푸시할 수 있다.
따라서 내 파이널 프로젝트와 같이 실시간성이 강조되지 않고 이벤트가 자주 발생하지 않으며 단방향 통신만 필요한 서비스 기능 구현을 위해서는 SSE 를 사용하는 것이 적절하다.
'Study' 카테고리의 다른 글
| SseEmitter 를 사용한 푸쉬알림 (0) | 2023.07.17 |
|---|---|
| 자바 데이터 타입, 변수, 배열 (0) | 2023.07.15 |
| 나는 Soolo 프로젝트 회고 (2) | 2023.07.05 |
| 인텔리제이 한글 인코딩 오류(UTF-8) (0) | 2023.04.29 |
| 객체지향 기본 1(클래스, 메서드, 생성자) (1) | 2023.03.11 |
