레디스 캐싱 전략, 캐시 만료, maxmemory-policy

🔸캐시로서의 레디스

캐시로서의 레디스는 다음과 같은 이점을 지니고 있다.

• 간편한 사용:
  키-값 형태로 데이터를 저장하고 반환하는 방식이 간단하며, 다양한 자료 구조(list, hash 등)를 변환 과정 없이 바로 저장할 수 있다.
• 빠른 속도:
  모든 데이터를 메모리에 저장하기 때문에 데이터 검색과 반환 속도가 매우 빠르다.
  평균 읽기 및 쓰기 속도가 1ms 미만으로 초당 수백만 건의 작업이 가능하다.
• 고가용성(HA):
  클러스터 기능을 통해 장애 발생 시 자동으로 장애를 감지하고 페일오버를 수행하여 운영자의 개입 없이 정상적으로 유지된다
• 유연한 확장성(레디스의 클러스터):
  레디스의 클러스터를 활용하면 캐시의 스케일 아웃이 쉬워 서비스 규모에 따라 캐시 자체의 규모를 쉽게 확장할 수 있습니다.

🚨따라서 레디스는 캐시 저장소 용도로 이상적이며 수많은 애플리케이션이 레디스를 캐시 용도로 사용하고 있다.

---

🔸캐싱 전략

레디스를 캐시로 사용할 때, 레디스를 어떻게 배치할 것인지에 따라 서비스의 성능에 큰 영향을 끼칠 수 있다.

 

캐싱 전략은 캐싱되는 데이터의 유형과 데이터에 대한 액세스 패턴에 따라 다르기 때문에 서비스에 맞는 적절한 캐싱 전략을 선택하는 것이 중요하다.

---

1️⃣ 읽기 전략 (look aside)

look aside 전략은 레디스를 캐시로 사용할 때 가장 일반적으로 배치하는 방법이다.

---

🔹1. 캐시 히트

애플리케이션은 찾고자 하는 데이터가 먼저 캐시에 있는지 확인한다.

캐시에 데이터가 있으면 캐시에서 데이터를 읽어온다 => 캐시 히트

---

🔹2. 캐시 미스

찾고자 하는 데이터가 없을 때에는 캐시 미스가 발생한다.

 

레디스로부터 데이터가 없다는 응답을 받은 애플리케이션은 직접 데이터베이스에 접근해 찾고자 하는 데이터를 가져온다.

그 뒤 애플리케이션은 이를 다시 캐시에 저장하는 과정을 거친다.

🚨 Lazy Loading !!

찾고자 하는 데이터가 레디스에 없을 때에만 레디스에 데이터가 저장되는 구조를 말한다.

캐시 미스가 발생하면 데이터베이스에 접근해야 하므로 성능 저하의 원인이 될 수 있다.

특히, 새로운 데이터를 저장하거나 처음 레디스를 도입할 때 성능에 영향을 줄 수 있다.

---

🔹3. 캐시 워밍

캐시 워밍은 이러한 Lazy Loading을 방지하기 위한 방법이자,

캐시 미스를 최소화하여 애플리케이션 데이터 접근 속도를 향상시키는 방법이다.

 

따라서 캐시 워밍은 서비스 시작 전 또는 특정 이벤트 발생 전에 필요한 데이터를 미리 캐시에 로드한다.

---

2️⃣ 쓰기 전략

캐시는 데이터베이스에 저장돼 있는 데이터를 단순히 복사해 온 값이다.

따라서 원본 데이터와 동일한 값을 갖도록 유지하는 것이 필수적이다.

 

만약 데이터가 변경될 때 원본 데이터베이스에만 업데이트돼 캐시에는 변경된 값이 반영되지 않는다면 데이터 간 불일치가 일어나며 이를 캐시 불일치라 한다.

 

캐시를 이용한 쓰기 전략은 대표적으로 세 가지가 있다.

---

🔹1. write through

데이터베이스에 업데이트할 때마다 매번 캐시에도 데이터를 함께 업데이트시키는 방식

• 장점 :
  • 캐시는 항상 최신 데이터를 가질 수 있다.
• 단점 :
  • 데이터는 매번 2개의 저장소에 저장돼야 하기 때문에 데이터를 쓸 때마다 시간이 많이 소요된다.

즉 다시 사용되지 않을 데이터도 무조건 캐시에 저장되기 때문에 리소스 낭비가 발생할 수 있다.

(이 방식을 사용할 경우 데이터를 저장할 때 만료 시간 사용 권장)

---

🔹2. cache invalidation

 

데이터베이스에 값을 업데이트할 때마다 캐시에서 데이터를 삭제하는 방식

• 장점 :
  • 리소스를 훨씬 절약할 수 있다. - write through 단점 보완
• 단점 :
  • 캐시 미스가 증가할 수 있다.
  • 실시간 처리가 어렵다.

업데이트 빈도가 낮고 읽기 빈도가 높은 시스템에 적합한 방식이다.

---

🔹3. write behind(write back)

애플리케이션이 먼저 캐시에 데이터를 쓰고, 나중에 비동기적으로 데이터베이스에 저장하는 방식

• 장점:
  • 데이터베이스에 즉시 쓰지 않고 캐시에 먼저 저장하므로 빠른 응답 속도를 제공한다.
  • 데이터베이스로의 쓰기 작업을 묶어서 처리하기 때문에 디스크 I/O를 줄일 수 있다.
• 단점:
  • 시스템 장애 시 캐시에만 저장된 데이터가 데이터베이스에 동기화되지 않아 손실될 수 있다.
  • 일관성 관리가 어렵다.

즉, 데이터의 일관성보다 성능이 중요한 경우, 쓰기 작업이 빈번한 경우에 유용하다.

(ex 유튜브와 같은 스트리밍 사이트의 동영상 좋아요 수)

---

🔸캐시 만료 시간

기본적으로 캐시는 데이터 스토어가 갖고 있는 데이터 중 사용자가 자주 사용할 만한 데이터를 갖고 와서 임시로 저장하는 저장소이다.  즉, 데이터 스토어보다 적은 양을 보관하는 데이터베이스의 서브셋이라고 볼 수 있다.

 

특히 레디스는 메모리에 모든 데이터를 저장하므로 공간은 더더욱 한정적이다.

 

따라서 캐시는 가득 차지 않게 일정 양의 데이터를 유지해야 하며 계속해서 새로운 데이터가 저장되고 기존 데이터는 삭제될 수 있도록 관리해야한다.

 

그러므로, 캐시로 레디스를 사용할 때에는 데이터를 저장함과 동시에 적절한 시간의 TTL값을 지정하는 것이 좋다.

---

1️⃣ 만료시간, TTL

만료시간, TTL : 데이터가 얼마나 오래 저장될 것인지를 나타내는 시간 설정

레디스는 데이터베이스 내의 특정 키에 대한 만료 시간을 설정할 수 있으며,

이는 데이터의 유효 기간 또는 만료시간을 정의하는 데 사용된다.

 

특징은 다음과 같다.

• 단위: 보통 초(second) 단위로 설정되며, 밀리초(millisecond) 단위로도 설정 가능(PTTL, PEXPIRE 사용 시).
• 자동 삭제: 설정된 시간이 지나면 자동으로 데이터가 삭제되어 메모리 공간을 효율적으로 관리할 수 있다.
• 데이터 수명 관리: 캐시 데이터 유지 및 관리에 도움을 준다.

키에 만료시간을 지정하는 예제를 살펴보고자한다.

---

🔹EXPIRE

> SET a 100
"OK"

> EXPIRE a 60
(integer) 1

사용법: EXPIRE <key> <seconds>

위의 예제는 a라는 키에 100을 저장한 뒤 EXPIRE 커맨드를 이용해 만료시간을 60초로 설정했다.

(INCR 커맨드로 데이터를 조작하거나 RENAME을 이용해 키의 이름을 바꾸더라도 설정된 만료 시간은 변경되지 않음)

---

🔹SET + EX

> SET a 100 EX 60
"OK"

사용법: SET <key> EX <seconds>

SET 명령어로 값을 저장할 때 만료 시간을 함께 설정할 수 있다.

---

🔹TTL 

// 만료시간이 설정된 경우
> TTL a
(integer) 58

// 만료시간이 설정되지 않은 경우
> TTL b
(integer) -1

// 키가 존재하지 않는 경우
> TTL c
(integer) -2

사용법: TTL <key>

TTL의 명령어를 통해 남은 만료시간을 확인할 수 있다.

이때, 반환되는 값은 다음과 같다.

• 만료 시간이 설정된 경우 : 남은 시간(초) 반환
• 만료 시간이 설정되지 않은 경우 : -1 반환
• 키가 없는 경우 : -2 반환

---

🚨기존 키에 새로운 값을 덮어 쓸 때?

> SET b 100
"OK"

> EXPIRE b 60
(integer) 1

> TTL b
(integer) 57

> SET b banana
"OK"

> TTL b
(integer) -1

INCR 커맨드로 데이터를 조작하거나 RENAME을 이용해 키의 이름을 바꾸더라도 설정된 만료 시간은 변경되지 않는다.

 

하지만, 기존 키에 새로운 값을 저장해 키를 덮어 쓸 떄에는 이전에 설정한 만료시간은 유지되지 않고 사라진다..

---

2️⃣ 레디스에서 키를 만료하는 방식?

레디스에서 키가 만료됐다고 해도 바로 메모리에서 삭제되지 않는다.

 

키는 passive 방식과 active 방식 두 가지 방식으로 삭제된다.

---

🔹passive 방식

클라이언트가 키에 접근하고자 할 떄 키가 만료됐다면 메모리에서 수동적으로 삭제한다.

• 특징:
  • 사용자 접근 시점에만 삭제가 이루어진다.
  • 사용자 접근이 없는 만료된 키는 여전히 메모리에 남아 있을 수 있다.
• 장점:
  • 불필요한 리소스 사용을 줄인다.
• 단점:
  • 사용자 접근이 적은 키는 메모리에 불필요하게 남아 있어 메모리 낭비 가능성이 있다.

---

🔹active 방식

TTL 값이 있는 키 중 20개를 무작위로 선택하여 만료된 키를 삭제한다.

 

• 동작 방식:
  • 20개의 키 중 25% 이상이 만료된 경우, 추가로 20개를 선택해 반복 확인.
    (이 과정은 1초에 10번 정도 수행됨)
• 장점:
  • 주기적으로 만료된 키를 정리해 메모리 낭비를 방지한다.
• 단점:
  • 랜덤 샘플링이므로 모든 만료된 키가 즉시 삭제되는 것은 아니다.

 

---

🔸메모리 관리와 maxmemory-policy 설정 

레디스에서 키에 만료 시간을 설정해 데이터가 자동으로 삭제되도록 함으로써 데이터이 수명을 관리할 수 있따.

 

하지만 레디스의 메모리는 제한적이기 때문에 모든 키에 만료 시간을 설정하더라도 너무 많은 키가 저장되면 메모리가 가득 차는 상황이 발생할 수 있다.

 

메모리의 용량을 초과하는 양의 데이터가 저장되면 레디스는 내부 정책을 사용해 어떤 키를 삭제할지 결정한다.

 

레디스에서는 메모리 관리는 다음과 같은 두개의 설정값으로 이루어진다.

• maxmemory: 최대 저장 용량을 설정
• maxmemory-policy: maxmemory 용량을 초과 할 떄의 처리 방식을 결정

maxmemory-policy의 다양한 설정값과 동작 방식에 대해 알아보자.

---

1️⃣ Noeviction (기본값)

Noeviction:
레디스에 데이터가 가득 차더라도 임의로 데이터를 삭제하지 않고 더 이상 레디스에 데이터를 저장할 수 없다는 에러를 반환하는 설정값

 

메모리 한도(maxmemory)에 도달하면 새로운 쓰기 요청을 거부한다.

따라서 기존 데이터는 그대로 유지되며, 삭제되지 않는다.

 

그러나 캐시에 데이터를 저장하지 못해 에러가 발생할 경우 로직에 따라 장애 상황으로 이어질 수 있다.

이런 상황에서는 관리자가 레디스의 데이터를 직접 지워야 하기 때문에 레디스를 캐시로 사용할 때 권장하지 않는 설정값이다.

 

데이터 유실이 치명적인 시스템, 내부적 판단으로 데이터를 삭제하는 것이 위험하다고 판단될 때 이 옵션을 사용할 수 있다.

 

---

2️⃣ LRU eviction

LRU(Least-Recently-Used) eviction : 
레디스의 메모리가 가득 찼을 때 가장 최근에 사용되지 않은 데이터를 우선적으로 삭제하는 메모리 관리 전략

이는, 최근에 액세스되지 않은 데이터는 나중에도 액세스될 가능성이 낮을 것이라는 가정을 전제한다.

이를 통해, 자주 사용되는 데이터는 유지하면서 불필요한 데이터를 효율적으로 제거한다.

 

레디스는 LRU 알고리즘을 이용한 두 가지 설정값을 가지고 있다.

---

🔹volatile-lru

만료 시간이 설정돼 있는 키에 한해서 LRU 방식으로 키를 삭제한다.

만료 시간이 설정돼 있는 데이터 중 가장 오래 사용되지 않은 데이터를 삭제한다.

 

특징

• 임시 데이터 관리에 적합하다.
• 만료 시간이 없는 데이터는 삭제 대상이 아니다.
• 모든 키에 TTL이 없으면 noeviction 상황과 동일하게 새로운 데이터를 저장할 수 없다.

---

🔹allkeys-LRU

모든 키에 대해 LRU 방식으로 데이터를 삭제한다.

 

만료 시간이 설정되지 않은 데이터도 삭제 가능한 방식이다.

 

특징:

• 캐시 데이터뿐만 아니라 모든 데이터에 적용 가능하다.
• 메모리 부족으로 인한 장애 상황 방지에 유리하다.
• 레디스를 캐시로 사용하는 경우와 메모리 관리가 중요한 대규모 트래픽 환경에 적합하다.
  (레디스를 캐시로 사용하는 경우 권장하는 방식)

---

3️⃣ LFU eviction

LFU(Least Frequently Used) eviction:
레디스에서 메모리가 가득 찼을 때 가장 사용 빈도가 낮은 데이터를 삭제하는 전략이다.

자주 사용되지 않는 데이터가 앞으로도 사용될 가능성이 낮다고 가정하여 메모리 효율성을 높이는 방식이다.

 

LFU는 LRU와 유사하지만 키를 액세스하는 패턴에 따라 우선순위가 유동적으로 바뀐다는 점에서 특정 케이스에서는 LRU보다 더 효율적일 수 있다. 키가 오랫동안 사용되지 않았더라도 과거에 자주 액세스했던 키라면 나중에도 자주 사용될 수 있다는 가정하에 우선순위가 높아진다.

 

LFU 또한 다음 두 가지 설정값을 가지고 있다.

---

🔹volatile-lfu

만료 시간이 설정돼 있는 키에 한해서 LFU 방식으로 키를 삭제한다.

특징:

• TTL 기반 데이터 관리에 적합하다.
• 만료 시간이 없는 데이터는 삭제되지 않는다.
• 특정 상황에서 장애를 유발할 가능성 있다 (만료된 키가 없을 경우).

---

🔹allkeys-lfu

모든 키에 대해 LRU 방식으로 데이터를 삭제한다.

특징:

• 캐시 시스템에서 데이터 접근 빈도 관리에 최적화.
• 메모리 부족 시 효과적으로 불필요한 데이터 삭제 가능.
•  

---

🚨 NOTE

LRU와 LFU는 모두 근사 알고리즘이다.

 

이 알고리즘들은 가장 오래 사용되지 않았거나 사용 빈도가 낮은 키를 찾기 위해 정확한 계산 대신 근사치를 사용하여 CPU와 메모리 리소스 소비를 최소화한다.

 

즉, 레디스는 정확한 키를 찾는 것보다 특정 키를 근사치로 찾아내 효율적으로 데이터를 삭제하는 방식으로 작동한다.

---

4️⃣ RANDOM eviction

RANDOM eviction(랜덤 제거 정책):
레디스에 저장된 키 중 하나를 무작위로 선택하여 삭제하는 전략이다.

별도의 알고리즘 계산 없이 단순하게 동작하기 때문에, 삭제될 키 값을 계산하지 않아도 된다는 점에서 레디스의 부하를 줄여줄 수 있는 방법이다.

 

하지만 이 방법은 랜덤으로 데이터를 삭제하기 때문에 나중에 사용될 수도 있는 데이터를 삭제할 가능성이 높아진다.

또한, LFU와 LRU는 근사 알고리즘을 사용하기 때문에 그다지 큰 리소스를 사용하지 않는다.

 

따라서 권장되지 않는다.

 

random eviction도 다음과 같은 두 가지 설정값을 가지고 있다.

• volatile-random : 만료 시간이 설정돼 있는 키에 한해 랜덤하게 키 삭제
• allkeys-random : 모든 키에 대해 랜덤하게 키 삭제

---

5️⃣ volatile-ttl

volatile-ttl 방식:
만료 시간이 가장 작은 키를 삭제하는 전략이다.

삭제 예정 시간이 얼마 남지 않은 키를 추출해 해당 키를 미리 삭제하는 옵션이다.

 

이 알고리즘 또한 LRU, LFU와 마찬가지로 근사 알고리즘을 이용한다.

 

따라서 저장된 모든 키를 스캔하면서 만료 시간을 비교하지 않아도 돼 간단하게 키를 찾아낼 수 있다.

---

📙 출처

<개발자를 위한 레디스> - 김가림