Templify가 k6 기반 부하 테스트를 Docker와 GitHub Actions로 자동화해 2vCPU 서버의 PDF 생성 API 처리량 한계를 정량화

Context

Templify PDF 생성 API는 Puppeteer로 Chromium을 실행하는 CPU 바운드 작업으로 1~4초의 응답시간이 필요하다. 개발 환경에서는 정상이지만 프로덕션 환경에서 동시 요청이 증가하면 서버 성능 한계를 파악할 수 없었다.

Technical Solution

• k6를 선택해 JavaScript로 테스트 스크립트 작성: 커스텀 런타임(Goja) 제약이 있지만 API 테스트에는 충분하고 YAML/XML 설정 불필요
• 부하 프로파일을 30초 ramp-up(5 VU) → 60초 steady state(5 VU) → 30초 ramp-down(0 VU)으로 구성: 서버의 연결 풀 워밍업 시간 확보
• p95 응답시간 3500ms 이하, 에러율 10% 미만을 성능 임계값으로 스크립트에 정의: 기계적 검증 가능
• 실제 프로덕션 Handlebars 템플릿 페이로드(마케팅 브로셔) 사용: 간단한 테스트 데이터의 성능 왜곡 방지
• Hetzner 서버 로컬(127.0.0.1)에서 k6 테스트 실행: GitHub Actions 러너의 네트워크 지연 제거하고 하드웨어 순수 처리량 측정

Impact

1 VU 기준 p95 응답시간 약 1.2초에서 5 VU 기준 약 3.2초로 증가 관찰. 5~6개 동시 Chromium 렌더링이 2vCPU 박스의 한계점 확인. GitHub Actions 자동화로 배포 시마다 SLA 위반 여부 기계적 검증.

Key Takeaway

p95 임계값 기반 성능 테스트를 CI/CD 파이프라인에 내장하면 평균값의 왜곡으로부터 보호받을 수 있으며, 로컬 루프백 테스트로 네트워크 변수 제거 후 하드웨어의 실제 처리 능력을 측정할 수 있다.