배경
이번 프로젝트에서는 검색 기능과 인기 검색어 API를 개발하며, 대량의 데이터에 대한 빠른 검색 응답이 중요한 과제로 떠올랐습니다.
초기에는 단순하게 LIKE 쿼리를 사용한 검색 기능을 제공했지만, 데이터가 많아질수록 검색 성능 저하가 심각해졌고, 이를 해결하기 위해 캐싱 전략을 도입하게 되었습니다.
구현 목표
- v1: 일반 검색 API (캐시 미적용)
- v2: 캐시를 적용한 검색 API (초기엔 Local Cache → 이후 Redis로 전환)
- 인기 검색어 캐싱 기능도 Redis로 구현
구현 방식
1. 캐시 적용 이유
| 항목 | 설명 |
|---|---|
| 검색 특성 | 사용자들이 동일한 키워드로 자주 검색 |
| DB 부하 | LIKE 쿼리 기반의 검색이 비용이 큼 |
| UX 개선 | 빠른 검색 응답 필요 |
| 확장성 | Redis는 Remote Cache로 scale-out 구조에 유리 |
2. 캐시 전략
검색 결과 캐싱 (5분 TTL)
@Cacheable(value = "storeSearch", key = "#keyword + '_' + #pageable.pageNumber + '_' + #pageable.pageSize")
public Page<StoreResponseDto> searchStoreWithCache(String keyword, Pageable pageable)인기 검색어 캐싱 (30분 TTL)
@Cacheable(value = "popularKeywords")
public List<PopularKeywordResponseDto> getPopularKeywords()3. 캐시 구조 및 기술 선택
-
초기: Spring의 Local Memory Cache(ConcurrentHashMap 기반)
-
변경: Redis 기반 Remote Cache
→ 이유: 서버가 늘어나는 상황에서 캐시 데이터 일관성 유지가 어려워짐 → Remote Cache로 확장성 확보 -
사용한 Redis 자료구조: 기본적인 String 타입 활용, ZSet(정렬된 집합)도 고려했으나 단순 캐싱 목적엔 적합하지 않음
트러블슈팅
1. ❌ nGrinder 성능 테스트 실패
검색 API 성능 개선을 위해 v1(캐시 미적용)과 v2(캐시 적용) API 간의 응답 속도 차이를 검증하려 했습니다. 이를 위해 성능 테스트 도구인 nGrinder를 활용했으나, 테스트 환경 설정 및 실행 과정에서 여러 문제를 마주했습니다.
| 항목 | 내용 |
|---|---|
| 테스트 툴 실행 오류 | nGrinder 환경 설정 및 서버 접속에 반복 실패 |
| 응답 분석 불가 | 성능 비교를 위한 스크립트 실행 자체가 어려움 |
| 원인 | 포트 충돌, 스크립트 작성 UI 오류, nGrinder 호환 이슈 등 복합적 문제 |
| 해결 계획 | 다른 도구(JMeter 등)로 대체 또는 환경 재설정 후 재시도 예정 |
2. 시도했던 과정
-
Docker로 nGrinder Controller 및 Agent 설치
-
http://localhost:<포트> 접속 시도 → 다수의 포트 충돌 발생
- 8080: 기존 Spring Boot 프로젝트 사용 중
- 8081: Jenkins가 사용 중
- 80: macOS에서 권한 문제로 접근 불가
-
여러 포트를 바꿔가며 시도 끝에 nGrinder 컨트롤러 구동에는 성공
하지만...
-
웹 UI에서 스크립트 생성을 위한 버튼 클릭이 되지 않는 현상 발생
-
Chrome 개발자 도구 콘솔에 에러 출력, log에도 명확한 로그 없음
3. 문제 원인 분석
-
nGrinder 버전 호환 문제 가능성 (Docker 이미지 vs 브라우저 호환성)
-
캐시 문제일 수 있어 브라우저 캐시 및 쿠키 삭제 시도
-
초기화 및 재설치 반복 (Docker 컨테이너 초기화 및 새 이미지 pull)
그러나 문제는 여전히 해결되지 않았고, UI 상에서 스크립트를 만들 수 없는 치명적인 오류가 지속
4. 해결을 위한 대안
| 방안 | 설명 |
|---|---|
| JMeter 전환 | UI 기반으로 테스트 구성 가능, mac 환경에서도 안정적 |
| AWS 기반 성능 테스트 | 실제 EC2 인프라에서 Apache Benchmark 등 대체 도구로 수행 |
| 로컬 부하 테스트 | wrk, hey 등 경량화된 CLI 도구 사용 고려 |
회고
도구 하나 설치도 쉽지 않다
nGrinder는 많은 기업에서 사용하는 도구지만, 도입 단계에서 버전 충돌, 포트 문제, UI 호환성 등 환경 구축 난이도가 높은 편이었습니다. 단순히 툴을 설치하는 것을 넘어 실행 가능한 상태로 만드는 것이 얼마나 중요한지를 경험하게 되었고, 다음부터는 대체 도구들을 사전 검토하거나 클라우드 기반 솔루션을 적극 활용해야겠다는 교훈을 얻었습니다.
