Cache를 활용하여 조회 성능 개선하기

wontaekoh·2024년 11월 7일
redis캐시
0

항해 플러스

목록 보기
5/7
post-thumbnail

e-commerce 비즈니스 로직에서 조회가 오래걸리는 쿼리를 캐싱을 통해 성능을 개선해보고, 적절한 캐싱전략을 사용해보자 하였습니다.

⚠️ 썸네일에 Redis 이미지가 있지만, Redis와 캐시는 동일한 개념이 아닙니다. Redis는 캐시를 구현하기 위한 데이터 저장소 중 하나일 뿐이며, 캐시 외에도 저장소, 메시지 브로커 등 다양한 기능을 제공합니다. 따라서 Redis를 단순히 캐시로만 생각하면 안 됩니다.

📌 캐시란?

캐시(Cache)는 데이터나 값을 미리 저장해 두었다가 필요할 때 빠르게 제공하기 위한 메모리 공간입니다. 주로 자주 사용되는 데이터에 대해 빠른 접근을 제공함으로써 응답 시간을 단축하고 시스템 성능을 개선하는 데 사용됩니다. 데이터베이스나 원격 서버로의 반복적인 접근을 줄여 시스템 리소스를 효율적으로 사용할 수 있게 합니다.

📌 캐시의 종류

캐시의 종류는 정말 다양하고 각각의 원리에 대해서 파고들면 그것만으로도 포스팅을 하나만들 수 있을 정도로 내용이 많아지기 때문에... 가볍게 특징정도만 알아보겠습니다.

  1. CPU 캐시 메모리

    • 특징: CPU 내부에 있는 고속 메모리로, 자주 사용되는 데이터를 저장하여 CPU가 빠르게 접근할 수 있도록 합니다.
    • 예시: L1, L2, L3 캐시 등 CPU 계층에서의 캐시 메모리입니다.

  2. 메모리 캐시

    • 특징: 서버의 메인 메모리(RAM)에 데이터를 저장하여 빠른 접근 속도를 제공합니다.
    • 예시: Redis, Memcached와 같은 인메모리 데이터 저장소가 여기에 해당합니다.

  3. 웹 캐시

    • 특징: 웹 페이지나 이미지와 같은 정적 자원을 저장하여 웹 서버의 부하를 줄이고 사용자에게 빠른 응답을 제공합니다.
    • 예시: CDN(Content Delivery Network)에서 제공하는 캐싱 서비스 등이 있습니다.

  4. 브라우저 캐시

    • 특징: 웹 브라우저가 웹 페이지, 이미지, CSS 파일 등을 저장하여 동일한 리소스를 다시 요청할 때 네트워크 부하를 줄이고 빠르게 페이지를 로드할 수 있게 합니다.
    • 예시: 브라우저 설정에서 확인할 수 있는 캐시된 이미지 및 파일들입니다.

  5. 데이터베이스 캐시

    • 특징: 데이터베이스 쿼리 결과를 캐싱하여 동일한 쿼리가 반복적으로 실행되는 경우 데이터베이스 부하를 줄입니다.
    • 예시: MySQL의 Query Cache, PostgreSQL의 캐시 메커니즘 등이 있습니다.

  6. 분산 캐시

    • 특징: 여러 대의 서버에 걸쳐 데이터를 캐싱하여 대규모 시스템에서도 빠른 성능을 제공할 수 있습니다.
    • 예시: Redis Cluster, Hazelcast와 같은 분산 캐시 솔루션이 여기에 해당합니다.

이번 포스팅에서는 Redis를 활용하여 메모리 캐싱을 사용해보겠습니다.

📌 어떤 상황에서 캐시를 적용해야할까?

캐싱을 적용해야하는 상황은 주로 다음과 같습니다.

1. 자주 조회되지만 자주 변경되지 않는 데이터

  • 상품 정보, 사용자 프로필, 인기 상품 목록 등과 같은 데이터는 조회는 빈번하지만, 변경은 상대적으로 적습니다. 이 경우 캐싱을 통해 데이터베이스 부하를 줄이고 빠른 응답을 제공할 수 있습니다.

2. 쿼리가 복잡해서 성능 개선이 필요한 경우

  • 복잡한 조인이나 연산이 많은 쿼리는 데이터베이스에 큰 부하를 줄 수 있습니다. 이러한 경우 캐싱을 통해 쿼리 실행 시간을 줄이고 데이터베이스의 부하를 줄일 수 있습니다.

3. 동일한 데이터를 반복적으로 요청할 때

  • 동일한 데이터를 여러 번 조회하는 경우, 데이터베이스나 서버로의 불필요한 접근을 피하기 위해 캐싱을 사용합니다. 예를 들어, 인기 상품 목록과 같은 데이터는 반복적으로 요청되기 때문에 캐싱을 통해 서버 자원을 절약할 수 있습니다.

4. 데이터 일관성이 상대적으로 덜 중요한 경우

  • 일관성이 덜 중요한 데이터는 캐싱을 통해 성능을 극대화할 수 있습니다. 예를 들어, 통계 데이터나 비실시간 정보는 약간의 지연이 있더라도 큰 문제가 없으므로 캐싱이 적합합니다.

📌 캐시를 적용해야하는 API 분석

API1.자주 조회o, 자주 변경X2.쿼리가 복잡3.동일데이터 반복요청4.데이터 일관성 중요도 낮음
/api/products[GET] - 상품목록조회⭕❌⭕⭕
/api/products/{id}[GET] - 상품단건조회❌❌❌❌
/api/products/popular[GET] - 인기상품 조회⭕⭕⭕⭕
/api/points[GET] - 포인트 조회❌❌❌❌
/api/carts[GET] - 장바구니 조회❌❌❌⭕

※ POST, PUT, DELETE 요청은 캐싱적용 대상이 아니기 때문에 표에 넣지 않았습니다.

인기상품과 상품목록 조회를 캐싱대상으로 선택

  • 인기 상품, 상품목록 데이터는 e-커머스에서 자주 조회되는 로직입니다.
  • 인기상품의 경우 주문, 주문상세, 제품이 조인되고, 집계가 들어가기 때문에 쿼리가 복잡합니다.
  • 인기 상품, 상품목록 데이터가 실시간으로 반영되지 않더라도 주문 시점에서 정확한 데이터를 보여주면 되기 때문에 캐싱대상으로 적합하다 생각하였습니다.

나머지 API는 캐싱하지 않는 이유

  • 포인트조회, 장바구니 조회와 같은 경우는 쿼리가 복잡하지 않고, 캐싱을 하는 것은 불필요하게 메모리를 차지한다고 생각하였습니다.
  • 포인트 충전, 주문 등과 같은 CUD 형태의 API는 실시간 데이터가 중요하고, 사용자의 재산 및 재고 관리와 직결되므로, 데이터의 정확성이 중요합니다. 따라서 이러한 API는 최신 데이터를 즉시 조회하고 변경하는 것이 적합하여 캐싱을 하지 않았습니다.

📌 캐시전략 및 TTL

캐시 전략에는 다양한 방식이 있으며, 각 전략은 시스템의 성능, 사용 사례, 요구사항 등에 따라 선택됩니다. 이론 및 개념에 대해서는 아래 잘 정리된 링크를 남겨두겠습니다.
캐시(Cache) 설계 전략 지침 💯 총정리

캐시 전략 선택 및 구현

읽기 전략으로는 Lock Aside, 쓰기 전략으로는 Write Around를 사용하여 이를 구현하였습니다.

  • 캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장
  • 캐시와 DB가 분리되어 가용되기 때문에 캐시 장애 대비 구성이 되어있음. 만일 redis가 다운 되더라도 DB에서 데이터를 가져올수 있어 서비스 자체는 문제가 없음.
  • 대신에 캐시에 붙어있던 connection이 많았다면, redis가 다운된 순간 순간적으로 DB로 몰려서 부하 발생.

구현코드

  • build.gradle
    implementation 'org.springframework.boot:spring-boot-starter-data-redis'
  • RedisConfig
@Configuration
@EnableCaching
@EnableRedisRepositories
public class RedisConfig {

	@Bean
	public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
		RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
		redisTemplate.setConnectionFactory(redisConnectionFactory);
		redisTemplate.setKeySerializer(new StringRedisSerializer());
		redisTemplate.setValueSerializer(new Jackson2JsonRedisSerializer<>(Object.class));
		return redisTemplate;
	}

	@Bean
	public RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
		RedisCacheConfiguration defaultCacheConfig  = RedisCacheConfiguration.defaultCacheConfig()
			.entryTtl(Duration.ofMinutes(10))
			.serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
			.serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

		Map<String, RedisCacheConfiguration> cacheConfigurations = new HashMap<>();
		// 인기상품 조회는 TTL 1시간
		cacheConfigurations.put(CacheConstants.POPULAR_PRODUCTS_CACHE, defaultCacheConfig.entryTtl(Duration.ofHours(1)));
		// 상품목록 조회는 TTL 10분
		cacheConfigurations.put(CacheConstants.PRODUCTS_ALL, defaultCacheConfig.entryTtl(Duration.ofMinutes(10)));

		return RedisCacheManager.builder(redisConnectionFactory)
			.cacheDefaults(defaultCacheConfig )
			.withInitialCacheConfigurations(cacheConfigurations)
			.build();
	}

}
  • Service단 코드
@Slf4j
@Service
@RequiredArgsConstructor
public class ProductService {

	private final ProductRepository productRepository;


	@Cacheable(value = CacheConstants.PRODUCTS_CACHE, key = CacheConstants.PRODUCTS_ALL)
	public List<ProductInfo.Amount> getDetailList() {
		// 로직생략...
	}

	@Cacheable(value = CacheConstants.POPULAR_PRODUCTS_CACHE, key = CacheConstants.RECENT_3_DAY_TOP_5_KEY)
	public List<ProductInfo.OrderAmount> getPopularProducts() {
		// 로직생략...
	}
}

캐시도입 전 후 성능 비교

1초동안 1000명의 사용자가 조회요청을 보내는 사니리오로 테스트를 하였습니다.

인기상품조회(전)인기상품조회(후)상품목록조회(전)상품목록조회(후)
평균응답시간(ms)17928742609815
초당처리 요청수362.6/sec696.9/sec161.9/sec694.9/sec
Jemeter를 활용한 성능 지표 이미지

  • 인기상품조회(전)

  • 인기상품조회(후)

  • 상품목록조회(전)

  • 상품목록조회(후)

  • 인기상품조회는 평균응답시간은 51.2%감소, 초당처리 요청수는 92.2% 증가하였습니다.
  • 상품목록조회는 평균응답시간은 68.7%감소, 초당처리 요청수는 329.2% 증가하였습니다.

용도에 따라 TTL 설정을 다르게 설정

상품 조회 요청은 3가지가 있습니다. 인기 상품조회, 상품목록 조회, 상품단건(상세)조회 캐시를 적용할 때 TTL 설정에 따라 실시간성과 정확도가 달라지게 되는데 이는 상호 배타적인 성격으로 인해 용도에 따라 적절하게 적용할 필요가 있습니다.

아래와같은 근거로 저는 TTL 설정, 캐싱 적용을 다르게 하였습니다.

캐시적용여부TTL이유
인기상품 조회Y1시간메인 페이지에 들어가면 항상 조회되는 데이터로, 실시간성이 낮아도 되며, 트래픽을 줄이는 것이 중요합니다. 1시간 동안 자주 변화하지 않기 때문에 1시간 TTL이 적절합니다.
상품목록 조회Y10분사용자가 특정 카테고리나 상품군을 조회할 때, 데이터의 실시간성이 중요하지만 완전한 실시간 업데이트가 필요하지는 않습니다. 데이터가 자주 갱신되므로 TTL을 10분으로 설정하여 실시간성과 효율성을 균형 있게 유지합니다.
상품단건(상세)조회N상품의 상세 정보는 가격, 재고, 프로모션 등과 같은 데이터가 자주 변경될 수 있기 때문에 실시간성이 매우 중요합니다. 캐시를 적용하지 않아 항상 최신 정보를 제공합니다.

📌 스케쥴링을 돌며 캐시 업데이트하여 Cache Stamped 현상을 방지

캐시를 사용하는 시스템에서는 캐시 데이터가 만료되었을 때 Cache Stamped 현상이 발생할 수 있습니다. 이러한 현상은 캐시가 일시적으로 비어 있는 동안 많은 요청이 동시에 데이터베이스(DB)에 접근해 부하를 일으키는 상황을 말합니다. 이 문제를 해결하기 위해 스케쥴링을 이용한 캐시 업데이트를 통해 해결하고자 하였습니다.

구현코드

@Component
@EnableScheduling
@RequiredArgsConstructor
public class ProductSchedule {

	private final ProductRepository productRepository;
	private final CacheManager cacheManager;

	/**
	 * 인기상품 조회 캐시 업데이트
	 * 20분 간격으로 실행 (20분 = 1200000ms)
	 */
	@Scheduled(fixedRate = 1200000)
	public void updatePopularProductsCache() {
		// 새로운 데이터를 DB에서 조회
		List<ProductInfo.OrderAmount> updatedData = //생략...

		// 캐시 덮어쓰기
		Objects.requireNonNull(cacheManager.getCache(CacheConstants.POPULAR_PRODUCTS_CACHE))
			.put(CacheConstants.RECENT_3_DAY_TOP_5_KEY.replace("'", ""), updatedData);
	}

	/**
	 * 상품목록 조회 캐시 업데이트
	 * 3분 간격으로 실행 (3분 = 180000ms)
	 */
	@Scheduled(fixedRate = 180000)
	public void updateProductsCache() {
		// 새로운 데이터를 DB에서 조회
		List<Product> productList = //생략...

		// 캐시 덮어쓰기
		Objects.requireNonNull(cacheManager.getCache(CacheConstants.PRODUCTS_CACHE))
			.put(CacheConstants.PRODUCTS_ALL.replace("'", ""), updatedData);
	}

}
  • 인기 상품 조회는 20분 간격, 상품 목록 조회는 3분 간격으로 스케쥴링이 동작하도록 하였는데 이는 TTL시간/3 정도의 값으로 스케쥴링 간격을 설정하였습니다.
  • 이는 캐시가 만료되기 전에 업데이트 시켜주어야 한다고 판단하였고, 혹시 스케쥴링이 실패하거나 타이밍이 안맞았을 경우를 대비해서 넉넉하게 시간을 잡기 위해 TTL시간/3` 정도의 값 으로 스케쥴링 간격을 설정하였습니다.

참고자료

profile
wontaekoh
주니어 백엔드 개발자, 오원택입니다!
이전 포스트

성능 분석을 통한 적합한 동시성 제어 방식 선택하기

다음 포스트

MSA 도입의 목적과 고려사항

0개의 댓글