Redis big key는 메모리만 낭비하는 문제가 아닙니다. latency를 키우고 persistence 비용을 올리고, 단순한 작업도 noisy한 운영 incident처럼 보이게 만듭니다. 많은 팀이 메모리 그래프나 느린 요청 같은 표면 증상만 보지만, 실제 문제는 oversized data structure 하나의 shape인 경우가 많습니다.
핵심은 간단합니다. 먼저 oversized key가 어디 있는지 찾고, 그다음 데이터를 더 잘게 나눌지, retention을 줄일지, 아예 다른 구조로 옮길지 결정해야 합니다. 응급 cleanup은 당장의 압박을 줄이지만, 같은 incident가 다시 오지 않게 만드는 건 구조 변경입니다.
무엇을 big key라고 부르나
big key는 절대적인 숫자로 정의되지 않습니다. 현재 workload에서 memory pressure를 만들거나, command를 느리게 하거나, persistence를 고통스럽게 만드는 정도의 크기나 element count를 가진 key라면 operational 관점에서 big key입니다.
즉 big key는 이론적인 정의보다 운영적인 정의에 가깝습니다.
big key가 메모리만의 문제가 아닌 이유
oversized key는 메모리 그래프에 먼저 드러나지만 영향 범위는 더 넓습니다.
- 그 key를 건드리는 command가 느려짐
- replication과 persistence 비용이 커짐
- eviction pressure가 더 고통스럽게 동작함
- 하나의 hot key가 다른 트래픽 latency까지 왜곡함
그래서 big key는 보통 memory capacity 문제라기보다 data shape 문제입니다.
big key가 생기는 흔한 방식
1. 하나의 list, set, hash가 끝없이 누적되는 경우
retention이 강제되지 않아 구조가 계속 커집니다.
2. cache key 하나에 너무 많은 데이터를 넣는 경우
cache 자체는 맞지만 value shape가 지나치게 비쌉니다.
3. 특정 tenant나 feature 하나가 hotspot이 되는 경우
분포가 고르지 않아 몇 개 key가 비용 대부분을 차지합니다.
4. cleanup은 있지만 너무 늦게 오는 경우
언젠가는 정리되지만 그 전에 이미 운영 pain을 만드는 크기가 됩니다.
blind redesign 전에 big key를 먼저 찾으세요
Redis는 key pattern과 memory usage를 확인할 수 있는 도구를 제공합니다.
대표적인 조사 경로는 아래와 같습니다.
redis-cli --bigkeysMEMORY USAGE <key>- 같은 데이터를 건드리는 command 주변의 latency와 slowlog 확인
이 단계가 있어야 “엄청 큰 key 하나” 문제인지, “중간 크기 key가 너무 많아 비슷한 압박”인지 구분할 수 있습니다.
응급 삭제보다 구조 변경이 더 자주 정답입니다
거대한 key 하나를 지우면 당장 통증은 줄어들 수 있지만, 진짜 해결은 구조 변경인 경우가 많습니다.
대표적인 해결책은 아래와 같습니다.
- 큰 객체 하나를 더 작은 단위로 나누기
- retention window 줄이기
- cached item마다 저장하는 데이터 줄이기
- 애초에 Redis가 이 data shape를 들고 있어야 하는지 다시 보기
실전 점검 순서
1. pain point가 memory인지 latency인지 둘 다인지 확인합니다
이걸 알아야 저장 비용이 문제인지, 접근 비용이 문제인지, 둘 다인지 분리할 수 있습니다.
2. 어떤 key가 압박 대부분을 만드는지 찾습니다
중요한 key가 무엇인지 모른 채 전체 데이터셋을 손보면 일이 커지기 쉽습니다.
3. 그 key들이 어떻게 접근되는지 봅니다
read pattern, write pattern, expiration behavior는 raw size만큼 중요합니다.
4. 구조를 쪼갤지, 보관 기간을 줄일지 결정합니다
장기적인 해결은 대개 cleanup script보다 shape change입니다.
5. persistence와 eviction 부작용을 다시 확인합니다
memory 그래프가 좋아져도 RDB, AOF, eviction pressure에서 같은 문제가 다시 드러날 수 있습니다.
바로 확인할 명령
redis-cli --bigkeys
redis-cli MEMORY USAGE my:key
redis-cli --latency
redis-cli SLOWLOG GET 20이 명령으로 oversized key를 찾고, 대략적인 무게를 보고, command latency가 같은 데이터와 맞물리는지 확인할 수 있습니다.
초반 판단에 도움이 되는 shortcut
특정 key family가 유독 크다면 아래 질문을 먼저 해보세요.
- 주된 pain이 storage cost인가 access cost인가
- cleanup 뒤에도 다시 같은 key가 커지는가
- tenant, time window, object boundary 단위로 쪼갤 수 있는가
- Redis가 이 정도 양의 material을 들고 있는 게 맞는가
이 질문들이 보통 “가장 큰 key 하나를 지우자”보다 훨씬 오래 가는 해결책으로 이어집니다.
big key를 볼 때의 실전 관점
좋은 해결책은 cleanup 질문보다 design 질문에서 나오는 경우가 많습니다.
먼저 아래를 물어보세요.
- 이 데이터를 더 작은 key로 쪼개야 하는가
- retention window를 더 짧게 해야 하는가
- 각 operation이 만지는 데이터를 줄여야 하는가
- Redis가 이 shape를 들고 있는 게 맞는가
이 질문의 답이 바뀌지 않으면 cleanup script를 돌려도 같은 big key가 다시 생깁니다.
FAQ
Q. big key는 메모리 문제만 일으키나요?
아니요. memory, latency, persistence, eviction behavior를 함께 건드리는 경우가 많습니다.
Q. 가장 빠른 첫 단계는 무엇인가요?
무언가를 지우기 전에 --bigkeys와 MEMORY USAGE를 먼저 확인하세요.
Q. 가장 큰 key부터 그냥 지우면 되나요?
애플리케이션 영향을 이해한 경우에만 그렇습니다. 증상은 지워도 구조 문제는 남을 수 있습니다.
Q. 언제 redesign이 불가피한가요?
같은 data structure가 반복해서 같은 운영 문제를 만드는 패턴일 때입니다.
Read Next
- memory pressure가 더 직접적이라면 Redis Memory Usage High를 보세요.
- 같은 workload에서 latency spike도 보인다면 Redis Latency Spikes Guide를 보세요.
- 압박 때문에 write가 거절된다면 Redis OOM Command Not Allowed Guide를 보세요.
Related Posts
- Redis Memory Usage High
- Redis Latency Spikes Guide
- Redis OOM Command Not Allowed Guide
- Redis Eviction Policy Guide
Sources:
- https://redis.io/docs/latest/develop/tools/cli/
- https://redis.io/docs/latest/commands/memory-usage/
- https://redis.io/docs/latest/commands/slowlog/
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.