MongoDB 복합 인덱스(Compound Index) 조회 성능 테스트

1. 테스트 개요

MongoDB 컬렉션에서 복합 인덱스의 유무가 특정 조회 기능의 성능에 미치는 영향을 측정하고 분석해보려고 한다.

 

이전 PostUuid를 이용한 단일 인덱스 테스트에서 성능 향상을 경험한 바 있으며, 이번 테스트는 사용자의 주요 기능으로 예상되는 카테고리별 게시글 목록 조회 기능에 초첨을 맞춘다.

 

 

해당 기능은 mainCategoryId, subCategoryId, 그리고 정렬 타입(createdAt, viewCount, likeCount)을 기준으로 데이터를 조회하는 특성상, 복합 인덱스가 필요할 것이라고 생각하였다.

 

이 테스트에서는 이를 검증하기 위해, 복합 인덱스 적용 전후의 평균 응답 시간과 처리량을 JMeter를 통해 측정하고 비교 분석하려고 한다.

 

2. 테스트 환경 및 시나리오

2.1 데이터 및 대상 API

• 테스트 데이터 : 컬렉션 내 100,000건의 게시물
• 테스트 API 경로

GET /api/v1/post-read?mainCategoryId=${RANDOM_MAIN_CATEGORY}&subCategoryId=${RANDOM_SUB_CATEGORY}&postSortType=POPULAR&size=20

DB 및 애플리케이션 캐시의 영향을 최소화하고 결과의 신뢰도를 높이기 위해, mainCategoryId와 subCategoryId를 JMeter의 Random Variable을 이용해 동적으로 변경하며 테스트를 진행하였다.

 

2.2 JMeter 부하 테스트 설정

• Number of Threads (Users): 20
• Ramp-up period (seconds): 10
• Loop Count: 100
• 총 요청 수: 2,000회 (20 Users * 100 Loops)

 

3. 테스트 결과

3.1 인덱스 적용 전 (Before)

별도의 인덱스를 설정하지 않은 상태에서 조회 성능 테스트를 진행하였다.

3.2 인덱스 적용 후 (After)

아래와 같이 deletedStatus, mainCategoryId, subCategoryId, viewCount를 포함하는 복합 인덱스를 생성한 후, 동일한 조건으로 테스트를 진행하였다.

@CompoundIndex(name = "category_sort_view_count", def = "{'deletedStatus': 1, 'mainCategoryId': 1, 'subCategoryId': 1, 'viewCount': -1}")

3.3 성능 비교 요약

지표 (Metric)	인덱스 사용 전	인덱스 사용 후	개선 효과
평균 응답 시간 (Average)	1080ms (1.08초)	16ms (0.016초)	약 67.5배 빨라짐
처리량 (Throughput)	17.1/초	181.7/초	약 10.6배 많아짐
최대 응답 시간 (Max)	1850ms (1.85초)	67ms (0.067초)	매우 안정적으로 변경

 

4. 결과 분석

평균 응답 시간: 인덱스 적용 후, 평균 응답 시간은 1.08초에서 0.016초로 약 67.5배 단축되었다. 이는 Full Scan으로 동작하던 쿼리가 인덱스를 통해 필요한 데이터에 즉시 접근하게 되면서 발생한 극적인 성능 향상으로, 사용자 경험(UX)을 크게 개선할 수 있음을 시사한다.

처리량 (Throughput): 1초당 처리 가능한 요청의 수는 17.1개에서 181.7개로 약 10.6배 증가하였다. 이는 각 요청이 DB 리소스를 점유하는 시간이 크게 줄었기 때문이며, 동일한 서버 자원으로 훨씬 더 많은 동시 사용자를 감당할 수 있음을 의미한다.

안정성: 최대 응답 시간이 1.85초에서 0.067초로 줄어, 일부 사용자가 겪을 수 있는 극단적인 지연 현상이 사라지고 매우 일관되고 안정적인 성능을 제공하게 되었다.

 

5. 결론 및 고찰

테스트 결과, (deletedStatus, mainCategoryId, subCategoryId, viewCount) 복합 인덱스는 카테고리별 인기순 정렬 조회 기능의 성능을 압도적으로 향상시키는 것으로 확인되었다.

물론 인덱스를 생성하면 조회 성능은 향상되지만, 데이터의 생성/수정/삭제 시 인덱스를 업데이트하는 추가 비용이 발생하여 쓰기 성능이 저하되는 트레이드오프가 존재한다.

하지만 본 프로젝트의 게시글 조회 기능은 쓰기 작업에 비해 읽기 작업이 훨씬 더 빈번하게 발생할 것으로 예상된다. 따라서 쓰기 성능의 미미한 저하라는 비용보다는, 핵심 기능의 조회 성능을 극대화하는 이점이 훨씬 크다고 판단하여 해당 복합 인덱스를 채택하기로 결정하였다.