Redis Cache 적용과 만료 전략 수립

Redis Cache 성능 비교

문제상황

사용자에게 지명 정보, 경로를 제공하기 위해 Kakao, Naver, Tmap Open API를 사용한다. 위 API 제공에 있어 호출까지의 시간이 소요되고 비용 낭비가 발생

• 이미 반환된 정보를 사용자가 재사용하는 경우가 많기 때문에 경로를 임시 메모리에 저장하는 로직 필요
• 데이터 특성 상 한번 참조된 값에 대해 변경이 자주 일어나지 않음

접근

• Redis Cache를 이용하여 Open API의 반환값을 일부 저장하여 사용자에게 제공

적용

• @CachePut과 @Cacheable Annotation을 사용하여 API에 레디스 캐시 적용

캐시 적용시 동작 흐름

Cache Aside 패턴을 사용했다.

 

@CachePut과 @Cacheable을 사용하는 API 분리 (동일 로직 수행)

위와 같이 API를 분리해 구현한 이유

• 사용자가 새로운 데이터를 원하는 경우 클라이언트가 모바일이기 때문에, 화면 상단을 쓸어내리는 등의 동작으로 수동 새로고침 요청을 보낼 수 있다.
  • 수동 새로고침 요청의 경우 @CachePut이 적용된 같은 로직의 API를 호출한다.
  • OpenAPI를 호출해 정보를 가져오며 무조건 캐시가 갱신된다.
  • 이후 @Cacheable이 적용된 API를 호출하여도 데이터의 불일치 현상이 일어나지 않는다.
    • @CachePut 적용 API에 @CachePut이 없는 경우 수동으로 조회하여 정보가 바뀌더라도 캐시는 갱신되지 않아 데이터 불일치 현상이 일어난다.
• DB 정보를 캐싱할 때와는 다르게 데이터가 변경됨을 감지할 수 없기 때문에 @CachePut이 사용된 API에서만 갱신하도록 하였다.

 

시나리오

Redis Cache를 적용하였을 때 성능 분석을 위해 다음과 같은 시나리오를 세우고 테스트 진행

1. 회원가입 수행
2. 보행자 경로 API를 요청하여 수행

결론

평균 Latency 4.12배 향상

• 추가로, 매번 OpenAPI를 호출하지 않기 때문에 네트워크 비용을 아끼는 효과도 있음

동기 처리 [평균 Latency 91.88ms]

비동기 처리 [평균 Latency 22.26ms]

분석

1. Redis Cache를 사용할 경우 사용하지 않은 경우에 비해 4.12배의 속도 성능 향상
2. Open API를 중복 요청하지 않아 네트워크 비용 절감
3. @CachePut을 통해 사용자의 요청 경로가 변경된 경우 기존 Cache값을 변경된 경로로 갱신해 제공하여 서비스상 유연성 향상

개선할 점

• 자주 조회되는 데이터는 만료시키지 않고 스케줄링으로 업데이트하고자 한다.
  
  • 이 방법은 초기에 고려한 방법이지만, 배치 서버에 대한 이해도가 아직은 부족하다 판단하여 TTL을 통해 캐시를 만료시키고 있다.
  • TTL을 데이터의 갱신 주기로 하기에는 다음과 같은 애매한 부분이 있다.
    • OpenAPI 의 데이터가 언제 갱신되는지 알기 어렵다.
    • 지명 정보가 대부분이었기에, 정말 드물게 갱신된다.
  • 현재는 TTL을 1시간으로 개인적으로 다소 길다고 생각되도록 잡아두었다. 데이터가 갱신될 일은 거의 없을 것이고, 사용 중이던 Elasticache 인스턴스의 메모리에 비해 수치적으로 계산했을때 많은 메모리를 차지하지 않을 것이라 판단했다. (비교적 덜 사용되는 API 이다.) 이후 꼭 스케줄링을 통한 갱신 방식으로 수정하고 싶은 부분이다.