Top10 캐싱 개선 검증 실험

[kimseonj]

배경

PR #80 에서 Top10 쿼리 기간 제한(최근 2개월) 및 Redis 장애 시 DB fallback을 추가했다.
배포 후 아래 두 가지 실험으로 개선 효과를 검증해야 한다.

---

실험 1: k6 부하 테스트 - cache miss 시 latency 감소 확인

목적

Top10 쿼리에 기간 제한을 추가하여 cache miss 시 DB 쿼리 시간이 단축되었는지 확인한다.
단건 쿼리 기준 5,695ms → 2,054ms(64% 감소)가 부하 환경에서도 유효한지 검증.

실험 조건

항목	값
도구	k6
VUs	50
지속 시간	5분
스크립트	scripts/k6/baseline.js

실행 명령어

K6_WEB_DASHBOARD=true \
K6_WEB_DASHBOARD_EXPORT=./top10/after-date-filter.html \
k6 run --env BASE_URL=http://jongju.duckdns.org:8080 --env API_PREFIX=/api --env ACCESS_TOKEN=$ACCESS_TOKEN ./baseline.js

확인 포인트

• get_top10_latency max 값이 이전(58s)보다 감소했는지
• 초반 stampede로 인한 타임아웃 건수가 이전(40건)보다 감소했는지
• Grafana Backend Latency에서 초반 스파이크 크기 비교

비교 기준 (이전 결과)

지표	이전 값
Top10 avg	315ms
Top10 max	58.01s
Top10 p95	27ms
타임아웃	40건 (0.22%)

---

실험 2: Redis 장애 시 DB fallback 확인

목적

Redis가 죽었을 때 Top10 API가 500 에러 대신 DB fallback으로 정상 응답하는지 확인한다.

실험 절차

# 1. Redis EC2에서 Redis 중지
docker stop redis

# 2. Top10 API 호출 (정상 응답이 와야 함)
curl -w "\nHTTP Status: %{http_code}\nTime: %{time_total}s\n" \
  http://jongju.duckdns.org:8080/api/posts/top10

# 3. 앱 로그에서 fallback 경고 확인
docker logs community-app --tail 20

# 4. Redis 재시작
docker start redis

# 5. 다시 API 호출하여 캐시 정상 동작 확인
curl -w "\nHTTP Status: %{http_code}\nTime: %{time_total}s\n" \
  http://jongju.duckdns.org:8080/api/posts/top10

확인 포인트

• Redis 중지 상태에서 HTTP 200 응답 반환
• 앱 로그에 Redis 조회 실패 - DB fallback 경고 출력
• Redis 재시작 후 캐시 정상 동작 복귀 (응답 시간 ms 단위)

[kimseonj]

실험 1 결과: k6 부하 테스트 (기간 제한 적용 후)

테스트 환경

• VUs: 50 / 지속 시간: 5분 / 스크립트: baseline.js

결과 비교

지표	이전 (기간 제한 전)	1차 실행	2차 실행
Top10 avg	315ms	124.71ms	120.3ms
Top10 max	58.01s	13.81s	12.81s
Top10 p95	27ms	45.36ms	58.84ms
Top10 med	-	20.64ms	23.32ms
타임아웃	40건 (0.22%)	0건	0건
error_rate	-	0.00%	0.00%
총 요청 수	-	20,397	20,550

분석

• avg 60~62% 감소 (315ms → 120~124ms)
• max 76~78% 감소 (58s → 12.8~13.8s) — 초반 cache miss stampede 영향 대폭 감소
• 타임아웃 완전 해소 (40건 → 0건)
• p95가 27ms → 45~58ms로 올라간 것은 이전에 타임아웃 40건이 체크 실패로 통계에서 제외된 영향으로 추정. 현재는 모든 요청이 성공하여 정직한 수치.

체크리스트

• get_top10_latency max 값이 이전(58s)보다 감소 → 12.8s (78% 감소)
• 타임아웃 건수가 이전(40건)보다 감소 → 0건
• Grafana Backend Latency 초반 스파이크 비교 (확인 필요)

[kimseonj]

실험 2 결과: Redis 장애 시 DB fallback 검증

1차 시도 — timeout 미설정 상태

Redis 중지 후 API 호출 결과:

HTTP Status: 500
Time: 60.276s

• Lettuce 기본 타임아웃(60초) 동안 Redis 연결 시도 → 타임아웃 후 500 에러
• fallback 코드에 도달하기 전에 60초 소요

원인 분석

• spring.data.redis.timeout 미설정 → Lettuce 기본값 60초 적용
• fallback 로직(RedisConnectionFailureException catch)은 있었지만, 예외 발생까지 60초 대기

해결

• spring.data.redis.timeout: 3s 추가 (PR ⚡️ Top10 캐싱 성능 개선 및 Redis 장애 대응 #82)

2차 시도 — timeout 3s 적용 후 부하 테스트 (Redis 중단 상태)

지표	Redis 정상	Redis 중단 (fallback)
Top10 avg	120ms	27.97s
Top10 max	12.81s	41.86s
error_rate	0%	12.59%
총 요청 수	20,550	921

원인 분석 — HikariCP 커넥션 풀 고갈

Grafana 메트릭 확인 결과:

• HikariCP active: 10 (최대), pending: 40
• Redis 캐시 없이 매 요청마다 Top10 DB 쿼리 실행 → 쿼리 처리 시간(~4초)이 커넥션을 장시간 점유
• 커넥션 풀 10개가 전부 점유되어 나머지 40개 요청이 커넥션 대기 → 게시글 목록/상세 API까지 연쇄 지연

📸 Grafana HikariCP 메트릭 스크린샷

체크리스트

• Redis 중지 상태에서 HTTP 200 응답 반환 → ❌ timeout 미설정 시 500 발생, 3s 설정 후 fallback 동작 확인 필요 (단건 curl)
• 부하 환경에서 fallback 동작 확인 → 동작하나 커넥션 풀 고갈로 성능 심각 저하
• Redis 재시작 후 캐시 정상 동작 복귀 확인
• Grafana 스크린샷 추가

향후 개선 방향

• 로컬 캐시(Caffeine) 2차 fallback 검토 — DB 부하 없이 즉시 응답 가능
• Redis 장애 시 circuit breaker 패턴 적용 검토 — 장애 감지 후 Redis 호출 자체를 스킵하여 3초 대기 제거

[kimseonj]

실험 2 추가 검증: timeout 3s 적용 후 단건 fallback 확인

Redis 중지 → 단건 curl 결과

• HTTP 200 정상 응답
• 응답 시간 3초 이내
• 이전(timeout 미설정 시) 60초 → 3초로 단축

📸 curl 응답 스크린샷

앱 로그

• Redis 조회 실패 - DB fallback 경고 정상 출력

📸 fallback 로그 스크린샷

체크리스트 최종

• Redis 중지 상태에서 HTTP 200 응답 반환 ✅
• 앱 로그에 Redis 조회 실패 - DB fallback 경고 출력 ✅
• Redis 재시작 후 캐시 정상 동작 복귀 ✅ (부하 테스트에서 확인)
• Grafana 스크린샷 추가