항공편 예매 서비스 - 진척도(96.71%) 치명적인 삽질

부하 테스트 시작

너무 바쁜 나머지 3주 차를 기록하지 못했다. 회고하자면 그 사이 인덱싱 문서화를 끝내고 대용량 테스트를 진행했다. Jmeter를 통해 VUser 350를 생성하여 3분 간 부하를 주는 테스트를 진행했는데 결과 쓰레드의 어마무시한 Context Switching이 발견되었고, thread poll size, HikariCP connection size를 조절해 가며 적정 값을 찾으려고 시도한 끝에 RPS 50 상승, 평균 응답 속도 1024 (ms) -> 952 (ms) 라는 아주 근사한 개선을 이뤄냈다.

그런데 부하 테스트에 대해 학습하며, 내가 만든 시나리오가 비현실적인 테스트 시나리오라는 걸 깨달았고, 다음과 같이 warm-up 및 기능과 기능 사이에 사용자 Think TIme 2초를 추가하여 스크립트를 다시 작성하게 되었다.

export const options = {
    scenarios: {
        warmup: {
            executor: 'ramping-vus',
            startVUs: 0,
            stages: [
                { duration: '30s', target: 30 }, 
            ],
            gracefulRampDown: '10s',
            tags: { scenario: 'warmup' }
        },

        load_test: {
            executor: 'ramping-vus',
            startVUs: 50,
            stages: [
                { duration: '1m', target: 100 },
                { duration: '1m', target: 150 },
                { duration: '1m', target: 200 },
                { duration: '2m', target: 200 }
            ],
            startTime: '35s',
            gracefulRampDown: '30s'
        },

 

문제는 테스트를 돌리니 Thread poll에 따른 개선 효과가 나오지 않았다.😱 원인을 찾아보니 warm-up을 하게 되면 쓰레드 풀이 초기화 되고 커넥션 풀이 준비되어 트래픽을 잘 받아낼 수 있기 때문에 thread poll size의 유무에 따른 차이가 거의 없지만, warm-up 없이 콜드 스타트 상태에서의 테스트는 thread poll size가 쓰레드의 과도한 생성을 제어해 주기 때문에 결과적으로 개선이 일어났던 것이었다.

근 한 주간 이 주제에 엄청난 에너지를 쏟았는데, warm-up의 등장으로 작성한 문서들이 쓰레기통으로 향하게 됐다.😭 이로써 삽질도 배움이라는 중요한 사실을 깨달을 수 있었다. 

Critical Chain

Critical Chain 3주 차를 작성하지 못했는데 리뷰하자면 3.1 Task가 예상보다 밀리면서 버퍼를 많이 소비했다. 그래도 일정을 빠듯하게 잡았기에 프로젝트 종료까지 8.5일이라는 여유가 있다. 앞으로 남은 여유 시간을 잘 활용해서 테스트 방향을 잘 잡아야 될 것 같다. 이제 정말 막바지이므로 Critical Chain은 4주 차를 마지막으로 끝내려고 한다.