Mar 23, 2026

마지막 업데이트 Mar 31, 2026

Redis 메모리 사용량이 높을 때 먼저 확인할 것들

Redis 메모리 사용량이 계속 올라가면 먼저 해야 할 일은 이것이 big key 문제인지, TTL이 빠진 것인지, queue처럼 무한히 쌓는 사용 방식인지, 아니면 원래 workload가 계획보다 커진 것인지를 가르는 것입니다. 많은 팀이 바로 서버 설정을 만지지만, 실제로는 이미 사라졌어야 할 데이터나 조용히 커진 data structure가 원인인 경우가 많습니다.

핵심은 server memory metric부터 보고, 실제 key 몇 개를 확인하고, 순수한 데이터 증가와 이미 없어졌어야 할 데이터 증가를 분리해서 봐야 한다는 점입니다.

먼저 더 많은 데이터를 저장하는 중인지, 이미 사라졌어야 할 데이터가 남아 있는지 구분하세요

이 둘은 대시보드에서는 거의 같은 모양으로 보일 수 있습니다.

한쪽은 Redis가 애플리케이션이 요청한 일을 그대로 하고 있고 workload가 원래 계획보다 커진 경우입니다. 다른 한쪽은 expire, trim, retention이 걸렸어야 할 데이터가 조용히 쌓이고 있는 경우입니다.

이 구분이 중요한 이유는 전자는 용량 계획과 데이터 모델 문제이고, 후자는 TTL과 retention 로직 문제이기 때문입니다.

추측보다 server-level memory부터 보세요

기본 명령은 아래 두 개입니다.

redis-cli INFO memory
redis-cli MEMORY STATS

INFO memory는 가장 빠른 운영 스냅샷이고, MEMORY STATS는 allocator overhead와 메모리 구조를 더 자세히 보여줍니다.

코드부터 뒤지기 전에 Redis가 스스로 무엇을 보고 있는지 먼저 확인해야 합니다.

몇 개 key가 대부분을 차지하는지 확인하세요

server 숫자만 보면 원인을 놓치기 쉽습니다.

아래 명령이 바로 도움이 됩니다.

redis-cli --bigkeys
redis-cli MEMORY USAGE your:key

--bigkeys는 의심 후보를 빠르게 찾는 데 좋고, MEMORY USAGE는 특정 key 하나의 실제 비용을 확인하는 데 좋습니다.

한두 개 key가 유독 크다면 그 시점부터는 일반 메모리 분석보다 Redis Big Keys가 더 직접적인 경로입니다.

이미 만료됐어야 할 key가 남아 있는지 보세요

메모리 incident가 사실은 TTL incident인 경우가 많습니다.

cache, session, rate limit, temporary key를 샘플링해서 아래를 보세요.

redis-cli TTL your:key

-1이 많이 나온다면 문제는 단순 데이터량이 아니라 expire 누락일 수 있습니다.

key 개수보다 data shape를 같이 봐야 합니다

Redis 메모리 문제는 순수한 개수보다 구조 때문에 커지는 경우가 많습니다.

대표 패턴은 아래와 같습니다.

field가 계속 늘어나는 hash
무한 queue처럼 쓰는 list
과거 데이터를 끝없이 저장하는 sorted set
feature마다 반복적으로 큰 value를 쓰는 경우

이 경우 문제는 Redis leak이라기보다 애플리케이션이 생각보다 더 많이 저장하고 있다는 쪽에 가깝습니다.

maxmemory와 eviction이 앱 기대와 맞는지도 보세요

아래 질문을 같이 해야 합니다.

maxmemory가 설정되어 있는가
eviction policy가 의도한 값인가
앱이 TTL을 기대하는가, eviction을 기대하는가, 둘 다인가

앱은 자동 정리를 기대하는데 서버 설정은 그렇지 않다면 incident 해석이 완전히 달라집니다.

갑작스러운 성장의 흔한 이유

1. TTL이 사라짐

SET 같은 overwrite 경로가 expire를 함께 유지하지 않는 경우가 흔합니다.

2. 특정 기능이 무한 데이터를 쌓음

feed, leaderboard, session index, queue, activity buffer는 cleanup rule이 없으면 계속 커집니다.

3. 몇 개 큰 key가 전체 메모리를 지배함

그래서 총 key 수보다 샘플 key 확인이 더 중요합니다.

4. consumer가 밀려 backlog가 쌓임

Redis를 buffer처럼 쓸 때 reader가 느려지면 메모리 증가는 자연스러운 결과일 수 있습니다.

실전 점검 순서

INFO memory를 본다
MEMORY STATS를 본다
--bigkeys와 MEMORY USAGE로 큰 key를 확인한다
cache 성격 key의 TTL을 확인한다
데이터 모델에 retention rule이 있는지 본다

이 순서가 메모리 설정부터 건드리는 것보다 훨씬 빨리 원인 종류를 좁혀줍니다.

초반 분기에 좋은 shortcut

메모리가 계속 오를 때는 아래처럼 먼저 갈라보세요.

--bigkeys에서 몇 개 outlier가 보인다: big key 먼저
key 크기는 적당한데 TTL이 없다: expiration drift 먼저
queue처럼 쌓이는 구조가 보인다: backlog나 retention 먼저
메모리 증가가 유효한 데이터 성장과 맞아떨어진다: capacity budget 먼저

이 분기만으로도 eviction 설정을 먼저 논쟁하는 시간을 줄일 수 있습니다.

FAQ

Q. Redis 메모리 사용량이 높으면 항상 leak인가요?

아니요. expire 누락, big key, 데이터 모델 문제인 경우가 많습니다.

Q. 특정 key 하나를 가장 빨리 확인하는 명령은 무엇인가요?

MEMORY USAGE key입니다.

Q. 밤새 메모리가 계속 오르면 무엇부터 봐야 하나요?

TTL 동작, backlog growth, retention 없는 기능을 먼저 보세요.

Q. 언제 big key를 먼저 의심해야 하나요?

샘플링한 key 몇 개가 이미 예상보다 크거나 --bigkeys가 바로 outlier를 보여줄 때입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.