[Cache] Cache 전략(read, write)

1. 서비스의 특징 생각하기

• wrtie 多, read less (ex : 시계열 로그)
• one write, lot read (ex : 유저 프로필)
• everytime static info return (ex : 검색 결과)

서비스의 특징에 따라서 캐싱 전략 역시 달라진다.

 

2. Cache 전략

2-1) Read 전략

[1] Cache-Aside (보조 캐시)

• 지연로딩 방식
• cache는 app과만 통신한다.
• app이 DB조회, 캐시 갱신 직접 관리

Flow : app은 요청을 받은 후 캐시와 우선 통신한다. 정상 데이터의 경우(cache hit) 그대로 응답한다.
만약 cache data에 miss가 났을 경우(cache miss) DB와 통신하며, 통신된 DB데이터를 응답과 동시에 cache에 save한다.

 

활용 : read 작업이 많은 경우에 적합

 

장점 :

• 캐시 장애 내구성이 뛰어남. 캐시 다운시 DB에 접근 가능하기에
• 캐시의 데이터 모델을 독립적, 효율적으로 설계할 수 있음. 복잡한 쿼리가 자주 조회되는 경우 쿼리결과를 특정 key값과 매칭하여 캐시에 저장해 빠르게 찾을수있음

주의점 :

• 캐시와 DB가 app을 중심으로 분리되어있기 때문에 DB데이터와 캐시 데이터가 불일치할 수 있음. 이를 위해 TTL(Time To Live)을 설정하여 TTL 만료전까지는 오래된 데이터라도 통과시킴

대표 tool : Memcached, Redis

 

 

[2] Read-Through Cache

• 지연로딩 방식
• app, cache, DB 직렬구조
• 캐시단에서 DB조회, 캐시갱신이 처리됨
• 캐시와 DB가 반드시 같은 구조여야함

활용 : one write, lot read에 적합함

 

주의점 : 데이터가 처음 요청될 때는 반드시 캐시 미스가 발생하며, 이때 캐시를 채우는 추가적인 시간이 소요됨. 캐시 워밍업 or 예열을 해 주요 데이터를 미리 캐시에 로드시켜놓음

 

 

2-2) write 전략

[1] Write-Through Cache

• app, cache, DB 직렬구조
• 캐시를 거쳐 DB에 동기식으로 write됨
• read-through와 함께 사용시 시너지

장점 : 캐시, DB의 일관성 보장

 

주의점 : 캐시, DB에 순차로 write되기에 지연 발생

대표 tool : DynamoDB Accelerator(DAX) (read-through/write-through)

 

[2] Write-Around

• 데이터 DB 저장 후 실제로 read되는 데이터만 선택적으로 캐시에 저장
• read-through와 조합시 시너지

활용 : 데이터가 한 번 작성된 후 거의 읽히지 않거나 전혀 읽히지 않는 경우(ex : 로그 기록, 채팅방 메시지)

 

[3] Write-Back / Write-Behind

• read-through와 사용시 시너지
• Flow : app -> 캐시로 write 후 캐시 -> app으로 완료 응답 전송, 이후 캐시->DB로 비동기적으로 write

장점 :

• write-through에 비해 app은 응답을 빠르게 받음
• DB장애 내구성이 뛰어남. DB 다운타임 발생시에도 시스템 정상동작.
  캐시단에서 배치 처리 또는 데이터 병합이 가능한 경우 DB write 횟수를 줄일 수 있음
  활용 : 쓰기 작업이 많은 시스템에 특히 적합
  대표 Tool : RDBMS 스토리지엔진 내부 기본탑재 - 쿼리 결과를 먼저 메모리에 기록된 후 적절한 시점에 디스크로 동기화

 

 

ref : https://maily.so/devpill/posts/8do7dxleogq