“같은 트래픽, CPU는 86% 덜 쓴다” — 100만 사이트 플랫폼 아임웹의 Valkey 9.1 실측 결과

100만 개 사이트를 호스팅하는 아임웹이 ElastiCache 엔진을 Valkey 7.2 에서 9.1 로 올린 뒤 3.5시간 동안 7억 건 명령을 처리하며 전후를 실측했다. 노드 사양은 그대로 두고 엔진만 바꿨는데 CPUUtilization 이 24.98%에서 3.35%로 86.6% 떨어졌다. 서울 리전 28노드 기준 연 5만 달러가량 절감된다.

핵심 포인트

엔진 업그레이드와 노드 다운사이징을 의도적으로 분리해, 순수 엔진 개선 효과만 격리 측정했다
CPUUtilization -86.6%, EngineCPUUtilization -31.6%, 100만 명령당 CPU -85.8%
latency 는 KeyBased -67.0%, SetType -53.6%, Cluster 계열 -92.3% 로 명령 종류마다 폭이 크게 달랐다
메모리는 DatabaseMemoryUsagePercentage -30.1%, fragmentation ratio 1.37에서 1.17로 개선
CurrConnections·Evictions·ReplicationLag 가 모두 무변화라 부작용 없이 얻은 개선임을 확인했다

상세 정리

배경: SSR 렌더링 경로에서 사이트 설정·메뉴·권한·세션·상품 표시 조건을 반복 조회해, 캐시가 보조가 아니라 응답성을 좌우하는 핵심 계층이었다
사전 준비: 업그레이드 중 연결이 끊길 수 있어 클라이언트의 다층 retry 를 먼저 점검했다
클라이언트 설정: ioredis 기준 connectTimeout 1000ms, commandTimeout 1000ms, maxRetriesPerRequest 3, retryStrategy 는 시도당 100ms 씩 늘려 최대 2000ms
커넥션 풀: idleTimeoutMillis 30000, maxLifetimeMillis 300000, testOnBorrow 활성화로 죽은 커넥션을 걸렀다
방어 계층: connection retry, command retry, offline queue, DB 폴백까지 4단을 두어 순간 단절을 흡수했다
실행 순서: 영향도 낮은 캐시부터 단계적으로 올렸고, 대표 범용 캐시는 19분(03:42~04:01 KST)만에 끝났다
8.0 의 개선: main thread 와 I/O thread 를 비동기화하고 command batching 을 넣어, 전체 시간의 40% 이상을 쓰던 lookupKey 를 줄였다
8.0 메모리: slot-to-key 메타데이터를 없애 작은 key/value 에서 메모리를 최대 20% 아꼈고, key pointer embedding 으로 추가 lookup 을 제거했다
8.1: 메모리 prefetching 으로 CPU cache locality 를 높이고, 64바이트 cache line 단위 hashtable 로 포인터 체이싱을 줄였다
9.0: zero-copy response 로 큰 값 응답에서 메모리 복사를 없앴고, atomic slot migration 으로 legacy 대비 약 9배 빠른 마이그레이션을 얻었다
9.1: shared queue 기반 통신으로 부하 분산을 자동화했다
공식 벤치마크: 2,000 노드 클러스터(primary 1,000 + replica 1,000, r7g.2xlarge, 클라이언트 750대)에서 초당 10억 요청을 기록했다
측정 조건: 2026-07-10 04:30~08:00 KST 를 전날 같은 시간대와 비교했고, 구간 내 초당 약 6만 건을 처리했다
비용: 서울 리전 On-Demand cache.r7g.2xlarge 기준 Redis OSS 시간당 1.045달러 대비 Valkey 0.836달러로, 28노드·730시간 환산 연 51,264달러 차이가 난다