서버 한 대의 한계
FastAPI 프로세스 하나가 WebSocket 연결 수만 개를 다룰 수는 있지만 백만 개까지는 어려워. 부하 분산기 뒤에 서버를 여러 대 두고 수평 확장하면 구조적인 문제가 생겨. 같은 방의 연결이 서로 다른 서버에 있을 수 있어서 메시지 버스를 공유하지 않으면 서버 A 의 전체 전송이 서버 B 의 사용자에게 닿지 않아.
표준 해법은 Redis Pub/Sub 이야
각 서버는 나가는 메시지를 Redis 채널에 발행하고 같은 채널을 구독해. Redis 가 모든 구독자에게 메시지를 펼쳐 주면 각 서버는 자기 로컬 연결에만 다시 전송하지. 중앙에 연결 상태를 두지 않고도 이 패턴은 서버 수천 대와 연결 수백만 개까지 확장할 수 있어.
cwkPippa 의 비슷한 패턴
cwkPippa 는 집의 Mac Studio 한 대에서 의도적으로 단일 서버로 돌아가. 하지만 사용자의 질문 하나를 여러 브레인 프로세스에 펼쳤다가 응답을 모으는 피파의 Council 패턴은 같은 모양이야. Redis 대신 하위 프로세스 파이프를 쓴다는 운반 방식만 다를 뿐, 펼치고 모으는 구조는 분산 실시간 시스템 전반에 나타나.