I. 비교
1. 방식
- Stateless (Polling): 요청-응답을 주기적으로 반복함. 연결 유지 없음.
- Stateful (SSE/WebSocket): 연결을 유지하며 서버가 이벤트를 푸시함.
WebSocket 제외 사유(대기열 특성)
2. Polling vs SSE/WebSocket 비교
비용과 부하 측면에서 우세한 방식은 접속자 수와 업데이트 주기에 따라 달라짐.
- Stateless (Polling): “서버 메모리는 아끼지만, 네트워크/CPU를 많이 씀”
- 장점: 서버가 연결 상태를 유지하지 않으므로 메모리 점유가 적음. 스케일 아웃이 쉬움.
- 단점: 매 요청마다 TCP Handshake + HTTP Header(약 500bytes 이상) 발생함. 10만 명이 1초 폴링이면 헤더만으로 초당 50MB 이상 낭비 가능.
- Stateful (SSE/WebSocket): “네트워크는 아끼지만, 서버 메모리/FD가 부담”
- 장점: 한 번 연결되면 데이터(순번)만 전송하므로 헤더 오버헤드가 거의 없음. 실시간성이 좋음.
- 단점: 동시 연결 수만큼 소켓/FD/RAM을 점유함. 저사양(2GB)에서 10만 연결은 매우 위험함.(커널 튜닝, FD 관리 등 힘듦)
3. 의사결정 기준
| 비교 항목 |
Stateless (Polling) |
Stateful (SSE) |
| 유리한 경우 |
접속자 수가 적거나 업데이트 주기가 매우 길 때 (>10초) |
접속자 수가 많고 업데이트 주기가 짧을 때 |
| 병목 지점 |
CPU, 네트워크 트래픽 (헤더 중복) |
RAM, 커널 소켓 개수 (FD) |
| 비용 최적화 |
서버 사양을 높이는 대신 CDN/Nginx 캐싱 활용 |
서버 사양을 높이는 대신 분산 서버 수 확장 |
4. 정량 모델: 방식별 병목 계산 (NestJS 기준)
1) Stateful(SSE) 방식 계산법 (RAM/FD)
2) Stateless(Polling) 방식 계산법 (RPS/네트워크)
3) 비용 대 성능 논리(왜 RAM이 싸게 먹히는가)
- Polling은
T를 줄일수록 RPS와 네트워크 비용이 폭발함(헤더 중복).
- SSE는 RAM(
X)을 써서 요청 수 자체를 줄임 → 네트워크 비용이 내려감.
- 결론: 대기열에서는 보통 CPU보다 RAM을 늘리는 편이 총비용 관점에서 유리하다는 주장 가능함.
5. 스케일링 관점