체육관 검색 API 성능 비교 보고서 (v1: 캐시 vs v2: 인메모리) - fitpassTeam/fitpass GitHub Wiki
1. 테스트 목적
Fitpass에서는 체육관 검색 API의 성능 개선을 위해 두 가지 방식을 설계하고 비교 테스트를 진행하였습니다.
- v1 (캐시 기반): Redis를 활용한 검색 결과 캐싱
- v2 (인메모리 기반): 전체 데이터를 메모리에 올려 검색 수행
2. 테스트 환경
- 총 데이터: 500만 건 이상
- 검색 키워드:
"홍대","강남" - API 엔드포인트:
/search/gyms/v1(캐시)/search/gyms/v2(인메모리)
10만 ~ 50만 건 규모에서는 성능 차이가 미미하여, 500만 건 이상 대용량으로 테스트 범위를 확장함
3. 테스트 시나리오 1: Postman 개별 요청 테스트
"홍대" 키워드 결과 요약
v1
첫번째 검색
두번째 검색
최솟값
최댓값
v2
첫번째 검색
두번째 검색
최솟값
실수로 인한 누락
최댓값
실수로 인한 누락
| 구분 | v1 (캐시) | v2 (인메모리) | 비교 결과 |
|---|---|---|---|
| 1차 요청 | 8.49s | 8.43s | 거의 동일 |
| 2차 요청 | 45ms | 4.70s | v1이 99.0% 빠름 |
| 최솟값 | 24ms | 4.70s | v1이 99.5% 빠름 |
| 최댓값 | 30ms | 8.43s | v1이 99.6% 빠름 |
| 평균 | 4.27초 | 6.57초 | v1이 35% 빠름 |
"강남" 키워드 결과 요약
v1
첫번째 검색
두번째 검색
최솟값
최댓값
v2
첫번째 검색
두번째 검색
최솟값
실수로 인한 누락
최댓값
실수로 인한 누락
| 구분 | v1 (캐시) | v2 (인메모리) | 비교 결과 |
|---|---|---|---|
| 1차 요청 | 10.86s | 8.52s | v2가 27.5% 빠름 |
| 2차 요청 | 40ms | 4.19s | v1이 99.0% 빠름 |
| 최솟값 | 20ms | 4.19s | v1이 99.5% 빠름 |
| 최댓값 | 36ms | 8.52s | v1이 99.6% 빠름 |
| 평균 | 5.45초 | 6.36초 | v1이 14.2% 빠름 |
4. 테스트 시나리오 2: JMeter 부하 테스트 (1,500명 동시 접속)
v1 (캐시 기반) 테스트 결과
| 지표 항목 | 수치 | 설명 |
|---|---|---|
| 평균 응답시간 | 3,737ms | 대용량 처리 대비 안정적 |
| 중간값 (Median) | 3,454ms | 일관된 성능 |
| 90% Line | 5,392ms | 90% 응답 5.4초 이내 |
| 95% Line | 6,242ms | |
| 99% Line | 7,021ms | |
| 최소값 | 580ms | 최적 조건 |
| 최대값 | 8,453ms | 최악 조건에서도 8.5초 |
| 에러율 | 0.00% | 안정성 최고 |
| TPS | 78.4/sec | 높은 처리량 |
v2 (인메모리 기반) 테스트 결과
| 지표 항목 | 수치 | 설명 |
|---|---|---|
| 평균 응답시간 | 65,101ms | 매우 느림, 대용량 처리에 부적합 |
| 중간값 (Median) | 67,564ms | |
| 90% Line | 86,858ms | |
| 95% Line | 88,178ms | |
| 99% Line | 91,894ms | |
| 최소값 | 6,698ms | 최적 조건조차 느림 |
| 최대값 | 93,901ms | 사실상 타임아웃 수준 |
| 에러율 | 69.33% | 안정성 매우 낮음 |
| TPS | 6.1/sec | 처리량 매우 낮음 |
5. 성능 분석: 캐시 vs 인메모리
대용량 환경에서의 차이
| 항목 | 캐시 시스템 (v1) | 인메모리 시스템 (v2) |
|---|---|---|
| 초기 로딩 속도 | 느림 (콜드 스타트) | 빠름 |
| 응답속도 (웜업 후) | 20~45ms | 4~8초 이상 |
| 메모리 효율 | 0.5~1GB | 5.5GB 이상 |
| 안정성 | 0% 에러율 | 69% 에러율 |
| 확장성 | Redis 클러스터 가능 | GC, 메모리 제약 많음 |
6. K6 캐시 성능 측정 결과
- 테스트 환경: 동시 사용자 10명 / 100회 요청
- 검색 키워드:
"강남","홍대"
| 지표 항목 | 수치 | 설명 |
|---|---|---|
| 평균 응답시간 | 22.25ms | 빠른 실시간 응답 |
| 최소 응답시간 | 11.97ms | |
| 최대 응답시간 | 77.57ms | |
| 90% Line | 32.48ms | |
| 실패율 | 0% | 모든 요청 성공 |
| TPS | 약 10건/sec | 실시간 검색에도 안정적 처리 |
7. 종합 성능 비교 요약
| 항목 | v1 (캐시) | v2 (인메모리) | v1이 v2보다 빠른 정도 |
|---|---|---|---|
| 평균 응답시간 | 3,737ms | 65,101ms | 94.3% 빠름 |
| 처리량 (TPS) | 78.4/sec | 6.1/sec | 1,185% 높음 |
| 에러율 | 0% | 69.33% | 안정성 최고 |
| 웜업 후 응답시간 | 22~45ms | 4~8초 | 극적인 성능 차이 |
8. 결론
캐시 시스템 (v1) 선정 이유
- 압도적인 성능 우위
- 응답속도: 최대 99% 빠름
- 안정성: 0% 에러율
- 처리량: 12.8배 이상
- 운영 측면의 이점
- 메모리 효율성
- Redis 기반 확장성 확보
- TTL, 캐시 워밍 전략을 통한 유연한 관리
- 비즈니스 영향
- 검색 UX 향상 → 빠른 피드백 제공
- 인프라 비용 절감 및 효율적 운영
인메모리 시스템 (v2)의 한계
- 성능 저하: 느린 응답 시간, 웜업 없음
- 메모리 과부하: 5.5GB 이상 필요
- 낮은 확장성: GC 문제, 운영 난이도 상승
- 실 운영 부적합: 에러율 69% 기록
결론: 대용량 검색 서비스에서 캐시 시스템은 초기 콜드 스타트 이후 압도적으로 우수한 성능과 안정성을 보이며, 인메모리 방식보다 운영 효율성과 사용자 경험 측면 모두에서 탁월한 선택임을 확인했습니다.