실시간 업데이트? 웹소켓 대신 SSE를 써야 하는 이유
대부분의 실시간 애플리케이션은 서버에서 클라이언트로의 단방향 통신(Server-to-Client)만 필요하며, 웹소켓(WebSocket)은 과도한 복잡성을 야기함
서버 전송 이벤트(SSE)는 HTTP 기반으로 구현되어 단순성(Simplicity), 자동 재연결(Auto-Reconnect), HTTP/2 멀티플렉싱(Multiplexing) 등의 장점을 가짐
실제 프로덕션 환경에서 SSE는 웹소켓과 유사한 성능(Similar Performance)을 보이며, 리소스 사용량 및 구현 복잡성 측면에서 유리함
웹소켓에서 SSE로의 마이그레이션은 HTTP POST 요청(HTTP POST Request)과 SSE 엔드포인트(Endpoint)를 통해 비교적 간단하게 수행 가능
SSE의 동작 원리: HTTP 기반의 단순함
SSE는 단방향 통신(Unidirectional Communication)에 특화된 기술로, HTTP 프로토콜(HTTP Protocol)을 기반으로 서버에서 클라이언트로 데이터를 스트리밍한다.
`text/event-stream` Content-Type: 서버는 `text/event-stream` 타입으로 응답을 전송하여 SSE 스트림(SSE Stream)을 시작
데이터 형식: `data: { ... }\n\n` 형식으로 데이터를 전송하며, 각 데이터 블록은 `data:` 접두사로 시작하고, 빈 줄(\n\n)로 구분
자동 재연결: 클라이언트 측 EventSource API(EventSource API)는 연결이 끊어질 경우 자동으로 재연결(Auto-Reconnect)을 시도
SSE는 웹소켓(WebSocket)과 달리 별도의 프로토콜 업그레이드(Protocol Upgrade)나 핸드셰이크(Handshake) 과정이 필요 없어 구현이 간단하고, HTTP 인프라(HTTP Infrastructure)를 그대로 활용할 수 있다.
웹소켓(WebSocket) vs SSE: 성능 비교
본문에 따르면 Timeplus의 벤치마크(Benchmark) 결과, SSE와 웹소켓은 100,000 events/sec 처리 시 유사한 성능(Similar Performance)을 보였다.
최대 처리량: SSE와 웹소켓 모두 3M events/sec 처리 가능
CPU 사용량: SSE는 웹소켓보다 약간 높은 CPU 사용량(CPU Usage)을 보였지만, 그 차이는 미미함
지연 시간: 웹소켓이 SSE보다 약간 낮은 지연 시간(Latency)을 보였지만, 3ms 차이는 대부분의 애플리케이션에서 무시할 수 있는 수준
SSE는 HTTP/2(HTTP/2)를 통해 멀티플렉싱(Multiplexing)을 지원하여, 단일 TCP 연결(TCP Connection)에서 다수의 스트림을 처리할 수 있어 효율적이다.
SSE의 장점: 단순성, 자동 재연결, HTTP/2
SSE는 웹소켓(WebSocket)에 비해 여러 가지 장점을 제공하며, 특히 단순성(Simplicity)과 HTTP/2(HTTP/2) 지원이 주요 특징이다.
단순한 구현: SSE는 HTTP 기반으로 구현되어, 웹소켓보다 구현 복잡도(Implementation Complexity)가 낮고 디버깅(Debugging)이 용이
자동 재연결: EventSource API(EventSource API)는 연결이 끊어질 경우 자동으로 재연결(Auto-Reconnect)을 지원하여, 개발자가 별도의 재연결 로직을 구현할 필요가 없음
HTTP/2 멀티플렉싱: HTTP/2를 통해 단일 TCP 연결(TCP Connection)에서 다수의 SSE 스트림을 처리할 수 있어, 연결 오버헤드(Connection Overhead)를 줄이고 효율적인 통신 가능
이러한 장점들로 인해 SSE는 단방향 실시간 통신(Unidirectional Real-time Communication)이 필요한 대부분의 애플리케이션에서 웹소켓보다 더 나은 선택이 될 수 있다.
실제 프로덕션 사례: Shopify BFCM Live Map
Shopify의 BFCM(Black Friday/Cyber Monday) Live Map은 SSE를 활용하여 대규모 트래픽(High Traffic)을 처리하고 실시간 판매 데이터를 시각화했다.
아키텍처: Flink(Flink)를 사용하여 Kafka(Kafka) 스트림에서 판매 이벤트를 처리하고, SSE 서버(SSE Server)를 통해 프론트엔드(Frontend)에 데이터를 전송
결과: 4일 동안 3230억 개의 이벤트(Events)를 처리하고, 수백만 개의 동시 SSE 연결(Concurrent SSE Connections)을 지원
성능: P50 지연 시간(Latency) 45ms, P95 지연 시간 120ms, 4 vCPU 서버에서 30%의 CPU 사용률(CPU Usage)
이 사례는 SSE가 대규모 실시간 데이터 스트리밍(Real-time Data Streaming)에 적합하며, 웹소켓(WebSocket)보다 더 효율적인 선택이 될 수 있음을 보여준다.
웹소켓(WebSocket)에서 SSE로의 마이그레이션
웹소켓(WebSocket)을 사용하고 있는 경우, SSE로의 마이그레이션(Migration)을 통해 코드 복잡성(Code Complexity)을 줄이고 성능을 향상시킬 수 있다.
통신 패턴 분석: 클라이언트(Client)가 서버(Server)로 전송하는 메시지 유형을 파악하고, 구독(Subscription) 및 설정 관련 메시지는 HTTP POST 요청(HTTP POST Request)으로 대체
서버 측 변경: 웹소켓 서버(WebSocket Server)를 SSE 엔드포인트(SSE Endpoint)로 변경하고, 데이터를 SSE 형식으로 전송
클라이언트 측 변경: 웹소켓 클라이언트(WebSocket Client)를 EventSource API(EventSource API)를 사용하는 SSE 클라이언트로 변경
이러한 단계를 통해 웹소켓의 복잡성을 줄이고, SSE의 단순성(Simplicity)과 효율성(Efficiency)을 활용할 수 있다.
