Redis 키 (타입별 데이터 조회, KEYS, SCAN 비교)

이번 글에서는 Redis의 다양한 데이터 타입을 알아보고, 각 타입에 맞는 값을 손쉽게 조회하는 방법을 알아보겠습니다.

1.  타입(TYPE) 확인하기 

값을 조회하기 전에 가장 먼저 할 일은 해당 키가 어떤 데이터 타입으로 저장되어 있는지 확인하는 것입니다. 이때 TYPE 명령어를 사용합니다.

# 'weather:active:regions'라는 키의 타입을 확인
127.0.0.1:6379[1]> TYPE weather:active:regions
zset

TYPE 명령어는 다음과 같은 대표적인 타입을 반환합니다.

• string: 가장 기본적인 문자열. 간단한 텍스트부터 JSON 데이터까지 담을 수 있음
• hash: 여러 필드(field)와 값(value) 쌍으로 이루어진 객체
• list: 데이터가 입력된 순서를 기억하는 목록
• set: 순서 없이, 중복되지 않는 값들의 집합
• zset (Sorted Set): 점수(score)가 매겨져 정렬된 집합.

이제 각 타입이 무엇이고, 어떻게 조회하는지 알아보겠습니다.

2. 타입별 데이터 조회하기

2.1) String

가장 기본적이고 널리 쓰이는 타입입니다.

• 언제 사용할까?: 사용자 세션 정보, 캐시 된 웹페이지 HTML, 간단한 카운터 값 등을 저장할 때 유용합니다.
• 조회 명령어: GET

# "weather:forecast:..." 키에 저장된 값 조회
127.0.0.1:6379[1]> GET weather:forecast:2235:832:2000
"{\"temp\":25.3,\"icon\":\"sunny\",\"humidity\":40}"

2.2) Hash

하나의 키 안에 '이름: 서울', '위도: 37.56'처럼 여러 개의 필드-값 쌍을 저장하는 구조입니다. 한 사람의 명함 정보처럼 관련 데이터를 묶어두기에 좋습니다.

• 언제 사용할까?: 사용자의 프로필 정보(ID, 이름, 이메일 등)처럼 하나의 개념을 구성하는 여러 속성을 저장할 때 적합합니다.
• 조회 명령어: HGETALL (모든 필드/값), HGET (특정 필드)

# 모든 정보를 한 번에 조회
127.0.0.1:6379[1]> HGETALL weather:location:2235:832
1) "id"
2) "832"
3) "name"
4) "Seoul"
...

# 'name' 필드만 콕 집어 조회
127.0.0.1:6379[1]> HGET weather:location:2235:832 name
"Seoul"

2.3) List

데이터가 들어온 순서대로 저장되는 자료구조입니다. 타임라인이나 대기열처럼 순서가 중요할 때 사용합니다.

• 언제 사용할까?: 최신 뉴스 목록, 사용자의 최근 활동 기록, 채팅 메시지 큐 등을 구현할 때 유용합니다.
• 조회 명령어: LRANGE (범위를 지정하여 조회)

# 0번째부터 마지막(-1) 데이터까지 모두 조회
127.0.0.1:6379[1]> LRANGE weather:active:regions 0 -1
1) "us-east"
2) "us-west"
3) "eu-central"

2.4) Set

List와 비슷하지만 중복된 값을 허용하지 않는 고유한 값들의 집합입니다. 순서는 보장되지 않습니다.

• 언제 사용할까?: 특정 게시물에 '좋아요'를 누른 사용자 목록, 특정 태그를 가진 모든 상품 ID 등 유니크한 값들을 관리할 때 사용합니다.
• 조회 명령어: SMEMBERS (모든 멤버 조회)

127.0.0.1:6379[1]> SMEMBERS weather:alert:types
1) "storm"
2) "flood"
3) "heatwave"

2.5) Sorted Set (ZSet)

Set처럼 중복되지 않는 값을 저장하지만, 각 값마다 점수(score)를 부여하여 점수 기준으로 정렬할 수 있는 특별한 타입입니다.

• 언제 사용할까?: 게임 랭킹, 실시간 인기 검색어 순위, 우선순위가 있는 작업 목록 등 순위 매기기가 필요할 때 최적의 선택입니다.
• 조회 명령어: ZRANGE (점수 기준 오름차순), ZREVRANGE (내림차순)

# 랭킹 0위부터 끝까지 점수와 함께 조회 (오름차순)
127.0.0.1:6379[1]> ZRANGE weather:temperature:ranking 0 -1 WITHSCORES
1) "seoul"
2) "15.5"
3) "busan"
4) "18.2"

3.  유용한 추가 명령어

데이터를 조회하는 것 외에도 키의 상태를 확인하는 유용한 명령어들이 있습니다.

• 키가 존재하는지 확인: EXISTS [key]
  • 1을 반환하면 존재, 0이면 존재하지 않음
• 키의 남은 수명(초) 확인: TTL [key]
  • 3600 처럼 남은 시간이 반환되거나, -1 (영구), -2 (존재하지 않음)가 반환
• 키가 사용하는 메모리 용량 확인: MEMORY USAGE [key]
  • 바이트(byte) 단위로 메모리 사용량 제공

4. 주의점

데이터베이스의 모든 키를 탐색하는 KEYS weather:* 명령어는 운영 중인 Redis 서버에서 사용에 주의가 필요합니다. 키가 수백만 개 이상일 경우, KEYS 명령어 하나가 서버 전체를 몇 초간 멈추게 할 수 있습니다.

대신, 서버에 부하를 주지 않고 안전하게 키를 탐색하는 SCAN 명령어를 사용하는 것이 권장됩니다.

# 커서를 0부터 시작해서 'weather:*' 패턴의 키를 10개씩 점진적으로 탐색
127.0.0.1:6379[1]> SCAN 0 MATCH weather:* COUNT 10

 

KEYS의 Blocking 방식

KEYS 명령어의 성능 저하 문제는 Redis의 단일 스레드(Single-Thread) 실행 모델에 기인합니다. Redis는 대부분의 명령어를 단일 스레드 상에서 순차적으로 처리하므로, 한 번에 하나의 작업만 수행할 수 있습니다.

 

KEYS 명령어는 대표적인 블로킹(Blocking) 연산으로, 다음과 같은 과정을 단 한 번의 작업으로 수행합니다.

1. 전체 키스페이스(Keyspace) 순회: Redis는 데이터베이스에 존재하는 모든 키를 순회하기 시작합니다. 데이터셋의 크기가 클수록 이 과정의 시간 복잡도는 O(N)으로 선형 증가합니다.
2. 패턴 매칭: 순회하는 각 키에 대해 주어진 패턴과의 일치 여부를 검사합니다.
3. 결과 집합 구성: 일치하는 키들을 메모리 내의 결과 집합에 추가합니다.
4. 결과 반환: 전체 키스페이스 순회가 완료된 후에야 구성된 결과 집합을 클라이언트에게 반환합니다.

이 모든 과정이 완료될 때까지 해당 스레드가 다른 어떤 작업도 처리하지 못하고 완전히 점유됩니다. 만약 수백만 개의 키를 순회하는 데 수 초가 소요된다면, 그 시간 동안 Redis 인스턴스는 다른 모든 클라이언트의 요청을 처리하지 못하는 응답 불가능(unresponsive) 상태가 됩니다. 이는 서비스 전체의 지연 시간(Latency) 급증으로 이어집니다.

---

SCAN의 Non-Blocking 방식

SCAN은 이러한 블로킹 문제를 해결하기 위해 점진적 순회 방식을 채택했습니다. 이는 장시간 소요될 수 있는 작업을 여러 개의 짧은 단계로 분할하여 실행하는 Non-Blocking 연산입니다.

SCAN은 커서(cursor) 기반의 메커니즘을 사용합니다.

1. 순회 시작: 클라이언트는 SCAN 0 MATCH... 와 같이 커서 값을 0으로 설정하여 순회를 시작합니다.
2. 제한된 순회 및 응답: Redis는 내부적으로 정해진 양의 작업만 수행하여 일부 키를 스캔하고, 해당 스캔에서 발견된 결과와 함께 다음 순회를 시작할 지점인 새로운 커서 값을 반환합니다. 이 연산은 매우 짧은 시간 안에 완료됩니다.
3. 다른 요청 처리: 다음 SCAN 요청이 들어오기 전까지, Redis 스레드는 다른 클라이언트의 요청을 처리할 수 있는 여유를 갖게 됩니다. 따라서 서버는 지속적으로 응답 가능한 상태를 유지합니다.
4. 순회 재개: 클라이언트는 이전 단계에서 반환된 새로운 커서 값을 사용하여 SCAN 명령을 다시 전송함으로써 순회를 이어갑니다.
5. 순회 완료: Redis가 다시 0번 커서를 반환하면, 전체 키스페이스 순회가 완료되었음을 의미합니다.

SCAN은 전체 순회를 완료하기까지의 총 실행 시간은 더 길 수 있으나, 각 단계를 짧게 나누어 실행함으로써 서버 전체의 운영에 영향을 미치는 블로킹 현상을 방지하고 안정적인 서비스 운영을 보장합니다.

 

 

따라서, 운영 환경에서 서비스의 가용성과 안정성을 보장하기 위해서는 KEYS 대신 SCAN을 사용이 권장됩니다.