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

이전 페이지 :  단일 캐시들을 저장하는 Redis 캐시 서버 개선 시도들 (1)

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

문제 상황

• • 만료 시간 수정 시 기존 활성화 캐시 처리에 대한 문제가 있었다.
    • 조회 속도를 너무 해치지 않는 선에서 성능을 개선해야한다.
  • 리스트를 사용하여 목록화 시도
    • 캐시들이 한 리스트 캐시에 만료 시간이 묶여서 각기 만료 시간이 관리되지 않기에 실제 캐시들을 따로 운용해야한다.
    • 전체 조회에 비해 성능은 향상되나 여전히 무수히 많은 조회가 일어난다.

 

해결 시도 2번

• 만료 시간 (Expired Time) 수정 시 활성화 되어있는 캐시들의 목록을 무시할 수는 없을까?
  • 만료 시간 수정 이전에 생성된 캐시들을 없는 것으로 취급하고 새로 생성하는 방식
  • 이를 위해 저장하는 Metadata 값에 Version을 추가하여 활용한다.
    • 캐시의 Key 구조를 Path + QueryString + Version 형태로 변경
    • 키 조회 시 현재 Metadata Version 값을 조회하여 해당 Version에 맞는 캐시 Key가 있는지 확인
    • 있다면 반환하고 없다면 메인 서버에 데이터를 요청하여 해당 Version에 맞는 Key를 생성한다.
  • 만료시간 수정 시 Metadata의 Version 값을 +1 해주는 방식으로 관리
  • 사용되지 않는 너무 많은 데이터가 Redis에 쌓이는 것을 방지하기 위해 Redis MaxMemory를 설정하여 지정한 용량을 넘길 경우 LRU 알고리즘을 활용해서 가장 오래 사용하지 않은 캐시들부터 삭제한다.

    

    Version을 활용한 캐시 조회 요약

  • 추가로 Mysql에 저장되는 Metadata 값도 Redis에 캐시로 저장하여 캐시 조회 시 Version 조회에 대한 속도를 향상한다.

 

부족한 점 & 단점

• Redis 내부에 사용되지 않는 쓰레기 데이터들이 일정량 쌓여있다는 점
  • 짧은 순간에 같은 Metadata에 대한 수정이 무수히 많이 일어난다면 쓰레기 정보가 Redis에 무수히 쌓인다
  • 드물지만 위와 같은 상황에서 쓰레기 값에 밀려서 현재 사용할 수 있는 값이 밀릴 수 있는 가능성이 존재
• 어찌되었던간에 조회 시 Metadata의 Version 값을 조회하는 시간이 추가된다.
  • 속도를 최대한 높인다고 하더라도 version 조회를 위한 시간이 추가로 소모된다.
  • 추가 시간을 줄이기 위해 Mysql의 Metatdata 정보를 Redis에 캐시화 시킨다고 해도 추가 시간이 발생할 수 밖에 없으며 이때는 Redis에 Metadata를 위한 Database를 추가로 설정해주어야한다.
    • Database를 추가 설정해주지 않고 같은 공간을 사용할 경우 비교적 덜 사용되는데 삭제되면 안되는 Metadata 정보가 LRU 알고리즘에 의해 밀려서 삭제될 가능성이 존재한다.