🔎 문제 분석 및 원인 파악

• 모든 조회 요청마다 DB/Neo4j 직접 호출
• 반복 조회 부하로 레이턴시 상승

🚀 개선 전략 및 실행 과정

1. Cache-Aside (Look-Aside) 패턴 도입

• @Cacheable(cacheNames="plans", key="#…")
• @Cacheable(cacheNames="planCounts", key="#…")

2. Redis 설정 최적화

planListPages, planCounts 모두 TTL 10분으로 설정

TTL 10분 설정 근거

• 요금제 변경 빈도

  • 요금제 신규 등록, 수정는 하루 중에도 자주 발생하지 않음
  • 10분 이내면 충분히 최신 변경 사항을 반영할 수 있어 비즈니스 요구 충족

• 캐시 적중률 vs. 신선도 균형

  • 너무 짧으면 캐시 적중률이 떨어져 DB 조회가 잦아지고,
  • 너무 길면 사용자에게 오래된 데이터를 제공할 수 있으므로
  • 10분은 “DB 부하 감소”와 “데이터 갱신 시점” 사이의 적절한 절충점

3. Eviction 정책 적용

• @CacheEvict(cacheNames={"planListPages","planCounts"}, allEntries=true)
• Plan 생성, 수정 시 전체 캐시 무효화

4. 캐시 저장 값 및 키 설계

findPlans(Pageable, GetPlansRequest)

• 어노테이션

@Transactional(readOnly = true)
@Cacheable(
value = "planListPages",
key = "'planListPages:' + #pageable.pageNumber + '-' +
        #request.planTypeStr() + '-' +
        #request.planSortOptionStr() + '-' +
        #request.searchKeyword() + '-' +
        (#request.planId() != null ? #request.planId() : '') + '-' +
        #request.cursorSortValue()"
)

• 키 포맷: 요금제 조회 시 페이지 번호, 요금제 타입, 요금제 정렬 조건, 검색 키워드, 페이지네이션에서 필요한 planId, cursorSortValue를 key값으로 설정

planListPages:
{pageNumber}-{pageSize}-{planType}-{sortOption}-{searchKeyword}-{planId}-{cursorSortValue}

countPlans()

• 어노테이션

@Transactional(readOnly = true)
@Cacheable(value = "planCounts", key = "'all'")
public PlansCountResponse countPlans() {
        return PlansCountResponse.from(planRepository.countPlans());
}

• 키 포맷: countPlans는 단일 키로 설정

planCounts:
all

5. 인덱싱 튜닝 (요금제 타입 필터 & 정렬 필드 재구성)

CREATE INDEX plan_type_index IF NOT EXISTS FOR (p:Plan) ON (p.planType);

📊 성능 테스트

테스트 환경

• Concurrent Users: 1,000
• Test Duration: 60초
• Dataset Size: 약 5,000개 요금제

부하 설정 근거

• LG U+ 사이트 일일 방문자: 약 25,200명
• 평균 세션(5분) 동시접속자: (25,200 × 300) ÷ 86,400 ≈ 87.5명
• 피크 계수(1.52) 적용 시: 135~175명
• 안정성 검증을 위해 1분 1,000명 환경으로 설정

테스트 시나리오

1. Baseline (Pre-Cache): 캐시·인덱스 미적용
2. Optimized (With Cache): 캐시 + 인덱스 적용

※ 동일한 스레드, 요청 빈도, 파라미터 조건으로 비교

결과 요약

구분	평균 지연 (Avg)	P95 지연	개선율
목록 조회 (Pre)	31 ms	38 ms	—
목록 조회 (With)	6 ms	12 ms	Avg ↓80%, P95 ↓68%
개수 조회 (Pre)	13 ms	18 ms	—
개수 조회 (With)	4 ms	6 ms	Avg ↓69%, P95 ↓66%

최종 결론

캐시 및 인덱스 적용으로 목록 조회 평균 응답이 31 ms → 6 ms(80%↓), P95 38 ms → 12 ms(68%↓), 개수 조회 평균 13 ms → 4 ms(69%↓), P95 18 ms →6 ms(66%↓) 로 대폭 개선