백엔드
Memory DB는 무엇으로 가득 차 있었을까 - 1부 : 클라이언트 캐싱과 tracking item
두줄요약
MemoryDB 메모리 급증의 원인을 Redis 클라이언트 캐싱 tracking item 누적으로 분석했습니다. 존재하지 않는 유령 키 조회가 TTL 없이 기록을 쌓는 구조를 확인했습니다.
문제 상황
- AWS MemoryDB Primary 메모리 사용률 85%, 여유 공간 500MB 미만
- Primary 2.63GB와 Replica 0.96GB의 비대칭 메모리 사용량
원인 분석
- 실데이터 165MB와 달리 Primary에 8B·24B 객체 약 2GB 누적
tracking_total_items와 객체 수의 일치로 클라이언트 캐싱 Tracking Table 식별- 연결 종료 후에도 tracking item을 지연 삭제하는 Redis 설계와 빈 키 조회의 결합
구조와 흐름
- 클라이언트 캐싱 시
(키 × 연결)단위 tracking item을 Radix Tree에 기록 - 키 변경·삭제·TTL 만료 시 해당 키의 tracking item 회수 및 무효화 전송
- 존재하지 않는 키도 캐싱 무효화 대상이므로 Tracking Table 기록 대상
주의할 점
- TTL이 있는 키라도 존재하지 않는 유령 키 조회 기록은 만료 이벤트 부재로 지속 누적
w:KR-유령 키 강제 무효화로 수십만 tracking item과 약 18MB 회수 확인- 읽기 대상 Replica 전환 후 tracking item 누적 위치만 Primary에서 Replica로 이동
