Redis를 효율적인 다중 계층 캐시로 구성하기

Redis는 작업 데이터를 메모리에 유지하기 때문에 빠르지만, 관리되지 않는 캐시는 여전히 호스트를 가득 채우고 쓰기 실패를 유발할 수 있습니다. Redis를 애플리케이션과 느린 데이터베이스 사이의 다중 계층 캐시로 사용할 때 주요 결정 사항은 메모리 제한, 축출 정책, TTL 규율, 그리고 캐시 데이터를 지속할지 여부입니다.

이 가이드는 기본 데이터 저장소가 아닌 캐시 워크로드를 위한 Redis 구성에 중점을 둡니다.

Redis 캐싱 계층 이해하기

많은 애플리케이션 설계에서 Redis는 더 작은 인-프로세스 캐시 뒤에 있는 공유 캐시입니다. 애플리케이션은 몇 밀리초 동안 몇 개의 핫 값을 로컬에 유지할 수 있는 반면, Redis는 더 큰 재사용 가능한 객체 세트를 몇 초 또는 몇 분 동안 저장합니다. 이로 인해 Redis는 트래픽이 급증할 때 데이터베이스를 보호하는 계층이 됩니다.

효율적인 구성은 두 가지 핵심 영역에 달려 있습니다:

1. 메모리 관리: Redis가 소비할 수 있는 메모리에 하드 제한을 설정합니다.
2. 축출 정책: 메모리 제한에 도달했을 때 Redis가 어떤 키를 제거할지 결정하는 방법을 정의합니다.

1. 안정성을 위한 메모리 제한 설정

Redis가 사용 가능한 모든 시스템 메모리를 소비하지 않도록 방지하는 것은 호스트 안정성을 위해 가장 중요합니다. maxmemory 지시문은 데이터 세트에 할당된 메모리(오버헤드 제외)에 대한 절대 상한을 설정합니다. 이 제한에 도달하면 Redis는 구성된 정책에 따라 키를 축출하기 시작합니다.

구성 지시문: maxmemory

이 설정은 프로덕션 환경에서 중요합니다. 일반적인 모범 사례는 운영 체제 작업 및 Redis 오버헤드(예: 내부 데이터 구조, 복제 버퍼)를 위해 약간의 여유 공간을 남겨 두는 것입니다.

예시 구성 (redis.conf):

# 최대 메모리 사용량을 4GB로 설정
maxmemory 4gb

팁: 더 쉬운 구성 관리를 위해 항상 사람이 읽을 수 있는 접미사(예: 100mb, 2gb)를 사용하세요.

메모리 정책 시행

maxmemory가 설정되고 maxmemory-policy가 noeviction으로 남아 있으면, 제한에 도달했을 때 더 많은 메모리가 필요한 명령이 실패할 수 있습니다. 캐시의 경우, Redis가 일반 캐시 쓰기를 거부하는 대신 오래된 캐시 항목을 폐기할 수 있는 축출 정책을 선택하세요.

2. 올바른 축출 정책 선택 (maxmemory-policy)

이 지시문은 메모리 제한을 초과했을 때 Redis가 제거할 키를 선택하는 데 사용하는 알고리즘을 정의합니다. 올바른 정책을 선택하는 것은 애플리케이션 데이터의 액세스 패턴에 크게 의존합니다.

휘발성 vs 비휘발성 정책

정책은 일반적으로 키에 설정된 TTL(Time-To-Live) 만료를 고려하는지 여부에 따라 분류됩니다:

• 휘발성: 만료 시간이 설정된 키만 고려합니다(EXPIRE 또는 SETEX).
• 모든 키: TTL에 관계없이 모든 키를 고려합니다.

대부분의 항목에 명시적 만료가 있는 순수 캐싱 계층의 경우 휘발성 정책이 탁월합니다. 외부 애플리케이션 로직에 의존하여 오래된 데이터를 관리하는 경우 비휘발성 정책을 선호할 수 있습니다.

주요 축출 알고리즘 설명

A. 가장 오래 사용되지 않음 (LRU)

이것은 일반 캐싱에서 가장 일반적이고 종종 기본 정책입니다. 가장 오랫동안 액세스되지 않은 키를 제거합니다. 액세스 패턴이 시간적 지역성 원칙(최근에 액세스한 데이터는 곧 다시 액세스될 가능성이 높음)을 따를 때 가장 잘 작동합니다.

구성:

maxmemory-policy allkeys-lru

B. 가장 적게 사용됨 (LFU)

LFU는 키가 액세스된 빈도를 추적합니다. 추정 액세스 빈도가 낮은 키를 축출합니다. 이는 워크로드에 가끔 스캔이나 일회성 읽기에서 살아남아야 하는 안정적인 인기 키 세트가 있을 때 잘 작동합니다.

구성:

maxmemory-policy allkeys-lfu

C. TTL 기반 축출

TTL 기반 축출은 키에 의미 있는 만료 시간이 있고 만료에 가장 가까운 키가 제거하기에 가장 안전할 때 유용합니다.

구성:

maxmemory-policy volatile-ttl

이 정책은 만료가 설정된 키만 고려합니다. 많은 키에 TTL이 없으면 Redis는 여전히 축출 가능한 키가 부족하여 쓰기를 거부할 수 있습니다.

D. 무작위 축출

무작위 축출은 간단하며 일회용 캐시 데이터에 때때로 허용되지만, 캐시에 명확한 액세스 패턴이 있을 때 첫 번째 선택은 거의 아닙니다.

maxmemory-policy allkeys-random

3. TTL을 일관되게 설정

축출 정책은 압력 해소 밸브이지 유일한 캐시 무효화 전략이 아닙니다. 대부분의 캐시 키는 데이터의 비즈니스 가치와 일치하는 만료 시간을 가져야 합니다.

예를 들어, 제품 상세 페이지는 렌더링된 조각을 5분 동안 캐시할 수 있습니다:

redis-cli SET product:123:html "$HTML" EX 300

사용자 권한 조회는 오래된 데이터가 더 위험하기 때문에 훨씬 짧은 TTL이 필요할 수 있습니다:

redis-cli SET user:42:permissions "$JSON" EX 30

allkeys-* 정책을 사용하고 있고 모든 키가 축출될 수 있다는 점에 동의하지 않는 한, 영구 키와 일회용 캐시 키를 동일한 Redis 데이터베이스에 혼합하지 마십시오. 일부 데이터가 절대 축출되어서는 안 되는 경우, 다른 정책을 가진 별도의 Redis 인스턴스나 데이터베이스에 보관하십시오.

4. 캐시 지속성이 도움이 되는지 결정

순수 캐시의 경우 Redis 지속성은 선택 사항입니다. RDB 및 AOF를 비활성화하면 디스크 I/O와 재시작 복잡성이 줄어들지만, Redis가 재시작될 때 모든 캐시 키가 손실됩니다.

save ""
appendonly no

애플리케이션이 데이터베이스에서 캐시를 재구축할 수 있는 경우 이는 허용됩니다. 캐시 워밍업이 비용이 많이 들거나 콜드 캐시가 데이터베이스에 과부하를 줄 경우 RDB 스냅샷 또는 AOF를 활성화된 상태로 유지하고 부하 상태에서 재시작 동작을 테스트하십시오.

5. 캐시 상태 모니터링

Redis 메트릭을 사용하여 캐시가 도움이 되고 있는지 확인하십시오:

redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO keyspace

특히 다음 필드를 주시하십시오:

메트릭	설명
used_memory_human	Redis가 현재 소비하는 메모리.
maxmemory_human	구성된 메모리 상한.
evicted_keys	Redis가 압력 하에 축출하고 있는지 여부.
keyspace_hits 및 keyspace_misses	캐시가 유용한 읽기를 제공하고 있는지 여부.
expired_keys	TTL 정리가 활성화되어 있는지 여부.

evicted_keys가 빠르게 증가하고 적중률이 떨어지면 메모리를 늘리거나, 가치가 낮은 키의 TTL을 줄이거나, 노이즈가 많은 워크로드를 별도의 캐시로 분할하십시오.

예시 캐시 구성

다음은 일회용 캐시 항목 전용 Redis 인스턴스의 합리적인 시작점입니다:

maxmemory 4gb
maxmemory-policy allkeys-lfu
save ""
appendonly no

모든 키에 신중하게 선택된 TTL이 있는 캐시의 경우:

maxmemory 4gb
maxmemory-policy volatile-ttl

CONFIG GET maxmemory maxmemory-policy를 사용하여 활성 설정을 확인하십시오:

redis-cli CONFIG GET maxmemory maxmemory-policy

결론

Redis 캐시 구성을 용량 제어 문제로 취급하십시오. maxmemory를 설정하고, 액세스 패턴과 일치하는 축출 정책을 선택하고, 캐시 키에 명시적 TTL을 제공하고, 지속성이 디스크 I/O 가치가 있는지 결정하십시오. 그런 다음 적중률, 축출 및 메모리 증가를 모니터링하여 캐시가 데이터베이스를 보호하고 다음 병목 현상이 되지 않도록 하십시오.