[Cache] 메모리 지표 Raboja & Redis 메모리 정책

개요

---

Redis는 모든 데이터를 메모리에 저장한다.(In-Memory) 디스크 기반 DB와 달리 메모리가 곧 저장 용량의 한계가 된다. 메모리 용량이 부족해지면 데이터 손실 가능성이 있고 비싼 메모리를 추가해야 한다.

 

maxmemory 도달 시, noeviction, volatile-lru, allkeys-lru, oom 등 서비스 장애로 이어질 현상이 나타날 수 있다. 비싼 메모리를 잘 활용하기 위해서 Redis Node에 접근해서 확인할 수 있는 메모리 관련 지표에 대해 알아보자. (이 문서에 잘 나와있음.)

 

🔖 참고

Redis Node에 접근해서 info memory를 하면 메모리 관련 여러 지표를 볼 수 있다. 이때 _human 이라는 suffix가 붙은 메트릭들은 사람이 알아보기 쉽게 Byte 단위를 변환해준다.

 

used_memory

---

• Redis가 할당한 총 메모리 (데이터 + 오버헤드)
• used_memory_dataset + used_memory_overhead
  • dataset: 사용자가 저장한 키-값 데이터가 차지하는 메모리
  • overhead: 데이터 저장 외, 서버 운영을 위해 사용하는 메모리(내부 자료구조 초기화, 상태 관리 등)

 

used_memory_rss

---

• OS 커널이 Redis 프로세스에 할당한 실제 물리 메모리 (Resident Set Size)

# 대략 이런 구조임
┌─────────────────────────────────────────┐
│           AWS ElastiCache               │
│  ┌───────────────────────────────────┐  │
│  │         EC2 인스턴스 (노드)         │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │      Amazon Linux OS        │  │  │
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │    Redis 프로세스      │  │  │  │
│  │  │  │                       │  │  │  │
│  │  │  │  used_memory: 10MB    │  │  │  │
│  │  │  └───────────────────────┘  │  │  │
│  │  │                             │  │  │
│  │  │  RSS: 22MB (OS가 할당한 양)  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

OS가 할당(한 것으로 추정하는) rss 크기가 더 큰 걸 볼 수 있다.

 

used_memory_peak

---

• 지금까지 사용한 최대 메모리
• slowlog get 10 : 대용량 데이터 처리 명령이 있었는지 확인해볼 수 있다.
• info commandstats : 명령어별 실행 횟수/ 시간 통계로, 어떤 명령어가 많이 실행됐는지 볼 수 있다.

# Commandstats 예시
cmdstat_del:calls=2404560,usec=7705505,usec_per_call=3.20,rejected_calls=0,failed_calls=0
cmdstat_get:calls=2339318,usec=7334684,usec_per_call=3.14,rejected_calls=0,failed_calls=0
cmdstat_config|get:calls=2659346,usec=16424915,usec_per_call=6.18,rejected_calls=0,failed_calls=0
cmdstat_config|set:calls=61,usec=222,usec_per_call=3.64,rejected_calls=0,failed_calls=0
cmdstat_slowlog|len:calls=1204539,usec=1586323,usec_per_call=1.32,rejected_calls=0,failed_calls=0

항상 그런건 아니지만… [ 메모리 피크 추적해볼 수 있는 케이스 ]

• 대량 MSET/LPUSH
• 큰 키 조회
  • 🔖 keys/smembers 대신 scan으로 조회한다.
    • keys: O(N) 블로킹 생길 수 있음
    • smembers: Set이 크면 전체 멤버를 메모리에 로드하게 됨
• Lua 스크립트로 큰 테이블 생성
• 클라이언트 연결 문제

 

maxmemory 관련 지표

---

• maxmemory: Redis가 사용할 수 있는 최대 메모리 한도. 이 값을 넘어가면 policy에 따라 동작한다.
  • ElastiCache에서는 이 값이 노드 타입에 따라 자동 적용된다.
    • 참고 문서

파란색 밑줄 그은 부분

• maxmemory_policy: 메모리가 max에 도달했을 때 어떻게 처리할지 결정하는 정책
  • 요 정책은 동작 구조랑 트리거 방식을 잘 알고있어야 함...! 따로 빼서 블로그로 정리해볼 예정이다.

정책	설명
volatile-lru	TTL이 설정된 키 중 가장 오래 사용 안 된 키 삭제
volatile-ttl	TTL이 가장 짧은 키 삭제
volatile-random	TTL이 설정된 키 중 랜덤 삭제
allkeys-lru	모든 키 중 가장 오래 사용 안 된 키 삭제
allkeys-random	모든 키 중 랜덤 삭제
noeviction	삭제 안 함, 쓰기 명령 에러 반환

 

 

fragmentation (메모리 단편화)

---

 

fragmentation_ratio = used_memory_rss / used_memory

• 1.0 ~ 1.5 : 정상
• > 1.5: 단편화 발생
• < 1.0 스왑 사용중(성능 저하 위험)

현재는 OS가 할당한 메모리가 Redis 실제 사용량의 2배 이상이라는 뜻.. 작은 키가 많이 삭제되었거나 데이터 크기 변동이 클 때 발생한다.

 

 

(일단 여기까지)