반응형
High Performance Series 02
속도와 정합성 사이의 줄타기,
캐시 읽기/쓰기 전략 패턴 총정리
안녕하세요, code-resting입니다. 캐시를 도입할 때 가장 큰 고민은 "DB 데이터가 바뀌었는데 캐시는 언제 업데이트하지?"일 것입니다. 잘못된 전략은 사용자에게 옛날 데이터를 보여주는 치명적인 결과를 낳죠. 오늘은 상황별 최적의 캐시 패턴을 분석하여, 데이터 정합성을 지키면서 성능을 극대화하는 법을 공유합니다.
1. 읽기 전략 (Read Strategies)
📍 Cache Aside (Look Aside)
가장 일반적인 방식입니다. 애플리케이션이 먼저 캐시를 확인하고, 없으면 DB에서 가져와 캐시에 저장합니다.
- 장점: 캐시 장애가 나도 DB로 서비스가 가능합니다.
- 단점: 초기 조회 시 속도가 느리고(Cache Miss), DB와 데이터가 다를 수 있습니다.
📍 Read Through
애플리케이션은 오직 캐시만 바라봅니다. 캐시가 없으면 캐시 라이브러리가 직접 DB에서 데이터를 읽어와 채워넣습니다.
- 장점: 애플리케이션 코드가 단순해집니다.
- 단점: 캐시 장애 시 서비스 전체가 중단될 위험이 있습니다.
2. 쓰기 전략 (Write Strategies)
📍 Write Through
데이터를 쓸 때 캐시와 DB에 동시에 저장합니다.
- 장점: 항상 최신 데이터가 유지됩니다.
- 단점: 쓰기 작업마다 두 번의 저장이 발생하여 성능이 느려질 수 있습니다.
📍 Write Back (Write Behind)
데이터를 일단 캐시에만 몰아서 쓰고, 나중에 배치(Batch) 작업으로 DB에 한꺼번에 반영합니다.
- 장점: 쓰기 속도가 압도적으로 빠릅니다. (로그, 실시간 클릭수 등)
- 단점: 캐시 장애 시 DB에 반영되지 않은 데이터가 유실될 위험이 큽니다.
3. 전략 선택 가이드라인
| 서비스 성격 | 권장 조합 | 핵심 포인트 |
|---|---|---|
| 일반적인 웹 서비스 | Cache-Aside + Write-Through | 무난한 성능과 안정성 |
| 쓰기가 빈번한 서비스 | Write-Back | DB 부하 감소 최우선 |
| 데이터 유실이 치명적일 때 | Write-Through | 데이터 정합성 최우선 |
💡 마무리하며
완벽한 캐시 전략은 없습니다. 오직 "우리 서비스에 맞는 전략"만 있을 뿐입니다. 2026년 현재 대다수의 기업은 Cache-Aside를 기본으로 하되, 데이터 업데이트 시 캐시를 제거(Evict)하는 방식을 조합하여 사용합니다. 여러분의 프로젝트 상황에 맞춰 가장 정교한 줄타기를 시작해 보세요!
728x90
반응형
'아키텍처' 카테고리의 다른 글
| 서버는 로직만! AWS S3와 CloudFront(CDN)로 정적 자원 서빙 최적화하기 (0) | 2026.04.20 |
|---|---|
| Redis가 죽으면 서비스도 죽는다? Sentinel vs Cluster로 고가용성(HA) 구축하기 (0) | 2026.04.10 |
| 서버 부하를 덜어주는 마법: 로컬 캐시(Ehcache) vs 글로벌 캐시(Redis) 선택 가이드 (0) | 2026.04.06 |
| MSA 트랜잭션의 구원자: 2PC(Two-Phase Commit)와 Saga 패턴 완벽 이해 (0) | 2026.04.02 |
| 서버 한 대로 안 될 때: 로드밸런서(L4 vs L7)와 Nginx 리버스 프록시 완벽 이해 (0) | 2026.03.12 |
댓글