[Redis] Redis 캐시 적용하기 - 인기글 조회 적용
지난번 진행했던 Redis 초기 세팅을 바탕으로 오늘은 홈페이지의 인기 게시물 조회 API에 캐시를 적용했다.
인기 게시물은 좋아요 수 기준으로 상위 10개를 불러온다. 실시간으로 데이터가 급격히 변하지 않지만 메인 페이지의 특성상 호출 빈도가 매우 높다. 매번 DB를 조회하는 대신 Redis 캐시를 사용해 성능을 개선했다.
1. RedisConfig 설정
@Configuration
@EnableCaching
public class RedisConfig {
...
public static final String POPULAR_POSTS_CACHE = "popularPosts"; // 홈페이지 사진 수다 미리 보기
...
private static final long POPULAR_POSTS_TTL_MINUTES = 10L;
@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory) {
RedisTemplate<String, Object> template = new RedisTemplate<>();
template.setConnectionFactory(connectionFactory);
template.setKeySerializer(new StringRedisSerializer());
template.setValueSerializer(new GenericJackson2JsonRedisSerializer(redisObjectMapper()));
return template;
}
@Bean
public CacheManager cacheManager(RedisConnectionFactory connectionFactory) {
RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
.entryTtl(Duration.ofMinutes(DEFAULT_CACHE_TTL_MINUTES))
.disableCachingNullValues()
.serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
.serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer(redisObjectMapper())));
return RedisCacheManager.builder(connectionFactory)
.cacheDefaults(config)
...
.withCacheConfiguration(POPULAR_POSTS_CACHE, config.entryTtl(Duration.ofMinutes(POPULAR_POSTS_TTL_MINUTES)))
.build();
}
private ObjectMapper redisObjectMapper() {
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.registerModule(new JavaTimeModule());
objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
BasicPolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
.allowIfBaseType(Object.class)
.allowIfSubType("com.finders.api")
.build();
objectMapper.activateDefaultTyping(ptv, ObjectMapper.DefaultTyping.EVERYTHING);
return objectMapper;
}
}
인기 게시물 전용 캐시 이름과 TTL 10분 설정을 추가했다.
EVERYTHING 설정을 사용하되, allowIfSubType("com.finders.api")를 통해 우리 패키지 하위 클래스만 타입 정보를 유지하도록 화이트리스트를 적용했다.
코드 리뷰 중에 EVERYTHING 대신 NON_FINAL을 사용해 구성을 더 단순하게 유지하는 것을 고려해 보라는 의견이 있었지만, 아래 트러블 슈팅에서 언급할 record 이슈로 인해 현재 설정을 유지하기로 했다.
2. PostCacheDTO
@Builder
public record PostCacheDTO(
Long id,
String title,
Integer likeCount,
Integer commentCount,
String objectPath
) implements Serializable {
}
Post 엔티티가 PostImage를 참조하고, PostImage가 다시 Post를 참조하는 등 순환 참조 문제가 발생할 수 있고, 캐시에 불필요한 정보까지 저장되는 것을 방지하기 위해 전용 DTO를 생성했다.
Entity를 직접 캐싱하지 않고, 필요한 데이터만 담은 PostCacheDTO를 생성했다.
3. PostResponse
// PostResponse
public static PostPreviewDTO fromCache(PostCacheDTO cache, boolean isLiked, String fullImageUrl) {
return PostPreviewDTO.builder()
.postId(cache.id())
.title(cache.title())
.likeCount(cache.likeCount())
.commentCount(cache.commentCount())
.isLiked(isLiked)
.image(new PostImageResDTO(fullImageUrl, null, null))
.build();
}
- 캐시 DTO를 응답 DTO로 변환했다.
4. PostRepository
// PostRepository
@Cacheable(value = "popularPosts", key = "'home_top10'")
public List<PostCacheDTO> findTop10PopularPosts() {
List<Long> ids = queryFactory
.select(post.id)
.from(post)
.where(post.status.eq(CommunityStatus.ACTIVE))
.orderBy(post.likeCount.desc(), post.createdAt.desc()) // 좋아요 순, 같으면 최신순
.limit(POPULAR_POSTS_LIMIT)
.fetch();
if (ids.isEmpty()) return List.of();
List<Post> posts = queryFactory
.selectFrom(post)
.leftJoin(post.postImageList).fetchJoin()
.where(post.id.in(ids))
.orderBy(post.likeCount.desc(), post.createdAt.desc())
.fetch();
return posts.stream()
.map(p -> PostCacheDTO.builder()
.id(p.getId())
.title(p.getTitle())
.likeCount(p.getLikeCount())
.commentCount(p.getCommentCount())
.objectPath(p.getPostImageList().isEmpty() ? null : p.getPostImageList().get(0).getObjectPath())
.build())
.toList();
}
@Cacheable을 적용하여 Redis에 데이터가 있으면 메서드 로직을 타지 않고 바로 반환한다.
쿼리 튜닝을 위해 ID 목록을 먼저 뽑고 IN 절로 데이터를 갖고 오는 방식을 사용했다.
조회 성능 개선이 목적이므로, 서비스가 아닌 조회 전용 Repository 메서드에 캐시를 적용했다. 해당 메서드는 상태 변경 로직이 없고, 캐시 무효화 시점도 명확해 안전하다고 판단했다.
인기 게시물은 모든 사용자에게 동일한 결과를 반환하므로 사용자 ID를 포함하지 않은 고정 캐시 키(home_top10)를 사용했다.
5. PostQueryServiceImpl
// PostQueryServiceImpl
@Override
public PostResponse.PostPreviewListDTO getPopularPosts(Long memberId) {
List<PostCacheDTO> cachedPosts = postQueryRepository.findTop10PopularPosts();
Set<Long> likedPostIds;
if (memberId != null && !cachedPosts.isEmpty()) {
List<Long> postIds = cachedPosts.stream().map(PostCacheDTO::id).toList();
likedPostIds = postLikeRepository.findLikedPostIdsByMemberAndPostIds(memberId, postIds);
} else {
likedPostIds = java.util.Collections.emptySet();
}
List<PostResponse.PostPreviewDTO> previews = cachedPosts.stream()
.map(dto -> {
boolean isLiked = likedPostIds.contains(dto.id());
String fullImageUrl = (dto.objectPath() != null)
? storageService.getPublicUrl(dto.objectPath())
: null;
return PostResponse.PostPreviewDTO.fromCache(dto, isLiked, fullImageUrl);
})
.toList();
return PostResponse.PostPreviewListDTO.from(previews);
}
- 전체 리스트는 캐시에서 가져오되, 내가 이 글에 좋아요를 눌렀는가와 같은 개인화된 정보는 서비스 레이어에서 동적으로 결합하도록 설계했다. 캐시의 효율성과 개인화 정보를 동시에 잡은 방식이다.
6. 트러블 슈팅
오늘 가장 시간을 많이 썼던 부분은 record 타입의 직렬화 충돌 문제였다.
Could not read JSON:Unexpected token (START_ARRAY) // 에러 발생
코드 리뷰 과정에서 EVERYTHING 대신 NON_FINAL을 사용해 구성을 단순화하자는 의견이 있었다. 그러나 Java의 record 타입은 모든 필드가 final이기 때문에 NON_FINAL 설정에서는 타입 정보가 누락되어 역직렬화 오류가 발생했다. 해당 오류로 인해 EVERYTHING은 유지하되, allowIfSubType("com.finders.api")를 통해 패키지 화이트리스트를 적용했다.
설정을 변경한 후에는 반드시 docker exec -it [컨테이너명] redis-cli flushall 을 통해 기존에 잘못된 데이터를 날려 줘야 한다. 설정 변경 후 기존에 잘못 직렬화된 데이터가 남아 있어 로컬 환경에서만 flushall로 캐시를 초기화했다.
오늘의 요약
캐시용 DTO를 별도로 설계하여 필요한 정보만 효율적으로 저장했다.
설정 변경 후에는 기존 캐시 데이터를 꼭 날리자.