✨FEAT: 캐시 전략 최적화로 메인 조회 API 병목 제거

[Pearl-K]

목적

기존 @Cacheable 기반 단순 String 캐시 구조를 Redis HSET 구조(calendar:intake:{userId}:{yyyy-MM})로 개선한다.

• 메인 캘린더 API의 응답 성능 향상
• 캐시 계산 비용 최소화
• 조회 기반 슬라이딩 TTL 전략 적용
• Redis 메모리 효율 개선

---

배경

• 기존 구조는 단순 KV 구조로 @Cacheable이 전체 값을 캐싱하고, 업데이트 시 전체 키를 제거한다.
• 이로 인해 하루 섭취 기록만 바뀌어도 한 달 전체 캐시가 폐기되며, 재계산 비용이 불필요하게 발생한다.
• 또한 과거 월은 거의 조회되지 않음에도 적절한 TTL 설정이 없어 Redis 메모리를 지속 점유하고 있다.

---

✅ Action Items

1. Spring Cache 제거

• @Cacheable, @CacheEvict 제거 (getIntakeLogCalendar, saveIntakeLog 등)

2. Redis 설정 변경

• 기존 Spring Cache를 위한 CacheManager Config 제거
• Redis Config에서 HSET 사용 위한 직렬화 설정
• CacheManagerService 구현

3. API 캐시 적용 로직 변경

• getIntakeLogCalendar()에서 날짜별 캐시 조회 → 없을 경우 계산 + Redis 저장
• saveIntakeLog()에서 날짜별 캐시 무효화 처리
  • 전체 key 삭제 대신 해당 날짜만 갱신 가능하도록 분리

4. TTL 정책

• Redis에 TTL 설정 적용 (EXPIRE key)
• 조회, 갱신 때마다 TTL도 함께 갱신 (Sliding TTL)

5. Redis 메모리 제한 정책 검토 및 적용

• maxmemory-policy (추후 고민 후 적용 예정)

---

추가 정보

• Redis 키 네이밍은 기존 이름을 유지하면서도 도메인 세부 역할(intake)을 추가하여 확장성을 고려한다. calendar:intake:{userId}:{yyyy-MM}
• 필드 명: yyyy-MM-dd (날짜별)
• 저장 값: IntakeSummaryResponse (직렬화 JSON)
• 클라이언트 응답 JSON 포맷은 기존과 동일하게 유지하여 클라이언트 측 변경이 일어나지 않도록 배려