RAM 값이 오른 지금, Redis는 언제 도입하고 InnoDB 버퍼풀은 언제까지 쓸 수 있을까

About this offer

RAM 가격이 오르는 지금, InnoDB 버퍼풀로 어디까지 버틸 수 있고 Redis는 언제 도입해야 하는지 정리했습니다. 한 줄 요약 Redis 도입 여부는 "버퍼풀이 부족한가"가 아니라 "버퍼풀로 해결할 수 없는 문제가 생겼는가"로 판단해야 합니다. 왜 지금 이 고민을 하는가 서버용 DRAM 가격이 2026년에 크게 올랐습니다. TrendForce는 서버 DRAM 계약 가격이 2026년 3분기에도 전 분기 대비 13~18% 오를 것으로 전망했습니다. 같은 자료에서 서버 DRAM 가격은 2027년 하반기까지 오름세가 이어지되 상승 폭은 완만해질 것으로 보았습니다. 메모리를 늘리는 비용이 커졌기 때문에, "RAM을 더 사서 버퍼풀을 키운다"와 "Redis를 따로 둔다"의 비용 차이를 다시 따져봐야 합니다. 여기서 놓치기 쉬운 점이 하나 있습니다. Redis도 RAM을 사용합니다. 따라서 Redis는 메모리를 아끼는 도구가 아닙니다. 자주 읽는 데이터를 한 번 더 메모리에 올려서 지연 시간과 DB 부하를 줄이는 도구입니다. InnoDB 버퍼풀 성능이 좋아진 이유 먼저, 버퍼풀은 어떻게 동작하는가 버퍼풀은 테이블과 인덱스 데이터를 메모리에 캐시하는 영역입니다. 필요한 페이지가 버퍼풀에 있으면 메모리에서 바로 읽고, 없으면 디스크에서 읽어 옵니다. 버퍼풀은 LRU 알고리즘을 변형해서 사용하며, 목록을 새(young) 영역과 오래된(old) 영역으로 나눕니다. 새로 읽은 페이지는 목록의 맨 앞이 아니라 중간 지점(midpoint)에 들어갑니다. old 영역에 들어간 페이지가 다시 사용되면 young 영역으로 올라갑니다. 이 구조 덕분에 큰 테이블을 한 번 스캔하더라도 자주 쓰는 페이지가 한꺼번에 밀려날 위험이 줄어듭니다. 무엇이 개선되었는가 이번에 확인한 개선은 Percona Server for MySQL 8.4.11-11에 포함된 변경입니다. Oracle MySQL에도 같은 변경이 들어갔는지는 확인하지 못했습니다. 따라서 아래 내용은 Percona Server를 쓰는 경우를 기준으로 읽어야 합니다. 1. 페이지를 읽는 동안 잡던 LRU 리스트 뮤텍스를 줄였습니다. 기존에는 디스크에서 페이지를 읽는 동안 풀 전체의 LRU 리스트 뮤텍스를 잡고 있었습니다. 이를 더 세밀한 페이지 해시 래치로 바꿔서, 여러 스레드의 읽기가 한 줄로 서지 않고 병렬로 진행됩니다. 2. 버퍼풀 인스턴스마다 전용 백그라운드 LRU 스레드를 두었습니다. 이 스레드가 오래된 페이지를 미리 제거하고 플러시해서 빈 페이지를 확보해 둡니다. 덕분에 사용자 쿼리가 실행 도중 직접 정리 작업을 하지 않아도 되고, 그만큼 쿼리 지연 시간이 줄어듭니다. 이 기능은 innodb_lru_threads 변수로 켜고 끌 수 있습니다. 3. 백그라운드 플러셔의 비효율을 고쳤습니다. 플러셔가 매번 LRU 목록의 꼬리부터 같은 페이지를 다시 스캔하던 문제가 있었습니다. 이제 이전에 멈춘 위치에서 이어서 스캔하므로 CPU 낭비가 줄어듭니다. 4. 같은 페이지에 접근하는 스레드끼리의 경합을 줄였습니다. 동시성이 높은 범위 조회에서 여러 스레드가 같은 버퍼풀 페이지를 읽을 때 BUF_BLOCK_MUTEX 경합이 줄어듭니다. 5. NUMA 환경에서 버퍼풀 초기화가 빨라졌습니다. 멀티스레드로 메모리를 할당하므로 버퍼풀이 큰 인스턴스의 서버 시작 시간이 짧아질 수 있습니다. 참고한 글에는 벤치마크 수치가 없어서 이 글에서도 개선 폭은 적지 않았습니다. 정리하면 이 개선들은 버퍼풀이 더 많은 데이터를 담게 되었다는 뜻이 아닙니다. 동시 접근이 많을 때 버퍼풀 안에서 기다리는 시간이 줄어들었다는 뜻입니다. 즉 버퍼풀 용량의 한계가 늘어난 것이 아니라, 용량 안에서 낼 수 있는 처리량이 늘어난 것입니다. 언제까지 InnoDB 버퍼풀로 충분한가 다음 조건이 유지되는 동안은 버퍼풀만으로 충분한 경우가 많습니다. 자주 읽는 데이터(워킹셋)가 버퍼풀에 들어갑니다. 버퍼풀 히트율이 서비스의 지연 시간 목표를 만족합니다. 쓰기가 아니라 읽기가 주된 부하입니다. MySQL 공식 문서는 전용 DB 서버에서 물리 메모리의 최대 80%까지 버퍼풀에 할당하는 경우가 흔하다고 설명합니다. 히트율 확인 방법 아래 상태 변수로 현재 상태를 확인할 수 있습니다. SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free'; Innodb_buffer_pool_read_requests 는 버퍼풀에 요청한 논리적 읽기 횟수입니다. Innodb_buffer_pool_reads 는 버퍼풀에서 찾지 못해 디스크에서 읽은 횟수입니다. 히트율은 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)로 계산합니다. Innodb_buffer_pool_wait_free 가 계속 늘어난다면 빈 페이지가 부족하다는 신호입니다. 몇 퍼센트 이상이면 괜찮다는 절대 기준은 없습니다. 서비스의 지연 시간 목표와 함께 추이를 봐야 합니다. 버퍼풀의 한계 신호 히트율이 떨어지고 디스크 읽기가 늘어납니다. 워킹셋이 버퍼풀보다 커졌다는 뜻입니다. Innodb_buffer_pool_wait_free 가 증가합니다. 병목이 읽기가 아니라 쓰기 쪽에 있습니다. 읽기 캐시를 키워도 해결되지 않습니다. 특정 행에 요청이 몰려 락 경합이 발생합니다. 캐시 크기가 아니라 구조의 문제입니다. 언제 Redis를 도입하는 것이 좋은가 버퍼풀은 디스크 I/O를 줄여 주지만, 쿼리를 파싱하고 실행하고 네트워크로 주고받는 비용은 그대로 남습니다. Redis는 바로 이 비용을 건너뛰는 데 의미가 있습니다. 도입을 검토할 신호 1. 같은 데이터를 매우 자주 읽는 핫 키가 있습니다. 조회 한 번의 DB 왕복 비용 자체가 부담이 되는 경우입니다. 2. 계산 비용이 큰 결과를 재사용합니다. 랭킹, 집계, 카운트처럼 만드는 데 비용이 크고 조금 오래된 값을 보여줘도 되는 경우입니다. 3. 만료 시간(TTL)이 자연스러운 데이터입니다. 세션, 인증 번호, 일시적인 상태 값이 해당합니다. 4. DB가 어울리지 않는 용도입니다. 원자적 카운터, 분산 락, 요청 횟수 제한(rate limit)이 해당합니다. 도입을 미뤄야 할 신호 느린 쿼리의 원인이 인덱스나 쿼리 자체에 있습니다. 먼저 EXPLAIN 으로 확인해야 합니다. 데이터가 자주 바뀌고 정합성이 중요한데 캐시 무효화 전략이 없습니다. 캐시 장애 시 DB로 요청이 몰리는 상황을 감당할 준비가 되어 있지 않습니다. 도입한다면 꼭 설정할 것 Redis는 64비트 환경에서 maxmemory 의 기본값이 제한 없음입니다. 캐시로 쓴다면 maxmemory 와 제거 정책( maxmemory-policy )을 반드시 정해야 합니다. 공식 문서는 일부 키가 훨씬 자주 접근되는 일반적인 경우에 allkeys-lru 를 좋은 기본값으로 안내합니다. noeviction 정책에서는 메모리가 가득 차면 새 데이터를 쓰는 명령이 오류를 반환합니다. 캐시 효율은 INFO stats 의 keyspace_hits 와 keyspace_misses 로 확인할 수 있습니다. 판단 순서 느린 쿼리와 인덱스를 먼저 점검합니다. 버퍼풀 히트율과 Innodb_buffer_pool_wait_free 를 확인합니다. 히트율이 낮다면 버퍼풀 증설을 먼저 검토합니다. 이때 증설 비용과 Redis 서버 비용을 함께 비교합니다. 히트율은 높은데 지연 시간 목표를 맞추지 못한다면 Redis 캐시를 검토합니다. TTL 데이터, 카운터, 락은 DB 성능과 별개로 Redis가 자연스러운 선택입니다. 마치며 RAM 가격이 오른 지금은 "일단 Redis부터 붙이는 것"이 오히려 비용을 두 번 쓰는 일이 될 수 있습니다. 먼저 버퍼풀 지표로 현재 상태를 확인하고, 버퍼풀로 풀 수 없는 문제가 보일 때 Redis를 도입하는 순서를 권합니다. 참고 자료 Performance improvements in Percona Server 8.4.11-11 (Percona Blog) MySQL 8.4 Reference Manual - Buffer Pool MySQL 8.4 Reference Manual - Making the Buffer Pool Scan Resistant Redis Docs - Key eviction TrendForce - Server DRAM Contract Prices Expected to Rise 13-18% QoQ in 3Q26