Cache-Aside 패턴이란
Cache-Aside는 애플리케이션이 캐시와 데이터베이스(DB)를 함께 사용할 때 가장 널리 쓰이는 방식입니다. 이름 그대로 캐시를 ‘옆에 두고(aside)’ 애플리케이션 코드가 직접 캐시와 DB를 제어하는 구조입니다. 캐시 서버(Redis, Memcached 등)가 자동으로 DB와 동기화해주는 게 아니라, 개발자가 로직 안에서 언제 캐시를 읽고 언제 채울지 직접 작성해야 합니다. 그래서 ‘Lazy Loading(지연 로딩)’ 패턴이라고도 불립니다.
비유하자면 도서관에서 자주 찾는 책을 사서 개인 책상 위에 올려두는 것과 비슷합니다. 필요한 책이 책상 위(캐시)에 있으면 바로 꺼내 보고, 없으면 서고(DB)에 가서 빌려온 뒤 다음에 또 찾을 걸 대비해 책상 위에 올려두는 것입니다.
동작 원리와 예시
Cache-Aside의 동작은 크게 두 가지 흐름으로 나뉩니다.
- 조회(Read): 먼저 캐시를 확인한다. 데이터가 있으면(Cache Hit) 바로 반환하고, 없으면(Cache Miss) DB에서 조회한 뒤 그 결과를 캐시에 저장하고 반환한다.
- 수정(Write): 데이터를 변경할 때는 DB를 먼저 업데이트하고, 관련된 캐시 데이터는 삭제(invalidate)한다. 다음 조회 시 자연스럽게 최신 데이터가 캐시에 다시 채워진다.
의사코드로 표현하면 다음과 같습니다.
data = cache.get(key)
if data is None:
data = db.query(key)
cache.set(key, data)
return data
수정 시에는 db.update(key, value); cache.delete(key) 형태로 처리해 캐시와 DB의 불일치를 최소화합니다.
실무에서 왜 쓰는지
Cache-Aside가 실무에서 널리 쓰이는 이유는 구현이 단순하면서도 효과가 확실하기 때문입니다. 자주 조회되지만 자주 바뀌지는 않는 데이터(상품 정보, 사용자 프로필 등)에 적용하면 DB 부하를 크게 줄이고 응답 속도를 높일 수 있습니다. 또한 캐시 서버에 장애가 생겨도 DB에서 직접 조회하는 경로가 남아 있어 서비스 전체가 멈추지 않는다는 장점도 있습니다.
다만 캐시와 DB 데이터가 잠깐 동안 불일치할 수 있는 시점이 존재하며, 캐시 삭제 로직을 빠뜨리면 오래된 데이터가 계속 반환되는 문제가 생길 수 있습니다. 그래서 TTL(유효시간)을 함께 설정해 일정 시간이 지나면 캐시가 자동 만료되도록 하는 경우가 많습니다. 결국 Cache-Aside는 ‘완벽한 실시간 일관성’보다는 ‘충분히 빠르고 실용적인 성능 개선’을 목표로 하는 패턴이라고 이해하면 됩니다.