Valkey 9.1, 메모리 10% 줄이고 검색 기능을 코어로 끌어들임

Valkey 9.1의 핵심은 “더 적은 돈으로 더 많이 버티기”임

• Valkey 9.1이 정식 출시됐고, 이번 릴리스의 메인 키워드는 효율성, 모듈성, 운영 도구임

  • Open Source Summit North America에서 AWS Principal Engineer이자 Valkey maintainer인 Madelyn Olson이 발표할 예정
  • Valkey Admin, Valkey Search, Valkey GLIDE 클라이언트 새 버전도 같이 나옴
  • Valkey는 Redis의 인기 있는 오픈소스 포크로, 빠르고 안정적인 데이터 접근을 인프라 비용 폭증 없이 제공하는 쪽을 노림

• 가장 눈에 띄는 숫자는 키당 메모리 사용량 최대 10% 절감임

  • 내부 데이터 저장·관리 레이아웃을 다시 손봐서 일반 워크로드에서 바로 효과가 난다고 함
  • 튜닝이나 설정 변경 없이 적용되는 개선이라 운영자 입장에서는 꽤 달달함
  • 클라우드 대규모 배포에서는 같은 워크로드를 더 작은 인스턴스나 더 적은 인스턴스로 돌릴 수 있다는 얘기임

• Olson은 이번 개선이 8.x나 9.0 때처럼 화려한 기능 폭발은 아니라고 봄
  • 이전 릴리스들은 Redis 쪽에서 풀지 못했던 기능들이 Valkey 엔진으로 밀려 들어온 시기였음
  • 9.1은 그보다 운영 효율과 예측 가능성에 더 초점을 둔 릴리스에 가까움

보안과 클러스터 운영도 꽤 현실적인 쪽으로 바뀜

• Valkey 9.1에는 데이터베이스 단위 ACL이 들어감

  • 단일 Valkey 인스턴스 안에서 여러 테넌트나 애플리케이션을 더 세밀하게 분리할 수 있음
  • TLS 인증서 자동 리로드도 추가돼서 인증서 갱신 때 운영 부담을 줄이는 방향임
  • 프로젝트 쪽 표현으로는 배포 규모나 형태와 무관하게 안정성과 보안성을 유지하게 해주는 기능임

• CLUSTERSCAN이라는 새 기능도 추가됨

  • 전체 클러스터에 걸쳐 일관된 key scanning을 가능하게 해줌
  • 기존처럼 노드별 스캔이나 임시 스크립트에 기대지 않아도 되는 쪽이라 클러스터 운영자에게 실용적임
  • 고부하 상황에서도 더 일관된 성능을 기대할 수 있다고 프로젝트는 설명함

검색이 Valkey 안으로 들어오고 있음

• Valkey Search 1.2는 캐시와 검색을 한 시스템 안에 묶으려는 시도임

  • full-text search, numeric filtering, tag-based lookup, AI-ready vector search를 제공함
  • 별도 검색 플랫폼을 운영하지 않고 Valkey 안에서 캐싱과 검색을 같이 처리하는 그림임
  • 검색, 전자상거래, 실시간 대시보드, 리더보드 같은 사용 사례를 겨냥함

• 성능 주장도 꽤 세게 나옴

  • 테라바이트 규모 데이터까지 확장하면서 마이크로초 단위 지연시간과 초당 수백만 요청을 유지할 수 있다고 설명함
  • 운영팀 입장에서는 별도 검색 인프라를 provision하고 관리하는 비용을 줄이는 게 핵심 포인트
  • agentic AI 쪽에서는 deterministic full-text query와 approximate vector similarity를 섞는 hybrid search가 중요해지고 있어서 더 밀어붙이는 분위기임

sequenceDiagram
    participant 앱 as 애플리케이션
    participant 클라이언트 as GLIDE 클라이언트
    participant 발키 as Valkey 엔진
    participant 검색 as Valkey Search
    앱->>클라이언트: 키 조회 또는 검색 요청
    클라이언트->>발키: 클러스터 라우팅과 연결 관리
    발키->>검색: 전문 검색 또는 벡터 검색 실행
    검색-->>발키: 검색 결과 반환
    발키-->>클라이언트: 데이터와 결과 반환
    클라이언트-->>앱: 로컬 캐시 반영 후 응답

클라이언트와 운영 도구도 같이 밀고 감

• Valkey Admin은 오픈소스 시각적 클러스터 관리 도구로 정식 제공됨

  • 클러스터 토폴로지, 노드별 성능, key browser를 실시간으로 볼 수 있게 설계됨
  • 대규모 Valkey 운영에서 “지금 어디가 아픈지”를 보기 쉽게 만드는 쪽임

• Valkey GLIDE 2.4는 클라이언트 사이드 캐싱과 언어 지원 확대가 핵심임

  • C#과 PHP 지원이 추가됐고, 기존 Java, JavaScript, Python, Go 등과 함께 더 넓은 생태계를 커버함
  • GLIDE는 Rust 공통 코어 기반이라 여러 언어에서 일관된 동작을 제공하는 방향임
  • 클러스터 토폴로지, 연결 관리, 요청 라우팅을 자동 처리해서 개발자가 직접 엮을 일이 줄어듦

• client-side caching은 read-heavy 워크로드에서 특히 의미가 큼

  • 같은 키를 초당 수천 번 가져오는 상황이면 로컬 메모리에서 바로 응답해 네트워크 왕복을 줄일 수 있음
  • 서버 부하와 cross-zone, cross-region 데이터 전송 비용까지 줄일 수 있다는 게 프로젝트의 주장임

AI 에이전트는 maintainer burnout을 줄이는 용도로 쓰는 중

• Olson은 Valkey 개발 과정에도 AI agent를 넣고 있다고 설명함

  • provenance guard 보안 기능과 복잡한 backporting, CI 테스트 자동화가 주요 대상임
  • AI agent가 코드베이스를 스캔하고 crash를 유도하고 버그를 표면화하는 식으로 동작함
  • 수백 시간 실행한 한 시도에서 20개 안팎의 버그와 CVE 하나를 찾았다고 함

• 다만 core engine 코드는 여전히 maintainer가 주도한다는 입장임

  • AI는 실험 코드 생성과 추가 검증 레이어로 쓰고, 핵심 변경은 사람이 꼼꼼히 본다는 쪽
  • backport도 AI가 시도하고 테스트를 돌리고 clean build가 나올 때까지 반복하지만, 최종 리뷰는 유지한다는 흐름임

채택세도 무시하기 어려운 수준으로 올라옴

• Olson에 따르면 Valkey는 요즘 주당 약 600만 container pull을 기록 중임

  • Redis는 주당 약 2,400만~2,500만 pull 수준이라고 언급됨
  • 절대 규모로는 Redis가 훨씬 크지만, Valkey는 1년 전 대비 주간 pull이 약 17배 늘었다고 함
  • Apple, Uber 같은 대기업 사례도 언급됐고, 마이그레이션이 쉽다는 피드백이 계속 나온다고 함

• Valkey 쪽은 Redis가 사라질 거라고 보진 않음

  • Redis는 이름값과 레거시가 워낙 크다는 걸 인정함
  • 대신 Valkey가 경쟁 압력을 만들고, Redis 쪽도 더 많은 것을 오픈소스로 열도록 자극하는 구도를 원함

기술 맥락

• Valkey 9.1의 기술적 선택은 단순히 기능을 더 붙이는 게 아니라, in-memory database의 운영 비용을 낮추는 쪽이에요. 키당 메모리 사용량 10% 절감은 작은 숫자처럼 보여도, 수억 개 키를 다루는 캐시나 세션 저장소에서는 인스턴스 비용으로 바로 이어지거든요.

• 검색을 별도 시스템이 아니라 Valkey 안으로 끌어온 것도 운영 복잡도를 줄이려는 선택이에요. Elasticsearch 같은 별도 검색 계층을 붙이면 색인, 동기화, 장애 대응이 늘어나는데, Valkey Search는 캐시와 검색을 한 시스템에서 처리해 그 부담을 줄이겠다는 방향이에요.

• GLIDE의 Rust 공통 코어도 같은 맥락이에요. 언어별 클라이언트가 제각각이면 클러스터 라우팅이나 장애 복구 동작이 달라져 운영 사고가 나기 쉬운데, 공통 코어를 두면 Java, Python, Go, C#, PHP에서 비슷한 품질을 기대할 수 있어요.

• AI agent 활용은 코어 개발을 대체한다기보다 반복 작업을 줄이는 도구로 보는 게 맞아요. backport, CI 반복, crash 탐색처럼 시간이 많이 먹히는 작업을 자동화해서 maintainer가 실제 설계와 리뷰에 더 집중하게 하려는 거예요.