NoSql, MemoryDB

Redis Memory LRU(Least Recently Used) 캐시

SungWookKang 2019. 6. 4. 08:47
반응형

 Redis Memory LRU(Least Recently Used) 캐시

 

·       Version : Redis 3.2.100 (Windows)

 

Redis에서 캐시로 사용되는 알고리즘으로 LRU(Least Recently Used) 사용한다.  LRU 알고리즘은 최근에 사용된 데이터들은 재사용이 가능성이 높다고 판단하여 계속해서 메모리에 상주 시킬수 있도록 재배치 하는 작업이다.  LRU 알고리즘으로 Redis 서버 인스턴스를 운영하기 위해서는CONFIG SET 명령어 또는  redis.conf 파일에서 아래 파라메터를 수정한다.

·       maxmemory <bytes>

·       maxmemory-samples 5

maxmemory 파라메터는 Redis 서버에 할당할 있는 최대 메모리 크기이며, 값을 0 설정할 경우 최대 메모리 한계가 없어진다. 32 bit 시스템에서는 암시적으로 메모리 제한이 3GB 사용한다.

maxmemory-samples 파라메터는 LRU 알고리즘에서 퇴거(eviction) 검사할 샘플 이다.

 

Redis 메모리의 상주 데이터를 삭제하는 종류는 가지가 있으며 memory-policy  구문을 사용하여 아래와 같은 정책을 적용할 있다.

·       noeviction : 메모리 제한에 도달한 상태에서 클라이언트가 많은 메모리를 사용하는  명령을 실행하려고 오류를 리턴한다. (대부분 쓰기 명령 DEL 명령시 발생한다.)

·       allkeys-lru : 가장 최근에 사용하지 않는 (LRU) 먼저 퇴거(eviction)하여 새로운 데이터를 위한 공간을 확보한다.

·       volatile-lru :  가장 최근에 사용되지 않은 (LRU) 먼저 퇴거(evict)하려고 시도하지만 만료 세트가 있는 키만 퇴거하여 새로운 데이터 공간을 확보한다.

·       allkeys-random : 세이터를 추가할 공간을 만들기 위해 임의로 키를 퇴거(evict)한다.

·       volatile-random :   데이터를 추가하기위한 공간을 만들기 위해 무작위로 키를 퇴거(evict)하지만 만료 세트가 있는 키만 제거한다.

·       volatile-ttl : 만료 세트가 있는 키를 제거하고 TTL(Short Time to Live)키를 제거하여 새로운 데이터를 추가 공간을 확보한다.

 

volatile-lru, volatile-random volatile-ttl 정책은 필수 구성요소와 일치하는 키가 없으면 아무런 행동을 하지 않는다. 올바른 퇴거 정책을 수립하기 위해서는 Redis INFO 정보를 모니터링하여 정책에 반영할 있도록 한다.

·       요청이 많으며 과거 데이터를 자주 사용하지 않는다면 allkeys-lru  정책을 사용한다.

·       모든 키가 연속적으로 스캔되는 순환 액세스가 있거나 배포가 균일할 것으로 예상되는 경우 (모든 요소는 동일한 확률로 액세스 가능성이 높음) allkeys-random 사용한다.

·       캐시 개체를 만들 다른 TTL 값을 사용하여 만료 기간이 좋은 항목에 대한 힌트를 Redis 제공하려면 volatile-ttl 사용한다.

 

volatile-lru volatile-random 정책은 캐싱 영구 집합에 대한 단일 인스턴스를 사용하려는 경우 유용하다. 그러나 일반적으로 이러한 문제를 해결하기 위해 개의 Reids 인스턴스를 실행하는 것이 좋다. 또한 키에 만료를 설정하면 메모리가 낭비되므로 allkeys-lru 같은 정책을 사용하면 메모리가 부족할 키가 만료되도록 설정할 필요가 없기 때문에 많은 메모리가 효율적으로 운영된다.

 

Redis LRU 알고리즘은 정확한 구현이 아니다. 이뜻은 Redis 퇴출을 위한 최선의 후보, 과거에 가장 많이 액세스 액세스를 선택할 없음을 의미한다. 대신 LRU 알고리즘의 근사치를 실행하거나 소수의 키를 샘플링 하고 샘플링된 중에서 가장 오래된 액세스 시간(가장 오래된 액세스 시간) 제거하려고 시도한다. 그러나 Redis 3.0 이후 알고리즘은 개선 퇴거 후보자를 확보하기 위해 개선되었다. 이로 인해 알고리즘의 성능이 향상되어 실제 LRU 알고리즘의 동작을 보다 자세히 근사할 있게 되었다.

Redis 진정한 LRU 구현을 사용하지 않는 이유는 많은 메모리가 필요하기 때문이다. 그러나 근사값은 Redis 사용하는 응용프로그램과 거의 같다. 다음은 Redis에서 사용한 LRU 근사값과 실제 LRU 비교하는 방법을 그래픽으로 비교한 것이다.

그림에서 연한 회색은 퇴거된 영역이며, 회색은 퇴거되지 않은 대상이다. 녹색은 추가된 객체이다. 시뮬레이션에서 지수법 접근 패턴을 사용하여 실제  LRU Redis 근사값 간의 차이가 미미하거나 존재하지 않는다는 것을 발견했다. 그러나 실제 LRU 근사하게 비교하고 캐시 미스 비율에 차이가 있는지 확인하기 위해 가지 추가 CPU 사용량을 희생시켜 샘플 크기를 10으로 늘릴 있다.

 

 

[참고자료]

https://redis.io/topics/lru-cache

 

2019-06-03 / Sungwook Kang / http://sungwookkang.com

 

Redis, Redis Architecture, 레디스 메모리, Redis LRU, LRU 알고리즘, Least Recently Used, 레디스 메모리 공간 확보, 레디스 메모리 제거

반응형

'NoSql, MemoryDB' 카테고리의 다른 글

CAP 이론  (0) 2020.06.08
Redis Memory LFU(Least Frequently Used) 캐시  (0) 2019.06.07
Redis Memory 정보  (0) 2019.05.21
Redis Architecture  (0) 2019.05.18
Redis 데이터 타입 – Geo  (0) 2019.05.15