데이터베이스에서 데이터를 캐싱할 때, 사전 예방적(proactive) 및 사후 대응적(reactive)으로 취할 수 있는 캐싱 패턴으로 Redis와 Memcached가 있습니다. 구현하기 위해 어떤 패턴을 취하든 모두 자신이 사용할 캐싱과 애플리케이션 목표와 밀접하게 관련되어 있어야 합니다.
가장 흔한 접근은 사전 예방적으로 'cache-aside'(혹은 'lazy loading')을 취하는 것, 그리고 사후 대응적으로 'write-through'를 취할 수 있습니다.
Cache-aside는 데이터가 요청된 후에 수정되는 방식이며, write-through 캐시는 메인 DB가 수정되었을 때 즉시 수정하는 방법입니다. 두 방법 모두, 애플리케이션이 어떤 데이터를 얼마나 캐싱할지를 관리하는 방법입니다.
아래의 다이어그램은 원격 분배 캐시를 사용하는 아키텍처의 전형적인 표현입니다.
Cache-Aside (Lazy Loading)
Cache-aside 캐시는 가장 흔하게 사용되는 캐싱 전략으로, 가장 근본적인 데이터 검색 로직은 다음과 같습니다.
- 애플리케이션이 데이터베이스로부터 데이터를 읽을 필요가 있을 경우, 캐시를 먼저 확인하여 데이터가 사용가능한지 확인합니다.
- 만약 데이터가 사용 가능한다면 (cache hit), 캐시된 데이터가 반환되고 응답은 호출자에게 발급됩니다.
- 데이터가 사용 가능하지 않다면 (cache miss), 데이터베이스에 데이터 쿼리가 전송됩니다. 그러면 캐시에 데이터베이스에서 검색된 데이터가 채워지고 데이터는 호출자에게 반환됩니다.
이 접근의 주된 장점으로는
- 캐시가 애플리케이션이 실제로 요청한 데이터만을 포함하기 때문에 캐시 크기를 비용 효율적으로 유지할 수 있고
- 이 접근 방식을 구현하는 것은 간단하며, lazy caching을 캡슐화하는 애플리케이션 프레임워크를 사용하든 사용자 정의 애플리케이션 로직을 사용하든 상관없이 즉각적인 성능 향상을 얻을 수 있다는 점입니다.
Cache-aside를 단일 캐싱 패턴으로 사용하는 것의 단점은 캐시 미스 후에 데이터가 캐시로 로딩되기 때문에 캐시와 DB에 대한 추가적인 왕복 시간이 필요하기 때문에 최초 응답 시간에 약간의 오버헤드가 추가된다는 점입니다.
Write-Through
Write-through 캐시는 캐시가 데이터를 포함하는 과정의 순서가 역전됩니다.
캐시 미스 후에 캐시를 데이터에 지연 로딩하는 것 대신, 메인 DB가 수정되면 즉시 캐시가 사전 대응적으로 업데이트됩니다.
가장 근본적인 데이터 검색 로직은 다음과 같이 요약됩니다.
- 애플리케이션, 배치, 혹은 백엔드 프로세스가 메인 DB를 업데이트 하면
- 그 즉시, 캐시 내부의 데이터가 업데이트 됩니다.
Write-through 패턴은 거의 항상 지연 로딩과 함께 구현됩니다. 만약 애플리케이션이 데이터 부재 혹은 만료로 인해 캐시 미스를 경험한다면 지연 로딩 패턴이 수행되어 캐시를 수정합니다.
이 접근의 주된 장점으로는
- 메인 DB와 함께 캐시가 최신이기 때문에, 캐시에서 데이터가 발견될 가능성이 훨씬 높아지고, 이는 전반적인 애플리케이션 성능과 사용자 경험을 향상시킵니다.
- 데이터베이스 읽기 작업이 최소한으로 수행되어 DB 성능이 최적화됩니다.
Write-through 접근의 단점은 드물게 요청되는 데이터 또한 캐시에 저장되기 때문에, 캐시의 크기가 커지고 비용 또한 비싸집니다.
적절한 캐싱 전략은 데이터에 대한 write-through와 지연 로딩을 효율적으로 사용하여 관련도와 희박성을 유지하기 위해 데이터에 대한 적절한 만료 시간을 설정해야 합니다.
참고 자료
- Caching patterns (링크)
- [데이터베이스] Redis 캐시(Cache) 설계 전략 (링크)
- [REDIS] 캐시(Cache) 설계 전략 지침 총정리 (링크)
'CS > 데이터베이스' 카테고리의 다른 글
[DB] 2. DB 모델링의 주요 개념 (0) | 2023.11.25 |
---|---|
[DB] 1. 데이터베이스 개요 및 관계형 DB 용어 정리 (0) | 2023.11.23 |
[ Redis ] SpringBoot 3.0.x + Redis로 DTO 캐싱하기 (0) | 2023.11.14 |
[Redis] Redis를 활용한 Refresh Token의 구현 및 장점 (1) | 2023.10.18 |