Key Management

2024. 9. 28. - Last update: 2026. 4. 25.

Redis에서 키(Key)는 모든 데이터에 접근하기 위한 유일한 문자열 식별자로, 데이터를 저장, 조회, 삭제하는 모든 명령어의 기본 단위로 사용된다.

키 이름 규칙

정해진 규칙은 없으나, 실무에서는 일관된 규칙을 정해 관리하여 키의 가독성을 높이고, 데이터 구조를 직관적으로 파악하며, 키 충돌을 방지하는 데 도움이 될 수 있도록 해야 한다.

표기법: 일반적으로 객체타입:ID:속성 형태의 구조를 사용(user:1001:profile)
장점:
- 명확성: user:1001과 같이 키 이름만으로 어떤 데이터를 담고 있는지 쉽게 유추 가능
- 그룹화: user:*와 같은 패턴으로 특정 타입의 모든 키를 논리적으로 그룹화하고 SCAN 명령어로 조회 가능

Redis의 키는 별도의 생성 명령어 없이, 값을 저장하는 시점에 자동으로 생성된다.

SET mykey "value"  # mykey가 없으면 생성
SET mykey "new_value"  # mykey가 있으면 값 업데이트
LPUSH mykey "1" "2"  # 에러 발생

리스트의 경우 들어간 아이템이 모두 삭제 되면 해당 키도 자동으로 삭제된다.

LPUSH mylist "1" "2" "3"
LPOP mylist
LPOP mylist
LPOP mylist  # mylist 키 삭제

명령어	기능	예시
`SET`	키와 값 설정	`SET mykey "value"`
`GET`	키의 값 조회	`GET mykey`
`EXISTS`	키가 존재하는지 확인	`EXISTS mykey`
`KEYS`	특정 패턴에 맞는 키 목록 조회	`KEYS user:*`
`SCAN`	키 목록을 순회하며 조회	`SCAN 0`
`SORT`	list, set, sorted set 데이터를 정렬하여 반환	`SORT mylist`
`RENAME`	키 이름 변경	`RENAME mykey newkey`
`COPY`	키 복사	`COPY mykey newkey`
`TYPE`	키의 데이터 타입 조회	`TYPE mykey`
`OBJECT`	키의 인코딩, 참조 카운트, 유휴 시간, 접근 빈도 등 내부 정보 조회(서브커맨드 필수)	`OBJECT ENCODING mykey`
`FLUSHALL`	레디스에 저장된 모든 키 삭제	`FLUSHALL`
`DEL`	키 삭제(동기 방식으로 동작)	`DEL mykey`
`UNLINK`	키 삭제(백그라운드에서 삭제 작업을 수행하여 비동기 방식으로 처리하여 블로킹 방지)	`UNLINK mykey`
`EXPIRE`	키의 TTL(만료 시간) 설정	`EXPIRE mykey 60`
`TTL`	남은 TTL 시간 조회	`TTL mykey`
`PERSIST`	TTL을 제거하고 키를 영구적으로 유지	`PERSIST mykey`

두 명령어 모두 특정 패턴에 맞는 키를 조회하는데 사용되지만, 안정성과 성능 면에서 차이가 있다.

KEYS: 전체 키 공간을 한 번에 탐색하여 키를 반환
- 시간 복잡도 O(N)이며 싱글 스레드가 순회를 완료할 때까지 이벤트 루프 전체가 블로킹 → 프로덕션에서 사용 금지
SCAN: 커서를 기반으로 키 공간을 여러 번에 나눠 순회
- 한 번의 호출은 O(1)에 가까운 짧은 시간만 블로킹하고, 클라이언트가 커서를 이어가며 완주
- 전체 완료는 O(N)이지만 여러 커서 호출로 분산되므로 다른 명령 처리를 거의 방해하지 않음

삭제 결과는 동일하지만 메모리 회수 타이밍이 다르다.

DEL: 메인 스레드에서 키와 값을 즉시 해제
- 작은 키(String 1개 등)에서는 문제없음
- 원소가 수십만~수백만 개인 거대한 자료구조(Hash, Set, Sorted Set 등)를 삭제하면 모든 원소의 메모리 해제 비용이 메인 스레드에 집중되어 수백 ms 블로킹이 발생 가능
UNLINK: 키 공간에서 키를 즉시 분리(unlink)해 이후 접근에서 보이지 않게 하고, 실제 메모리 회수는 백그라운드 lazyfree 스레드가 수행
- 클라이언트 응답은 빠르게 반환되고, 메인 스레드는 이벤트 루프를 이어감
- 대용량 키·컬렉션을 다룰 때 권장하는 방식

Redis