DB대신 캐시? - 성능 개선(캐시)

 서비스의 트래픽이 증가하면서 응답 속도가 느려지고 처리량(TPS)이 한계에 가까워질 때, 가장 먼저 떠오르는 해결책은 서버 확장이다. 수직 확장(서버 스펙 업그레이드)이나 수평 확장(서버 추가)은 효과가 빠르지만, 비용이 많이 들고 구조도 복잡해진다. 이럴 때, 보다 효율적인 대안으로 떠오르는 것이 바로 캐시(Cache) 이다.

 

캐시란?

캐시는 자주 사용하는 데이터를 미리 저장해두고, 같은 요청이 다시 들어오면 원본(DB나 외부 API 등)을 거치지 않고 즉시 반환하는 저장소다. 내부적으로는 보통 Key-Value 구조의 Map과 유사하며, 응답 속도를 극적으로 단축시킬 수 있다.

캐시 동작 방식

1. 서버는 먼저 캐시에서 데이터 조회 시도
2. 캐시에 데이터가 있으면 → 그대로 반환 (DB 접근 생략)
3. 캐시에 없다면 → DB나 외부 API 호출
4. 그 결과를 캐시에 저장해 이후 요청에 재사용

캐시가 필요한 이유

• 응답 속도 향상
• DB/외부 API 부하 감소
• 트래픽이 몰려도 안정적 서비스 유지

예를 들어, 매번 DB에서 읽어야 하는 데이터를 캐시에 보관하면 응답 시간이 수 밀리초 단위로 줄어들 수 있다.

 

 

적중률

캐시의 효과는 적중률(Cache Hit Ratio) 로 측정할 수 있다.

캐시 적중률 = 캐시에서 데이터를 성공적으로 조회한 횟수 / 전체 캐시 조회 시도 횟수

 

예를 들어 100번 조회 중 87번이 캐시에서 처리됐다면, 적중률은 87%
적중률이 높을수록 DB 요청이 줄고, 시스템 전체 성능이 향상된다.

 

 

🤔 모든 데이터를 캐시에 넣으면 될까?

캐시는 기본적으로 메모리를 사용하므로, 저장 가능한 데이터량에는 한계가 있다.
이 때문에 캐시는 내부적으로 데이터를 저장할 때 삭제 정책(교체 정책, Eviction Policy) 을 활용한다.

 

 

 

로컬 캐시, 리모트 캐시

서버에서는 보통 두 가지 방식의 캐시를 사용한다.

1. 로컬 캐시 (In-Process Cache)

• 서버 내부 메모리에 저장
• 매우 빠른 응답 (네트워크 불필요)
• 구조가 단순하고 설정이 쉬움

단점:

• 서버 재시작 시 캐시 초기화
• 서버별로 캐시가 따로 존재 → 데이터 일관성 문제

2. 리모트 캐시 (Out-of-Process Cache)

• 별도의 캐시 서버 사용 (예: Redis)
• 여러 서버에서 공통된 캐시 저장소 공유 가능
• 수평 확장에 유리, 캐시 유지 가능

단점:

• 네트워크 통신 필요 → 속도 느림
• 별도의 서버 장비와 프로세스가 필요하기 때문에 구조가 복잡해짐

 

캐시에 보관할 데이터 규모가 작고 변경 빈도가 낮다면 로컬 캐시로 충분하다.

데이터 규모가 크다면 리모트 캐시가 좋다. 또한 배포 빈도가 많아도 리모트 캐시를 고려해볼 필요가 있음. 서버를 재시작하면 로컬 캐시의 데이터는 처음부터 다시 쌓아야하기 때문이다.

 

 

캐시 사전 적재

트래픽이 특정 시간대에 몰리는 서비스라면, 데이터가 요청되기 전에 미리 캐시에 넣어두는 전략이 효과적이다.

예시:

• 교육 플랫폼에서 오전 9시에 실시간 강의 수강생 10만 명 접속 예상
• 각 수강생의 개인 맞춤 강의 리스트를 DB에서 불러오면 DB 부하 폭주
• 오전 8시 50분에 모든 수강생 데이터를 미리 캐시에 적재
• 실시간 요청 시 캐시에서 즉시 응답 → 빠른 처리 + 안정성 확보

 

 

캐시 무효화 전략

캐시의 최대 단점은 원본 데이터와 불일치할 수 있다는 점이다. 데이터가 변경됐는데, 여전히 변경 전 값이 캐시에 남아 있다면 심각한 문제가 발생할 수 있다.

무효화 방식

• 즉시 무효화: 데이터 변경 시 캐시에서 즉시 삭제 (민감한 정보에 적합)
• 유효 기간(TTL) 설정: 일정 시간 지나면 자동 삭제 (변경 빈도 낮은 데이터에 적합)
• 로컬 캐시 주의: 서버 간 캐시가 공유되지 않기 때문에, A 서버에서는 변경되었지만 B 서버는 이전 값을 갖는 상황이 생길 수 있음

 

 

캐시는 ‘성능’을 넘어 ‘설계’의 영역

캐시는 단순히 속도를 빠르게 하기 위한 장치가 아니라, 서비스의 구조와 확장성에 큰 영향을 주는 핵심 구성 요소

• 응답 시간을 줄이고 DB 부하를 완화할 수 있음
• 로컬과 리모트 캐시의 특성을 구분해 전략적으로 활용
• 적중률을 높이기 위한 설계와 무효화 정책이 매우 중요