현대적인 백엔드 시스템 아키텍처에서 Redis는 단순한 캐시 솔루션을 넘어 세션 저장소, 메시지 브로커, 실시간 순위 집계 등 핵심적인 역할을 수행하고 있습니다. 그러나 Redis는 인메모리 데이터베이스라는 특성상 물리적인 메모리 한계에 매우 민감하게 반응합니다. 서비스 운영 중 가장 당혹스러운 순간 중 하나는 바로 잘 돌아가던 서버가 갑자기 'OOM(Out Of Memory) command not allowed'라는 에러 메시지를 뱉으며 멈춰버리는 상황일 것입니다. 이는 단순히 하드웨어 리소스가 부족해서 발생하는 문제일 수도 있지만, 대부분의 경우 Redis 내부의 메모리 관리 정책, 즉 maxmemory-policy 설정이 데이터의 성격과 맞지 않게 구성되어 있기 때문에 발생합니다.
특히 중요한 사용자 세션 데이터나 결제 임시 정보 등 절대 삭제되어서는 안 되는 데이터와, 언제든지 다시 생성 가능한 단순 캐시 데이터가 하나의 Redis 인스턴스에 혼재되어 있을 때 이 문제는 더욱 치명적입니다. 적절한 정책이 설정되어 있지 않다면 Redis는 메모리가 가득 찼을 때 새로운 쓰기 작업을 거부하거나, 심지어 보존해야 할 중요한 데이터까지 무차별적으로 삭제해 버릴 수도 있습니다. 본 가이드에서는 Redis 서버의 메모리 부족으로 인한 OOM 에러 발생 메커니즘을 심층적으로 분석하고, maxmemory-policy 설정을 전략적으로 변경하여 중요 데이터를 안전하게 보호하면서도 서비스의 가용성을 유지하는 구체적인 방법을 다룹니다.
Redis OOM 에러의 원인과 메모리 구조 이해하기
Redis에서 OOM 에러가 발생한다는 것은 할당된 maxmemory 한도에 도달했으며, 더 이상 데이터를 저장할 공간이 없다는 것을 의미합니다. 하지만 여기서 중요한 점은 단순히 공간이 없다는 사실보다, 공간이 없을 때 Redis가 '어떻게 행동하도록 설정되어 있는가'입니다. 많은 개발자가 초기 설정 시 메모리 한계값인 maxmemory만 설정하고, 그 한계에 도달했을 때의 행동 지침인 maxmemory-policy는 기본값으로 방치하는 경우가 많습니다.
기본 설정의 위험성: noeviction 정책
Redis의 기본 메모리 정책은 보통 noeviction으로 설정되어 있습니다. 이 단어가 의미하는 바는 명확합니다. '축출(Eviction)하지 않겠다'는 것입니다. 메모리가 가득 찼을 때 기존 데이터를 삭제하여 공간을 확보하는 대신, 새로운 데이터의 쓰기 작업(SET, LPUSH 등)을 전면 거부하고 에러를 반환합니다.
이는 데이터의 무결성 측면에서는 가장 안전해 보일 수 있으나, 가용성 측면에서는 재앙과도 같습니다. 예를 들어, 로그인이 필요한 서비스에서 세션 생성을 위해 Redis에 쓰기 요청을 보냈는데 OOM 에러가 발생한다면, 모든 사용자의 로그인이 불가능해지는 전면 장애로 이어집니다. 따라서 중요 데이터를 보존하면서도 서비스가 멈추지 않게 하려면 이 정책을 반드시 상황에 맞게 변경해야 합니다.
메모리 부족 시나리오와 시스템 영향
메모리 부족 상황은 갑작스러운 트래픽 폭주로 인해 캐시 데이터가 급증하거나, 만료 시간(TTL)이 설정되지 않은 좀비 키(Key)들이 누적되면서 서서히 발생할 수 있습니다. 운영체제 레벨의 OOM Killer가 Redis 프로세스를 강제로 종료시키는 상황과 Redis 내부의 OOM 에러는 구분해야 합니다. 우리가 다루는 것은 Redis 프로세스는 살아있지만, 내부 정책에 의해 쓰기가 거부되는 상황입니다. 이 경우 애플리케이션 로그에는 'OOM command not allowed when used memory > maxmemory'와 같은 명시적인 에러 로그가 남게 되므로, 모니터링 시스템을 통해 이를 조기에 감지하는 것이 중요합니다.
중요 데이터 보존을 위한 maxmemory-policy 전략
Redis를 캐시 용도와 저장소 용도로 혼합해서 사용할 때 가장 큰 딜레마는 "어떤 데이터를 지우고, 어떤 데이터를 남길 것인가"입니다. 중요 데이터를 보존하기 위해서는 Redis가 삭제 대상으로 삼는 키(Key)의 범위를 명확히 제한해야 합니다. 이를 위해 Redis는 크게 두 가지 범주의 정책을 제공합니다. 하나는 모든 키를 대상으로 하는 allkeys 계열이고, 다른 하나는 만료 시간(TTL)이 설정된 키만을 대상으로 하는 volatile 계열입니다.
핵심 전략: volatile-lru 및 volatile-lfu 활용
중요 데이터(영구 보존이 필요한 설정값, 마스터 데이터 등)를 보호하는 가장 확실한 방법은 해당 데이터에 만료 시간(TTL)을 설정하지 않는 것입니다. 그리고 maxmemory-policy를 volatile-lru 혹은 volatile-lfu로 설정합니다.
- 작동 원리: 이 정책들은 오직 'Expire Set(만료 시간이 설정된 키 집합)' 내에서만 삭제 대상을 찾습니다. 만료 시간이 없는 키는 메모리가 아무리 부족해도 절대 삭제되지 않습니다.
- 보존 효과: 따라서 중요한 데이터는 TTL 없이 저장하고, 삭제되어도 다시 DB에서 조회 가능한 단순 캐시 데이터에는 반드시 TTL을 설정하여 저장하면, Redis는 메모리가 부족할 때 캐시 데이터만 골라서 삭제하고 중요 데이터는 안전하게 지킵니다.
Tip: 만약 모든 데이터가 중요해서 하나라도 삭제되면 안 되는 경우라면, 정책 변경보다는 Scale-up(메모리 증설)이나 Redis Cluster를 통한 Sharding(분산 저장)을 고려해야 합니다. 정책 변경은 제한된 리소스 내에서 우선순위를 정하는 방법임을 명심해야 합니다.
LRU와 LFU 알고리즘의 선택 기준
삭제 대상을 선정하는 알고리즘인
댓글
댓글 쓰기