본 문서는 Redis 도입에 대한 고찰을 기록한 글입니다.

Redis 도입을 고려한 이유

본 서비스에서 "책 상세 조회" 기능이 존재합니다.

이 때, 서비스에서 기술적으로 게시 글을 보여주는 것으로 풀어내었습니다.

서비스 특성 상, 책에 대한 정보를 조회하는 내용은 아주 많이 일어난다고 판단하였습니다.

그리하여 매번 DB에 접근하는 것을 방지하고자 Redis 도입을 고민하기 시작하였습니다.

기대 효과

1. 게시 글 Data 캐싱을 통한 응답 속도 완화

2. DB 병목현상 완화

코드 살펴보기

본격적으로 캐싱을 적용하기 전에 많은 옵션 값을 살펴보았습니다.
옵션 값의 후보로는 다음과 같습니다.

1. @Cacheable : 캐시 생성 및 전달
2. @CachePut : 캐시 내용 수정
3. @CacheEvict : 캐시 삭제

각각의 어노테이션은 역할이 다릅니다.

현 로직에서 가장 필요한 것은 "캐시 생성"입니다.

그리하여 아래의 코드와 같이 구성하였습니다.

@Cacheable(value = ["board"], key="#isbn")
        fun getBoard(isbn: String): ResponseOfGetBoard {
            var result = getBoardDto(isbn)
            return result
        }

위와 같이 "@Cacheable" 을 통하여 캐싱 작업을 이루었습니다.

테스트

최초의 조회

캐시 Hit가 일어나지 않는 첫번째 조회에서는 다음과 같이 Select 문이 생성된 것을 볼 수 있습니다.

두번째 조회

캐시 Hit가 발생하여 두번째 조회에서는 다음과 같이 아무런 명령어가 생성되지 않을 것을 볼 수 있습니다.

그리고 다음과 같이 Redis에 캐시가 적용된 것을 볼 수 있습니다.

성능 조회

최초의 조회

최초의 조회에서는 다음과 같이 "195ms"가 걸린 것을 볼 수 있습니다.

두번째 조회

두번째 조회에서는 캐시 Hit가 발생하여 "11ms"가 걸린 것을 볼 수 있습니다.

DB에는 1건의 Board가 저장, Redis에는 1건의 Board가 저장되어 있기 때문에 대용량 데이터 및 대용량 트래픽 상황에서는 상이한 결과가 생길 수 있습니다. 하지만 대용량 데이터 및 대용량 트래픽이 될 수록 더욱 극적인 성능 최적화가 발생하게 됩니다.

Redis를 조회하여 195ms -> 11ms로 극적인 최적화를 이룰 수 있었습니다.