본문으로 건너뛰기
J
0
r/jeffnews • HN • • 약 3분

Redis 8.0 출시 — I/O 스레딩 갈아엎고 처리량 3배, 2.1M ops/sec 달성

backend

요약

Redis 8.0이 I/O 스레딩 모델을 완전히 재설계해서 16코어 기준 2.1M ops/sec를 달성함 (7.4 대비 3배). Hash field expiration, Vector search HNSW, Client-side caching v2, Redis Functions 2.0 async 실행 등 굵직한 기능이 추가되고, jemalloc 통합으로 메모리 fragmentation도 25% 줄어듦.

기사 전체 정리

Redis 8.0 출시 — I/O 스레딩 모델 갈아엎고 처리량 3배 뛴 이야기

핵심: I/O 스레딩 모델 완전 재설계

  • 기존 io-threads 구현을 완전히 새로 작성한 버전임
  • 멀티코어 시스템에서 최대 3배 처리량 향상을 달성함
  • lock contention을 60% 줄인 설계라서 코어 수 늘릴수록 효과가 확실함

❗중요

> 16코어 머신 벤치마크 결과: Redis 8.0은 2.1M ops/sec, Redis 7.4는 700K ops/sec. 약 3배 차이남.

새로 들어온 주요 기능들

  • Hash field expiration: 해시 키 전체가 아니라 개별 필드에 TTL 설정이 가능해짐. 이거 진짜 오래 기다린 기능임. 키 하나에 여러 필드 넣고 쓰는 패턴에서 필드별로 만료 관리가 됨
  • Vector search HNSW 인덱스 지원: AI/ML 워크로드용으로 HNSW 인덱스가 추가됨. 벡터 검색 성능이 확 달라질 부분
  • Client-side caching v2: server-assisted invalidation 방식의 클라이언트 사이드 캐싱 2세대가 도입됨
  • Redis Functions 2.0: async execution 지원이 핵심임. 오래 걸리는 Lua 스크립트가 메인 스레드를 블로킹하지 않고 실행 가능해짐. 이건 운영 관점에서 상당히 큰 변화임

❗중요

> 메모리 효율도 개선됨 — 새로운 jemalloc 통합으로 가변 크기 키 워크로드에서 fragmentation이 25% 감소함.

핵심 포인트

  • I/O 스레딩 모델 완전 재작성으로 멀티코어에서 최대 3배 처리량 향상, lock contention 60% 감소
  • 16코어 벤치마크: 2.1M ops/sec (Redis 7.4는 700K ops/sec)
  • Hash 개별 필드에 TTL 설정 가능한 Hash field expiration 지원
  • AI/ML용 Vector search HNSW 인덱스 및 Client-side caching v2 도입
  • Redis Functions 2.0에서 async execution으로 Lua 스크립트 논블로킹 실행 가능
  • jemalloc 통합으로 가변 크기 키 워크로드에서 fragmentation 25% 감소

인사이트

단순 성능 개선이 아니라 I/O 모델 자체를 갈아엎은 거라서, 멀티코어 환경에서 Redis를 쓰고 있다면 업그레이드 효과가 상당할 것임. Hash field expiration은 실무에서 키 설계 패턴을 바꿀 수 있는 변화.

#redis#database#performance#release
원문 보기
댓글 뒤로가기

댓글

댓글

댓글을 불러오는 중...

관련 기사

backend

Blue Brain Nexus — 데이터 기반 과학을 위한 지식 그래프 플랫폼

스위스 EPFL Blue Brain Project의 오픈소스 지식 그래프 생태계. Fusion(웹앱), Nexus Forge(Python 프레임워크), Delta(백엔드 서비스) 세 제품으로 구성. Linked Data와 SHACL 기반으로 시맨틱 데이터 관리를 제공.

backend

POSIX atime: 파일을 읽기만 해도 쓰기가 발생하는 구조의 문제점

POSIX 표준의 atime은 파일을 읽을 때마다 접근 시간을 기록하므로 모든 읽기가 쓰기로 이어짐. Linux는 2009년부터 relatime을 기본값으로 도입해 성능 문제를 완화했으며, 저자는 대다수 사용자에게 atime 자체가 불필요한 레거시라고 주장함.

backend

에러의 두 가지 종류

소프트웨어 에러를 expected(정상 운영 중 발생, 처리 필요)와 unexpected(버그, crash 허용)로 나누는 프레임워크를 제안하는 글. 맥락에 따라 선 긋는 위치가 달라지며, Rust의 에러 철학과 맥이 같음.

backend

Mycelium으로 복잡성 관리하기: AI 코딩 에이전트 시대의 소프트웨어 아키텍처

LLM도 인간과 동일한 인지적 한계(context rot)를 겪기 때문에, 계층적이고 분리 가능한 컴포넌트 설계가 필수적임. Clojure 기반 Mycelium 프레임워크는 상태 머신으로 라우팅과 데이터 변환을 분리하고, Malli 스키마로 Cell 간 계약을 강제하여 AI 에이전트가 제한된 컨텍스트에서 안전하게 작업할 수 있게 함.

backend

"스왑은 RAM의 2배" 규칙은 대체 어디서 온 걸까

1990년대 SunOS의 노오버커밋 정책, fork/exec의 메모리 더블링, HDD 스왑 단편화 회피라는 세 가지 조건이 만든 경험칙이 '스왑 = RAM × 2'의 기원이다. 현대 리눅스의 오버커밋과 SSD 환경에서는 더 이상 유효하지 않다.