DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

Redis 메모리 누수 및 급증 문제 해결을 위한 4가지 필수 전략

메모리 누수와 갑작스러운 급증은 Redis 성능을 저하시킬 수 있습니다. 이 전문 가이드는 메모리 소비를 사전에 관리하고 문제를 해결하기 위한 4가지 필수 전략을 제공합니다. `INFO` 및 `MEMORY USAGE` 명령어를 활용한 심층 진단, 효과적인 `maxmemory` 제거 정책 구현, 예상치 못한 성장을 유발하는 대규모 키 식별 및 정리, 그리고 능동적 조각 모음을 통한 시스템 수준 단편화 문제 해결 방법을 알아보세요. 이러한 검증된 실행 가능한 기술을 통해 캐시 성능을 안정화하고 인메모리 데이터 저장소의 안정성을 보장하세요.

Redis 메모리 누수 및 급증 문제 해결을 위한 4가지 필수 전략

Redis는 인메모리 데이터 저장소이므로 메모리 문제가 빠르게 나타납니다. TTL 처리의 작은 실수, 하나의 과도하게 큰 리스트, 또는 여유 RAM이 없는 호스트에서의 백그라운드 저장은 지연 시간, 쓰기 오류, 제거, 스와핑, 또는 운영 체제에 의해 Redis 프로세스가 종료되는 결과로 이어질 수 있습니다.

첫 번째 유용한 습관은 모든 메모리 증가를 누수라고 부르지 않는 것입니다. 실제 Redis 누수는 드뭅니다. 대부분의 사고는 실제 데이터 증가, 할당기 단편화, 또는 지속성 중 일시적인 쓰기 중 복사 오버헤드 중 하나입니다. 대시보드에서는 비슷해 보이지만 해결 방법은 완전히 다릅니다.

used_memory가 계속 증가한다면 애플리케이션이 예상보다 더 많은 데이터를 저장하고 있을 가능성이 높습니다. used_memory는 안정적이지만 used_memory_rss가 급증한다면 단편화, 포크된 백그라운드 작업 또는 운영 체제를 살펴보세요. 트래픽 급증 중에 둘 다 증가한 후 절대 떨어지지 않는다면 TTL, 제거 정책 및 큰 키를 확인하세요.

전략 1: 사용량 및 단편화 메트릭의 상세 모니터링

메모리 문제를 진단하는 첫 번째 단계는 기준을 설정하고 Redis가 메모리 사용량을 어떻게 보고하는지 이해하는 것입니다. 표준 INFO memory 명령은 데이터가 사용하는 메모리와 운영 체제가 사용하는 메모리를 구분하는 필수 메트릭을 제공합니다.

진단을 위한 주요 메트릭

급증이 발생하면 INFO memory에서 다음 메트릭을 즉시 확인하세요.

  1. used_memory: Redis가 데이터 및 내부 구조에 할당한 메모리입니다.
  2. used_memory_dataset: 일부 오버헤드를 제외한 실제 데이터 세트가 사용하는 메모리입니다.
  3. used_memory_rss: 운영 체제가 Redis 프로세스에 할당한 상주 메모리입니다.
  4. mem_fragmentation_ratio: RSS와 할당된 메모리의 대략적인 비교입니다. 확정적인 판단이 아닌 단서로 취급하세요.
# 기본 메모리 통계 확인
redis-cli INFO memory

# 샘플 출력 일부
# used_memory:1073741824 			# 1 GB 데이터
# used_memory_rss:1509949440 		# ~1.5 GB RAM
# mem_fragmentation_ratio:1.40625 	# RSS가 used_memory보다 약 40% 높음

단편화 비율 해석

1.0에 가까운 비율은 일반적으로 건강합니다. 1.5 이상의 비율은 특히 RSS가 호스트에 위협이 될 만큼 높은 경우 조사할 가치가 있습니다. 1.0 미만의 비율이 자동으로 스와핑을 증명하지는 않습니다. 측정 예외 사례, 공유 메모리 계정 또는 매우 작은 데이터 세트 때문에 발생할 수 있습니다. vmstat, top, sar 또는 모니터링 시스템을 사용하여 OS 스왑 메트릭을 직접 확인하세요.

used_memory는 일정하지만 BGSAVE 또는 BGREWRITEAOF 중에 RSS가 급증한다면 쓰기 중 복사가 원인일 가능성이 높습니다. 자식 프로세스가 지속성 파일을 쓰는 동안 부모는 쓰기 처리를 계속합니다. 부모에 의해 변경된 페이지는 복사되어야 하므로 일시적으로 메모리 압력이 증가합니다.

전략 2: 강력한 제거 정책 구현

무제한 성장은 Redis에서 인지된 메모리 "누수"의 가장 빈번한 원인입니다. 인스턴스가 캐시로 사용되는 경우 maxmemory 지시문에 의해 시행되는 정의된 메모리 사용량 상한선이 반드시 있어야 합니다.

maxmemory가 설정되지 않으면 Redis는 호스트에 압력이 가해질 때까지 계속 메모리를 할당할 수 있습니다. 전용 Redis 박스에서는 커널이 Redis를 종료하는 것으로 끝날 수 있습니다. 컨테이너에서는 컨테이너 런타임이 더 일찍 종료할 수 있습니다.

maxmemory 설정 및 정책 선택

redis.conf 또는 CONFIG SET을 사용하여 최대 메모리 제한을 지정하세요.

# 최대 메모리를 4GB로 설정합니다. Redis 오버헤드, 포크된 자식,
# OS 페이지 캐시 및 기타 프로세스를 위한 여유 공간을 남겨둡니다.
CONFIG SET maxmemory 4gb

# 제거 정책 구성
# allkeys-lru: 전체 데이터 세트에서 가장 최근에 사용되지 않은 키를 제거합니다.
CONFIG SET maxmemory-policy allkeys-lru
정책 이름 설명 사용 사례
noeviction 기본값. 메모리 제한에 도달하면 쓰기 명령에 오류를 반환합니다. 데이터 손실이 허용되지 않는 데이터베이스.
allkeys-lru 만료 여부와 관계없이 가장 최근에 사용되지 않은 키를 제거합니다. 범용 캐싱.
volatile-lru 만료가 설정된 키 중에서만 가장 최근에 사용되지 않은 키를 제거합니다. 혼합 사용 사례 (유지된 데이터 + 캐시 데이터).
allkeys-random 제한에 도달하면 무작위 키를 제거합니다. 간단한 세션 저장소 또는 액세스 패턴을 예측할 수 없는 경우.

순수 캐시의 경우 allkeys-lru 또는 allkeys-lfu가 합리적인 시작점인 경우가 많습니다. 일부 키만 폐기 가능한 혼합 Redis 인스턴스의 경우 volatile-lru 또는 다른 volatile-* 정책이 더 안전할 수 있지만 모든 캐시 키에 만료가 있는 경우에만 해당됩니다. 위험한 설정은 noeviction, TTL 규율 부재, 메모리가 가득 차기 전에 알림이 없는 캐시입니다.

전략 3: 대규모 키 급증 진단 및 정리

때로는 문제가 키의 수가 아닙니다. 경계 없이 성장한 하나의 키입니다: 트리밍되지 않는 사용자 피드 리스트, 지금까지 본 모든 이벤트의 정렬된 집합, 또는 세션 필드의 덤핑 그라운드로 사용되는 해시.

redis-cli --bigkeys 사용

redis-cli --bigkeys 유틸리티는 키 공간을 스캔하고 유형 및 요소 수별로 큰 키를 보고합니다. 정확한 바이트 크기를 측정하지 않으며 사용 중인 프로덕션 인스턴스에 부하를 추가할 수 있으므로 가능하면 복제본에 대해 신중하게 실행하세요.

# bigkeys 분석 실행
redis-cli --bigkeys

# 샘플 출력 (대규모 리스트 식별)
---------- 요약 ----------
...
[5] 'user:1001:feed'에서 859387개 항목으로 가장 큰 리스트 발견

MEMORY USAGE 사용 (Redis 4.0+)

의심스러운 키의 정확한 크기를 바이트 단위로 확인하려면 MEMORY USAGE 명령을 사용하세요. 이는 심층 진단에 필수적입니다.

# 특정 키의 메모리 사용량 확인 (바이트 단위)
redis-cli MEMORY USAGE user:1001:feed

# 출력: (예) 84329014

큰 키를 식별한 경우 쓰기 경로를 검토하세요. 일반적인 수정 사항은 LTRIM으로 리스트 트리밍, 임시 구조 만료, 매우 큰 해시 또는 정렬된 집합을 더 작은 키 파티션으로 분할, HSCAN, SSCAN 또는 ZSCAN과 같은 페이지 액세스로 "모든 것 로드" 읽기 대체입니다. 실제 수정은 일반적으로 Redis 설정이 아닌 애플리케이션 동작에 있습니다.

전략 4: 메모리 단편화 및 쓰기 중 복사 관리

높은 단편화 또는 갑작스러운 RSS 급증은 종종 데이터 누수로 오인됩니다. 이러한 문제는 메모리 할당, 객체 변동 및 포크 기반 지속성과 관련이 있습니다.

능동적 조각 모음

능동적 조각 모음은 서버가 계속 실행되는 동안 Redis가 낭비된 할당기 공간을 회수하는 데 도움이 될 수 있습니다. 다양한 크기의 값을 많이 생성하고 삭제하는 워크로드에 유용합니다. 또한 CPU를 사용하므로 의도적으로 활성화하고 변경 후 지연 시간을 모니터링하세요.

redis.conf에서 활성화 및 구성:

# 능동적 조각 모음 활성화
activedefrag yes

# 하한 및 상한 임계값은 백분율 스타일 구성 값입니다.
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100

쓰기 중 복사 오버헤드 감소

Redis가 RDB 스냅샷 또는 AOF 재작성을 위해 자식 프로세스를 포크하면 OS는 CoW 최적화를 사용합니다. 자식 프로세스가 활성화된 동안 부모 프로세스가 많은 쓰기를 수행하면 기록된 모든 페이지를 복제해야 하므로 used_memory_rss가 일시적으로 급증합니다. 이 급증은 Redis 메모리 사용량을 쉽게 두 배로 늘릴 수 있습니다.

완화 단계:

  1. 트래픽이 적은 시간에 지속성을 예약하세요.
  2. 할당기 오버헤드, 클라이언트, 복제 버퍼 및 포크된 자식을 위해 maxmemory 위에 메모리 여유 공간을 남겨두세요. 적절한 여유 공간은 데이터 세트 크기와 쓰기 속도에 따라 다릅니다. 실제 BGSAVE 또는 BGREWRITEAOF 중에 측정하세요.
  3. 스냅샷, AOF 재작성, 백업 및 호스트 수준 스캔과 같은 무거운 백그라운드 작업이 겹치지 않도록 하세요.
  4. 배치 작업이 쓰기 중 복사 성장을 유발하는 경우 지속성 중 쓰기 변동을 줄이세요.

첫 번째 대응으로 할당기 환경 변수를 사용하지 마세요. Redis는 일반적으로 jemalloc으로 빌드되며, 테스트 없이 할당기 동작을 변경하면 새로운 지연 시간이나 메모리 동작이 발생할 수 있습니다. 능동적 조각 모음 및 워크로드 수정 후에도 단편화가 심각하게 남아 있으면 프로덕션을 건드리기 전에 스테이징 인스턴스 또는 복제본에서 변경 사항을 테스트하세요.

실용적인 사고 처리 흐름

메모리가 급증하면 Redis를 다시 시작하기 전에 사실을 수집하세요. 다시 시작하면 증거가 숨겨질 수 있습니다.

실행:

redis-cli INFO memory
redis-cli INFO persistence
redis-cli DBSIZE
redis-cli --bigkeys

그런 다음 무엇이 변경되었는지 질문하세요. 배포로 인해 TTL이 제거되었나요? 큐 소비자가 중지되어 리스트가 증가했나요? 새로운 보고 작업이 거대한 해시에 대해 HGETALL을 실행했나요? 트래픽 최고점 동안 AOF 재작성이 시작되었나요? 컨테이너 메모리 제한이 변경되었나요?

최고의 Redis 메모리 수정은 일반적으로 간단합니다: 현실적인 maxmemory 설정, 워크로드와 일치하는 제거 정책 선택, 모든 캐시 키에 TTL 부여, 무제한 구조 분할, 메모리 여유 공간 없이 지속성이 실행되지 않도록 하고, 인스턴스가 한계에 도달하기 전에 메모리 추세에 대한 알림 설정입니다.