작업 내용
채팅 시스템의 실제 처리 성능(동시 접속, 메시지 처리량, 지연시간)을 측정하고 병목을 찾는다.
측정 시나리오
- 동시 WebSocket 접속자 수별 메시지 처리량(msg/s) / 지연시간(지연시간 백분위수 -> p50, p95, p99)
- 단일 API 인스턴스 vs 멀티 인스턴스(docker-compose scale) 비교 — Redis Pub/Sub 브로드캐스트 오버헤드 확인
- 레이트리밋 적용 전/후 비교 (도배 시나리오)
도구
k6 또는 Locust로 WebSocket 부하 스크립트 작성 (repo에 재현 가능하게 포함)
완료 기준
- 스크립트가 repo에 커밋되어 동일 조건에서 재실행 가능
- 측정 결과(수치/그래프)가 문서로 정리됨 (README 또는 docs/)
- 병목 구간에 대한 짧은 분석 포함 (DB 커밋 vs Redis vs 이벤트루프 등)
참고 사항
- 이 이슈는 애플리케이션 코드(app/) 수정은 필요 없음. 다만 멀티 인스턴스 비교 시나리오를 실제로 돌리려면 인프라 설정 조정이 필요함
- docker-compose.prod.yaml의 app 서비스에 container_name: teampling-app이 고정돼 있어 --scale app=N이 불가능함 → 스케일 테스트 시 이 고정값 제거 필요
- nginx.conf의 upstream backend { server app:8000; }는 고정 호스트 하나만 바라봐서 여러 인스턴스로 자동 분산되지 않음 → Docker 내장 DNS(127.0.0.11)로 런타임 재확인하도록 resolver 지시자를 추가하거나, 부하테스트 전용 별도 compose 오버레이(app-1, app-2 명시)로 처리
- 이 조정은 운영 compose 파일을 직접 고치기보다 부하테스트 전용 별도 파일(docker-compose.loadtest.yaml 등)로 분리하는 걸 권장 — 운영 설정에 영향 안 주도록
- 신규로 추가되는 건 k6/Locust 스크립트와 (필요시) 부하테스트 전용 compose/nginx 설정 파일
작업 내용
채팅 시스템의 실제 처리 성능(동시 접속, 메시지 처리량, 지연시간)을 측정하고 병목을 찾는다.
측정 시나리오
도구
k6 또는 Locust로 WebSocket 부하 스크립트 작성 (repo에 재현 가능하게 포함)
완료 기준
참고 사항