[Redis] Spring boot 에서 Redis로 성능 개선하기

Cache란?

나중에 할 요청 결과를 미리 저장 해 두었다가 빠르게 서비스 해 주는 것

• Look aside Cache(일반적으로 많이 쓰는 방식)
  • DB를 가기 전에 Cache에 먼저 데이터가 있는지 확인 해본다.
  • 만약 Cache에 데이터가 있다면 캐시 데이터를 읽고, 없다면 DB를 읽은 후 Cache에 저장 & 결과 리턴
• Write Back(로그를 DB에 저장하는 경우, 쓰기 연산이 많은 경우)
  • 캐시에 먼저 저장했다가, 특정 시점마다 DB에 저장하는 방식
  • ex. 걸리는 시간(배치 작업) - DB insert 쿼리를 1번씩 * 500번 >> insert쿼리 500개 합친 것 * 1번
  • 단점: 장애가 생기면 데이터가 사라질 위험이 있다. 왜냐면 리부팅 되면 메모리는 사라지기 때문

 

캐시가 되는 대상들

- 단순한 구조의 정보 

- 반복적으로 계속 사용하는 정보 

- 정보의 변경주기가 빈번하지 않고, 단위처리 시간이 오래걸리는 정보 

- 정보의 최신화가 실시간으로 이뤄지지않아도 서비스에 영향이 적은 정보

 

 

캐싱 전략 (Caching Strategies)

보통 레디스를 cache로 사용할 때 레디스를 어떻게 배치하냐에 따라 시스템 전체 성능에 큰 영향을 끼친다. 그래서 레디스를 어디에 어떻게 배치할 지에 대한 전략을 세워야 하는데 이를, 캐싱 전략(Caching Strategies)이라고 한다.

캐싱 전략은 데이터의 유형과 해당 데이터에 대한 액세스 패턴을 잘 고려해서 선택해야 한다. 크게 읽기 전략과 쓰기 전략으로 두 가지로 나뉜다.

 

먼저 읽기 전략부터 알아보자.

 

읽기 전략 (Read Strategies)

 

Look-aside (Lazy Loading) 전략 : 데이터를 읽는 작업이 많을 때 사용하는 전략이며, 레디스를 캐시로 쓸때 가장 많이 사용된다.

 

먼저 애플리케이션이 데이터를 읽을때, 캐시를 확인하여 캐시에 데이터가 존재하면 캐시에서 데이터를 읽어온다. 만약 레디스에 찾는 데이터가 없다면 DB에 접근해서 데이터를 직접 가져와 레디스에 저장한다.

따라서, 캐시에는 찾는 데이터가 없을 때만 데이터가 캐싱되기 때문에 이를 지연로딩(Lazy Loading)이라고도 부른다. 이 구조는 레디스 장애 발생 시 시스템이 다운되지 않고, DB에서 데이터를 가지고 올 수 있다.

대신 캐시로 붙어있던 커넥션이 많이 있었다면 그 커넥션이 모두 데이터베이스로 붙기 때문에 DB에 많은 트래픽이 한꺼번에 몰릴 수 있다. 

 

Look-aside 의 문제점은 CUD'연산을 하는 경우, DB와 Cache data 사이의 정합성 문제가 발생할 수 있다는 것이다. DB에는 변경되었지만 Cache Data에서 변경되지 않는 경우를 말한다. 

이 문제는 캐시워밍(Cache Warming)으로 해결 가능하다.

 

캐시워밍(Cache Warming) 이란?

미리 cache로 db의 데이터를 밀어 넣어두는 작업을 의미한다. 이 작업을 수행하지 않으면 서비스 초기에 트래픽 급증시 대량의 cache miss 가 발생하여 데이터베이스 부하가 급증 할 수 있다. 

 

 

쓰기 전략 (Write Strategies)

 

쓰기 전략에는 2가지 종류가 있다.

 

Write-around : DB에 데이터를 저장하고 Cache miss가 발생할 경우 DB에서 데이터를 캐싱한다. 이 경우엔 cache 내의 데이터와 DB 내의 데이터가 다를 수 있다. 

왜냐하면, 캐싱된 데이터가 있을 경우 데이터를 수정할때 캐싱된 데이터를 수정하지 않고, 캐시에 데이터는 있기 때문에 새로 캐싱을 하지 않는다. 

 

Write-through : DB에 데이터를 저장할 때 cache에도 함께 저장하는 방법이다. cache는 항상 최신 정보를 가지고 있다는 장점이 있지만 저장할 때마다 두 단계(DB에 저장, 캐시에 저장) 거쳐야 하기 때문에 상대적으로 느리다. 

그리고 재사용되지 않는 데이터도 무조건 캐시에 넣어버리기 때문에 일종의 리소스 낭비를 초래 할 수 있다. 이 경우 데이터를 저장할 때는 Expire time을 설정해주는 것이 좋다.

 

 

Redis를 선택한 이유

1. 사용이 간편하다.

• 단순한 key-value 구조 다양한 자료구조 지원

2. 빠른 성능을 보여줌. 

• 평균 작업속도 < 1 ms
• 초당 수백만 건의 작업 가능 ⇒ 지연시간 감소, 처리량 증가

3. 레퍼런스 자료가 많음.

• Spring Cache, Caffeine 등 다른 캐싱 구현 방법이 있지만 Redis 관련 자료가 압도적으로 많음

4. 원격 캐시

• 여러 노드나 애플리케이션 간에 데이터를 공유할 수 있어 일관된 정보를 제공하고 확장성이 좋음

 

Redis 캐시 활성화를 위한 어노테이션

• @EnableCaching
  • SpringBoot에게 캐싱기능이 필요하다고 전달
  • SpringBoot Starter class에 적용
• @Cacheable
  • DB에서 애플리케이션으로 데이터를 가져오고 Cache에 저장하는데 사용
  • DB에서 데이터를 가져오는 메서드에 적용
• @CachePut
  • DB의 데이터 업데이트가 있을 때 Redis Cache에 데이터를 업데이트
  • DB에서 PUT/PATCH와 같은 업데이트에서 사용
• @CacheEvict
  • DB의 데이터 삭제가 있을 때 Redis Cache에 데이터를 삭제
  • DB에서 DELETE와 같은 삭제에서 사용

 

이제 프로젝트에 적용해보자. 

본 예시는 Redis가 설치된 환경을 가정하여 진행합니다.

 

다른 로직의 캐싱처리도 진행할거지만 가장 먼저 하고싶었던 부분이 있다. 

바로 이 부분이다. 

 

token을 헤더에 포함하여 요청이 오는 경우 항상 jwt filter를 타게되는데 이때 member 조회 쿼리를 날려 PrincipalDetails를 만들어 SecurityContextHolder에 넣어준다. 

 

프로젝트 특성상 90% 이상의 api가 헤더에 token을 필요로 하기 때문에 사용자가 많이질 시 성능 개선이 꽤나 이뤄질 것으로 짐작된다. 

 

 

 

사용법은 정말 간단하다.

 

먼저 RedisConfig 파일에 cacheManager를 등록해주자. 

// 캐싱 처리를 위한 빈 등록
@Bean
public CacheManager authCacheManager(RedisConnectionFactory cf) {
    RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
            .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
            .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer())) // Value Serializer 변경
            .entryTtl(Duration.ofMinutes(30L)); // 캐시 수명 30분

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

 

entryTtl 부분에 캐시를 얼마동안 갖고 있을 것인지 설정해주면 된다. 우선은 30분으로 잡아두고 진행했다. 

또 @EnableCaching을 등록해줘야 Cache를 사용할 수 있다. 나는 RedisConfig에 등록해주었다.

 

 

loadUserByUsername 메소드 위에 @Cacheable 어노테이션을 적용해준다.

cacheManager는 RedisConfig에서 등록했던 빈 이름이다. 

cacheNames를 loginMember로 잡았고 key를 phone으로 잡았기 때문에 phone의 값이 01012345678 이었다면 redis엔 loginMember::01012345678 로 key값이 저장된다. 

나중에 redis-cli 에서 확인해볼 것이다.

@Override
@Cacheable(cacheNames = "loginMember", key = "#phone", condition = "#phone != null", cacheManager = "authCacheManager")
public PrincipalDetails loadUserByUsername(String phone) throws UsernameNotFoundException {
    log.info("loadUserByUsername 실행");
    Member findMember = memberRepository.findByPhone(phone)
            .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
    MemberDto memberDto = MemberDto.builder()
            .id(findMember.getId())
            .role(findMember.getRole())
            .build();
    return new PrincipalDetails(memberDto);
}

 

 

Redis 캐시를 적용하고 처음 token 조회가 포함되는 api 요청을 해보면 아래와 같이 member 조회 로직이 나간다. 즉, redis에 캐싱 데이터가 존재하지 않아 cache miss가 일어난 것이다. 동시에 redis에 등록해준다. 

 

 

조금 전에 로그인한 유저로 인증이 필요로하는 api 요청을 해보면? 별도의 쿼리 없이 인증을 완료하는 모습을 볼 수 있다. 

 

 

redis엔 어떻게 저장되어 있을까?

{cacheNames::key} 값 형태로 잘 저장되어 있다. 

 

get 으로 조회해보면 다음과 같이 잘 저장되어 있는것을 확인할 수 있다.

 

 

 

 

 

 

여기서 궁금한 점이 생겼다.

아래 코드 처럼 많은 비즈니스 로직에서 현재 로그인한 memberId를 받아와 member를 조회하고있다. 

 

이 부분도 member 조회 로직도 Redis로 캐싱처리 하면 안 되나.. 생각이 들었다.

하지만 Redis로 member를 조회 시 영속성 컨텍스트안에 들어가지 않는 문제가 있다. 

또 아래 사진 처럼 엔티티를 외부 캐시에 저장하면 절대!! 안된다고 한다..!

 

 

 

 

 

번외

번외로 다른 개발자 분들과 얘기하다 의문인 점이 생겼다.

JWT를 사용하여 인증,인가를 처리할 경우 jwt filter에서 loadUserByUsername 같은 회원 쿼리를  날려 확인해야 하는가?? 필요 없는가?? 에 대해 고민하게 되었다. 

 

나는 로그인이 되어 토큰을 이미 발급한 상황이더라도 이미 회원이 탈퇴했을 수 있기 때문에 실제 DB에 있는 회원에 대한 토큰인지 검증하는 로직은 필요하다 생각하는데.. 

 

조금 더 알아봐야겠다. 

 

 

참고: https://www.youtube.com/watch?v=92NizoBL4uA