캐싱은 시스템 성능을 높이는 방법 중 하나이다. 캐시를 통해 데이터베이스 부하를 줄이고 빠른 응답속도를 가져올 수 있다.
캐싱을 하는 방법과 종류가 다양한데, 데이터의 유형마다 이를 달리하여 적절한 캐시 방식을 구현하는 것이 좋다.
먼저 두가지의 읽기 정책을 알아보자.
1. Cache-Aside
동작방식
읽기 요청이 들어오면, 애플리케이션이 캐시에 해당 데이터가 있는지 확인한다.
캐시가 있는 경우, Cache Hit이 일어나고 조회가 끝난다.
캐시가 없는 경우, Cache Miss가 일어나고 DB에 조회를 한다.
애플리케이션이 DB에서 데이터를 가져온 후 캐시에 직접 저장한다. (주체가 애플리케이션)
해당 방식을 사용하게 되면, 캐시서버가 죽어도 애플리케이션이 직접 DB에 접근하기 때문에 캐시오류에 탄력적이다.
Cache-Aside는 읽기가 많은 워크로드에 적합하다.
2. Read-Through
동작방식
읽기 요청이 들어오면, 애플리케이션이 캐시에 해당 데이터가 있는지 확인한다.
캐시가 있는 경우, Cache Hit이 일어나고 조회가 끝난다.
캐시가 없는 경우, Cache Miss가 일어나고 캐시가 DB에 조회를 한다.
캐시가 DB에서 데이터를 가져와 저장한 뒤, 앱에 데이터를 제공해준다. (주체가 캐시)
첫 요청시 매번 Cache Miss가 일어나기 때문에 초기 요청이 느리다는 단점이 있다. (개발자가 수동으로 쿼리를 실행해 캐싱을 해둬야 한다)
Read-Through도 읽기가 많은 워크로드에 적합하다.
다음으로는 세가지의 캐시 쓰기 정책에 대해 알아보자.
1. Write-Through
애플리케이션에서 쓰기 요청이 일어나면, 캐시에 먼저 쓰고 DB에 쓴다.
쓰기가 캐시 -> DB 순으로 일어나기 때문에 캐시와 DB는 항상 일관성을 유지할 수 있다.
하지만 쓰기 수행을 2번하기 때문에 이에 따른 latency가 발생한다.
2. Write-Around
애플리케이션에서 쓰기 요청이 일어나면, DB에 바로 쓴다.
이후 읽기 요청이 들어오는 데이터만 캐시에 쌓는 방식으로 동작한다.
해당 쓰기 방식의 경우, 한번 쓰고 적게 읽는 데이터에 적합하다. (real-time logs, chatroom message 등)
3. Write-Back
Write Through 방식과 유사하게 캐시 데이터가 DB에 기록된다.
하지만 Write Through와의 차이점은, 캐시의 데이터가 비동기적으로 DB에 업데이트된다는 것이다.
Write-Back 방식을 사용하면 Write-Through의 단점이었던 latency가 줄어들어 쓰기연산이 더 빨라진다.
'시스템설계' 카테고리의 다른 글
[시스템 설계] 데이터센터 이중화 (0) | 2023.05.06 |
---|---|
[시스템 설계] 무상태(stateless) 웹 계층 (0) | 2023.05.03 |
[시스템 설계] 서버 응답시간(latency) 개선 (캐시, CDN) (0) | 2023.04.28 |
[시스템 설계] Failover 시스템 설계 (0) | 2023.04.27 |
Reverse Proxy, Forward Proxy (0) | 2023.04.26 |