부하 테스트 모범 사례 체크리스트

# 부하 테스트 - 성능 중심 신뢰성 엔지니어의 관점 - 모든 부하 테스트는 서면 목표에서 시작하라. 예를 들어 500 RPS(초당 요청 수)에서 p95 지연 시간 300ms 미만과 같은 구체적인 목표 없이 막연한 "무엇이 깨지는지 보자"는 금물이다. - k6, Gatling 또는 Locust를 사용하여 부하 테스트를 코드로 작성하고 서비스와 동일한 저장소에 유지하라. - 프로덕션 로그에서 실제 트래픽을 모델링하라: 엔드포인트의 혼합, 페이로드 크기 및 요청 간 사고 시간(think time)을 포함한다. - 인터넷에 노출된 서비스를 테스트할 때는 고정 도착률을 가진 개방형 워크로드 모델을 사용하라. 폐쇄형 모델은 큐잉 지연을 숨기기 때문이다. - 의도적으로 별도의 테스트 유형을 실행하라: 스모크 테스트, 예상 최대치에서의 부하 테스트, 최대치를 초과하는 스트레스 테스트, 스파이크 테스트, 그리고 메모리 누수를 확인하기 위한 장시간 소크 테스트. - 지연 시간을 백분위수로 보고하라. 최소한 p50, p95, p99를 포함하고 평균값만 절대 신뢰하지 마라. - 테스트 스크립트에 통과 또는 실패 임계값을 정의하여 CI가 빌드를 자동으로 실패시킬 수 있게 하라. - 동일한 인스턴스 크기, 데이터 볼륨 및 구성을 가진 프로덕션과 유사한 환경에서 부하 테스트를 실행하라. - 프로덕션 카디널리티와 일치하는 테스트 데이터를 시드하라. 작은 데이터베이스는 모든 쿼리를 빠르게 보이게 만든다. - 측정 전에 캐시와 연결 풀을 워밍업하고 결과에서 워밍업 기간을 제외하라. - 충분한 CPU와 네트워크 여유가 있는 머신에서 부하를 생성하고 부하 생성기 자체의 메트릭도 관찰하라. - 테스트 결과를 서버 측 메트릭, 트레이스 및 로그와 상호 연관시켜 추측 대신 실제 병목 지점을 찾아라. - 지연 시간과 함께 오류율 및 타임아웃을 추적하라. 오류를 반환하는 빠른 응답은 성공이 아니다. - 실행마다 하나의 변수만 변경하고 각 결과와 함께 커밋, 구성 및 환경을 기록하라. - 메인 브랜치에 대한 모든 병합 시 짧은 성능 스모크 테스트를 실행하고 주요 릴리스 전에는 전체 테스트 스위트를 실행하라. - 결과를 저장된 기준선과 비교하고 합의된 비율보다 큰 회귀를 플래그로 표시하라. - 호출당 비용이 발생하거나 속도 제한이 있는 타사 API는 목(mock) 또는 샌드박스로 처리하되, 자체 의존성은 실제로 테스트하라. - 한계 지점을 찾고 시스템이 어떻게 실패하는지 문서화하라: 429 또는 503으로의 우아한 거부가 완전한 붕괴보다 낫다. - 부하를 점진적으로 증가시키고 새 용량이 도움을 주는 데 걸리는 시간을 측정하여 오토스케일링이 제때 반응하는지 확인하라. - 부하 테스트를 팀과 온콜 엔지니어에게 공지하고 승인 없이 공유 프로덕션 시스템을 대상으로 절대 실행하지 마라. - 발견 사항을 명확한 헤드룸 목표와 함께 용량 계획으로 전환하라. 예를 들어 테스트된 한계의 60% 이하로 실행하는 것과 같은 목표를 설정하라.