캐시 읽기 전략

1. Look Aside

어떠한 데이터를 조회할 때 우선 캐시를 확인한 뒤, Cache Miss 발생시 DB에 접근하여 읽어온 뒤 캐시에 저장하고 데이터를 반환한다. 이는 가장 범용적인 캐싱 전략이며, 읽기 요청이 많은 경우에 적합하다.

Redis에 장애가 발생해도 그 외 DB에서 데이터를 읽어올 수 있으므로 전체에 치명적인 영향을 주지는 않는다는 장점이 있다. 또한 Hit될 경우 DB에 접근하지 않으므로, DB 액세스 수를 줄일 수 있다.

반면 Cache Miss의 경우 DB로 재요청한다. 만약 Cache Hit 발생시 DB까지 확인하지 않으므로, Hit된 이 캐시 데이터가 과연 최신 데이터인지에 대한 고려가 필요하다. 최신성 보장을 위해 적절한 쓰기 전략과 조합하거나 TTL을 설정하는 등의 작업이 필요하다.

2. Read Through

데이터를 읽을 때 무조건 캐시 데이터만 조회하는 방식이다. 만약 Cache Miss가 발생하면 DB에서 해당 데이터를 조회하여 캐시에 저장한다. 뉴스 기사 읽기와 같이 동일한 데이터가 여러 번 요청되는 경우에 적합하다.

캐시 쓰기 전략

1. Write back

쓰기 작업을 우선 캐시에만 업데이트한 뒤 특정 시점마다 한 번에 DB에 저장하는 방식이다. 이 때 DB에 저장된 데이터는 캐시에서 삭제한다?? 언제부터 삭제된건지 명확한 구분 가능?

후기입 방법은 잦은 쓰기 작업은 우선 Redis로 처리하고 DB의 쓰기 작업에 대한 부담은 줄일 수 있으므로, 쓰기 작업이 잦을 경우 유리하다.

가장 대표적인 예시는 조회수 캐싱이다. Youtube와 같은 플랫폼에서는 조회수가 매우 빠르게 증가한다. 이 경우 캐시에 조회수를 저장하고 주기적으로 DB에 동기화여 쓰기 부담을 줄인다.

그러나 DB에 쓰기 전 캐시 장애가 발생하면 데이터 유실이 발생할 수 있다는 단점이 있다. 만약 유실되면 안되는 중요한 데이터라면 다른 쓰기 방식을 선택하거나 신뢰도 높은 아키텍처를 구축해야 한다.

이러한 후기입 방식은 대부분의 RDB스토리지 엔진에서도 내부적으로 사용하고 있다. 쿼리를 실행할 떄 우선 메모리에 기록해뒀다가 Flush입력시 한번에 반영되는 것도 후기입의 일종이다.

Write back 캐싱 전략은 캐시에 우선 쓰기 때문에 캐시 데이터가 최신성을 보장한다는 특징이 있다. 따라서 캐시를 통해서 데이터를 조회하는 Read Through 읽기 전략과 조합하면 언제나 가장 최근 업데이트된 데이터를 캐시에서 사용할 수 있어, 일관성에 대한 고민을 하지 않아도 된다.

2. Write Through

Read Through와 유사하다. 다만 읽느냐 쓰느냐의 차이만 존재한다. 먼저 캐시에 기록한 다음 바로 DB에 저장하는 방식이다.

얼추 보면 Write Back과 유사해 보이지만, 한가지 큰 차이점은 바로 ‘일괄 처리’인지 ‘실시간 처리’인지의 차이이다.

Write Back의 경우 일정 간격마다 모아서 DB에 동기화하지만, Redis는 쓰기 작업 발생시마다 DB에도 바로 이어서 쓴다.

이 역시 캐시는 항상 최신 정보를 가지므로 일관성을 보장한다는 장점이 있으나, 만약 Redis에 쓰기 작업을 마친 후 DB에 쓰기 전 서버 장애 발생시 이 또한 일관성을 보장하지 못할 수 있다.

또한 저장할 때마다 Redis와 DB 두 단계를 모두 거쳐야 하므로, 재사용되지 않을 수도 있는데 무조건 캐시에 저장한다는 단점이 있다.

이는 한정된 메모리를 낭비할 가능성이 있으므로 TTL을 사용하여 메모리를 관리하는 것을 권장한다.

3. Write Around

모든 데이터를 DB에 저장하고, 이후 조회시 Cache Miss가 발생하는 경우에만 캐시에 저장한다.

이는 자주 사용되지 않는 데이터는 캐시에 로드되지 않고, 반드시 한번 이상 조회된 데이터만 캐시에 로드된다는 장점이 있으나 캐시 데이터와 DB데이터의 일관성을 보장하지는 못한다. 만약 이미 캐시에 로드된 데이터를 DB에서 수정한다면 일관성이 깨진다. 일관성을 보장하기 위한 전략을 고민해야 한다.

Look Asize와 Write Around는 가장 일반적인 전략 조합이다.