캐시(Cache) 적용 패턴 및 관리 전략

캐시(Cache) 적용 패턴 및 관리 전략

Cache-Aside: Cache 분리 (별도 관리)

캐시는 데이터베이스와 직접 연결되지 않고, 애플리케이션이 주체가 된다. 애플리케이션이 요청을 받으면, 데이터가 캐시에 있는지 먼저 검사를 하며, 그 결과(캐시에 데이터가 로딩되어 있는지 여부)에 따라 다음 액션이 결정된다. 캐시에 데이터가 없다면, 애플리케이션이 캐시에 데이터를 업데이트 한다. 캐시에 대한 의존성이 낮으므로, 캐시가 다운되더라도 원천 데이터베이스로 서비스를 계속할 수 있다. 읽기 요청이 많은 경우에 적합하다.

 

Read-Through: Cache를 통해서 읽기

애플리케이션이 직접 바라보는 것은 데이터베이스가 아니라 캐시가 된다. through 라는 단어가 나타내듯이 캐시가 메인이다. 따라서, 캐시가 주 데이터스토어로 인식된다. 데이터베이스로 동기화하는 몫은 캐시에 위임된다. 최초 데이터 로딩은 미스가 나며, 그 때 데이터가 로딩된다. 그 이후는 캐시에서 처리를 하게 된다. 마찬가지로 읽기요청이 많은 경우를 처리하는데 적합하다. 첫 요청의 캐시 미스를 방어해야 한다면 스케쥴 작업 등을 통해 미리 캐시를 warm up 시켜놓기도 한다.

 

Write-Through: Cache를 통해서 쓰기

Read-Through와 마찬가지로 애플리케이션이 직접 바라보는 것은 데이터베이스가 아니라 캐시가 된다. 마찬가지로 캐시가 주 데이터스토어의 역할을 수행한다. 데이터베이스로 동기화하는 몫은 캐시에 위임된다. 데이터가 캐시와 DB에 모두 반영이 되었을 때를 정상적인 쓰기 오퍼레이션이 성공한 것으로 간주한다. 캐시와 데이터베이스에 모두 데이터를 기록하기 떄문에 신뢰성이 더 높아진다. 즉, 장애발생시 데이터를 유실할 가능성을 낮춰준다. 게다가, 캐시와 데이터베이스의 데이터/ 상태 불일치 문제도 해결할 수 있다. 그러나, 캐시와 데이터베이스 두 곳에 모두 기록해야 하므로, 쓰기 레이턴시가 증가한다. 요청 클라이언트에게 피드백을 하는 시점은 캐시와 데이터베이스를 모두 업데이트한 후가 된다. 기록한 데이터를 다시 자주 읽는 경우에 좋다.

 

Write-Around: (Cache 피해서) DB에만 쓰기

쓰기 요청이 캐시를 거치지 않고, 데이터베이스에 직접 전달된다. 데이터는 쓰기 오퍼레이션에 의해 캐시에 업데이트 되지 않는다. 캐시에 데이터가 로딩되는 시점은, 언젠가 해당 데이터가 캐시에 요청이 되고, miss가 발생했을 때이다. 즉, 읽은 데이터만 캐시에 로딩된다. 기록하는 데이터가 자주 사용되지 않는 경우에 적합하다.

 

Write-Behind (Write-Back): Cache에 나중에 쓰기

쓰기 요청은 캐시까지만이다. 캐시에 데이터가 갱신되면 쓰기 요청은 완료된다. 그리고, 별도의 서비스 등을 통해 캐시의 내용이 나중에 데이터베이스로 동기화 된다. 캐시의 flush 정책(LRU, FIFO, LIFO 등)에 따라 데이터가 데이터베이스로 저장된다. 쓰기 요청이 많은 경우에 적합하다. 캐시의 내용을 데이터베이스에 몰아서 수행하므로, 쓰기 비용을 절약할 수 있다. 바꿔 말하면, 데이터를 모아뒀다가 한번에 기록하므로 그 사이에 장애가 발생하면 데이터의 유실이 발생한다.

 

Refresh Ahead: Cache를 미리 갱신하기

자주 사용되는 데이터에 대해, 캐시가 만료되기 전에 미리 TTL을 갱신한다. 캐시 miss가 발생한 후, 다시 데이터를 로딩하는 낭비를 막을 수 있다.

 

반응형

 

참고

Memcached vs. Redis - 특징 비교

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html