Cache-Aside장점단점쓰기 전략Read-Through Cache사용 사례 및 장단점Write-Through Cache동작 방식사용 사례 및 장단점Write-Around사용 사례Write-Back or Write-Behind사용사례 및 장단점
Cache-Aside
일반적으로 가장 흔히 사용 되는 캐싱 전략이다.
캐시 정보를 별도의 저장소에 저장하고, 애플리케이션이 캐시 및 데이터베이스와 직접 통신한다.
캐시와 주요 데이터베이스 간의 연결은 없고, 모든 캐시 및 데이터베이스 작업은 애플리케이션에 의해 처리된다.
장점
- 해당 전략을 사용하는 경우 시스템은 캐시 실패에 유연한 대처가 가능하다.
- 만약 캐시 클러스터가 중단되도, 시스템은 데이터베이스에서 바로 데이터를 가져올 수 있다.
(피크 타임에 시스템이 중단된다면, 응답 시간은 매우 지연되고 데이터베이스 역시 갑작스러운 부하로 문제가 생길 수 있어 큰 효과가 없을 수 있다)
- 데이터베이스에 저장 되는 데이터 구조와 캐시에 저장 되는 데이터 구조가 달라도 된다.
- 여러 복합적인 데이터를 필요로 하는 경우, 응답에 필요한 형태의 데이터를 별도로 정의하여 캐시에 저장할 수 있다.
단점
- 데이터베이스에 저장된 정보와 캐시에 저장된 정보 간의 데이터 불일치가 발생할 수 있다.
쓰기 전략
Cache-aside 전략을 사용할 때 가장 일반적인 쓰기 전략은 데이터를 데이터베이스에 직접 쓰는 것이다.이 경우 캐시가 데이터베이스와 일치하지 않을 수 있기 때문에 TTL 을 사용하여, 특정 시간이 지나면 다시 데이터베이스에서 값을 조회한다.
만약 데이터의 신선도가 반드시 보장되어야 한다면, 캐시 정보 자체를 무효화하거나 올바른 읽기 전략을 사용해야 한다.
Read-Through Cache
Read-through 전략은 캐시와 데이터베이스가 하나의 라인(프로세스)에 묶인다.Cache miss 가 발생 했을 때, 데이터베이스로부터 데이터를 가져와 캐시에 저장한 후 애플리케이션에 반환한다.Cache-aside 와 Read-through 전략은 모두 데이터를 처음 읽으면 그때 데이터를 가져오기 때문에 lazily 하게 데이터를 가져오는 전략이다. (영속성 컨텍스트의 동작 방식과 비슷함)
Cahce-aside 전략과 매우 유사하지만, 2가지의 차이점이 있다.Cache-aside에서는 애플리케이션이 데이터베이스로부터 직접 데이터를 가져오고 캐시에 저장하는 역할을 수행하지만,Read-through에서는 이러한 동작이 라이브러리나 캐시 서비스 제공자에 의해 자동으로 수행된다.
Read-through에서 저장된 데이터 구조는 데이터베이스의 데이터 구조와 일치한다.
사용 사례 및 장단점
Read-through 전략은 동일한 데이터가 여러 번 요청되는 읽기 중심의 작업에 가장 적합하다. (ex. 뉴스 기사)단점
- 데이터가 처음 요청될 때 항상
Cache miss가 발생하여 데이터를 캐시에 로드하는 추가 비용이 발생한다.
→ 개발자는 이를 위해 사전에 미리 데이터베이스에서 데이터를 조회해 캐시에 저장하는 방식으로 문제를 해결할 수 있다.
Cache-aside와 마찬가지로 데이터베이스에 저장된 정보와 캐시에 저장된 정보 간의 데이터 불일치가 발생할 수 있다.
Write-Through Cache
Write-through 전략은 데이터를 먼저 캐시에 저장한 다음 데이터베이스에 저장한다.캐시는 데이터베이스와 하나의 라인(프로세스)에 위치하며, 쓰기 작업은 항상 캐시를 통해 이루어진다.
→ 캐시가 주 데이터베이스와 일관성을 유지하는 데 도움
동작 방식
- 애플리케이션은 데이터를 즉시 캐시에 저장한다.
- 캐시는 주 데이터베이스에 해당 데이터를 업데이트 한다.
- 쓰기 작업이 완료되면, 캐시와 데이터베이스는 모두 같은 값을 가지고 데이터의 일관성을 보장한다.
사용 사례 및 장단점
먼저 캐시에 데이터를 저장한 이후 데이터베이스에 데이터를 저장하기 때문에 (두 번의 쓰기 작업) 추가적인 지연이 발생한다.
하지만
Read-through 전략과 함께 사용할 경우 언제나 데이터의 일관성을 보장할 수 있기 때문에 캐시 무효화 문제에 대해서는 해결할 수 있다. (모든 데이터베이스 쓰기가 캐시를 통해 이루어진다고 가정할 때)DynamoDB Accelerator (DAX) 는 read-through / write-through 캐싱 전략의 좋은 예제입니다. 이 서비스는 DynamoDB 와 애플리케이션은 한 라인단위로 묶기 때문에 DynamoDB 에 대한 읽기와 쓰기 작업은 DAX 를 통해 수행됩니다.
장점
- 데이터의 일관성을 보장한다.
단점
- 먼저 캐시에 데이터를 저장한 이후 데이터베이스에 데이터를 저장하기 때문에 (두 번의 쓰기 작업) 추가적인 지연이 발생한다.
Write-Around
Write-around 전략은 데이터를 쓸 때 데이터베이스에 우선 저장하고 데이터를 조회하는 요청이 오면 그때 가져온 데이터를 캐시에 저장한다.사용 사례
Write-around 전략은 Read-through 전략과 함께 사용될 경우 데이터를 한 번 쓰고 거의 호출하지 않은 상황에서 좋은 성능을 제공한다. (ex. 실시간 로그, 채팅방 메시지)마찬가지로
Cache-aside 전략과도 조합할 수 있다.Write-Back or Write-Behind
Write-back 전략은 애플리케이션이 데이터를 우선적으로 캐시에 저장 후 바로 클라이언트에 제공한 뒤, 나중에 쌓인 데이터를 한 번에 데이터베이스에 저장한다.Write-through 전략과 매우 유사하지만, 한 가지 결정적인 차이가 있다.Write-through전략에서 캐시된 데이터는 동기적으로 주 데이터베이스에 업데이트 됩니다.
Write-back전략에서 캐시된 데이터는 비동기적으로 주 데이터베이스에 업데이트 됩니다.
애플리케이션 관점으로는 응답하기 전에 캐시만 업데이트 하면 되기 때문에
Write-back 전략을 통한 쓰기가 더 빠르게 처리된다.
사용사례 및 장단점
Write-back 전략은 쓰기 성능을 향상시키고 쓰기 중심의 작업에 적합하다.Read-through 전략과 함께 사용될 경우, 최근에 업데이트 된 데이터는 언제나 캐싱되어 있기 때문에 복잡한 부하에 적합하다.장점
- 데이터베이스에 일시적으로 부하가 걸리거나 문제가 생기는 상황에서도 견딜 수 있다.
- DynamoDB 처럼 요청에 따라 과금이 발생하는 서비스를 이용할 경우 배치 또는 병합을 지원된다면, 전체적인 데이터 쓰기 작업을 줄임으로써 부하를 줄이고 비용도 절감할 수 있다. (DAX의 경우
Write-through전략을 사용하기 때문에 애플리케이션이 쓰기 중심의 작업을 수행할 경우에는 비용 절감 효과를 기대할 수 없다)
Cache-aside전략과 함께 사용하면 특정 시간대에 몰리는 요청을 처리할 수 있다.
단점
- 캐시에 문제가 생길 경우, 데이터가 영구적으로 손실될 수 있다.
대부분의 데이터베이스 저장소 엔진(InnoDB) 는
Write-back 캐시를 내부에 기본적으로 가지고 있다.따라서 쿼리는 처음에 메모리에 저장 되었다가 나중에 디스크로 전달된다.