C.W.K.
Stream
Lesson 01 of 07 · published

Load Balancing

~12 min · production, load-balancer, sticky-sessions

Level 0Poller
0 XP0/60 lessons0/10 achievements
0/120 XP to next level120 XP to go0% complete

Sticky-session 문제

WebSocket connection 이 persistent + stateful — 특정 서버 프로세스에 살아. 클라가 reconnect 시 session, room 멤버십, auth context 기억 없는 다른 서버 hit 할 수 있음. Sticky session 이 같은 클라의 reconnect 가 같은 서버 도달 보장.

세 sticky 전략

IP hash: 가장 단순, cookie 안 필요, shared NAT (대학 wifi, corporate VPN) 에선 깨짐. Cookie-based affinity: 정확, 근데 cookie 가 첫 WebSocket upgrade 시간에 항상 set 안 됨. Connection-aware (least-conn): 균등 분배, 근데 affinity 없음 — 서버가 stateless 거나 Redis bridge 가 보완할 때만 좋음.

Code

Nginx ip_hash sticky·nginx
upstream websocket_servers {
    ip_hash;                # same client IP -> same backend
    server backend1:8000;
    server backend2:8000;
    server backend3:8000;
    keepalive 64;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;

    location /ws {
        proxy_pass http://websocket_servers;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout  3600s;
        proxy_send_timeout  3600s;
    }
}
HAProxy cookie sticky·text
backend websocket
    cookie SRV insert indirect nocache
    server srv1 backend1:8000 check cookie srv1
    server srv2 backend2:8000 check cookie srv2
    server srv3 backend3:8000 check cookie srv3
    timeout tunnel 1h

External links

Exercise

Nginx 뒤에 두 FastAPI WebSocket 서버 + ip_hash 띄워. 같은 NAT 의 두 device (집 wifi 의 폰 + 노트북) 에서 connect; 같은 backend 떨어질 수 있는지 확인. 다른 IP 둘에서 connect; backend 사이 분배되는지 확인. 본 거 문서화.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.