Spring Boot에서 Redis 캐시 적용 전략과 실전 구현: 캐시 히트율 90% 달성하기

🚀 Spring Boot에서 Redis 캐시 적용 전략과 실전 구현

- 캐시 히트율 90% 달성하기

API 응답 속도가 느리거나 DB 부하가 높을 때 가장 먼저 고려되는 해결책 중 하나는 캐시(Cache)입니다.
하지만 단순히 Redis를 붙였다고 해서 성능이 무조건 좋아지진 않습니다.
캐시 히트율(Cache Hit Rate)이 낮으면 Redis가 있어도 효과는 미미하죠.

이번 글에서는 다음 내용을 다룹니다:

• 캐시 히트율의 개념과 계산 방법
• DB와 캐시 간 데이터 불일치 문제 해결 전략
• 실전 계층 구조에서의 캐시 적용 예시
• 캐시 히트율을 높이기 위한 실전 팁
• @Cacheable, @CacheEvict 실전 코드

---

 

✅ 캐시는 어디에 적용하는 게 좋을까? Controller vs Service

캐시는 Controller에 직접 적용할 수도 있고, Service 계층에 적용할 수도 있습니다.
하지만 각 계층의 책임(SOC: Separation of Concerns)을 고려하면 Service 계층이 대부분의 경우 더 적절합니다.

---

📌 Controller에 캐시를 적용할 수는 있지만…

항목	Controller에서 캐시 적용 시
✅ 장점	빠른 응답 가능 (캐시 → 바로 리턴) 단순 JSON 캐시에 유리
❌ 단점	비즈니스 로직 중복 관심사 분리 침해 테스트 어려움 재사용성 낮음

 

Controller 캐시 적용 예시 (비추천):

@GetMapping("/api/products/{id}")
public ResponseEntity<ProductDto> getProduct(@PathVariable Long id) {
    String key = "product:" + id;
    String cached = redisTemplate.opsForValue().get(key);
    if (cached != null) {
        return ResponseEntity.ok(objectMapper.readValue(cached, ProductDto.class));
    }

    ProductDto product = productService.getProductById(id);
    redisTemplate.opsForValue().set(key, objectMapper.writeValueAsString(product), 10, TimeUnit.MINUTES);
    return ResponseEntity.ok(product);
}

---

 

✅ 그래서 대부분은 Service 계층에 적용

Service는 도메인 로직을 처리하는 계층이기 때문에 캐시 조건/무효화 등의 정책을 더 유연하게 다룰 수 있습니다.
또한, 여러 곳에서 재사용되므로 유지보수성과 일관성이 높습니다.

 

Service 캐시 적용 예시 (추천):

@Cacheable(value = "productCache", key = "#id")
public ProductDto getProductById(Long id) {
    Product product = productRepository.findById(id)
        .orElseThrow(() -> new NotFoundException("Product not found"));
    return new ProductDto(product);
}

@CacheEvict(value = "productCache", key = "#productDto.id")
public void updateProduct(ProductDto productDto) {
    Product product = productRepository.findById(productDto.getId())
        .orElseThrow(() -> new NotFoundException("Product not found"));
    product.setName(productDto.getName());
    product.setPrice(productDto.getPrice());
    productRepository.save(product);
}

---

🧠 언제 Controller 캐시도 고려할 수 있을까?

• 정적 JSON 응답 (ex. 인기 상품, 랭킹 등)
• TTL이 명확하고, 사용자 인증과 무관한 경우

Controller 캐시 사용 예시:

@GetMapping("/api/ranking")  
public ResponseEntity<List> getDailyRanking() {  
    String key = "ranking:daily";  
    String cached = redisTemplate.opsForValue().get(key);  
    if (cached != null) {  
    	return ResponseEntity.ok(objectMapper.readValue(cached, new TypeReference<List>() {}));  
	}

    List<ProductDto> ranking = productService.getDailyRanking();
    redisTemplate.opsForValue().set(key, objectMapper.writeValueAsString(ranking), 1, TimeUnit.HOURS);
    return ResponseEntity.ok(ranking);
}

---

 

🧩 ✍️ 내 프로젝트 구조와 캐시 적용 위치

제가 개발 중인 애플리케이션의 계층 구조는 다음과 같습니다:

  Controller → Application Service → Database Service → DB

💡 그래서 캐시는 어디에 넣었나?

저는 Database Service 계층에 캐시를 적용했습니다. 이유는 다음과 같습니다:

이유	설명
DB 접근 로직이 이 계층에 집중되어 있음	대부분의 캐싱 대상이 DB 조회 결과
Application Service에서 캐시가 있는지 신경 쓰지 않아도 됨	도메인 유스케이스 로직이 단순해짐
변경 시 일관성 있는 무효화 가능	저장/삭제 로직도 이 계층에서 처리

---

 

✅ 실전 적용: Database Service 계층 캐시 코드

@Service
public class UserDatabaseService {

    @Cacheable(value = "userCache", key = "#userId", unless = "#result == null")
    public UserDto findUserById(Long userId) {
        User user = userRepository.findById(userId)
            .orElseThrow(() -> new NotFoundException("User not found"));
        return new UserDto(user);
    }

    @CacheEvict(value = "userCache", key = "#userDto.id")
    public void updateUser(UserDto userDto) {
        User user = userRepository.findById(userDto.getId())
            .orElseThrow(() -> new NotFoundException("User not found"));
        user.setName(userDto.getName());
        user.setEmail(userDto.getEmail());
        userRepository.save(user);
    }
}

---

🔧 RedisCacheManager 설정 (TTL 포함)

@Bean
public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) {
    RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
        .entryTtl(Duration.ofMinutes(10))
        .serializeValuesWith(SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

    return RedisCacheManager.builder(connectionFactory)
        .cacheDefaults(config)
        .build();
}

---

 

🧠 캐시 히트율이란?

캐시 히트율 = (캐시 히트 수 / 전체 요청 수) × 100

Redis CLI에서 확인:

127.0.0.1:6379> INFO stats
keyspace_hits:158920
keyspace_misses:4180

히트율 = 158920 / (158920 + 4180) ≈ 97.4%

 

---

✅ 캐시 히트율을 높이기 위한 전략

1. 일관된 키 설계

@Cacheable(value = "userCache", key = "'user:' + #userId")

---

2. 인기 데이터 프리히트 (Pre-warming)

@PostConstruct
public void preloadPopularItems() {
    List<Product> top = productRepository.findTop10ByOrderBySalesDesc();
    for (Product p : top) {
        redisTemplate.opsForValue().set("product:" + p.getId(), objectMapper.writeValueAsString(p), 1, TimeUnit.HOURS);
    }
}

---

3. Cache Stampede 방지

@Cacheable(value = "userCache", key = "#userId", sync = true)

---

4. TTL을 상황별로 차등 적용

redisTemplate.opsForValue().set("user:active:123", jsonData, 5, TimeUnit.MINUTES);
redisTemplate.opsForValue().set("user:archived:123", jsonData, 60, TimeUnit.MINUTES);

---

 

🧩 마무리: 캐시는 단순한 “속도”가 아니다

Redis 캐시는 단순히 "빠르게 응답하기" 위한 도구가 아니라,
어떻게 데이터를 재사용하고 관리할지에 대한 아키텍처 전략입니다.

---

✅ 캐시가 효과적인 상황

상황	이유
동일한 요청이 자주 반복될 때	응답을 그대로 재사용 가능 → 히트율 ↑
DB I/O 비용이 크거나 트래픽이 급증할 때	부하 분산
데이터가 자주 바뀌지 않는 경우	정적 콘텐츠로 캐싱 안정적
외부 API 호출 결과를 저장할 때	응답 속도 + 비용 절감

 

예시

• 사용자 프로필 정보 (조회 빈도 높고, 변경은 드묾)
• 인기 상품 목록, 랭킹 리스트
• 지역 기반 추천, 환율/날씨 데이터
• 로그인 후 사용자 권한 정보

---

❌ 캐시를 피해야 하는 상황

상황	이유
데이터가 자주 변경되는 경우	캐시 무효화 관리가 복잡하고 위험
실시간성이 매우 중요한 경우	캐시된 오래된 데이터가 치명적일 수 있음
트랜잭션/일관성이 중요한 비즈니스 로직	캐시보다 DB 정확성이 우선

예시

• 은행 계좌 잔액, 결제 처리
• 재고 수량, 실시간 예약 처리
• 관리자 페이지 실시간 통계
• 민감한 개인정보 관련 API

---

📌 핵심 요약:

• “무조건 캐싱”은 안 된다.
• “자주 조회되지만 잘 안 바뀌는 데이터”가 캐시 대상의 우선순위.
• “변경이 자주 되거나, 잘못된 정보가 위험한 데이터”는 캐시보다 DB 우선.