[Cache] cash 말고! DB cache 활용 전략!

곰민·2022년 11월 25일

올바르게 수행되면 캐시는 응답 시간을 줄이고 데이터베이스의 부하를 줄이며 비용 절감에 효과적이다.
캐시를 활용하는 몇 가지 전략이 있으며 올바른 것을 선택하면 좋은 효과를 볼 수 있다.
캐싱 전략은 데이터를 어떻게 읽고 쓸 것인가에 따라 달라진다.
캐싱 활용 전략에 대해서 학습해 보자!😁

캐시 활용 전략

⚡️ Look aside Cache(Cache aside)

출처 https://velog.io/@hwaya2828/Redis-캐시-전략
출처 https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

Cache에서 데이터가 있는지 체크한다.

Cache에 Data가 있으면 Cache hit! -> Data를 Application에 return 한다.
Cache에서 Data를 못 찾는 경우 Cache miss -> Application은 DB에 쿼리를 날려서 데이터를 읽고 Application에 Data를 반환한 뒤 Cache에 Data를 저장한다.

🚀 특징

읽기에 상당히 적합하다.
반복적인 호출에 적합하다.
캐시 시스템 자체에 대한 장애 대비 구성이 가능하다.
ex) Cache DB인 Redis가 죽더라도 DB에서 데이터를 가져올 수 있다.
- But Redis와 같은 Cache에 Connection이 상당히 많았다면 Redis가 죽고 난 뒤 DB에 일시적으로 Connection이 상당히 발생하므로 DB에 부하가 올 수 있다.
정합성 문제 발생
- Cache Store 와 Data Store 가 가지고 있는 데이터가 서로 다를 수 있다.
- 초기 조회 시 무조건 Data Store를 호출해야 하므로 단건 호출 빈도가 높은 서비스에 부적합하다.
읽기가 많은 경우 상당히 적합하다.

🔥 초기에 데이터가 DB에만 저장되어 있어 처음에 cache miss가 많아지기 때문에 성능 저하의 가능성이 있다.
미리 DB에서 캐시로 데이터를 넣어주는 작업이 필요하고 이를 Cache Warming이라고 한다.

⚡️ Read Through

출처 : https://velog.io/@hwaya2828/Redis-캐시-전략
출처 : https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

캐시는 데이터베이스와 인라인으로 배치되며 Cache Miss가 있는 경우 DB에서 Miss된 데이터를 로드하고 Cache를 채우고 Application으로 반환.
Cache-aside, Read-through 전략은 처음 Read 하는 경우에만 data load를 lazy 하게 진행함.

🚀 특징

읽기가 많은 워크 로드에 적합하다.
Read Through 방식은 Cache Aside 방식과 비슷하지만 차이점이 존재한다.
- 차이점
  1. cache-aside에서는, application은 데이터베이스에서 데이터를 가져오고 캐시를 채우는 역할을 함.
    read-through에서는 위에 로직을 라이브러리가 지원하거나 stand alone 형식의 cache provider가 지원해 줌.
  2. cache-aside와는 다르게, read-through에서 DB에서 직접 Cache를 채우기 때문에 cache의 데이터 모델은 DB의 데이터 모델과 다를 수가 없다.
Read-Through는 동일한 데이터가 여러번 요청될 때 읽기가 많은 워크 로드에 적합함.

⚡️ Write Back(Write Behind)

참조 https://velog.io/@hwaya2828/Redis-캐시-전략
참조 https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

log를 DB에 넣어야 하는 경우에 cache에 몰아 넣어 놓고 한번에 배치 작업으로 DB에 저장하는 로직과 같이 Cache에 데이터를 몰아두고 DB에 한번에 배치작업으로 write 한다.

🚀 특징

Queue의 역할을 한다.
DB에 대한 전체 쓰기를 줄일 수 있기 때문에 비용을 감소할 수 있다.
Data 정합성이 확보된다
단 캐시가 장애가 났을 경우 Data가 유실될 수 있다.
불필요한 리소스가 저장된다.
Write Back 패턴의 경우 Cache Store가 데이터 저장소 역할을 하면서 동시에 Data Store에 Write 부하를 줄이기 위한 Queue의 역할도 한다.
- Database의 부하를 경감 시킬 수 있는 장점이 있다.
- 대체로 쓰기 작업이 많은 경우 적용을 권장한다.
Write Back 패턴의 장점
- 데이터베이스의 일시적인 다운타임을 허용하거나 장애에 대응할 수 있다.
- Cache와 Date Store 간 데이터 정합성 유지하기 유용하다.
- 쓰기 성능을 향상시키고 쓰기 작업량이 많은 워크 로드에 적합하다.
  - read-throught와 결합하면 최근 업데이트되고 엑스스된 데이터를 항상 캐시에 사용할 수 있는 혼합 워크 로드에 적합하다.
Write Back 패턴의 단점
- Cache Store에서 Data Store로 데이터를 전송하기 전에 장애 발생 시 데이터 분실 발생 위험이 있을 수 있음
- 자주 사용되지 않는 데이터가 저장되어 리소스 낭비, Write 작업에 부하 발생할 수 있음
  - *TTL을 꼭 사용하여 사용되지 않은 데이터를 삭제해야 한다
  
  *TTL 이란?
  타임 투 리브(Time to live, TTL)는 컴퓨터나 네트워크에서 데이터의 유효 기간을 나타내기 위한 방법이다.
  TTL은 계수기나 타임스탬프의 형태로 데이터에 포함되며, 정해진 유효기간이 지나면 데이터는 폐기된다.
  컴퓨터 네트워크에서 TTL은 패킷의 무한 순환을 방지하는 역할을 한다.
  컴퓨터 애플리케이션에서 TTL은 캐시의 성능이나 프라이버시 수준을 향상시키는 데에 사용되기도 한다

일부 개발자들은
cache-aside 와 write-back에서 Peak 둘 다 로드 기간 동안 트래픽 spike를 잘 처리하기 위해 Redis를 활용하기도 한다.
대부분 RDBMS에서 스토리지 엔진(InnoDB)은 기본적으로 내부에서 후기입 캐시를 활성화 → 쿼리는 먼저 메모리에 기록되거 결국에는 디스크로 플러시 된다.

⚡️ Write Through

출처 : https://velog.io/@hwaya2828/Redis-캐시-전략
출처 : https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

Application 이 Data를 쓰거나 값을 update 하려고 할 때
1. 응용프로그램은 Data를 Cache에 직접 쓴다.
2. Cache는 DB에 Data를 update 한다.
3. 쓰기가 완료되면 Cache와 Database 모두 동일한 값을 가지며 Cache는 항상 일관성을 유지한다.

🚀 특징

항상 Cache와 DB가 동기화되어 있어 DB 작성할 때마다 Cache에 Data를 추가한다.
Cache와 Back up DB에 업데이트를 같이 하여 데이터 일관성을 유지할 수 있어서 안정적이다.
데이터 유실이 절대로 발생하면 안 되는 상황에 적합하다.
기억장치에 데이터를 기록할 때 cpu 대기시간이 필요하기 때문에 성능이 떨어진다.
사실상 Cache가 자체적으로 많은 작업을 수행하지 않는다.
Wrtie Through 패턴은 Cache Store에도 반영하고 Data Store에도 동시에 반영하는 방식
- Write Back은 일정 시간을 두고 나중에 한꺼번에 저장한다.
- 그래서 항상 동기화가 되어 있어 항상 최신 정보를 가지고 있다는 장점이 있다.
하지만 결국 저장할 때마다 2단계 과정을 거쳐 치기 때문에 상대적으로 느리며 무조건 일단 Cache Store에 저장하기 때문에 캐시에 넣은 데이터를 저장만 하고 사용하지 않을 가능성이 있어서 리소스 낭비 가능성이 있다.
- 이 역시 이를 해결하기 위해 TTL을 꼭 사용하여 사용되지 않는 데이터를 반드시 삭제해야 한다.

⚡️ Write Around

출처 : https://aws.amazon.com/ko/blogs/database/amazon-dynamodb-accelerator-dax-a-read-throughwrite-through-cache-for-dynamodb/

IoT 또는 ad Tech Space의 일부 워크 로드에는 한 번 쓰고 절대 읽지 않는 상당한 양의 데이터가 있고 이런 시나리오에서는 write - through 전략을 사용하는 것이 의미 없는 경우가 많음.
Cache가 읽지 않은 데이터로 채워지면 일반적으로 사용률과 Cache/Catch, miss 비율이 낮아 효용이 감소한다.
쓰기가 DB로 직접 이동하는 쓰기 패턴을 사용할 수 있다.
따라서 읽은 데이터만 캐시 된다.

🚀 특징

읽은 데이터만 캐시에 저장한다.
Write Through보다 빠르다.
데이터 정합성 문제가 발생할 수 있음
요청이 들어오면 DB에 직접적으로 다 저장한 뒤 읽은 데이터만 Cache에 저장됨
속도는 빠르나 Cache에 update 하고 보조 기억장치에는 바로 update 하지 않아 Cache와 보조 메모리의 값이 서로 다른 경우 발생

• ex) 실시간 로그 또는 채팅방 메시지로 사용될 수 있다