들어가기에 앞서
캐시(Cache)란?
자주 사용하는 데이터를 미리 복사해 두는 임시 저장소.
자주 사용하는 데이터의 사본을 저장해 두고, 데이터나 값에 대한 요청이 들어오면 빠르게 처리할 수 있도록 도와주어 데이터를 가져오는 시간이 오래 걸리거나 재계산하는 시간이 오래 걸리는 작업 효율화에 도움을 준다.
예시
응답 속도 향상 + 서버 부하 감소 + 대규모 트래픽 분산 처리 + 외부 API 호출 비용 절감 효과를 위해 캐시를 활용한 서비스들
-
인스타그램 : 피드에 들어갔을 때 친구 게시물, DM, 릴스, 내 프로필 정보 등의 데이터를 미리 캐싱해 두고, 조회 요청이 들어오면 빠르게 읽을 수 있도록 해준다.
-
셋로그 : 메인 화면에서 시간대별 친구 영상 데이터와 영상에 대한 댓글 데이터를 미리 캐싱해 두고, 조회 요청이 들어오면 빠르게 읽을 수 있도록 해준다.
캐시 불일치 (Cache Inconsistency)
캐시 불일치는 원본 데이터베이스에 저장된 데이터와 캐시에 저장된 데이터가 서로 다른 상황
캐시와 DB의 불일치는 왜 발생하나
서버 간 네트워크 문제, 비동기 처리로 인한 DB 저장과 캐시 갱신 간의 지연, 동시성 문제 등
캐시는 DB의 데이터를 복사하여 저장하는 임시 저장소이기에 원본 데이터인 DB의 값이 변경되었을 때 캐시의 데이터가 함께 즉시 갱신되지 않으면 발생한다.
문제 해결을 위한 캐시 전략
읽기(Read) 전략
Cache Aside (Lazy Loading)
캐시를 사용할 때 클라이언트가 데이터를 요청하면, 서버는 먼저 캐시에서 데이터를 조회한다.
이때 찾고자 하는 데이터가 캐시에 존재하면(Cache Hit) 캐시에서 데이터를 반환하고, 데이터가 존재하지 않으면(Cache Miss) 원본 데이터베이스(DB)에서 데이터를 조회하여 반환한 뒤 해당 데이터를 캐시에도 저장한다.
쓰기(Write) 전략
Write Through
원본 데이터에 대한 변경분이 생긴 경우, 매번 캐시에 해당 데이터를 찾아 함께 변경하는 방식.
2번 쓰기가 발생하지만, 캐시는 항상 최신 데이터를 가지게 된다.
그러나, 무작정 데이터를 갱신하거나 저장하는 방식은 리소스 낭비가 될 수 있다.
사용자가 잘 사용하지 않는 데이터마저 캐시에 저장되기 때문이다.
따라서 해당 방식을 사용할 경우, 캐시가 오랫동안 사용되지 않으면 자동으로 삭제되도록 TTL(Time To Live)과 같은 만료 시간을 함께 사용하는 것이 좋다.
Cache Invalidation
원본 데이터에 대한 변경분이 생긴 경우, 캐시 데이터를 만료시키는 방식
Write Through 방식의 단점을 보완한 방식이며 캐시에 데이터가 삭제되니 캐시 불일치에 대한 걱정은 하지 않아도 된다.
Cache Miss 증가 → DB 접근률 증가 → DB 부하로 이어질 가능성이 있고
캐시 재생성 시간 증가로 인해 사용자가 체감하는 서비스 이용시간이 느릴 것이다.
Write Back (Write Behind)
원본 데이터에 대한 변경분이 생긴 경우, 캐시를 먼저 업데이트한 이후 추후에 원본 데이터를 변경하는 방식
즉, 디스크 쓰기 작업을 비동기 작업으로 수행하여 성능을 개선하는 방식이다.
이 방식은 쓰기 작업이 빈번하며 일시적인 캐시 불일치를 허용하는 서비스에서 유용하게 사용될 가능성이 높다. (데이터를 DB에 저장하는 것보다 캐시 저장이 훨씬 빠르기 때문)
일관성 수준 선택
강력한 일관성(Strong Consistency) vs 결과적 일관성(Eventual Consistency)
| 구분 | 강력한 일관성 (Strong Consistency) | 결과적 일관성 (Eventual Consistency) |
|---|---|---|
| 특징 | 모든 사용자가 즉시 최신 데이터를 조회 가능 | 일정 시간이 지나면 최종적으로 데이터 일치 |
| 장점 | 높은 데이터 정확성 보장 | 높은 성능과 확장성 |
| 단점 | 성능 저하 및 시스템 부하 증가 가능 | 일시적인 데이터 불일치 발생 가능 |
| 적합한 서비스 | 금융, 결제, 재고 관리 | SNS, 조회 수, 추천 시스템, 통계 데이터 |
| 주로 사용하는 캐시 전략 | Write Through, Cache Invalidation | Cache Aside, Write Back (Write Behind) |
| 우선 가치 | 데이터 정확성 | 성능 및 확장성 |
서비스 특성에 따라 데이터 정확성을 우선할지, 성능과 확장성을 우선할지 적절한 캐시 전략과 일관성 수준을 선택하는 것이 중요하다.
결론
Q. 캐시를 도입하면 데이터가 DB와 달라지는 문제가 생기곤 하는데, 이런 불일치는 왜 발생하고 어떻게 해결하면 좋을까요?
A. 캐시는 DB의 데이터를 복사하여 저장하는 임시 저장소이기 때문에 원본 데이터인 DB의 값이 변경되었을 때 캐시의 데이터가 함께 즉각 갱신되지 않으면 캐시불일치가 발생합니다.
이러한 불일치 문제를 해결하기 위해서는 캐시와 DB 간 데이터 일관성을 유지할 수 있는 읽기 및 쓰기전략이 필요합니다.
예를 들어, 강력한 일관성이 필요한 경우에는 Write Through나 Cache Invalidation 전략을 사용하여 캐시와 DB의 데이터를 최대한 동일하게 유지하고
성능과 확장성이 더 중요한 서비스에서는 Cache Aside, Write Back(Write Behind)과 같은 결과적 일관성 기반 전략을 사용해야 합니다.
이러한 전략들을 서비스 특성에 맞게 잘 선택한다면
캐시 불일치 문제를 완화할 수 있으며,
상태 기반 렌더링과 대규모 트래픽 처리 등 사용자 경험에 최적화된 서비스를
효율적으로 구현해 나갈 수 있을 것입니다.
이상!
