우리는 서비스 중 스케줄을 관리해주는 서비스가 있다.
스케줄에 적힌 시간에 가까워지면 알림을 보내주는 기능을 만드려고 하는데,
알고 있는 것은 web socket과 pub/sub을 이용하는 방법 뿐이었다.
그런데 찾다보니 sse(Server-Sent-Event)라는 것을 알게 되었다.
그리고 나는 sse를 사용하는 것으로 선택했다.
그 이유를 정리해보려 한다.
SSE(Server-Sent-Event)
서버에서 클라이언트로 실시간 이벤트를 전달하는 웹 기술이다.
HTTP 특징인 비연결성은 연결한 적이 있어도 연결을 끊어버린다는 것이다.
이를 해결하기 위한 웹 기술은 Polling, Long Polling, WebSocket 그리고 SSE가 있다.
여기서 SSE는 단방향 통신이며 클라이언트의 별도 추가요청 없이 서버에서 업데이트를 스트리밍할 수 있다는 특징을 가진다.
여기서 중요하게 본 것은 실시간과 단방향이다.
WebSocket vs SSE
Socket과 SSE에 가장 큰 차이점을 하나 말해보라고 한다면 Socket은 양방향(bidirectional)으로 데이터를 주고 받을 수 있지만 SSE(Server-Sent-Event)를 사용하게 되면 클라이언트는 데이터를 받을 수만(mono-directional) 있게 된다.
| Socket | Server-Sent-Event | |
|---|---|---|
| 브라우저 지원 | 대부분 브라우저에서 지원 | 대부분 모던 브라우저 지원(polyfills 가능) |
| 통신 방향 | 양방향 | 일방향(서버에서 클라이언트로) |
| 리얼타임 | Yes | Yes |
| 데이터 형태 | Binary, UTF-8 | UTF-8 |
| 자동 재접속 | No | Yes(3초마다 제시도) |
| 최대 동시 접속 수 | 브라우저 연결 한도는 없지만 서버 셋업에 따라 다름 | HTTP를 통해서 할 때는 브라우저당 6개 까지 가능 / HTTP2로는 100개가 기본 |
| 프로토콜 | websocket | HTTP |
| 베터리 소모량 | 큼 | 작음 |
| Firewall 친화적 | Nope | Yes |
우리의 서비스는 알림을 주는 것이므로 굳이 양방향일 필요가 없다.
배터리 및 데이터 소모량 또한 소켓은 계속 서버랑 계속 handshake를 하고 있는데, SSE는 한번 열어두고 계속 기다리고 있다. 아무리 소켓이 서버에 보내는 데이터가 적긴 하지만 계속 열려 있다면 어쩼든 왔다 갔다 하니까 더 클 수밖에 없다.
결국 실시간 통신이 가능하면서, 단방향으로 자원을 덜 먹는 SSE를 선택하게 된 것이다.
고민해야 할 것은 최대 동시 접속 수 인데, 잘 고민해봐야겠다.
