8.8 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | last_reviewed | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| company-tech-blog / 우아한형제들 기술블로그 — 실시간 서비스 경험기(배달운영시스템) WebSocket | company-tech-blog | https://techblog.woowahan.com/2547/ |
|
|
|
2026-06-02 | 2026-06-02 |
우아한형제들 기술블로그 — 실시간 서비스 경험기(배달운영시스템) WebSocket
Layer:
raw/company-tech-blogs/— 우아한형제들(배달의민족) 기술블로그 2017년 게시물 발췌. Strength 분류:company-case-study— 대기업 기술 블로그의 특정 서비스 운영 사례 (2017년 기준). 공식 best practice 로 취급 금지. 이 자료의 진술은 2017년 기준 PHP/Node.js/Socket.IO 환경 사례이며, 현재 Spring Boot 3.x 환경과 직접적으로 동일하지 않음.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-streaming-response-contract | WebSocket (Socket.IO) 운영 시 마주친 실무 문제(이벤트 유실, 클러스터링, 브라우저 연결 끊김 감지, CPU 포화) 의 산업 사례 근거 — WebSocket alternative 의 운영 부담 evidence |
출처 / Source
- 원본 URL: https://techblog.woowahan.com/2547/
- 저자 / 조직: WoowaTech / 우아한형제들 (배달의민족) 기술블로그
- 발행일: 2017-09-12
- 카테고리: Backend
- 마지막 확인일: 2026-06-02
왜 저장했는지 / Why archived
feature-streaming-response-contract 에서 WebSocket alternative 를 평가할 때 "운영 부담" 항목의 현실적 evidence 가 필요. 우아한형제들이 Socket.IO(WebSocket) 로 실시간 배달 운영 시스템(BROS) 을 구축하고 운영하면서 마주친 구체적 문제들—이벤트 유실, 모바일 네트워크 불안정, Node.js 싱글 프로세스 한계(클러스터링 + Redis Pub/Sub), CPU 100% 포화, Internet Explorer 연결 끊김 미감지(좀비 세션)—을 상세히 기술. WebSocket 운영 복잡성의 사례 근거.
핵심 인용 / Key quotes (verbatim)
"socket.io 서버의 실시간 이벤트 메시지로 데이터를 전송 angularjs model에 반영" [Socket.IO 기반 실시간 데이터 전송 아키텍처]
"2분에 1번씩 batch proccess 한곳에서 만 배달 데이터를 select하여" [Mobile network 이벤트 유실 보완 — 주기적 batch poll 병행]
"다양한 network 상황 때문에 이벤트 유실이 발생했으며, 특히 라이더분들이 지하 지역에서 LTE 신호가 약해지는 문제" [모바일 네트워크 불안정으로 인한 WebSocket 이벤트 유실]
"Mobile network 환경은 24시간 내내 connected 상태가 아닐 수 있기 때문에 발생하는 이벤트 유실에 대한 보완이 필수적이었습니다" [WebSocket 연결 유지의 모바일 환경 한계]
[CPU 포화 문제] Synchronous loop (async/waterfall) 가 이벤트 루프 차단 → 소수 클라이언트 연결에도 CPU 100% 포화
[Internet Explorer 연결 끊김] 브라우저 창 닫을 때 disconnect event 가 발생하지 않아 서버에 좀비 세션 잔존
[클러스터링] Node.js 단일 프로세스 한계 → multi-process 클러스터링 + Redis Pub/Sub 프로세스 간 메시지 중계
"Master process managing worker lifecycle... Sticky session handling for load balancing" [로드 밸런서 sticky session 필요]
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| WOOWA-WS-C1 | Socket.IO(WebSocket) 기반 실시간 서비스에서 모바일 네트워크 불안정(LTE 신호 약화, 지하)으로 이벤트 유실이 발생했으며, 2분 batch poll 로 보완했다 | "다양한 network 상황 때문에 이벤트 유실이 발생했으며, 특히 라이더분들이 지하 지역에서 LTE 신호가 약해지는 문제" + "2분에 1번씩 batch proccess" | company-case-study |
모바일 클라이언트(라이더 앱) + 불안정 네트워크 환경 | WebSocket 이 데스크탑/유선 환경에서도 동일한 이벤트 유실이 발생한다는 뜻 아님 |
| WOOWA-WS-C2 | WebSocket 서버를 multi-process 로 클러스터링할 때 프로세스 간 메시지 중계를 위해 Redis Pub/Sub 를 사용했으며, 로드 밸런서에 sticky session 설정이 필요했다 | "Node.js single-process limitation required multi-process clustering with Redis Pub/Sub mediating cross-process communication" + "Sticky session handling for load balancing" | company-case-study |
Node.js(Socket.IO) 기반 WebSocket 서버의 수평 확장 시나리오 | Spring Boot WebSocket 에도 동일하게 Redis Pub/Sub 가 필요하다는 뜻 아님 — Spring 의 STOMP + Message Broker 계층이 이 역할을 대신할 수 있음 |
| WOOWA-WS-C3 | Internet Explorer 에서 브라우저 창을 닫을 때 disconnect event 가 발생하지 않아 서버에 좀비 세션이 잔존했다 | "Internet Explorer failed to signal disconnection events when windows closed, leaving zombie sessions in server state tracking" | company-case-study |
2017년 기준 Internet Explorer + Socket.IO 환경 | 현재 모던 브라우저(Chrome/Firefox/Edge)에서도 동일 문제가 발생한다는 뜻 아님 — IE 특화 이슈 (현재 IE 는 EOL) |
| WOOWA-WS-C4 | Synchronous 루프 처리(async/waterfall)가 이벤트 루프를 차단하여 소수 클라이언트 연결에도 CPU 100% 포화가 발생했다 | "Synchronous loop processing using async/waterfall methods blocked the event loop, causing 100% CPU utilization despite low client counts" | company-case-study |
Node.js 이벤트 루프 + synchronous 처리 패턴 조합 | Spring MVC(servlet thread-per-request) 환경에서도 동일 문제가 발생한다는 뜻 아님 — Node.js 이벤트 루프 특화 이슈 |
| WOOWA-WS-C5 | WebSocket 기반 실시간 서비스는 이벤트 유실 보완을 위해 별도 batch poll 을 병행해야 하는 경우가 있다 — "WebSocket 만으로 완전한 신뢰성 보장이 어렵다"는 운영 경험 | "Mobile network 환경은 24시간 내내 connected 상태가 아닐 수 있기 때문에 발생하는 이벤트 유실에 대한 보완이 필수적이었습니다" | company-case-study |
모바일 클라이언트가 포함된 WebSocket 서비스 | WebSocket 이 데스크탑/안정적 네트워크에서도 신뢰성이 부족하다는 주장 아님 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것 (단,
company-case-studystrength + 2017년 Node.js/IE 환경 한정):C1: 모바일 네트워크 불안정 시 WebSocket 이벤트 유실 → batch poll 보완 필요 (모바일 클라이언트 포함 시)C2: WebSocket multi-server 확장 시 sticky session + 프로세스 간 메시지 중계(Redis 등) 필요C4: 동기 처리 루프 + WebSocket 이벤트 루프 조합은 CPU 포화 위험C5: WebSocket 만으로 이벤트 유실을 완전히 방지하기 어려울 수 있음 (특히 모바일)
- 이 자료가 증명하지 않는 것:
- Spring Boot WebSocket 이 Node.js Socket.IO 와 동일한 문제를 갖는다는 주장 — 기술 스택이 다름
- 2017년 IE 이슈(
C3)가 현재 모던 브라우저에도 적용된다는 주장 — IE EOL (2022) - WebSocket 이 SSE 보다 항상 운영 부담이 크다는 주장 — 이 사례는 SSE 미사용, WebSocket 만의 부담
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-skeleton 의 예상 클라이언트 환경 — 모바일(불안정 네트워크) 포함 여부 (C1, C5 적용성)
- ca-skeleton 이 WebSocket 도입 시 Spring 의 STOMP Message Broker 가 sticky session 필요성을 줄이는지 (C2 대안)
메모 / Notes
- 이 아티클은 2017년 Node.js/Socket.IO/PHP/IE 환경 기준 — Spring Boot 3.x + 모던 브라우저 환경에 직접 적용 시 기술 격차 주의
C3(IE 좀비 세션) 는 현재 ca-skeleton 대상 환경에서 적용 불가 (IE EOL) — 과거 사례로만 참조C2의 sticky session 필요성은 Spring WebSocket + STOMP 에서SimpleBroker→StompBrokerRelay(RabbitMQ/ActiveMQ) 로 전환하면 완화 가능 — 별도 조사 필요- 2017년 아티클이므로
C4의 기술 이슈(Node.js async/waterfall) 는 현재 Node.js async/await 환경에서 대부분 해결됨
Related / 관련
- 같은 출처 최신 아티클: raw/company-tech-blogs/sse-realtime-notification-woowahan (2025년 — SSE 전환 후 운영 사례)
- 같은 주제 다른 raw 자료: raw/official-docs/rfc6455-websocket (WebSocket 프로토콜 공식 사양)
- 인용하는 branch: raw/branch-notes/feature-streaming-response-contract