백엔드
Memory DB는 무엇으로 가득 차 있었을까 - 2부 : BCAST 전환과 Failover
두줄요약
유령 키로 누적되는 MemoryDB OPTIN tracking item 문제를 BCAST 전환으로 구조적으로 차단했습니다.\n리허설 후 failover를 두 차례 수행해 7,684만 개 항목과 메모리 사용률을 정상화했습니다.
문제 상황
- 실제 데이터 165MB와 달리 MemoryDB 메모리 사용률 85%, tracking item 7,684만 개 누적
- 존재하지 않는 유령 키 조회 후 쓰기 없는 경우 tracking item이 회수되지 않는 OPTIN 구조
구조와 흐름
- OPTIN의 키×클라이언트 단위 기록과 lazy 회수, BCAST의 prefix×클라이언트 단위 등록과 연결 종료 즉시 회수
- BCAST의 양방향 prefix 색인과 beforeSleep 시점 무효화 메시지 일괄 전송
- 키별 캐시 보유 여부 판단 책임을 서버에서 클라이언트로 이전
해결 방법
- rueidis 버전 업데이트 후 고정 prefix 5개를 BCAST로 등록하고 prefix 커버리지 대조 테스트 추가
- 기존 tracking item 제거를 위해 리허설 뒤 프로덕션 failover 2회 수행
성능/운영 포인트
- 3,000키 배치 갱신 시 네트워크 1~3Mbps 증가, 엔진 CPU 피크 17% 이하 확인
- failover 후 tracking item 0, 양 노드 메모리 사용률 약 4%, 4주간 재누적 없음
- BCAST 적용 시 쓰기 빈도, prefix 범위·중복, 연결별 실제 구독 범위, 라이브러리 지원 점검 필요
