1. 테스트 배경

프로젝트 도메인에서 가장 많이 사용되는프로젝트 찾기 API의 최대 권장 운영 부하를 확인하고 시스템의 한계점을 파악하기 위해 성능 테스트를 진행했습니다.

대상 API: GET /api/v2/projects/search

동시 사용자 100명 조건에서 2분간 처리율(Throughput) 을 50 -> 100 -> 150 -> .... 올려가며 병목 지점을 식별하고 권장 운영 부하를 알 수 있습니다.

테스트 이전(BEFORE) 상태:

image.png

초기 CTT(Concurrent Think Time) 3000/min으로 부하 테스트를 진행했을 때, 커넥션 풀의 Pending 지표가 80까지 급증하며 시스템이 불안정한 상태를 보였습니다. 이때의 응답 시간은 다음과 같이 저하되었습니다.

image.png

image.png

2. 1차 개선: 쿼리 튜닝 및 인덱스 적용

성능 저하의 주요 원인을 파악한 결과, keyword 파라미터 없이 전체 프로젝트 목록을 조회하는 경우에도 응답 속도가 느린 것을 확인했습니다. 이는 데이터베이스에서 필터링(WHERE)과 정렬(ORDER BY)을 수행할 때 적절한 인덱스가 없어 발생하는 문제였습니다.

과거에 trigram 인덱스를 활용하여 키워드 검색 성능을 99% 이상 개선했던 경험을 바탕으로, 이번 전체 목록 조회 성능 문제 역시 인덱스 추가를 통해 해결할 수 있을 것이라 판단했습니다.

느린 쿼리가 근본적인 문제라고 보고, 커넥션 풀 튜닝에 앞서 쿼리 성능 개선을 우선 진행했습니다. 쿼리의 WHERE 절에 사용되는 조건과 ORDER BY 절의 정렬 기준인 created_at 컬럼에 복합 인덱스와 단일 인덱스를 각각 생성하여 적용했습니다.

-- 상태/삭제여부/시작일 복합 인덱스 (필터링 조건)
CREATE INDEX idx_projects_state_deleted_start
ON projects (state, is_deleted, period_start);

-- 상태/삭제여부/종료일 복합 인덱스 (필터링 조건)
CREATE INDEX idx_projects_state_deleted_end
ON projects (state, is_deleted, period_end);

-- 생성일자 정렬용 인덱스 (정렬 조건)
CREATE INDEX idx_projects_created_at ON projects (created_at);

image.png