들어가며
『가상 면접 사례로 배우는 대규모 시스템 설계 기초』에서 캐시 계층에 대한 내용을 읽으며, 캐시 전략 관련 참고 자료를 함께 살펴보게 되었습니다. 이 글에서는 캐시 전략의 종류와, 각각의 전략이 어떤 상황에서 선택되는지를 정리해보려 합니다.
캐싱 전략과 올바른 선택 방법
캐싱은 시스템 성능을 향상시키는 가장 단단한 방법 중 하나입니다. 적절하게 구현되어 있는 캐시는 응답 시간을 줄이고, 데이터베이스 부하를 감소시키며, 비용을 절감할 수 있습니다. 여러 가지 전략이 있으며, 올바른 전략을 선택하는 것이 큰 차이를 만들 수 있습니다.
캐싱 전략은 데이터 및 데이터 접근 패턴에 따라 다르게 선택합니다. 예를 들어, 다음과 같은 사항을 고려하여 올바른 캐시 전략을 수립해야 합니다.
- 시스템이 쓰기 중심인지 (예: 시간 기반 로그)
- 데이터가 한 번 쓰이고, 자주 조회되는지 (예: 사용자 프로필)
- 데이터가 항상 다른(고유한) 정보를 반환하는지 (예: 검색 쿼리)
즉, 인기있는 모바일 게임 순위 TOP 10을 보여줘야 서비스와 사용자 정보를 제공해야 하는 서비스의 캐싱 전략은 매우 다릅니다. 이처럼, 옳은 캐시 전략을 선택하는 것은 성능 향상에 매우 중요한 요소로 이를 소개하도록 하겠습니다.
Cache-Aside
Cache-Aside는 가장 흔히 사용되는 캐싱 전략입니다. 캐시 정보를 저장하는 저장소가 별도로 존재하며, 애플리케이션이 캐시와 데이터베이스 모두와 직접 통신하는 구조입니다. 캐시와 기본 데이터베이스 간에는 연결이 없으며, 이에 대한 모든 작업은 애플리케이션에 의해 처리됩니다. 이 구조는 아래 그림과 같습니다.
위 그림에서 발생하는 작업은 다음과 같습니다.
- 애플리케이션은 우선 캐시 여부를 확인
- 캐시에서 데이터를 찾으면
Cache hit라고 하며, 캐시에서 데이터를 읽어 반환합니다. - 캐시에서 데이터를 찾지 못하면
Cache miss라고 하며, 애플리케이션은 데이터베이스에서 데이터를 조회하는 추가 작업을 수행하여 이에 대한 반환 값을 반환하게 됩니다. 이후, 동일한 요청에 대한Cache hit를 위해 캐시에 데이터를 저장합니다.
Use cases, Pros and Cons
Cache-Aside 전략은 읽기 중심 서비스에 적합합니다. 일반적으로 Memcached와 Redis를 사용하며, 해당 전략을 사용하는 경우 시스템은 캐시 실패에 유연한 대처가 가능합니다. 만약, 캐시 클러스터가 다운되면 시스템은 여전히 데이터베이스에 직접 접근하여 작동할 수 있습니다.
또 다른 장점은 캐시에 저장된 데이터 구조와 데이터베이스에 저장된 데이터 구조가 달라도 된다는 점입니다. 어러 복합적인 데이터를 필요로 하는 경우, 데이터베이스의 데이터 구조를 따르는게 아닌 응답에 필요한 형태로 가공하여 캐시에 저장할 수 있습니다.
Cache-Aside 전략을 사용할 때 일반적인 데이터 쓰기 전략은 DB에 직접 값을 저장하는 것입니다. 그러나 이 경우, DB와 캐시에 저장된 데이터 간 불일치가 발생할 수 있습니다. 이를 해결하기 위해, 일반적으로 TTL을 사용하여 특정 시간이 지날 경우 다시 데이터베이스에서 데이터를 조회하도록 합니다. 만약, 데이터의 실시간성이 반드시 보장되어야 한다면, 캐시 정보 자체를 무효화하거나 적절한 쓰기 전략을 사용해야 합니다.
Read-Through Cache
Read-Through Cache는 데이터베이스와 하나의 라인으로 작동합니다. Cache miss가 발생한 경우, 데이터베이스로 부터 데이터를 가져와 캐시에 저장한 후 애플리케이션에 반환합니다. 이를 그림으로 표현하면 다음과 같습니다.
Use cases, Pros and Cons
Read-Through Cache와 Cache-Aside 전략은 비슷하지만, 다음과 같은 두 가지 차이점이 존재합니다.
- Cache-Aside는 애플리케이션이 직접 데이터베이스에서 데이터를 가져오고 캐시에 저장합니다. 하지만, Read-Through에서는 이러한 동작이 라이브러리나 캐싱 서비스 제공자에 의해 자동으로 수행됩니다.
- Cache-Aside와 달리, Read-Through는 데이터베이스와 캐시에 저장된 데이터의 구조가 반드시 일치합니다.
Read-Through Cache 전략은 읽기 부하가 크고 반복적으로 같은 데이터에 대한 요청이 있는 경우에 적합합니다. 단점으로는 데이터가 처음 요청되는 경우에는 무조건 Cache miss가 발생하고 데이터를 데이터베이스에서 조회해야 하는 것 입니다. 개발자는 이를 위해 사전에 데이터베이스에서 데이터를 조회해 캐시에 저장하는 방식으로 문제를 극복할 수 있습니다.
Cache-Aside와 마찬가지로 데이터베이스와 캐시에 저장된 정보에 불일치가 발생할 수 있으며, 다음으로는 이에 대한 해결책인 쓰기 전략을 소개하도록 하겠습니다.
Write-Through Cache
Write-Through Cache는 데이터가 먼저 캐시에 쓰이고, 그 다음 데이터베이스에 쓰입니다. 캐시는 데이터베이스와 하나의 라인에 위치하며, 쓰기 작업은 항상 캐시를 통해 기본 데이터베이스로 전달됩니다. 다음 그림을 참고하면 좋을 것 같습니다.
위 그림에서 발생하는 작업은 다음과 같습니다.
- 애플리케이션은 데이터를 캐시 저장소에 저장합니다.
- 캐시 저장소는 메인 데이터베이스에 데이터를 업데이트합니다.
- 쓰기 작업이 완료되면, 캐시와 데이터베이스는 모두 동일한 데이터를 가지고 있게 되므로 동일성을 보장합니다.
Use cases, Pros and Cons
Write-Through Cache 전략은 경우 캐시에 데이터를 저장한 이후 데이터베이스에 데이터를 저장하기 때문에 추가적인 오버헤드가 발생할 수 있습니다. 그러나 Read-Through Cache 전략과 함께 사용할 경우 언제나 데이터의 실시간성을 보장할 수 있기 때문에 캐시 무효화 문제는 해결할 수 있습니다.
AWS의 DynamoDB Accelator는 Read-Through / Write- Through Cache 전략의 좋은 예제입니다. 이 서비스는 DynamoDB와 애플리케이션을 한 라인 단위로 묶기 때문에 DynamoDB에 대한 읽기와 쓰기 작업은 DAX를 통해 수행됩니다.
Write-Around
Write-Around는 데이터를 저장할 때 데이터베이스에 우선 저장하고, 데이터를 조회하는 요청이 오면 그때 가져온 데이터를 캐시에 저장하는 방식입니다.
Use cases, Pros and Cons
Write-Around 전략은 Read-Through와 함께 사용될 경우 데이터를 한 번 쓰고 거의 호출하지 않는 상황에서 좋은 성능을 가져갈 수 있습니다. 예를 들어, 실시간 로그나 채팅방의 메시지와 같은 것들이 있습니다. 또한, 이 전략은 Cache-Aside 전략과도 함께 사용할 수 있습니다.
Write-Back And Write-Behind Cache
Write-Back(Behind) 전략은 애플리케이션이 캐시에 데이터를 저장한 후 클라이언트 요청에 즉시 응답하고, 나중에 캐시에 저장된 데이터를 데이터베이스에 저장합니다.
Write-Through Cache 전략과 매우 유사하지만 다음과 같은 결정적인 차이가 있습니다.
- Write-Through Cache 전략에서 캐싱된 데이터는 동기적으로 데이터베이스에 반영
- Write-Back Cache 전략에서 캐싱된 데이터는 비동기적으로 데이터베이스에 반영
Use cases, Pros and Cons
Write-Back(Behind) 전략은 쓰기에 부하가 큰 경우에 적합합니다. Read-Through 전략과 함께 사용될 경우, 최근에 업데이트 된 데이터의 경우 언제나 캐싱되어 있기 때문에 복합적인 부하에 적합합니다.
이 전략은 데이터베이스에 일시적으로 부하가 걸리거나 문제가 생기는 상황에서 서비스가 어느정도 내성을 가질 수 있습니다. DynamoDB 처럼 요청에 따라 과금이 발생하는 서비스를 이용할 경우 배치 또는 병합을 지원하여 전체적인 데이터 쓰기 작업을 줄임으로써 부하를 줄이고 비용도 절감할 수 있습니다. DAX의 경우 Write-Through Cache 전략을 사용하기 때문에 애플리케이션이 쓰기 위주의 동작을 수행할 경우엔 비용 절감을 효과를 기대할 순 없습니다.
몇몇 개발자는 Cache-Aside 전략과 Write-Back 전략을 함께 사용하면서 특정 시간대에 몰리는 요청을 처리합니다. 그러나 캐시 저장소에 문제가 생길 경우, 영구적으로 데이터를 잃을 수 있다는 단점이 있습니다.
