캐시
자주 사용되어지는 데이터를 임시 저장소에 보관하는 기술이다.
임시 저장소는 무한한 공간이 아니다
Why
상대적으로 느린 입출력을 통해 사용되는 정보를 보다 빠르게 접근하기 위해 임시 저장하여 전체적인 성능 향상을 도모하는 메커니즘이 캐싱의 핵심이다.
장점
데이터 엑세스가 빠르다
단점
휘발된다
실시간성 보장해야 하는 곳에 잦은 입출력으로 성능 저하가 발생될 수 있다.
원본 데이터와는 다를 수 있는 동기화에 유의 해야 한다.
종류
- 데이터 캐싱 → I/O 자원 절약!
- http 캐싱 304 → 네트워크 전송량(대역폭) 절약!
- cors
- 콘텐츠 캐싱 (CDN) → 네트워크 전송량(대역폭) 절약!
- SpringBoot
- Thread Local
- OS - Local Cache
희생정책
LRU: 가장 오랜전에 참조가 이루어진 데이터 희생
LFU: 가장 자주 참초되지 않은 데이터 희생
읽기 쓰기의 따른 캐싱 전략
읽기 전략
Look Aside (별도 관리)
접근 방법: chach → DataBase
특징
장점 :
- Redis가 다운되어도 캐시 장애 대비 구성 능동적이다
- 필요하다면 원하는 데이터만 별도로 캐시에 저장할 수 있다.
단점
- 원본 데이터와는 다른 동기화 문제가 발생할 수 있다.
- 처음 서비스 가용시 cache에 데이터가 없어 오버해드가 크다.
- cache warming을 통해 해당 부문을 극복할 수 있다.
Read Through
접근 방법: chach (↔ DataBase)
특징
장점
- 데이터 동기화가 항상 이루어져 있다.
단점
- 레디스가 다운되면 단일 장애 지점이 된다
- 가용성을 향상하기 위한 Replication으로 극복할 수 있다.
- 처음 서비스 가용시 부하가 몰려 오버헤드가 크다.
- cache warming을로 해당 부문 극복
두가지 읽기 방식의 차이는 “데이터 동기화” 를 누구에게 책임질 것인지에 차이가 있다.
데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식의 차이
쓰기 전략
write-Around
접근방법: db에만 쓰는 방식이다.
특징
장점
- write가 단 1번만 일어난다.
단점
- 캐시와 db 동기가 맞지 않는다.
- 관리해야할 것이 부가적으로 많아진다.
- 일반적으로 DB에만 쓰기 때문에 데이터의 상태 변경이 일어나면 cache도 무조건 update 해줘야 한다.
Look-Aside, Read Through와 결합해서 사용되어 지고, 불필요한 데이터가 cache에 올라가는 부문을 예방할 수 있는 방식이 된다.
Write-Back
접근 방법: chach (↔ DataBase)
특징
장점
- Write가 빈번한 서비스에 적절하다
- app ↔ cache 는 동기, cache ↔ db 비동기
- 데이터 동기화를 위해 신경쓰지 않아도 된다
단점
- 자주 사용되지 않는 것들도 저장되어 비효율적이다
(자주 사용되는 것이 제한된 용량으로 없어질수도 있기 때문이다)
해당 부문을 TTL로 극복할 수 있다.
- 캐시가 다운되면 전체가 다운되는 단일 장애 지점이 된다.
- 이를 극복하기 위해 아키텍처를 구성해야 한다.
- 2번의 write 가 필요하다
- 한편으로는 write가 가벼운 곳에서 작용하고 db에서 쓰기 횟수를 줄일 수 있다.
Read Throug 읽기 전략과 함께 사용하면 최근 업데이트된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합하다.
Write-Through
접근 방법: 1. cache 2. DataBase
특징
장점
- Cache, DB 정합성을 실시간으로 보장할 수 있다.
- 최신성보를 가지고 있어 큰 장점이다.
- 데이터 유실이 절대 발생하면 안되는 상황에 적합
단점
- 매요청 마다 2번의 write가 동기적으로 발생하여 성능 poor 하다
- 자주 사용되지 않는 불필요한 리소스가 저장된다
해당 부문을 TTL로 극복할 수 있다.
캐싱 조합
Look Aside + Write Around → 일반적인 조합
Read Through + Write Around → 데이터 정합성 이슈 완벽한 장치 (캐시와 DB 동기화 보장)
Read Through + Write Through → 최신 데이터 보장