서버에서 데이터 조회 및 저장 성능을 최적화하기 위해 캐시를 활용하는 것은 필수적이다. 하지만 단순히 캐시를 사용하는 것만으로는 충분하지 않으며, 데이터의 변경 빈도와 일관성 유지 방식에 따라 적절한 캐시 패턴(Cache Pattern)을 선택해야 한다. 이번 글에서는 MAFI4 프로젝트 대규모 사용자 대비 피드백에 관해, 캐시 데이터 활용을 해법으로 적용하기 전 간단한 패턴, 예시등을 정리하였다.
1. 캐시를 사용하는 이유
캐시는 일반적으로 메모리(RAM) 기반 저장소인 Redis, Memcached 등을 활용하며, 데이터베이스(DB)는 디스크 기반 저장소이다.
캐시(Redis 등) vs. 데이터베이스(DB) 비교
| 비교 항목 | 캐시 (메모리 기반) | 데이터베이스 (디스크 기반) |
| 속도 | 매우 빠름 (나노초 단위) | 상대적으로 느림 (밀리초 단위) |
| 저장 방식 | RAM(휘발성) | 디스크(비휘발성) |
| 데이터 일관성 | 최신 데이터 반영이 어려울 수 있음 | 강한 일관성 유지 가능 |
| 주요 역할 | 빠른 데이터 조회 및 응답 속도 최적화 | 데이터 영구 저장 |
캐시는 RAM을 기반으로 동작하기 때문에, 데이터베이스보다 훨씬 빠른 속도로 데이터를 제공할 수 있다. 그러나 휘발성(Volatile)이기 때문에 서버가 재부팅되면 데이터가 사라질 수 있으며, 항상 최신 데이터를 유지하는 것이 어려울 수도 있다.
이러한 특성을 고려하여, 캐시는 주로 조회가 빈번한 데이터의 성능 최적화를 위해 사용되며, 적절한 캐시 패턴을 선택하는 것이 중요하다.
Cache Aside Pattern (캐시 어사이드 패턴)
적절한 경우
- 데이터가 자주 변경되지는 않지만, 조회 요청이 많은 경우
- 캐시 적중률(Cache Hit Rate)이 높은 환경
- 실시간성이 크게 요구되지 않는 경우
예제
- 네이버 웹툰, 리디북스의 "인기 작품 목록" 조회
- 인기 작품은 자주 조회되지만 실시간으로 자주 바뀌지는 않는다.
- 사용자가 인기 작품을 조회할 때 캐시에서 먼저 가져오고, 없으면 DB에서 가져와 캐시에 저장한다.
- TTL(예: 10~30분)을 설정하여 주기적으로 캐시를 갱신하며, TTL 설정에 따라 실제와 다른 정보를 볼 가능성이 있지만 치명적이지 않다.
- 쇼핑몰의 "상품 상세 페이지" 조회
- 상품 정보(가격, 설명 등)는 자주 조회되지만, 변경은 빈번하지 않다.
- 가격이 바뀌었을 때만 캐시를 갱신하면 된다.
- 다만, 가격 정보는 실시간 반영이 중요할 수 있어 TTL과 관계없이 가격 변경 시 캐시를 즉시 갱신하는 로직이 필요하다.
- 온라인 게임의 "유저 경험치 및 랭킹 시스템"
- 유저의 경험치와 랭킹 정보는 자주 조회되지만, 변경은 특정 이벤트(경기 종료, 일정 시간마다) 시 발생한다.
- 매번 DB에서 계산하기보다는 일정 간격(예: 1시간)으로 캐시에 저장하여 성능을 최적화할 수 있다.
Write Through Pattern (라이트 쓰루 패턴)
적절한 경우
- 데이터가 자주 변경되며, 조회 요청도 빈번한 경우
- 캐시와 DB의 일관성이 중요한 환경
- 데이터가 실시간으로 반영되어야 하는 경우
예제
- 쇼핑몰의 "장바구니 정보" 저장
- 사용자가 장바구니를 업데이트할 때, 캐시에 먼저 저장하고 동시에 DB에도 반영한다.
- 이를 통해 데이터 일관성을 유지할 수 있다.
- SNS의 "유저 프로필 정보" 관리
- 닉네임, 상태 메시지 등은 자주 변경되지만 즉시 반영되어야 한다.
- Write Through 패턴을 적용하면 프로필 변경 시 캐시와 DB에 동시에 업데이트되어 실시간성이 유지된다.
- 금융 서비스의 "계좌 잔액 조회"
- 계좌 잔액은 정확한 값이 유지되어야 하므로, 캐시가 오래된 데이터를 제공해서는 안 된다.
- Write Through 패턴을 사용하여 계좌 잔액 변경 시 DB와 캐시에 즉시 반영한다.
Write Back Pattern (라이트 백 패턴)
적절한 경우
- 데이터 변경이 매우 빈번하지만, 약간의 지연을 허용할 수 있는 경우
- 쓰기 성능을 극대화해야 하는 환경
- 시스템 장애 발생 시, 데이터 유실을 감수할 수 있는 경우
예제
- 온라인 게임의 "전투 로그 저장"
- 실시간으로 많은 전투 로그가 기록되지만, 즉시 DB에 저장할 필요는 없다.
- 캐시에 먼저 저장한 후, 일정 주기마다 배치 처리로 DB에 반영하여 성능을 최적화한다.
- 대규모 로그 시스템 (웹 트래픽 로그, 애플리케이션 로그 등)
- 웹 서버의 트래픽 로그나 API 호출 기록은 초당 수천 건 이상 발생할 수 있다.
- 모든 요청을 즉시 DB에 저장하면 부하가 크므로, Write Back 패턴을 사용해 캐시에 먼저 저장한 후 일정 시간마다 배치 처리한다.
- IoT 시스템의 센서 데이터 저장
- 센서에서 지속적으로 데이터를 수집하는 경우, 모든 데이터를 즉시 DB에 저장하면 부담이 크다.
- 캐시에 먼저 저장하고, 주기적으로 DB에 반영하여 성능을 최적화한다.
2. 결론
캐시 패턴을 선택할 때는 데이터 변경 빈도와 일관성 요구 사항을 고려하는 것이 중요하다.
- 조회가 많지만 변경이 적다면 → Cache Aside
- 변경이 자주 발생하며 실시간 반영이 필요하다면 → Write Through
- 변경이 매우 빈번하지만, 즉시 반영이 필요하지 않다면 → Write Back
| 패턴 | 적절한 환경 | 주요 특징 |
| Cache Aside | 조회가 빈번하지만 변경이 적은 데이터 | 필요할 때만 DB에서 캐시에 로드, TTL 설정 가능 |
| Write Through | 변경이 빈번하고 실시간 일관성이 중요한 데이터 | 변경 시 캐시와 DB를 동시에 업데이트 |
| Write Back | 변경이 매우 빈번하지만, 지연 저장이 가능한 데이터 | 캐시에 먼저 저장 후, 일정 주기로 DB 반영 |