WebSocket 로드밸런싱

WebSocket 연결을 통해 하나의 클라이언트가 대량의 데이터를 지속적으로 전송할 경우, HAProxy가 해당 연결에 대해 로드밸런싱을 하지 못하는가?

🔍 결론부터 말하면:

기존 WebSocket 연결이 이미 맺어진 상태라면, HAProxy는 해당 연결을 다른 백엔드 서버로 옮겨 로드밸런싱할 수 없습니다.
즉, WebSocket 연결은 세션이 고정되어 있기 때문에, 연결이 맺어진 후에는 로드밸런싱이 불가능합니다.

---

🧠 자세한 설명

1. WebSocket의 특징

• WebSocket은 long-lived(지속적인) TCP 연결입니다.
• 초기에는 HTTP handshake로 시작하고, 업그레이드(Upgrade: websocket) 후에 단일 TCP 연결이 지속됩니다.
• 따라서 로드밸런싱은 연결이 생성될 때 1회만 이루어지고, 이후에는 그 연결은 고정된 백엔드 서버에 유지됩니다.

---

2. HAProxy의 로드밸런싱 시점

HAProxy는 다음 중 하나일 때 로드밸런싱을 수행합니다:

• HTTP 요청 단위: 요청마다 백엔드를 선택 (short-lived HTTP)
• TCP 연결 단위: 연결 시점에 백엔드 서버를 선택

WebSocket은 TCP 연결 기반이므로, 연결이 한 번 맺어지면 해당 서버에 고정되고,
클라이언트가 많은 데이터를 전송한다고 해서 HAProxy가 이를 다른 서버로 분산시키진 못합니다.

---

3. 문제 상황

1명의 클라이언트가 WebSocket을 통해 지속적으로 대량의 데이터를 전송하면?

• HAProxy는 이 연결을 하나의 백엔드 서버에 고정시켜놓았기 때문에,
• 이 서버만 과부하될 수 있고, 다른 서버는 한가할 수 있음
• 즉, 로드밸런싱 효과가 떨어지게 됨

---

🛠 해결 방법/대안

✅ 1. 클라이언트 분할 처리

• 클라이언트가 가능한 경우, 여러 WebSocket 연결을 만들고, 각 연결을 분산되도록 처리
• HAProxy가 처음 연결 분배는 가능하므로 분산 효과를 얻을 수 있음

✅ 2. WebSocket-aware 로드밸런서 구성

• WebSocket 트래픽을 이해하고 QoS 또는 페어링된 리밸런싱 등을 지원하는 Layer 7 (L7) 로드밸런서 사용
  • 예: NGINX Plus, Envoy, Istio 등 일부 고급 프록시
  • 하지만 WebSocket 리밸런싱은 여전히 복잡하고 완벽하진 않음

✅ 3. 백엔드 서버 간 메시지 큐 or Pub/Sub 사용

• 클라이언트 연결은 고정되더라도, 처리해야 할 작업은 Redis, Kafka, RabbitMQ 등을 통해 분산 처리
• 백엔드 서버들이 서로 데이터를 공유하여 부하 분산

✅ 4. Connection Rate Limit 또는 QoS

• HAProxy나 프론트 프록시에서 클라이언트 단일 연결 제한, 대역폭 제한 등 설정
• 일부 클라이언트가 과도한 리소스를 쓰는 것 방지

---

✅ 정리

항목 가능 여부

WebSocket 연결 전 로드밸런싱	✅ 가능
연결 후 실시간 리밸런싱	❌ 불가능
대량 데이터 유입 시 분산 처리	❌ 기본적으로는 불가능 (보완 필요)

---

필요하시다면, HAProxy 설정 예시, 또는 WebSocket 처리 아키텍처도 도와드릴 수 있어요.