🔧 조회 성능 개선을 위한 캐싱 및 Redis 활용 방안 분석

개요

조회 성능이 저하되는 쿼리에 대한 캐싱 및 Redis를 활용하여 성능을 개선할 수 있는 방안을 조사합니다.

주요 내용

콘서트 대기열 서비스에서는 특정 콘서트 일정 데이터가 자주 조회 됩니다. 같은 콘서트에 대해 다수의 사용자가 동시에 조회 요청을 보내는 경우, 데이터베이스에 부하가 집중되어 성능 저하나 지연이 발생할 수 있습니다. 이를 해결하고자 콘서트 일정 조회 시 Redis 캐싱을 적용하여, 데이터베이스의 부하를 줄이고 응답 속도를 개선하고자 합니다.

Redis 캐싱 선정 이유

1. 데이터베이스 부하 감소: Redis는 메모리 기반 데이터 저장소로 조회 속도가 매우 빠릅니다. 이를 통해 데이터베이스에 직접 접근하는 빈도를 줄이고, 데이터베이스의 부하를 감소시킬 수 있습니다.

2. 빠른 응답 시간: 캐시된 데이터를 사용하면 사용자 요청에 즉각적으로 응답할 수 있어 성능을 개선할 수 있습니다.

3. TTL 설정 가능: Redis는 캐시된 데이터에 유효 기간을 설정할 수 있는 TTL을 지원합니다.

4. 다양한 데이터 구조 지원: Redis는 문자열뿐만 아니라 리스트, 해시 등 다양한 데이터 구조를 지원하므로, 다양한 데이터를 효과적으로 저장하고 조회할 수 있습니다.

레디스 캐싱 적용

레디스 캐싱 설정

@EnableCaching
@Configuration
public class RedissonConfig {

    @Bean
    public CacheManager contentCacheManager(RedisConnectionFactory cf) {
        RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer())) 
                .entryTtl(Duration.ofMinutes(3L)); // 캐시 수명 3분 설정

        return RedisCacheManager.RedisCacheManagerBuilder.fromConnectionFactory(cf).cacheDefaults(redisCacheConfiguration).build();
    }

    @Bean
    public RedissonClient redissonClient() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379");
        return Redisson.create(config);
    }
}

Redis 캐시를 구성하는 데 필요한 CacheManager, RedisCacheConfiguration, RedisConnectionFactory 등을 정의합니다.

• serializeKeysWith: Redis 캐시에서 사용될 캐시 키의 직렬화 방식을 설정합니다. 이 예제에서는 StringRedisSerializer를 사용하여, 캐시의 키를 문자열 형태로 직렬화합니다.

• serializeValuesWith: 캐시 값의 직렬화 방식을 설정합니다. 여기서는 GenericJackson2JsonRedisSerializer를 사용하여, 캐시의 값을 JSON 형식으로 직렬화합니다. 이는 복잡한 객체들을 Redis에 저장할 때 유용하며, 직렬화된 데이터를 JSON 형식으로 변환하여 Redis에 저장합니다.

• entryTtl(Duration.ofMinutes(3L)): 캐시 항목의 TTL을 설정합니다. 캐시 항목은 3분이 지나면 만료되어 Redis에서 자동으로 삭제됩니다.

레디스 캐싱 서비스

    @Cacheable(value = "concertSchedules")
    public List<Schedule> redisCacheableSchedule(Long concertId) {
        List<Schedule> schedules = scheduleRepository.existsSchedule(concertId);
        Schedule.existSchedules(schedules);
        return schedules;
    }

@Cacheable 어노테이션을 사용하여 Redis 캐시에서 스케줄을 조회하거나, 캐시가 없으면 데이터베이스에서 조회하여 결과를 캐싱합니다.

레디스 캐싱 테스트

    @Test
    void 스케줄_조회_성공() {
    	// Given
        Long concertId = 1L;
        long startTime = System.nanoTime();

        // When
        List<Schedule> schedules = scheduleService.schedule(concertId);

        // Then
        long endTime = System.nanoTime();
        long duration = endTime - startTime;

        System.out.println("스케줄 조회 경과 시간 (나노초): " + duration);

        Assertions.assertThat(schedules).hasSize(2);
    }


    @Test
    void 레디스_캐싱_스케줄_조회_성공() {
    	// Given
        Long concertId = 1L;

        long startTime = System.nanoTime();

        // When
        List<Schedule> schedules = scheduleService.redisCacheableSchedule(concertId);

        // Then
        long endTime = System.nanoTime();
        long duration = endTime - startTime;

        System.out.println("레디스 캐싱 스케줄 조회 경과 시간 (나노초): " + duration);

        Assertions.assertThat(schedules).hasSize(2);
    }

데이터베이스에서 직접 스케줄을 조회하는 성능과 Redis 캐시에서 스케줄을 조회하는 성능을 분석하는 코드를 작성하여 Redis 캐싱이 성능에 미치는 영향을 평가하고, 캐시 활용으로 응답 시간이 얼마나 개선되는지 확인하려고 합니다.

레디스 데이터 조회

GET concertSchedules::1 명령어를 통해 다음과 같이 캐싱 데이터를 확인할 수 있었습니다.

성능 비교 분석

• 스케줄 조회 경과 시간 (나노초): 338860000
• 레디스 캐싱 스케줄 조회 경과 시간 (나노초): 259237400

테스트 결과, Redis 캐시를 활용한 조회는 데이터베이스에서 직접 조회하는 것보다 빠른 성능을 보였습니다. 구체적으로, 데이터베이스에서 직접 조회한 경과 시간은 약 338.86ms였고, Redis 캐시에서 조회한 경과 시간은 약 259.24m로 약 22.6% 빠른 성능을 보였습니다.

Redis 캐시가 데이터베이스의 부담을 줄여주고, 반복적으로 요청되는 데이터를 빠르게 반환할 수 있다는 것을 확인할 수 있었습니다. 캐시된 데이터는 메모리에서 바로 조회되기 때문에 데이터베이스 접근 시간을 단축시킬 수 있습니다.

결론

Redis 캐싱은 데이터베이스 조회 성능을 개선하는 기술로, 반복적인 데이터 요청에 대한 응답 속도를 향상시킬 수 있습니다. Redis를 활용한 캐시 조회가 데이터베이스 조회보다 빠르다는 점은 큰 장점이라고 생각합니다.