서버 부하를 줄이는 마법: Redis(글로벌) vs Caffeine(로컬) 캐시 전략 총정리

System Performance Optimization

데이터를 가장 빨리 가져오는 법,
캐시(Cache) 설계의 정석

 

안녕하세요, code-resting입니다. 모든 요청을 데이터베이스(DB)에서 처리한다면 서버는 금세 비명을 지를 것입니다. 성능 좋은 백엔드 서버의 핵심은 "얼마나 DB 조회를 줄이느냐"에 달려 있죠. 오늘은 상황에 맞는 캐시 선택 기준과 효율적인 아키텍처를 살펴보겠습니다.

1. 로컬 캐시 vs 글로벌 캐시

캐시는 어디에 저장하느냐에 따라 크게 두 종류로 나뉩니다.

📍 로컬 캐시 (Caffeine, Ehcache)

• 장점: 네트워크 비용 없음, 압도적으로 빠름.
• 단점: 서버 간 데이터 불일치 발생, 메모리 공유 불가.
• 용도: 설정값, 공지사항 등 자주 안 변하는 데이터.

🌐 글로벌 캐시 (Redis, Memcached)

• 장점: 모든 서버가 동일 데이터 공유, 대용량 저장 가능.
• 단점: 네트워크 지연(I/O) 발생, 별도 인프라 운영 필요.
• 용도: 세션, 유저 프로필, 실시간 랭킹 등.

2. 자주 쓰이는 캐시 읽기/쓰기 전략

비즈니스 요구사항에 따라 데이터를 어떻게 갱신할지 결정해야 합니다.

• Look Aside (Cache Aside): 데이터를 찾을 때 캐시를 먼저 확인하고, 없으면 DB에서 가져와 캐시에 저장하는 가장 일반적인 방식.
• Write Through: 데이터를 DB에 저장할 때 캐시에도 항상 같이 업데이트. 데이터 일관성이 좋지만 쓰기 성능이 약간 희생됨.
• Write Back: 캐시에 먼저 저장하고 일정 시간 뒤에 DB에 모아서 저장. 쓰기 성능은 최고지만 서버 장애 시 데이터 유실 위험이 있음.

3. 2026년형 하이브리드: 2단계 캐싱

극도의 성능이 필요한 서비스는 로컬 캐시와 글로벌 캐시를 조합합니다.

1차로 로컬 캐시(Caffeine)를 조회하고, 없으면 2차로 글로벌 캐시(Redis)를 확인합니다. Redis까지 거친 후에도 데이터가 없다면 최종적으로 DB를 조회합니다. 이 방식은 Redis조차 병목이 되는 초고대용량 트래픽 환경에서 매우 효과적입니다.

4. 실무 주의사항: Cache Stampede

🔥 캐시 스탬피드 현상이란?

인기 있는 데이터의 캐시 만료 시점에 수많은 요청이 동시에 DB로 몰려 서버가 뻗는 현상입니다. 이를 방지하기 위해 만료 시간을 무작위(Random TTL)로 설정하거나, PER(Probabilistic Early Recomputation) 알고리즘을 도입하는 것을 고려해야 합니다.

💡 결론

캐시는 정답이 없습니다. 데이터의 휘발성, 일관성 요구 수준, 트래픽 규모를 고려하여 최적의 조합을 찾아야 합니다. "캐시는 단순히 저장하는 곳이 아니라, 데이터의 수명을 관리하는 전략"임을 잊지 마세요.

© 2026 code-resting. All rights reserved.