운영 Redis에서 큰 키를 찾고 삭제하려는데 다른 요청이 멈출까 걱정됩니다. KEYS와 큰 키 삭제는 왜 지연을 만들며 어떻게 나눠 조사하고 정리하나요?

Redis의 주 명령 실행 경로는 한 번에 한 명령을 처리하므로, 전체 키를 한 번에 찾거나 큰 자료구조를 반환·삭제하는 명령은 다른 클라이언트의 짧은 명령까지 기다리게 할 수 있습니다. KEYS는 패턴에 맞는 전체 키를 한 번에 순회해 실행 시간과 응답 크기를 만들고, 큰 hash·list·set의 조회와 삭제는 자료구조 순회·직렬화·메모리 해제 비용을 만듭니다. 출력 버퍼가 커지면 네트워크와 client buffer도 압박받습니다. 이 운영 문제를 대형 키 관리로 다룹니다.

조사를 작은 단위로 나눕니다

운영 전체를 KEYS *로 잠그지 않고 SCAN 커서를 저장해 작은 배치로 반복합니다. COUNT는 다음 호출에서 얼마나 시도할지에 대한 힌트일 뿐 정확한 반환 개수나 일관된 스냅샷을 보장하지 않습니다. 순회 중 키가 추가·삭제되면 누락·중복 가능성이 있으므로 정리 작업은 같은 키를 여러 번 만나도 안전하게 만들고, 패턴·자료형·테넌트 소유권·현재 버전을 다시 확인한 뒤 삭제합니다. 큰 키를 찾는 것과 내용을 전부 읽어 크기를 계산하는 것은 별도의 비용이므로 MEMORY USAGE, 샘플링과 명령별 지표를 목적에 맞게 사용하겠습니다.

UNLINK는 객체 해제 작업의 일부를 lazy free 경로로 넘겨 주 실행 경로의 지연을 줄일 수 있습니다. 하지만 명령 응답 직후 메모리가 모두 OS로 돌아오거나 RSS가 즉시 내려간다는 뜻은 아닙니다. 큰 키는 삭제뿐 아니라 복제, RDB fork의 copy-on-write, AOF rewrite와 네트워크 응답에도 부담을 줍니다. 장기 해결은 사용자·시간·버킷 단위로 자료구조를 나누고 TTL·소유권·원자 갱신 요구를 다시 설계하는 것입니다.

운영 예산 안에서 정리합니다

slowlog·latency monitor·명령별 호출·실행 시간·응답 bytes·pending client buffer·lazy free 대기·RSS와 정상 요청 p99를 같이 봅니다. 배치 사이에 정상 트래픽이 처리될 여유를 두고, 한 번에 삭제하는 개수와 rate를 제한합니다. 정리 전후에 duplicate scan, 재시작·복제·AOF/RDB 작업, 캐시 미스와 사용자 오류를 비교합니다. SCAN으로 바꾸는 것만으로 안전해지는 것이 아니라 조사·검증·삭제 작업 전체를 작은 단위와 중단 가능한 상태 머신으로 만드는 것이 핵심입니다.

SCAN은 전체 순회를 커서로 나누며, 순회가 시작될 때부터 끝날 때까지 계속 존재한 키는 반환하도록 설계되지만 순회 중 추가·삭제·갱신된 키의 반환과 중복은 일관된 스냅샷으로 보장되지 않습니다. 서버가 재시작되면 이전 opaque cursor로 정확한 재개를 기대할 수 없으므로 0부터 멱등적으로 재순회해야 합니다. 정리 작업은 같은 키를 여러 번 만나도 안전해야 합니다.

발견한 키를 바로 무조건 삭제하지 않고 타입·소유권·TTL·버전을 확인한 뒤 조건부 삭제를 실제 삭제와 원자적으로 묶겠습니다. UNLINK는 해제 일부를 lazy free로 넘길 뿐 RSS나 fork copy-on-write·복제·AOF 비용을 즉시 없애지 않습니다. 노드별 SCAN과 작은 rate 제한을 사용하고, 재시작·중단 후 재개, 정상 요청 p99와 lazy free 대기를 함께 검증하겠습니다.

SCAN은 전체 순회 시작부터 끝까지 계속 존재한 키는 반환하지만, 순회 중 추가·삭제·갱신된 키에 대해서는 스냅샷 일관성을 보장하지 않습니다. 재시작 후 이전 opaque cursor의 정확한 재개도 기대하지 않고 0부터 멱등적으로 다시 순회합니다. 조건 검사와 삭제는 원자적 조건부 연산으로 묶겠습니다.