Redis는 메모리에 데이터를 저장하기 때문에, 디스크에 데이터를 저장하는 Database보다 빠른 조회 성능을 가지게 된다.
다양한 활용 방법이 존재하지만, 주로 조회 빈도가 높은 데이터를 캐싱하거나, 만료 시간을 지닌 데이터를 저장하는 데 쓰인다.
본 포스팅을 통해 Redis 설치부터 간단한 Spring Boot 프로그램에 적용하는 실습을 진행해보자. 완성된 코드는 Github에 업로드 해두었다.
일반적으로 인증코드 저장, Refresh Token 관리 등에 Redis를 활용하나, 본 포스팅에서는 임의의 DTO를 저장한다.
Redis는 "서버"이므로, Gradle 의존성 추가 외에 추가적인 설치가 필요하다.
필자와 같이 mac 유저라면, homebrew 설치부터 진행해야 한다.
homebrew를 설치했다면, 터미널에서 아래 명령어를 통해 redis를 설치한다.
설치가 완료되면, 아래 명령어를 통해 서버를 시작하자.
설치가 잘 되었다면 다음 화면을 볼 수 있을 것이다.
이제 서버를 백그라운드로 실행한 후, client 모드로 서버에 접근하자.
기본 포트인 6379가 확인된다면 성공이다.
이제 Spring으로 넘어가자! Redis Client 모드는 이후에 사용할 것이므로 그대로 두자.
우선, gradle 의존성을 추가한다.
필자는 Redis Caching Server와 MySQL Server를 설정했다.
앞서 언급한 Redis의 기본 포트인 6379를 적용했음을 알 수 있다.
이제 Spring Application을 Redis Server에 연결하자.
참고로 Lettuce는 Redis의 Client Library이다.
Redis랑 발음이 비슷해서 Lettuce로 지었다고 한다. ㅋㅋㅋㅋㅋㅋㅋ
이로써, Redis 적용을 위한 준비 과정을 마쳤다!
아직 Server에 저장할 데이터가 없으므로, 아주 간단하게 구현해보자.
name
만 입력받는 회원가입 요청 DTO를 생성했다.
toEntity
는 DTO를 Entity로 변환하는 converter 역할을 수행한다.
이 부분이 핵심이니 유의하자.
Redis Server에는 Entity가 아닌 Client에게 전송할 DTO를 저장한다.
@RedisHash
를 통해 Caching할 DTO를 지정한다.value
: Key의 접두사이다. redisKey가 100이라면, Redis Server에는 member:100
으로 저장된다.timeToLive
: Redis Server 내에서의 만료 시간을 지정한다. 아래는 20초로 지정한 모습이다.@Id
: Redis Server에서 해당 DTO를 해싱할 Key를 지정한다.
❗️
import org.springframework.data.annotation.Id;
를 해야한다. Entity의@Id
와 다르다!
또한, 필자는 Entity의 임의로 id
값을 redisKey로 부여했다.
위 DTO들을 바탕으로, 회원가입 후 조회하는 프로그램을 작성해보자.
Redis 구현 방법은 두 가지로 나뉜다.
1. RedisTemplate
이용
2. Repository
이용
2번의 경우, 흔히 사용하는 JpaRepository 구현 방법과 매우 유사해 해당 방식을 택하였다.
그러면 이제 Redis Server에 접근할 RedisRepository를 만들자.
save()
: 회원가입 요청을 처리해 Redis Server와 MySQL Server에 모두 저장하는 Logic을 구현한다.findMember()
: Redis Server에 Cache 되어있는지 확인하고, 없다면 MySQL Server에서 가져오는 Logic을 구현한다.간단한 코드이므로 설명은 생략한다.
조회 API에서 성능 비교를 위해 시간을 측정한 모습이다.
기존에 연결해둔 Swagger를 통해 Post 요청을 진행 후, 곧바로(timeToLive 만료 전!) Get 요청을 해보았다.
keys *
명령어를 통해 모든 redis key를 조회한 결과, id
가 1인 DTO가 접두사와 함께 잘 저장되어있음을 알 수 있다.
참고로 member만 있는 것은 namespace다.
만료되기 전이므로 Redis Server에서 Dto를 가져왔고, 이때 소요시간은 7ms이다.
동일하게 모든 key를 조회한 결과, 만료 시간을 초과하여 namespace만 존재하는 것이 확인된다.
Caching Data가 존재하지 않아 DB에서 select query를 통해 조회하는 모습이다.
이때 소요시간은 58ms이다.
조회 성능이 8배 이상 차이남을 확인할 수 있다.
https://github.com/Around-Hub-Studio/AroundHub_SpringBoot
너무 좋은 포스팅입니다 !!