맛동산🎅 동화 캐시 시스템 구축하기

도입 배경

맛동산🎅은 아이 맞춤형 동화를 생성하고, 아이에게 동화를 들려주며 직접 상호작용할 수 있는 전용 인형 디바이스를 제공하는 서비스이다.

처음 AI가 아이의 나이, 언어, 주어진 프롬프트에 맞게 동화를 생성해서 제공하면 그 이후에 유저들은 생성된 동화를 공유하거나 조회할 수 있다.

이렇듯, 동화가 사용자 맞춤형으로 AI에 의해 생성되기 때문에 처음 생성 이후, 수정 & 삭제 요청이 매우 적고 조회 요청이 많을 것이라는 점을 알 수 있었다.

또한 인기 동화, 최근 생성된 동화 리스트 등을 제공하면서 특정 동화로의 조회가 몰릴 수 있을 것이라는 생각이 들었다.

이에 동화 캐시 시스템 도입을 결정하게 되었다.

---

캐시란?

본격적으로 캐시 시스템을 구축하기에 앞서 먼저 캐시란 무엇인지에 대해서 간략하게 살펴보면 좋을 것 같다.

캐시란 무엇일까?

컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소

캐시는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리키며 데이터에 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.

또한 캐시의 종류로는 CPU 캐시, 웹 캐시, 브라우저 캐시, 어플리케이션 캐시 등등 여러 종류가 있으며 컴퓨터 과학 전반에서 캐시가 사용되고 있다고 해도 과언이 아니다.

이때 캐시가 효율적으로 동작하려면 캐시에 저장할 데이터가 지역성을 가져야 한다.

• 시간적 지역성
  • 특정 데이터가 한번 접근되었을 경우, 가까운 미래에 또 한번 데이터에 접근할 가능성이 높은 것
• 공간적 지역성
  • 특정 데이터와 가까운 주소가 순서대로 접근되었을 경우

또한 캐시 시스템을 구축하는데에는 다양한 전략이 있을 수 있다.

• 읽기 전략 – Look Aside 전략

  

• 읽기 전략 – Read Through 전략

  

• 쓰기 전략 – Write Back 전략

  

• 쓰기 전략 – Write Through 전략

  

• 쓰기 전략 – Write Around 전략

  

---

Redis를 활용한 캐시 시스템 구축하기

스프링에서 캐시 시스템을 구축하는 방법으로는 여러가지가 있지만 본 프로젝트에서는 익숙한 Redis를 활용하여서 진행해 보았다.

Cache를 사용하기에 앞서 어떠한 전략으로 적용하여 성능을 개선할지 고민해보아야 하는데, 본 프로젝트에서는 캐시의 읽기 전략으로 Read Through 전략을, 쓰기 전략으로는 Write Through 전략을 사용하였다.

RedisConfig.java

@Configuration
@EnableCaching
public class RedisConfig {

    @Bean
    public CacheManager customCacheManager(RedisConnectionFactory redisConnectionFactory) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(15))
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

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

먼저 RedisConfig에서 캐시와 관련된 설정을 진행해주었다. 여기서 TTL, 캐시키와 캐시값의 직렬화 방식 등 캐싱 정책을 설정할 수 있다.

• entryTtl: 캐시의 TTL 설정
• serializeKeysWith: 캐시키의 직렬화 방식
• serializeValuesWith: 캐시값의 직렬화 방식

MatdongsanServerApplication.java

@SpringBootApplication
@EnableFeignClients
@EnableCaching
public class MatdongsanServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(MatdongsanServerApplication.class, args);
    }
}

다음으로는 서버를 실행시키는 SpringBoot Starter class에 @EnableCaching 어노테이션을 넣어서 캐시 기능을 사용할 수 있도록 해주었다.

StoryCacheService.java

@Service
@RequiredArgsConstructor
public class StoryCacheService {

    private final StoryRepository storyRepository;

    @Cacheable(value = "stories", key = "#storyId", cacheManager = "customCacheManager")
    public Story getStory(String storyId) {
        return storyRepository.findByIdOrThrow(storyId);
    }

    @CachePut(value = "stories", key = "#storyId", cacheManager = "customCacheManager")
    public Story updateStory(String storyId, StoryDto.StoryUpdateRequest requestDto) {
        return storyRepository.findByIdOrThrow(storyId)
                .updateStoryDetail(requestDto);
    }

    @CachePut(value = "stories", key = "#storyId", cacheManager = "customCacheManager")
    public Story likeStory(String storyId) {
        return storyRepository.findByIdOrThrow(storyId)
                .addLikes();
    }

    @CachePut(value = "stories", key = "#storyId", cacheManager = "customCacheManager")
    public Story unlikeStory(String storyId) {
        return storyRepository.findByIdOrThrow(storyId)
                .removeLikes();
    }
}

캐시 활성화를 위해서 별도로 StoryCacheService를 구현하였고 다른 클래스에서 해당 클래스의 메서드를 호출해 동화의 CRUD 작업을 처리하도록 구현하였다.

캐시 시스템 구축에는 제공되는 @Cacheable과 @CachePut 어노테이션을 활용하였고, 동화 ID를 KEY로 동화 내용을 캐시할 수 있도록 구현하였다.

@Cacheable과 @CachePut의 역할은 아래와 같다.

• @Cacheable
  • 메서드 호출 결과를 캐시에 저장하고, 이후 동일한 매개변수로 메서드가 호출되면 캐시에서 결과를 반환
  • 메서드 실행 전에 캐시를 먼저 확인 후, 캐시에 값이 없으면 메서드를 실행한 뒤 결과를 캐시에 저장
• @CachePut
  • 메서드 실행 결과를 강제로 캐시에 저장
  • 항상 메서드를 실행하며, 반환된 결과를 캐시에 업데이트

캐시를 비우는데 사용되는 @CacheEvict도 있는데 본 프로젝트에서는 동화 삭제 기능을 별도로 구현하지 않았기 때문에 사용하지는 않았다.

---

성능 테스트

구축한 캐시 시스템이 어느 정도의 성능이 나오는지 간단한 성능 테스트를 진행해보았다.

테스트에는 nGrinder를 활용하였고 미리 1000개의 동화 데이터를 생성 후, 파레토의 법칙을 따르는 조회 요청을 보내도록 하였다.

테스트 시나리오는 아래와 같이 구성하였다.

• Agent: 1대
• 테스트 유저: 1000
• 테스트 시간: 1분
• Ramp-Up (시간에 따라 사용자 증가)

성능 테스트의 결과로 아래와 같은 지표를 확인할 수 있었다.

• 캐시를 적용하지 않은 경우

  

• 캐시를 적용한 경우

  

	캐시 적용 X	캐시 적용	성능 개선
TPS	141.4	224.4	약 58.7% 개선
Mean Test Time	1227.27	1024.08	약 16.6% 개선

TPS의 경우 약 58.7%의 성능 향상, 평균 응답 시간의 경우 약 16.6%의 성능 향상을 확인할 수 있었다.

생각보다는 낮은 폭의 성능 향상을 확인할 수 있었는데 아마 동화 조회 요청에서 해당 동화에 좋아요를 눌렀는지 등의 정보는 어쩔 수 없이 디비에서 가져와야 하기 때문에 이런 결과가 나왔던 것 같다.

---

마치며

잘 몰랐던 캐시에 대해서 학습하고 직접 프로젝트에 적용해보면서, 내가 설계한 서버의 성능 향상에 대해서 고민할 수 있었던 좋은 경험이었다.

특히, 데이터베이스와 캐시 간의 일관성을 유지하는 전략의 중요성을 깨달았고, 실무에서의 캐시 도입을 위해선 효과적인 전략 수립이 필요할 것이라는 생각이 들었다.

또 직접 nGrinder를 통해서 테스트를 진행하며, 성능 개선 사항을 수치로 확인할 수 있어서 좋았다.