(리스트)단일 캐시들을 저장하는 Redis 캐시 서버 개선 시도들 (1)

문제 상황

• 캐시 서버를 구현하는 프로젝트를 진행하는 중의 문제가 발생
  • 캐시의 Key 값으로 요청의 Path + QueryString 형태를 사용
  • 캐시의 Metadata 값(Expired Time)은 Path를 기준으로 관리
  • Path에 대한 Expired Time이 변경될 때 기존의 활성화 되어있는 Key들을 찾아서 삭제 혹은 갱신을 해야하거나 Path별 활성화된 캐시들 목록을 조회 해야하는 등의 상황
• Redis에서 특정 목록들을 검색할 때 Scans를 이용해서 검색하는데 특정 패턴의 Key들을 조회하는 방식이다보니 기본적으로 전체 조회를 하게된다.
  • 만료시간 수정 한 번을 위해 무수한 캐시들을 전체 조회하는 것은 성능적으로 매우 낭비인 상황

 

해결 시도 1번

• 리스트 등의 자료구조를 활용하기
  • 캐시 생성 / 만료 / 삭제 시 Path 별 리스트를 생성하여 리스트 내부에 Key 값들을 추가 / 삭제하는 방식
  • 캐시 조회, 삭제 등 목록을 관리할 때 해당 리스트를 조회해서 활용한다.

Ex라는 이름의 캐시를 관리할 때 리스트를 활용한다..

부족한 점 & 단점

• 같은 Path의 캐시들이라고 하더라도 생성 시간은 제각각이기 때문에 생성시간에 따른 만료시간도 제각각이다.
  • 그러나 리스트로 관리되고 있기 때문에 리스트 캐시 하나에 만료시간이 공통으로 관리되고 있다.
    (심지어 리스트 캐시는 삭제가 되면 안된다.)
  • 결국 단일 캐시 조회 시 일일이 생성시간과 만료시간을 계산해서 유효한 데이터인지 검증해야한다.
    • 수정 시 성능 향상을 위해 조회 시 성능을 낮춰야하는 상황이라 유효한 방법이 되지 못한다.
  • 조회 성능을 맞추기 위해 만료시간을 가진 실제 캐시도 따로 운용해야한다.
    • 목록을  조회해야할 때는 리스트를 활용하고 조회 시에는 단일 실제 캐시를 활용한다. 
    • 그 과정에서 Redis KeyEvents 등을 활용해 두 캐시의 정합성을 맞추어야한다.

단순히 캐시 목록을 가진 리스트와 Response를 가진 실제 캐시

• 이렇게 맞추더라도 캐시가 무수히 많다면 전체 조회에 비해 괜찮은 성능인 것이지 여전히 O(n)의 성능을 가지기 때문에 효율이 그렇게 좋지 않다.

 

다음 해결 시도에 대해서는 단일 캐시들을 저장하는 Redis 캐시 서버 개선 시도들 (2)에서 설명한다.

(Versioning)단일 캐시들을 저장하는 Redis 캐시 서버 개선 시도들 (2)