Redis : Cache Strategy pattern

 

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. 그림에는 Redis가 표시되어 있지만 Ehcache, Memcached, Hazelcast, Caffeine Cache 등 다양한 구현체로 이를 구현할 수 있습니다. 

 

 

 

Read Cache Strategy

 

Look Aside Cache

서비스에 사용자 조회 요청이 들어오면 우선 Cache에 저장된 데이터가 있는지 확인하는 전략입니다.

• 초반 Cache 성능 향상 및 트래픽 급증 대비를 위해 (Cache miss 감소) cache warm up을 수행하는 것이 좋습니다.

 

이 방식은 Cache에 장애가 발생하더라도 데이터베이스에 요청을 전달함으로써 Cache 장애로 인한 서비스 중단 발생을 대비할 수 있습니다. 하지만 조회 요청이 많을 경우 Cache에서 발생한 장애가 데이터베이스로 전파되어 전체 장애가 발생할 수 있습니다..

• 그리고 Cache에서 사용되는 데이터 모델이 데이터베이스의 모델(테이블)과 다른 것 또한 하나의 특징입니다. 예시로 최근에 조회한 글의 조회 수라거나, Query를 통해 만들어진 결과가 Cache에 저장될 수 있습니다.
• Spring Abstraction Cache module에서 제공하는 기본 구현체가 이 방식을 따르고 있습니다.

 

Cache warm-up or Cache warming : 미리 Cache로 데이터베이스의 데이터를 밀어 넣어두는 작업을 의미합니다. 이 작업을 수행하지 않는다면 서비스 초반, 트래픽 급증 시 발생하는 대량의 Cache miss + Cacheable 작업으로 인해 Cache와 데이터베이스의 부하가 급증하는 Thundering Herd가 발생할 수 있습니다.

물론 warm-up을 통해 추가되었던 Cache가 expire 된다면 다시 Thundering Herd가 발생할 여지가 있으므로 이를 원천적으로 해결하기 위해서는 Probabilistic Early Recomputation 방식 등과 같이 Cache의 TTL이 만료되기 전에 갱신시키는 방법 등을 고려하여야 합니다.

Thundering Herd는 모든 지점에서 발생되는 것은 아니며, 서비스의 첫 페이지와 같은 대부분의 조회가 몰리는 지점에서 주로 발생됩니다.

 

 

 

Read Through (Inline-Cache)

서비스에 사용자 조회 요청이 들어오면 Cache를 조회하고 Cache miss가 났을 때 데이터베이스에 저장된 데이터를 조회하여 Cache를 업데이트한 뒤 값을 반환하는 전략입니다. 

• 이 방식 또한 서비스 운영 초반에 cache warm up을 수행하는 것이 좋습니다.

 

이 방식은 직접적인 데이터베이스 접근을 최소화하고 Read에 대한 소모되는 Resource를 최소화할 수 있습니다. 하지만 Cache에 장애가 발생하였을 경우 이는 바로 서비스 전체 중단으로 빠질 수 있습니다. 그렇기에 Cache를 제공하는 Redis과 같은 구성 요소를 Replication 또는 Cluster로 구성하여 가용성을 높여야 합니다.

• 이 방식은 앞서 설명한 Look Aside 방식과는 달리 데이터베이스와 동일한 데이터 구조를 지니며, Query의 대상(모델)은 Cache에 저장되어 있습니다.

 

 

 

 

Write Cache Strategy

 

Write Around

데이터베이스에 데이터를 저장하고 Cache miss가 발생했을 때 Cache로 데이터를 가져오는 쓰기 전략입니다. 이는 Look aside cache의 Cache miss 발생 시 흐름을 이야기합니다.

• Cache miss가 발생하기 전에 데이터베이스에 저장된 데이터가 수정되었을 때, 사용자가 조회하는 Cache와 데이터베이스 간의 데이터 불일치가 발생하게 됩니다.

 

데이터 불일치를 방지하기 위해서는 데이터베이스에 저장된 데이터가 수정, 삭제될 때마다 저장해둔 Cache 또한 삭제하거나 변경해야 하며 데이터 수정 사항이 빈번할 수록 Cache의 expire를 짧게 조정하는 식으로 대처하여야 합니다.

데이터 수정, 삭제 요청이 너무 빈번한 경우 Cache를 변경하거나 삭제하는 비용이 조회하는 비용보다 커지게 될 수 있기 때문에 잘 고려하여 적용하여야 합니다.

 

 

 

Write Through

데이터베이스와 Cache에 동시에 데이터를 저장하는 전략입니다. 이 방법은 Write Around 전략에서 발생하는 데이터 불일치 문제가 발생하지 않지만 (Cache에도 계속 최신의 데이터가 반영되기 때문에) 매 요청마다 2번의 Write가 발생하게 됨으로써 빈번한 생성, 수정이 발생하는 서비스 영역에서는 성능 이슈(부하)가 가중될 수 있습니다.

• 이 전략을 Read through 전략과 결합하여 사용한다면 최신 데이터 보장을 통해 Cache의 수정이나 변경을 하지 않으면서도 안정적으로 Read Through 전략의 이점을 끌어올릴 수 있습니다.

 

 

 

Write Back

Cache에 데이터를 저장, 반영하고 일정 주기(스케줄링)의 배치 작업을 통해 데이터를 데이터베이스에 반영하는 전략입니다.

• 이 방법은 Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스 영역의 경우 (data set이 큰 경우) 적용해볼 수 있는 방법입니다. (데이터베이스를 조회하지 않고 지속적인 접근이 가능하도록 합니다.)
• 데이터의 불일치나 조회 요청으로 인한 서비스 부하는 발생하지 않으나, In-memory에 데이터가 일정 기간 저장되기 때문에 장애가 발생하였을 때 데이터 손실이 발생할 수 있습니다.
  • 이 또한 Replication이나 Cluster 구조를 적용함으로써 Cache 서비스의 가용성을 높여야만 합니다.

 

이 전략을 통해 새로운 데이터를 추가하거나 변경하는 성능을 끌어올릴 수 있고 또한 읽어오는 데이터의 크기를 의식하지 않을 수 있습니다. 부가적으로 데이터베이스 장애가 발생하더라도 지속적인 서비스를 제공할 수 있도록 보장합니다.

 

 

 

 

참고 자료

• https://www.ehcache.org/documentation/3.3/caching-patterns.html
• https://www.computerweekly.com/feature/Write-through-write-around-write-back-Cache-explained
• https://docs.oracle.com/cd/E15357_01/coh.360/e15723/cache_rtwtwbra.htm#COHDG5177