본문 바로가기

Spring Boot/Cache

캐시의 기본 개념과 필요성 : 대용량 트래픽에서 캐시의 역할

캐시는 왜 필요한가?

 

 - 대용량 트래픽 환경에서 캐시(Cache)가 어떤 역할을 하는가

 - 캐시를 통해 데이터베이스 부하를 줄이는 방법

 - 캐시가 응답 시간을 개선하고 시스템 성능을 향상시키는 원리

 - 캐시가 확장성과 비용 효율성 측면에서 어떤 이점을 제공하는가

 - 사례를 통해 캐시가 시스템 안정성에 기여하는 과정

 


1. 대용량 트래픽 환경과 캐시의 필요성

대용량 트래픽 환경 : 짧은 시간 안에 다수의 사용자가 동시에 요청을 보내는 상황

모든 요청이 DB로 직접 향한다면, 문제가 발생한다

 

DB 부하 증가 : 동일한 데이터를 여러번 조회하면서 CPU, 메모리, 디스크 I/O가 과부하됨

응답 지연 : 요청이 몰리면서 쿼리 처리 속도가 느려짐

서비스 중단 위험 : DB 연결 수 초과, 장애, 서버 다운 등의 문제가 발생할 수 있음

 

이런 상황에서 캐시는 데이터 요청을 분산 처리하고, 자주 사용되는 데이터를 메모리에서 즉시 제공함으로써 시스템을 보호함

 

캐시에 데이터가 존재한다면, DB로 직접 가지 않는다

 

* 캐시는 데이터베이스 앞단에서 '완충지대(Buffer Layer)' 역할을 하며, 서버 안정성과 성능을 동시에 확보함

 


2. 데이터베이스 부하 감소

1) 개념

캐시의 가장 큰 역할 중 하나는 데이터베이스로 향하는 요청 수를 줄이는 것임

자주 요청되는 데이터(인기 게시글, 상품 록, 실시간 랭킹 등)를 캐시에 저장하면, DB는 동일한 쿼리를 여러번 처리하지 않아도 됨

완충역할을 하는 캐시서버

 

캐시는 DB 접근 빈도를 줄여 부하를 분산시키며, 전체 시스템의 안정성을 높임

 


3. 응답 시간 개선

1) 개념

캐시를 사용하면 데이터를 메모리에서 바로 가져오기 때문에 응답 속도가 매우매우 빨라진다

DB 쿼리 실행, 네트워크 왕복, 디스크 I/O 등과 같은 단계가 모두 생략되기 때문

 

2) 캐시를 사용하지 않을 때의 요청 흐름

Spring 애플리케이션의 Layered Architecture(레이어드 아키텍처)

 

 - Controller : 사용자의 요청을 받음(HTTP)

 - > Service : 비즈니스 로직 실행

 - > Repository : DB 접근 로직 수행(JPA, MyBatis 등등..) * Repository는 실제 DB가 아님

 - > Database(RDBMS) : 실제 데이터 저장소

 

위와 같은 구조로 내려가며, 이후 DB에서 데이터를 읽고 다시 같은 경로로 응답을 반환함

이 구조에서는 모든 요청마다 DB를 직접 조회해야 하기 때문에 DB 부하가 커지고, 응답 지연(latency)이 발생함

 

3) 캐시를 사용할 때의 요청 흐름

캐시를 도입하면 Service에서 데이터를 미리 확인한 후, 캐시에 데이터가 존재한다면 Repository를 거치지 않는다.

캐시를 사용할 때와 사용하지 않을 때의 구조

 

4) 시간 비교 예시

처리 방식 요청 흐름 평균 응답속도 주요 병목지점
DB 접근 Controller - > Service - > Repository - > DB 약 800 ~ 1500ms DB 쿼리, 네트워크 I/O
캐시 접근 Controller - > Service - > Cache 약 10 ~ 50ms (차이 매우큼) 거의 없음(메모리 접근)

 

* 캐시를 사용하면 Repository - > DB 호출을 건너뛰어, 요청 경로를 단축시키고 전체 응답 속도를 매우매우 향상시킬 수 있음

 


4. 시스템 확장성 향상

1) 개념

확장성이란, 시스템이 사용자 수 증가에도 성능 저하없이 대응할 수 있는 능력을 말함

캐시를 도입하면 요청이 DB에 집중되지 않고 분산되어, 더 많은 사용자를 처리할 수 있음

요청이 증가함에 따른 캐시의 효율성

 

캐시는 수평 확장(Scale-out) 구조에서도 필수적인 구성 요소임

여러 서버가 동시에 동일한 캐시 서버를 참조함으로써 일관된 성능을 유지할 수 있음

 


5. 비용 측면에서의 효율성 향상

1) 개념

서버는 처리량이 늘어날수록 CPU, 메모리, 네트워크 비용이 증가함

캐시를 사용하면 비용을 획기적으로 절감할 수 있음

 - 캐시를 통해 DB 서버 수를 줄일 수 있음

 - 네트워크 전송 비용 감소(데이터를 가까운 곳에서 꺼내옴)

 - 클라우드 과금 절감 효과(I/O, 트래픽, CPU 사용량 감소)

 

구분 캐시 미사용 캐시 사용
월간 DB 트래픽 100% 약 30%
서버 유지비 높음 낮음
전체 운영비용 약 100만원 이상 40만원 수준

 

* 실제 대형 서비스에서는 캐시가 전체 인프라 비용의 절반 이상을 절약하는 사례가 매우 많다. 캐시는 당연한 것

 


* 캐시는 단순 속도 향상만이 아니라, 시스템 전체 안정성 확보 수단으로 활용됨

* 캐시를 도입할 땐 트래픽 패턴(자주 조회되는 데이터, 반복 요청)을 먼저 분석해야함

* 정적 데이터(상품 목록, 지역명, 코드값 등)부터 캐시를 적용하면 효율이 높음

* 캐시 계층은 DB 앞단 뿐만 아니라 API Gateway / CDN / 브라우저 등 여러 레벨에 존재할 수 있음

 


정리

 - DB 부하 감소 : 동일 데이터 요청을 캐시로 처리해 DB 접근 빈도를 줄임

 - 응답 시간 개선 : 메모리 접근을 통해 빠른 데이터 제공

 - 시스템 확장성 : 다수의 요청을 분산 처리하여 성능 유지