ElastiCache Redis 도입 시점: RDS 반복 읽기 쿼리 성능 개선 실전 가이드
RDS 인스턴스의 CPU와 커넥션 수가 치솟는데 슬로우 쿼리 로그를 열어보면 항상 같은 쿼리들이 반복해서 찍혀 있다. 상품 목록, 사용자 세션, 설정값처럼 데이터는 거의 바뀌지 않는데 매 요청마다 DB를 치고 있는 상황 — ElastiCache Redis를 캐시 레이어로 추가하는 것이 ElastiCache Redis 도입 의 가장 전형적인 시나리오다. TL;DR — ElastiCache Redis 도입 판단 기준 판단 항목 Redis 도입 적합 도입 불필요 동일 쿼리 반복 비율 전체 읽기의 30% 이상이 동일 키 대부분 유니크 쿼리 데이터 변경 주기 수 분 ~ 수 시간 단위 실시간 갱신 필수 RDS 병목 지점 읽기 쿼리 과부하 쓰기 병목, 스키마 문제 응답 지연 허용 범위 수십 ms 이내 목표 DB 직접 조회로 충분 캐시 일관성 요구 Eventually Consistent 허용 Strong Consistency 필수 ElastiCache Redis가 RDS 부하를 줄이는 원리 Redis는 인메모리 데이터 구조 저장소다. RDS가 디스크 I/O와 쿼리 파싱, 실행 계획 수립을 거쳐 결과를 반환하는 동안, Redis는 메모리에서 키-값을 직접 조회해 반환한다. 이 구조적 차이가 응답 속도 격차를 만든다. 캐시 히트 시 요청은 RDS에 도달하지 않는다. RDS 입장에서는 해당 쿼리가 존재하지 않는 것과 같다. 커넥션 풀 소모도 없고, 실행 계획 수립 비용도 없다. 트래픽이 몰리는 구간에서 RDS 커넥션 수가 안정적으로 유지되는 이유가 여기에 있다. graph LR App["애플리케이션 서버"] Redis["ElastiCache Redis"] RDS["Amazon RDS"] App -->|"① GE...