피드로 돌아가기
What Broke When We Hit 100k WebSocket Connections (And How Realtime Orchestration Saved Us)
Dev.toDev.to
Infrastructure

100k WebSocket 연결 한계 극복을 위한 Realtime Orchestration 계층 도입

What Broke When We Hit 100k WebSocket Connections (And How Realtime Orchestration Saved Us)

hamza qureshi2026년 5월 19일5분advanced

AI 요약

Context

초기 Redis pub/sub 기반의 단순 구조로 AI 모델 출력을 스트리밍했으나, 트래픽 증가에 따른 Latency spikes와 메시지 유실 발생. Redis의 비지속성 및 publish-time fanout 구조로 인해 서버 Thread blocking과 CPU 부하가 임계점에 도달한 상황.

Technical Solution

  • Topic Partitioning: Tenant+Room 기반 키 설정을 통한 라우팅 프로세스 분산 및 예측 가능한 Fanout 부하 제어
  • Decoupled Publish-Fanout: Publisher는 Event Stream에 빠르게 기록하고 전담 Router Worker가 읽어 전송하는 비동기 구조 설계
  • Sequence-based Recovery: 메시지별 Sequence Number와 Client-side Idempotency 도입을 통한 데이터 정렬 및 유실 구간 복구
  • Connection Lifecycle Management: 배포 시 Graceful Draining 및 Buffered Queue 기반의 Backpressure 제어로 제어 메시지 우선순위 확보
  • Managed Orchestration Layer: DNotifier 도입을 통한 커스텀 리플레이 로직 및 샤드 맵 관리 비용 제거

실천 포인트

- [ ] Fanout 작업이 Request Handler 내 동기 루프로 구현되어 있는지 확인 - [ ] 단순 In-memory 세션 맵 외에 재연결 시 짧은 기간의 Event Replay 전략 수립 - [ ] 메시지 순서 보장을 위한 Sequence Number 및 Idempotency Key 적용 여부 검토 - [ ] Tenant/Room 단위의 Topic Partitioning을 통한 부하 분산 설계 적용

태그

#Realtime Orchestration#WebSocket#Event-Driven#Fanout#Pub/Sub
원문 읽기