Redis Cache Aside + RDBMS 인덱스 협응 성능 개선 전략

RDBMS 성능 최적화를 이야기할 때 가장 먼저 떠올리는 방법은 인덱스(Index) 추가입니다.

하지만 트래픽이 증가하고 동일한 조회 요청이 반복되는 환경에서는 DB 인덱스만으로는 한계가 드러나며, 이 지점에서 Redis 기반 Cache Aside 패턴이 등장합니다.

 

이 글에서는 DB Index와 Cache Aside를 경쟁 관계가 아닌, 서로 다른 문제를 해결하는 도구로 바라보고 공식 문서 기준으로 성능 특성과 적용 조건을 비교합니다.

 

---

 

DB Index의 역할과 한계

DB Index의 정의와 목적

MySQL 및 PostgreSQL 공식 문서에 따르면, 인덱스(Index)는 테이블의 특정 컬럼을 기준으로 데이터 접근 경로를 최적화하여 검색 비용을 줄이기 위한 자료구조입니다.

• B-Tree 계열 인덱스가 기본 
• 조건 검색(WHERE), 정렬(ORDER BY), 조인(JOIN) 성능 개선이 목적  
• 디스크 기반 스토리지에서 탐색 범위를 줄이는 역할 

즉, 인덱스는 “DB 내부에서 더 빠르게 찾기” 위한 장치입니다.

 

---

 

DB Index로 해결할 수 있는 문제

DB Index는 다음 상황에서 매우 효과적입니다. 

• 단건 조회 또는 범위 조회가 빈번한 경우
• 데이터 최신성이 항상 보장되어야 하는 경우
• 데이터 수정 빈도가 조회 빈도와 유사한 경우

이 경우 잘 설계된 인덱스만으로도 충분한 성능을 확보할 수 있습니다.

 

---

 

DB Index의 구조적 한계

공식 문서 기준에서 인덱스는 다음 한계를 가집니다.

• 모든 조회는 DB 접근을 전제로 함
• 디스크 I/O 및 버퍼 캐시 의존
• 트래픽 증가 시:
  • CPU 사용량 증가
  • Buffer Pool 경쟁 증가
  • 락/동시성 비용 증가

즉, 인덱스는 DB 접근 비용을 줄일 뿐, DB 접근 자체를 제거하지는 못합니다. 

 

 

---

 

Cache Aside 패턴의 정의와 동작 원리

Cache Aside 패턴이란

Redis 공식 문서와 Spring Data Redis에서는 Cache Aside를 애플리케이션이 캐시와 DB를 직접 제어하는 패턴으로 정의합니다.

 

동작 흐름은 다음과 같습니다.

1. 애플리케이션이 캐시 조회
2. 캐시 히트 → 바로 반환
3. 캐시 미스 → DB 조회
4. 조회 결과를 캐시에 저장 후 반환
5. 데이터 변경 시 → DB 업데이트 후 캐시 삭제

 

---

 

Cache Aside의 핵심 역할

Cache Aside는 DB 조회 자체를 제거하는 것이 목적입니다. 

• Redis는 메모리 기반 저장소
• 네트워크 왕복 + 메모리 접근
• DB 인덱스보다 훨씬 짧은 응답 시간

즉, Cache Aside는 “DB를 빠르게 만드는 것”이 아니라 “DB를 안 가게 만드는 것”에 가깝습니다.

 

 

---

 

DB Index vs Cache Aside 동작 원리 비교

구분	DB Index	Cache Aside
위치	DB 내부	애플리케이션 외부
저장 매체	디스크 + 버퍼 캐시	메모리
목적	탐색 비용 감소	DB 접근 제거
조회 경로	항상 DB 접근	캐시 히트 시 DB 미접근
최신성	항상 보장	TTL/무효화 필요

 

 

---

 

성능 비교 관점

단일 요청 처리 시간

• DB Index
  • 인덱스 탐색 + DB 페이지 접근
  • 밀리초(ms) 단위
• Cache Aside (Redis Hit)
  • 네트워크 + 메모리 접근
  • 서브 밀리초 단위

단일 요청 기준으로도 Redis 캐시가 더 빠릅니다.

 

---

 

반복 조회 처리

반복 조회 상황에서는 차이가 더 명확해집니다.

• DB Index - 매 요청마다 DB 접근 발생
• Cache Aside - 캐시 히트 시 DB 부하 0 

공식 문서 기준으로 Redis는 읽기 부하를 DB에서 완전히 분리할 수 있습니다.

 

---

 

고트래픽 환경에서의 부하 차이

• DB Index
  • CPU / Buffer Pool / 락 경쟁 증가
• Cache Aside
  • DB QPS 감소
  • DB는 쓰기 및 캐시 미스 처리에만 집중

이 때문에 트래픽 증가 곡선이 DB Index와 Cache Aside에서 완전히 다르게 나타납니다.

 

---

 

적용 조건과 선택 기준

DB Index만으로 충분한 경우

다음 조건에서는 Cache 도입이 불필요합니다.

• 트래픽이 낮거나 안정적인 경우
• 조회 패턴이 단순한 경우
• 데이터 최신성이 매우 중요한 경우
• 캐시 무효화 비용이 더 큰 경우

이 경우 인덱스 튜닝이 우선입니다.

 

---

 

Cache Aside를 도입해야 하는 경우

공식 문서와 실무 기준에서 Cache Aside는 다음 경우에 적합합니다.

• 동일 조회가 반복되는 경우
• 읽기 트래픽이 쓰기보다 훨씬 많은 경우
• 조회 비용이 높은 복잡한 쿼리
• DB 부하가 병목으로 드러난 경우

 

---

 

DB Index + Cache Aside 병행

실무에서는 대부분 두 가지를 함께 사용합니다.

• DB Index: 캐시 미스 처리 최적화
• Cache Aside: DB 접근 자체 감소

Cache Aside는 인덱스를 대체하지 않습니다. 

오히려 인덱스를 전제로 더 큰 효과를 냅니다. 

 

 

---

 

 

주의점과 오해

Cache Aside는 인덱스를 대체하지 않는다

• 캐시 미스 시 DB 접근은 필수
• 인덱스가 없으면 캐시 미스 비용이 커짐

캐시는 항상 정합성 비용이 따른다

• TTL
• 명시적 무효화
• 캐시 장애 패턴 대응 필요

DB Index에는 없는 운영 복잡성이 존재합니다.

 

---

 

정리와 맺음말

• DB Index
  • DB 내부 최적화
  • 기본 전제 조건
• Cache Aside
  • DB 접근 자체 감소
  • 트래픽 대응 수단

두 기술은 경쟁 관계가 아니라 서로 다른 계층에서 병목을 해결하는 도구입니다. 

실무에서는 “인덱스로 기본 성능을 확보한 뒤, 캐시로 확장성을 얻는다” 라는 접근이 가장 안정적입니다.