안녕하세요. Redis와 같은 Caching을 이용한다면 RDB 보다 빠른 write와 read를 경험 할 수 있게 됩니다. 이런 장점을 극대화하기 위한 전략들이 몇가지 존재합니다. 이를 활용하여 우리는 Redis를 다양한 상황에서 사용할 수 있습니다.
오늘은 Redis를 이용한 캐싱 전략(Caching Strategies)에 대해서 알아보도록 하겠습니다.
오늘 포스팅은 아마존의 ElasticCache docs를 번역 및 가공 한 것으로 원문을 보기 원하시는 분들은 Link를 참조해 주시기 바랍니다.
레이지 로딩(Lazy Loading)
이름에 나타나듯이 레이지 로딩은 클라이언트에게서 데이터가 필요로 해질 때 Cache에 로딩하는 전략입니다. DB나 외부 API에 접근하기 전 Cache를 먼저 확인 한 후 Cache에 데이터가 존재한다면 Cache 데이터를 그렇지 않다면 원본(DB나 외부 API)에 접근하여 값을 가져와 캐시에 올려놓습니다.
캐시에 데이터가 있을 경우 (만료 X)
- 클라이언트가 서버에 데이터를 요청합니다.
- 서버는 Cache에 해당 데이터가 있는지 확인합니다.
- 캐시에 데이터가 있으므로 바로 반환합니다.
캐시에 데이터가 없을 경우
- 클라이언트가 서버에 데이터를 요청합니다.
- 서버는 Cache에 해당 데이터가 있는지 확인합니다.
- 캐시에 데이터가 없으므로 원 데이터를 가져옵니다.
- 가져온 데이터를 캐시에 저장합니다.
- 데이터를 클라이언트에게 반환합니다.
레이지 로딩 장점
- 요청 받은 데이터만 캐시에 저장합니다. 파르토의 법칙에 따르면 전체 데이터 중 20% 정도가 대부분이 접근 하고 나머지 80%는 거의 접근이 없습니다. 따라서 실제로 접근이 있는 데이터만 캐시에 담을 수 있습니다.
- 캐시 미스가 발생했을 때 치명적이지 않습니다. 왜냐하면 차선책으로 실제 데이터에 접근하여 최신의 데이터 가져오기 때문입니다. 그 후 데이터 접근에 대해서는 다시 캐시가 적용됩니다.
레이지 로딩 단점
- 값을 읽을 때 캐시 미스마다 3가지의 패널티를 가집니다. 첫번째, 캐시에 확인 요청입니다. 두번째, 데이터베이스에 확인 요청입니다. 마지막으로 캐시에 데이터를 데이터베이스에서 가져온 데이터를 쓰는 부분입니다. 캐시 미스가 많이 일어난다면 딜레이는 눈에 띄게 증가할 것입니다.
- 캐시 미스가 발생했을 때 마다 캐시에 데이터를 쓰기 때문에 캐시의 데이터는 최신을 유지 못할 가능성이 있습니다. 따라서 캐시의 데이터를 반환했는데 부정확한 데이터가 반환될 수 있습니다.
Write-Through
write-through 전략은 데이터를 추가하거나 업데이트할 때 캐시에 동시에 업데이트하는 전략입니다. 아래의 이미지와 같습니다.
그리고 읽을때는 아래와 같이 실제 DB를 볼 필요 없이 cache만 읽으면 됩니다.
Write-Through 장점
- 캐시에 들어있는 데이터는 항상 최신의 데이터를 유지합니다. 왜냐하면 DB와 캐시의 값은 항상 동시에 쓰기 때문입니다.
Write-Through 단점
- 값을 쓸 때 마다 캐시와 데이터베이스에 모두 쓰기때문에 업데이트와 생성은 항상 2번의 패널티를 가집니다. 이는 쓰기 작업이 많은 시스템이라면 눈에 띄는 딜레이를 유발할 수 있습니다.
- 새로운 노드가 추가되거나 했을 경우 데이터를 찾지 못할 수 있습니다. 왜냐하면 새로운 노드에는 해당 데이터가 없을 것이기 때문입니다.
- 만약 읽을 때 캐시 미싱이 일어났다면 이를 다시 매꿔주기가 애매해집니다.
- 대부분의 데이터는 거의 읽히지 않으므로 리소스 낭비로 이어질 수 있습니다.
Adding TTL
레이지 로딩 전략은 최신 데이터가 아닐 가능성이 있습니다. 하지만 캐싱 미스가 발생했을 때 심각한 오류를 발생하진 않습니다. Write-through 전략은 항상 최신의 데이터를 유지합니다. 하지만 캐싱 미스가 발생 했을 경우 잘못된 경우가 발생할 수 있으며 불필요한 메모리를 사용하여 낭비가 발생할 수 있습니다.
각 전략에 TTL(time to live)를 추가함으로써 이득을 취할 수 있습니다. TTL은 key가 자연스럽게 만료되어 없어지게 하는 시간(Redis의 경우 Integer 당 1밀리초 단위)입니다. 레이지 로딩 전략에서는 TTL을 설정 함으로써 자연스럽게 값이 없어지고 캐싱 미스를 일으켜 최신을 유지할 수 있게됩니다. Write-through 전략에서 TTL을 설정하면 업데이트가 되지 않는 데이터들은 없어지게 됩니다. 그렇게 되면 메모리적인 이득을 얻을 수 있게됩니다.
마무리
오늘은 이렇게 Cache를 이용한 시스템의 성능을 올릴 수 있는 전략에 대해서 알아보았습니다.
본인의 프로젝트에 맞는 전략을 선택하는데 도움이 됬으면 합니다.
아 그리고 두 전략을 섞어서 사용할 수 도 있을 것 같습니다.
오늘은 여기까지입니다.
감사합니다.
참조
'datasource > redis' 카테고리의 다른 글
[redis + Spring] Spring Data Redis를 이용한 Transaction 처리 (1) | 2021.07.22 |
---|---|
[redis] 트랜잭션(Transaction) - 이론편 (3) | 2021.07.18 |
[Redis] Hashes을 이용하여 매핑 만들기 ( Strings VS Hashes ) (0) | 2020.12.31 |
[Redis] Redis 자료구조 알아보기 (0) | 2020.12.24 |
[Java + Redis] Spring Data Redis로 Redis와 연동하기 - RedisRepository 편 (1) | 2020.08.18 |
댓글