[ 성능 테스트 ] 4. 캐시 도입으로 반복적인 조회에 대응하기

지난번 커넥션 풀 튜닝 후 진행했던 스케줄 추천 API 부하 테스트에 이어, 이번에는 캐시(Cache) 도입으로 성능을 한 단계 더 끌어올린 경험을 공유한다.

배경 및 목표

커넥션 풀 튜닝을 통해 응답 시간이 크게 개선됐지만, 95백분위 응답 시간이 여전히 3초를 약간 초과하는 상황이었다.

• 이전 95백분위 응답 시간: 약 3.12초
• 목표: 3초 이하 유지
• 실패율은 0%로 안정적

따라서, 반복 조회되는 데이터에 캐시를 도입해 데이터베이스 부하를 줄이고, 응답 속도를 더 개선하는 것을 목표로 삼았다.

---

캐시 도입 과정

1. 캐시 적용 대상 선정
   • 스케줄 추천 API 특성상 동일한 요청에 대한 결과가 자주 조회되므로, 결과 데이터를 메모리 기반 캐시로 저장하도록 결정했다.
   • 변경 빈도가 낮고 조회가 빈번한 데이터에 집중해 캐시 적중률을 높이는 데 주력했다.
2. 캐시 구현 방식
   • Spring Framework의 @Cacheable 어노테이션을 활용해 메서드 결과 캐싱 적용
   • Redis를 외부 캐시 스토리지로 사용하여 확장성과 데이터 일관성 확보
   • TTL(Time To Live)을 적절히 설정해 데이터 신선도 유지
3. 테스트 및 검증
   • 기존과 동일한 k6 스크립트로 부하 테스트를 수행하여 성능 변화를 객관적으로 측정
   • Pinpoint APM으로 DB 호출 감소 및 캐시 히트율을 모니터링

Spring Boot에서 Redis 설정하기

---

캐시 도입 후 성능 지표

지표값설명

총 요청 횟수	29,894회	이전보다 더 많은 요청 처리
초당 요청 처리량 (RPS)	약 453 요청/초	커넥션 풀 튜닝 이후에도 증가 추세 유지
응답 시간 평균	1.09초	이전 1.69초 대비 큰 폭 개선
응답 시간 중앙값	0.9초 (903ms)	안정적인 응답 시간 분포
95백분위 응답 시간 (p95)	2.28초	목표 3초 이내로 안정화
실패 요청 비율	0%	무결점 처리 유지
동시 가상 사용자 수	최대 500명	최대 부하 환경 유지

---

느낀 점 및 향후 계획

• 캐시 도입으로 DB 호출량이 눈에 띄게 줄었고, 응답 시간이 평균 및 95백분위 모두 크게 단축되었다.
• 같은 k6 스크립트를 재활용해 성능 변화를 명확히 비교할 수 있었고, Pinpoint로 캐시 효과와 병목 해소 상황을 상세히 파악할 수 있었다.
• 현재 RPS 약 450이라는 숫자가 주는 의미가 생각보다 컸다. 작은 서비스 수준을 넘어선 꽤 높은 부하라는 걸 이번 테스트를 통해 실감했다.
• 하지만, 정작 나는 아직 로드 밸런싱이나 수평 확장 같은 인프라 운영의 핵심 개념에 대해 많이 알지 못한다. 이번 기회에 이런 부분들을 하나씩 공부하면서, 어떻게 하면 지금의 트래픽을 효율적으로 분산하고 병목을 줄일 수 있을지 고민해 보고 싶다.
• 앞으로는 로드 밸런싱에 대한 기본 원리부터 시작해서, L4, L7 로드 밸런서 차이, 클라우드 환경에서의 오토스케일링, 그리고 서비스 메쉬 같은 최신 기술까지 차근차근 알아갈 예정이다.
• 테스트 결과를 토대로 트래픽이 늘어날 때 어떻게 시스템이 반응하는지 관찰하며, 실제 운영 환경에 적용 가능한 로드 밸런싱 전략을 설계하는 게 최우선 과제다.
• 이러한 학습과 실험 과정을 통해 서비스 안정성을 높이고, 고부하 상황에서도 무리 없이 대응할 수 있는 구조를 만들어 나가려고 한다.

---

마무리

이번 테스트를 통해 개선된 API가 꽤 높은 부하도 견딜 수 있다는 자신감을 얻었다. 하지만, 아직 로드 밸런싱 같은 인프라 운영에 대해선 많이 부족한 상태라 앞으로 하나씩 차근차근 배워 나가야 한다는 것도 절실히 느꼈다.