Data Science Lab

 Redis Memory LFU(Least Frequently Used) 캐시

·       Version : Redis 4.0

Redis 4.0 부터 제공되는 LFU 알고리즘 캐시는 자주 참조되는 데이터만 배치하고 그렇지 않은 데이터들은 메모리로부터 제거하여 자주 사용되는 데이터들이 메모리에 배치되도록하는  알고리즘이다. LRU 알고리즘은 최근에 액세스 했지만 실제로는 거의 요청하지 않는 항목에 대해서도 메모리에 보관하고 자주 요청되는 키에 대해서는 만료가 되기 때문에 의도하지 않은 성능이 나타날 수도 있다.

LFU는 Approximated LRU와 유사하다. 모리스 카운터라고 하는 확률적 카운터를 사용하여 개체의 액세스 빈도를 계산하고 감쇠 기간과 결합하여 시간이 지남에 따라 카운터가 감소한다. 알고리즘은 액세스 패턴의 변화를 확인하고 과거에 액세스가 있었지만 자주 액세스되지 않는 키는 삭제 후보로 선정한다. 이러한 방법은 LRU에서 발생하는것과 유사하게 샘플링된다. 그러나 LRU와 달리 LFU에는 특정 조정가능한 매개변수가 있다. 예를들어 더 이상 객체에 액세스하지 않게 되면 랭크를 얼마나 빨리 감소 시킬것인지 설정할 수 있다. Redis 4.0은 기본적으로 아래와 같이 구성된다.

·       100만건의 요청에 카운터를 포화시킨다.

·       카운터를 1분마다 감쇠한다.

카운터 범위 조정은 Redis.conf 파일에 아래와 같이 관련 파라메터를 수정한다.

·       lfu-log-factor 10 (기본값 10)

·       lfu-decay-time 1

lfu-decay-time의 변수값은 분(minute)로 사용되며 0으로 설정할 경우 항상 카운터를 스캔할 때마다 카운터를 감소시킨다.

lfu-log-factor의 범위는 0-255이며,  factor가 높을수록 최대 값에 도달하기 위해 더 많은 액세스가 필요하다. Hits 값은 사용자가 메모리로부터 데이터를 재참조한 값으로 높을 수록 좋다. 아래 표에서는 팩터가 10일때 1M 이상의 힛트가 발생하는 경우 가장 이상적인 것을 확인할 수 있다..

[참고자료]

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

·       Approximate counting algorithm : https://en.wikipedia.org/wiki/Approximate_counting_algorithm

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

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

 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, 레디스 메모리 공간 확보, 레디스 메모리 제거

 Redis Memory 정보

·       Version : Redis 3.2.100 (Windows)

Redis에서 info명령은 서버의 각종 통계 및 상태를 보여준다. 다양한 매개 변수를 사용하여 특정 정보를 확인할 수 있으며 이번 포스트에서는 메모리 관련 정보를 확인해본다.

Redis에 접속하여 Redis info 명령을 실행하면 메모리 관련 사용 정보를 반환한다.

·       *_human 값은 동일 항목의 byte 값을 Kbyte로 변환하여 나타낸 값

이상적으로 used_memory_rss 값은 used_memory 보다 약간 높아야 한다. rss >>를 사용하면 mem_fragmemtation_ratio 를 검사하여 메모리 조각화(내부 또는 외부)가 있는지 확인할 수 있다.  >> rss를 사용하면 Redis 메모리의 일부가 운영체제에 스왑 아웃을 되었다는 것을 의미한다. 이 뜻은 지연이 있다는 것을 의미한다.

Redis는 메모리 페이지에 매핑되는 할당 방식을 제어할 수 없으므로 높은 used_memory_rss는 메모리 사용이 급증하여다는 것을 의미한다. Redis가 메모리를 해제하면 메모리는시스템에 메모리를 반환하거나 하지 않을 수 있다. 따라서 운영체제에서 보고한 used_ memory값과 메모리 소비간에 불일치가 있을 수 있다. used_memory_peak  값은 일반적으로 이 지점을 확인하는데 유용하다.

서버의 메모리에 대한 추가 정보는 memory stats 명령과 memory doctor를 참조하여 확인할 수 있다.

[참고자료]

https://redis.io/commands/INFO

2019-05-20 / Sungwook Kang / http://sungwookkang.com

Redis, Redis Architecture, 레디스 메모리, 레디스 메모리 사용량, 메모리 모니터링, Redis, info memory

 Redis Architecture

·       Version : Redis 3.2.100 (Windows)

아래 그림은 Redis Server Architecture 이며, 크게 3가지 영역인, 메모리, 파일, 프로세스 영역으로 구성되어 있다.

[메모리 영역]

·       Resident Area (Working Set) : 사용자가 Redis 서버에 접속해서 처리하는 모든 데이터가 가정 먼저 저장되는 영역이며 실제 작업이 수행되는 영역.

·       Data Structure : Redis를 운영하기 위한 다양한 정보를 저장하고 관리하기 위한 영역.

[파일 영역]

·       AOF 파일 : 메모리에 저장된 사용자 데이터를 파일에 기록하는 영역 (스냅샷 데이터)

·       DUMP 파일 : 소량의 데이터를 일시적으로 저장할때 사용하는 영역

[프로세스 영역]

·       Server Process : redis-server.exe 또는 redis-sentinel.exe  실행 코드에 의해 활성화되는 프로세스이며, Redis 인스턴스 관리 및 사용자 요청 작업을 처리한다. 4개의 멀티 스레드로 구성된다.

ü  Main Thread : Redis 서버에서 수행되는 대부분의 명령어와 이벤트 처리

ü  BIO-Close-FILE  : AOF(Append Only File)에 데이터를 Rewrite 할때 기존 파일은 Close 하고 새로운 AOF 파일에  Write할 때 사용.

ü  BIO-AOF-Resync : AOF에 쓰기 작업을 수행할 때 사용

ü  BIO-LAZY-Free : unlink, FLUSHALL, FLUSHDB 명령어를 실행할 때 빠른 성능을 보장하기 위해 백그라운드에서 사용

·       Client Process : redis-cli.exe 또는 사용자 애플리케이션에 의해 실행되는 명령어를 실행하기 위해 제공되는 프로세스.

[참고자료]

https://docs.redislabs.com/latest/rs/concepts/

2019-05-14 / Sungwook Kang / http://sungwookkang.com

Redis, Redis Architecture, 레디스 아키텍처, 레디스 스레드, 레디스 프로세스, 레디스 메모리 아키텍처