963초짜리 쿼리 하나가 HLL 205만까지 끌어올렸습니다

문제 상황

• Aurora MySQL Writer DB에서 HLL(History List Length)이 205만까지 급증한 사건
• 원인은 격리 수준 자체보다 963초 동안 지속된 단일 쿼리로 인해 스냅샷 수명이 길어진 점
• HLL 알람은 있었지만 평소 범위와 원인 판단 기준이 없어 해석이 어려웠던 상황

원인 분석

• HLL은 커밋된 쓰기에서 생성된 undo log가 purge되지 못하고 쌓인 backlog 신호
• 오래 유지된 read view가 purge 경계를 막아 undo 정리를 지연시키는 구조
• Writer는 이미 Read Committed였지만, 긴 statement 하나가 read view를 오래 붙잡아 HLL이 상승

해결 방법

• 단일 SELECT DISTINCT를 기본 키 기준 1만 건 단위의 짧은 조회로 분할
• 청크 결과를 합치며 중복 제거하고, 실패 시 기존 경로로 우회하는 방식 적용
• 일부 사이트 카나리 검증 후 전체 적용으로 HLL 최고값과 장기 조회 재발을 억제

주의할 점

• Aurora Reader의 Read Committed와 ARRRC 조합은 일관성 약화와 결과 변동 가능성 동반
• HLL 감소만 보고 설정을 바꾸기보다 조회의 일관성 요구사항을 먼저 확인 필요
• HLL은 장애 확정 값이 아니라 backlog 크기이므로, 열린 트랜잭션과 장기 쿼리를 함께 봐야 함