캐싱 전략

성능 최적화를 위해 Redis 같은 캐시 레이어를 붙이다보면, 또 이런데서 나오는 관리포인트나 딜레마가 발생하기 시작한다.
결국 데이터소스가 2개 이상이 되는 것이기 때문이다.

여기에서는 상황에 따라서 몇가지 접근법이 존재한다.

Cache Aside

가장 일반적으로 많이 사용되는 캐싱 전략이다.

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

1. 앱은 일단 캐시에 원하는 데이터가 있는지를 검사한다.
2. 캐시가 있다면 그걸 바로 반환한다.
3. 캐시가 없다면 DB로부터 데이터를 만들어서 캐시에 저장하고, 반환한다.

여기서 캐시 저장은 TTL 기반으로 수명을 두고서 사용하기도 한다.

읽기가 많으면서도, 접근하는 데이터의 분포가 몰려있는 패턴에 적합하다.

그리고 read 시의 성능이 균일하지 않다는 단점이 있지만, lazy한 특성 탓에 캐시 용량을 컴팩트하게 유지하기는 가장 좋다.
read되지 않으면 캐시에도 저장하지 않기 때문이다.

Read Through

Read Through는 Cache Aside와 비슷하면서도 크게 다른 접근법이다.

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
DB를 기반으로 캐시를 만들고, 앱이 그 캐시를 읽는다는 점에서는 Cache Aside와 비슷하지만, 앱이 DB와 직접 연결되지 않는다는 것이 다르다.

별도의 마법같은 처리를 통해서 캐시가 최신상태를 유지한다는 가정 하에서, 그냥 캐시에서만 값을 읽어오는 것이다.
그래서 캐시의 최신성을 보장하는 Write Through나 Write Back 패턴과 함께 사용할 때 의미가 있다.

하지만 캐시를 모두 미리 저장해야한다는 전제조건이 있기 때문에, 모든 데이터를 균일하게 사용하는게 아니라면 Cache Aside에 비해 캐시 저장공간 낭비가 심할 수 있다는 것이 단점이다.

Write Through

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
Write Through는 조금 다르게 캐시의 관리를 바라보는 접근방법이다.
DB를 수정하고 캐시를 맞추는게 아니라, 캐시를 수정하고 DB를 맞춘다.

이러면 캐시가 항상 최신 상태라는 것을 보장할 수 있기 때문에, 읽기 시에 캐시를 수정하는 부담을 줄일 수 있다. Read Through를 사용할 수 있는 것이다.

가령, Redis와 RDB를 스토리지로 사용하는 상황에서 캐시 데이터를 수정한다면, Redis의 캐시를 업데이트하고 RDB를 똑같이 업데이트해서 일관성을 유지하는 것이다.
대신 캐시는 최신이지만 모종의 이유로 DB에는 동기화되지 않는 골치아픈 문제가 발생할 수는 있다.

읽기는 빠르게 만들 수 있지만, 비교적 느린 DB 레이어에도 수정을 동기적으로 하기 때문에 쓰기 작업 자체에 대해서는 레이턴시를 줄이는 데 한계가 있다.

Write Behind

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
Write Back이라고도 부른다.

Write Through가 캐시를 먼저 수정하되 정직하게 데이터소스를 동시에 업데이트하는 방법이라면, Write Behind는 비동기적으로 느슨하게 동기화를 맞춘다.

우선 캐시를 먼저 수정하고, 나중에 알아서 캐시 수정사항이 DB에 저장되도록 하는 것이다. 사실 CDC의 개념과 크게 다르지 않다.

대표적으로 Redis는 엔터프라이즈 옵션을 쓸 경우에 한해 이러한 기능을 제공하고, RedisGears 같은 확장을 사용할 수도 있다.

이건 쓰기가 매우 많은 패턴에 적합하다.
하지만 쓰기가 그리 많지 않다면 Read Through + Write Through로도 충분하다. 오히려 관리포인트만 증가할 것이다.

하드웨어 수준 캐싱 전략

위에서는 Redis 같은 소프트웨어 시스템 수준 캐싱을 위주로 이야기했지만, 사실 이건 하드웨어 캐시 수준에서도 사용하는 개념이다.

Redis를 CPU의 캐시 메모리로, DB를 일반 메모리로 대치시켜도 동일한 이야기를 할 수 있다.

https://youtu.be/GhEYqA5dxD4?si=-t1v2RzE8TwxUp4T

현대의 CPU들은 대부분 Write Back 기반의 캐싱 전략을 사용한다.
캐시 수정할때마다 램 수정한다고 기다리면 속이 터지기 때문이다...

참조
https://cyber0946.tistory.com/m/81
https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/gears-v1/python/recipes/write-behind/
https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
https://codeahoy.com/learn/tutorials/distributed-caching-at-scale/