Redis 8.10: Compact Hashes로 스키마 공유 메모리를 줄이고 gRPC 제어면·AOF 백업을 더한 방법

왜 Compact Hashes인가

Redis에서 해시(Hash)를 수백만 개 저장할 때 가장 흔한 패턴이 있다. 사용자 세션, 상품 정보, 이벤트 레코드처럼 동일한 필드 구조를 가진 키가 대량으로 존재하는 경우다.

HSET user:1001  name "Alice"  age 30  tier "gold"
HSET user:1002  name "Bob"    age 25  tier "silver"
HSET user:1003  name "Carol"  age 28  tier "gold"

기존 해시 인코딩에서는 name, age, tier라는 필드 이름이 키마다 독립적으로 저장된다. 키가 100만 개라면 필드 이름이 100만 번 복제된다. 필드 이름이 짧아도 포인터와 메타데이터가 따라붙기 때문에, 실제 값보다 구조 유지 비용이 더 클 수 있다.

Redis 8.10(2026년 7월)이 도입한 Compact Hashes는 이 문제를 정면으로 해결한다.

Compact Hashes 작동 방식

Compact Hashes는 동일한 필드 집합을 공유하는 해시 키들이 하나의 스키마 템플릿을 참조하도록 저장 구조를 바꾼다.

내부적으로는 필드 이름 배열을 별도의 스키마 오브젝트에 한 번만 저장하고, 각 해시 키는 값 배열과 스키마를 가리키는 포인터만 유지한다. 키가 100만 개여도 필드 이름은 딱 한 번 저장된다.

Compact Hashes는 기존 해시 API와 완전히 호환된다. HSET, HGET, HGETALL을 그대로 쓰면 된다. 스키마 공유는 Redis가 내부적으로 처리한다.

Compact Hashes를 활성화하는 시점

모든 해시에 Compact Hashes가 적합하지는 않다. 스키마가 공유되려면 키들이 동일한 필드 집합을 가져야 한다. 필드 구조가 키마다 다르면 스키마 공유 효과가 없다.

좋은 적용 대상:

• 사용자 프로필 (user:{id} → name, age, plan, created_at)
• 세션 데이터 (session:{token} → user_id, expire, role)
• 상품 메타데이터 (product:{sku} → name, price, stock)

적합하지 않은 대상:

• 필드가 동적으로 추가되는 비정형 해시
• 키마다 필드 구성이 크게 다른 경우

HIMPORT: Compact Hash 대량 적재

Compact Hashes를 대량으로 채울 때는 HIMPORT 명령이 유효하다. 개별 HSET 호출보다 처리량이 높으며, 스키마를 한 번에 확정하고 값만 연속으로 주입하는 방식이다.

HIMPORT user-schema name age tier
  1001 Alice 30 gold
  1002 Bob   25 silver
  1003 Carol 28 gold

(위는 개념 표기 — 실제 명령 구문은 릴리스 문서를 참고)

대량 마이그레이션이나 초기 적재 시나리오에서 파이프라이닝과 함께 쓰면 효과가 크다.

기타 새 명령

LMOVEM · BLMOVEM: 리스트 간 다중 요소 이동. 기존 LMOVE는 한 번에 하나의 요소만 이동한다. LMOVEM은 여러 요소를 한 번에 이동해 작업 큐 패턴에서 라운드트립을 줄인다.

SUNIONCARD · SDIFFCARD: 집합 합집합·차집합의 원소 개수만 반환한다. 실제 결과 집합을 메모리에 만들지 않으므로, 교집합이나 차집합의 규모를 먼저 파악한 뒤 처리 여부를 결정하는 패턴에 유용하다.

XREAD · XREADGROUP MAXCOUNT · MAXSIZE: 스트림 소비 시 응답의 최대 항목 수와 최대 바이트 크기를 동시에 제한할 수 있다. 클라이언트 측 버퍼 오버플로 방지와 네트워크 대역폭 제어에 쓴다.

TLS 피어 인증

클러스터 내 노드 간 통신 보안이 강화됐다. 8.10은 TLS 피어 인증서 기반 서버-서버 인증을 지원한다. 기존에는 공유 암호(password) 기반으로 노드 간 신뢰를 확인했다면, 이제는 각 노드가 인증서를 제시하고 상대방이 이를 검증한다.

운영 관점에서는 인증서 갱신 주기를 고려해야 한다. 노드 인증서를 교체할 때 롤링 방식으로 재시작하지 않으면 피어 인증 실패가 발생한다. Let's Encrypt처럼 단기(90일) 인증서를 쓰는 환경이라면 자동 갱신과 인증서 핫 리로드 절차를 미리 구성해야 한다.

BACKUP: 노드 사이드 백업

BACKUP 명령은 노드가 직접 다중 파트 AOF 스냅샷을 생성한다. 기존 BGSAVE(RDB)나 외부 도구 의존 방식과 달리, AOF 기반이므로 특정 시점까지의 연속성이 보장된다.

BACKUP START
BACKUP STATUS
BACKUP STOP

복구 시에는 생성된 파트 파일들을 순서대로 재조합해 데이터를 복원한다. 클라우드 스토리지에 파트별로 업로드하는 파이프라인 구성이 수월해진다.

보안 패치: 8.10.1

8.10.1에서 버퍼 오버플로와 UAF(use-after-free) 취약점이 수정됐다. 영향받는 영역은 RDB 로딩, Vector Sets 연산, TLS 인증 처리다. 8.10.0을 운영 중이라면 즉시 8.10.1로 올려야 한다.

운영자 체크리스트

References

• https://raw.githubusercontent.com/redis/redis/8.10/00-RELEASENOTES
• https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisce/redisos-8.10-release-notes/
• https://releases.sh/redis
• https://mungomash.com/software/redis/versions/