확장의 비용

연결마다 드는 자원

WebSocket 연결 하나는 파일 디스크립터 1개와 읽기·쓰기 버퍼, 프레임워크 메타데이터, 연결별 상태를 합쳐 약 10~50KB 의 메모리를 써. 유휴 상태의 CPU 비용은 0 에 가깝고 활성 상태에서는 메시지 빈도에 비례해 늘어나. 연결 100K개는 큰 서버 한 대에 들어가고 1M개도 가능하지만 세심한 설계가 필요해. 10M개라면 지역별 분할이나 관리형 서비스가 필요해.

운영체제 한계가 중요해

Linux 의 프로세스당 파일 디스크립터 기본값은 1024라서 올리지 않으면 서버 하나에 WebSocket 연결 1024개도 열 수 없어. ulimit, limits.conf, sysctl 로 높여. 네트워크가 잠깐 끊긴 뒤 몰려드는 재연결을 처리하려면 net.core.somaxconn 과 tcp_max_syn_backlog 도 조정해.

직접 운영과 관리형 서비스의 솔직한 절충

직접 운영은 연결 1K개에서는 싸지만 10M개에서는 비싸. 관리형 서비스는 1K개에서는 비싸도 10M개에서는 확장과 당직 전문 인력을 따로 채용하지 않아도 돼서 쌀 수 있어. 대부분 앱의 전환점은 동시 연결 100K~1M개 부근이야. cwkPippa 는 분명 직접 운영 영역이지만 전 세계 SaaS 채팅 제품이라면 다를 수 있어.

Code

연결 수를 높이기 위한 Linux 조정·shell

# /etc/security/limits.conf
*  soft  nofile  1000000
*  hard  nofile  1000000

# /etc/sysctl.conf
net.core.somaxconn         = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout   = 15
net.core.netdev_max_backlog = 5000

# Reload
sudo sysctl -p
ulimit -n 1000000

규모별 선택표·text

| Scale                      | Recommendation                          |
| -------------------------- | --------------------------------------- |
| < 1K concurrent            | Single FastAPI server, raw WebSocket    |
| 1K - 100K concurrent       | 2-5 servers + Redis Pub/Sub             |
| 100K - 1M concurrent       | Sharded servers + Redis cluster + LB    |
| 1M+ concurrent             | Strongly consider Ably / Pusher / etc.  |
| Tight team or deadline     | Managed service from the start          |
| Custom protocol or trading | Self-host at any scale                  |

Exercise

일상에서 쓰는 실제 채팅 앱, 주식 앱, 알림 앱 세 개를 골라. DAU 를 찾아 피크 시간에 30% 가 온라인이라고 가정해 동시 WebSocket 연결 수를 추정하고 선택표에서 위치를 찾아. 아는 팀과 제품 상황을 바탕으로 각 회사가 권장 방식을 고르거나 고르지 않을 이유를 소리 내어 추론해.