Redis chache policy - 캐시 전략 내부 및 아키텍처

목차

 

 

Redis Cache( key eviction )

 

Redis를 캐시로 사용하는 경우 새 데이터를 추가할 때 이전 데이터를 자동으로 제거하도록 하는 것이 편리한 경우가 많습니다. 이 동작은 널리 사용되는 memcached 시스템 의 기본 동작이므로 개발자 커뮤니티에서 잘 알려져 있습니다 .

 

Maxmemory구성 지시어

 

 redis.conf 에 100MB의 메모리 제한을 구성하려면 파일 내에서 다음 지시어를 사용할 수 있습니다

maxmemory 100mb

 

 

 

0으로 설정하면 maxmemory메모리 제한이 없습니다. 이는 64비트 시스템의 기본 동작이지만 32비트 시스템은 3GB의 암시적 메모리 제한을 사용합니다.

지정된 메모리 양에 도달하면 제거 정책 구성 방법에 따라 기본 동작이 결정됩니다. Redis는 더 많은 메모리를 사용할 수 있는 명령에 대해 오류를 반환하거나, 새 데이터가 추가될 때마다 일부 이전 데이터를 제거하여 지정된 제한으로 돌아갈 수 있습니다.

 

 

 

Eviction 정책

maxmemory 제한에 도달했을 때 Redis가 따르는 정확한 동작은 maxmemory-policy 구성 지시문을 사용하여 구성됩니다.

 

 

• noeviction : 메모리 제한에 도달하면 새 값이 저장되지 않습니다. 데이터베이스가 복제를 사용하는 경우 이는 기본 데이터베이스에 적용됩니다.
• allkeys-lru : 가장 최근에 사용한 키를 유지합니다. 가장 최근에 사용되지 않은(늦게) 사용된(LRU) 키를 제거합니다.
• allkeys-lfu : 자주 사용하는 키를 보관합니다. 가장 자주 사용되지 않는(LFU) 키를 제거합니다.
• volatile -lru : expire필드가 true로 설정된 가장 최근에 사용된 키를 제거합니다.
• volatile -lfu : expire필드가 true 로 설정된 상태 에서 가장 자주 사용되지 않는 키를 제거합니다.
• allkeys-random : 추가된 새 데이터를 위한 공간을 만들기 위해 키를 무작위로 제거합니다.
• volatile -random : expire필드가 true로 설정된 키를 무작위로 제거합니다.
• volatile -ttl : expire필드가 true로 설정되고 남은 TTL(Time-To-Live) 값이 가장 짧은 키를 제거합니다.

 

 volatile-lru, volatile-lfu, volatile-random, volatile-ttl 정책은 전제 조건과 일치하는 제거 키가 없는 경우 noeviction 처럼 동작합니다 .

 

 

상황에 따른 추천 정책

• 요청의 인기도에 대한 거듭제곱 분포가 예상되는 경우 allkeys-lru 정책을 사용하십시오 . 즉, 요소의 하위 집합이 나머지 요소보다 훨씬 더 자주 액세스될 것으로 예상합니다. 확신이 없다면 이것은 좋은 선택입니다 .
• 모든 키가 지속적으로 스캔되는 순환 액세스가 있거나 배포가 균일할 것으로 예상되는 경우 allkeys-random을 사용하십시오 .
• 캐시 객체를 생성할 때 다양한 TTL 값을 사용하여 만료에 적합한 후보에 대한 힌트를 Redis에 제공하려면 volatile-ttl을 사용하세요 .

volatile-lru 와 volatile-random  정책은 캐싱과 영구 키 세트 모두에 단일 인스턴스를 사용하려는 경우 주로 유용합니다. 그러나 이러한 문제를 해결하려면 일반적으로 두 개의 Redis 인스턴스를 실행하는 것이 더 좋습니다.

 

또한 expire 값을 키에 설정하면 메모리 비용이 발생하므로

allkeys-lru와 같은 정책을 사용하는 것이 메모리 부족으로 인해 키가 제거되도록 expire 구성을 설정할 필요가 없기 때문에 메모리 효율성이 더 높다는 것을 고려해야 합니다.

 

 

Eviction 절차

• 클라이언트가 새 명령을 실행하면 더 많은 데이터가 추가됩니다.
• Redis는 메모리 사용량을 확인하고 한도보다 큰 경우 maxmemory정책에 따라 키를 제거합니다.
• 새로운 명령이 실행됩니다

 

 

 

 

 

캐시 아키텍처

읽기 방식

• Look Aside : DB와 cache를 병렬로 구성,  속도가 빠름, 단건 호출에는 안좋음, 반복적인 호출에 좋음
• Read Through : cache 뒤에  DB를 구성, 속도가 느림, 데이터가 같음

 

쓰기 방식

• Write Back: 단일 구성, Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
• Write Through : 단일 구성, 데이터 유실이 발생하면 안 되는 상황에 적합
• Write Around: 병렬 구성, 속도가 굉장히 빠름, 데이터 불일치 발생할수 있다.

 

조합

LA + WA - 가장 많이 쓰임

RT + WA - 항상 DB에 데이터를 쓰므로 데이터 불일치가 없다.

RT + WT - 단일로, 구성 데이터 불일치가 없다.

 

 

Reference

 

https://redis.io/docs/reference/eviction/

Key eviction

 

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EC%BA%90%EC%8B%9CCache-%EC%84%A4%EA%B3%84-%EC%A0%84%EB%9E%B5-%EC%A7%80%EC%B9%A8-%EC%B4%9D%EC%A0%95%EB%A6%AC

[REDIS] 📚 캐시(Cache) 설계 전략 지침 💯 총정리

 

 

 

끝!