오답 목록 페이지 최적화 | Notion

요약

단계	상황	P95 Latency	TPS	상태 평가 및 비고
1. 초기	데이터 0건 (t3.small)	676.43 ms	271 req/s	느림 (CPU 병목 심각)
2. 진단	스케일 업 (c6i.xlarge)	73.15 ms	838 req/s	매우 빠름 (하드웨어 성능으로 해결)
3. 악화	데이터 주입(c6i.xlarge)	1.04 s	290 req/s	최악 (실제 데이터 부하 발생)
4. 최적화 1	로그 제거 + 캐싱(c6i.xlarge)	334.73 ms	558 req/s	개선됨 (속도 3배 ↑, 처리량 2배 ↑)
5. 최적화 2	URL 제거 (네트워크)(c6i.xlarge)	338.84 ms	557 req/s	비용 절감 (전송량 -48%, 운영비 절감)

1. 도구 선정: 왜 k6를 썼나?

JMeter나 nGrinder도 있지만 k6를 골랐다. 이유는 단순하다.

내 환경 문제: nGrinder는 Java 11이 필요한데, 내 맥북(Java 17+) 환경이랑 안 맞아서 설치부터 애먹기 싫었다.
유지보수: JMeter는 XML이라 읽기도 힘들고 GUI로 설정하는 게 불편했다. k6는 자바스크립트라 코드 짜기도 편하고 깃허브에 올리기도 좋았다.
가벼움: 터미널에서 바로 돌리면 끝이라 아주 간편했다.

가장 먼저 테스트를 한 곳은, 오답 목록 조회 였다.

어플은, 오답노트 등록, 오답 보기가 메인이기 때문이다.

K6를 그라파나 연결시 주의점

참고: 그라파나 연결할 때 k6 최신 버전(11.3.0 이상)에서 오류가 좀 있어서 안정적인 구버전(11.2.3)을 썼다.

2. 첫 번째 시도: 데이터가 0건인데도 느리다

테스트 조건

시나리오: 최대 300명(VUs)이 6분 동안 접속 (problems-list-300.js)
환경: AWS t3.small (2 vCPU)
요청: 오답 목록 조회 (page=0&size=20)

결과 요약

TPS: 271 req/s