🏷️캐시(Cache), 캐싱(Caching)이란?
캐시(Cache)란, 원본 저장소보다 빠른 임시 데이터 저장소를 말한다.
캐싱(Caching)이란, 캐시에 접근해서 데이터를 빠르게 가져오는 방식을 말한다.
🏷️데이터를 캐싱할 때 사용하는 전략(Cache Aside, Write Around)
✔️Cache Aside(=Look Aside, Lazy Loading) 전략
- 데이터를 조회할 때 주로 사용하는 전략이 이 Cache Aside 전략이다. 게시판에서 조회 기능을 구현하고 이를 배포했다고 가정할 때 아래와 같은 흐름으로 전략이 수행된다.
- 처음 게시판 서비스를 배포하면 게시글이 존재하지 않는 상태이기 때문에 데이터베이스와 레디스에 아무런 데이터가 저장되어 있지 않다.
- 일부 사용자가 접속해 게시글 작성을 하게 되면 이 데이터가 데이터베이스에 저장된다.
- 사용자가 게시물을 조회한다. 이 때, 레디스에는 아무런 데이터가 없는 상태이다. 데이터베이스로부터 게시물 데이터 조회를 하기 전에 레디스에 해당 게시물 데이터가 있는지 확인한다.
- 레디스에 데이터가 없는 걸 확인한 뒤 데이터베이스로부터 데이터를 조회해서 응답을 보낸다.
- 데이터베이스로부터 조회한 데이터를 응답한 뒤에 레디스에도 데이터를 저장해둔다.
- 다시 한 번 사용자가 데이터를 조회하려고 요청한다.
- 레디스에 조회하고자 하는 데이터가 있는질 확인했더니 데이터가 존재해서 레디스로부터 데이터를 바로 가져온다.
✔️캐시 용어 : Cache Hit, Cache Miss
- 위와 같이 사용자가 데이터를 요청했을 때 캐시에 데이터가 있어 이를 가져올 수 있다면 이를 Cache Hit이라고 한다.
- 위와 같이 사용자가 데이터를 요청했을 때 캐시에 데이터가 없어 이를 가져올 수 없다면 이를 Cache Miss라고 한다.
✔️Write Around 전략
- Cache Aside 전략이 데이터 조회와 관련된 전략이라면 Write Around 전략은 데이터를 어떻게 쓸 지(저장, 수정, 삭제)에 관련된 전략이다.
- Write Around 전략은 데이터를 저장할 때 레디스에 저장하지 않고 데이터베이스에만 저장하는 것을 말한다. 그러다 데이터를 조회할 때 레디스에 데이터가 없으면 데이터베이스로부터 데이터를 조회해와서 레디스에 저장시켜주는 방식이다.
✔️Cache Aside 전략 + Write Around 전략 혼합 문제점
- Write Around 전략을 바탕으로 데이터를 저장하게 되면 데이터베이스에 저장을 하게 되고 클라이언트의 요청이 들어오면 해당 데이터를 데이터베이스로부터 조회하여 레디스에 저장한다.
- 이전에 데이터베이스에 저장한 내용을 수정하게 되면 Write Around 전략에 따라 이를 데이터베이스에 반영하겠지만 레디스에 있는 데이터를 Cache Aside 전략을 바탕으로 데이터에 접근하면 변경사항이 반영되지 않았으므로 데이터의 일관성이 없는 문제가 발생한다.
- 또한, RDBMS는 디스크, Redis는 메모리이기에 데이터베이스에 비해서 많은 양의 데이터를 저장할 순 없다.
❗결과적으로 이 한계는 극복이 가능한가? → 극복 불가능하다.
앞서 말했던 전략들을 혼용할 경우 데이터 일관성 측면에서의 문제가 발생한다. 그렇다고 캐시와 데이터베이스의 내용을 일치시키기 위해 데이터를 수정할 때마다 동시에 업데이트를 해주면 성능적으로 느려지게 된다. 하지만 내용을 일치시키지 않는다면 데이터가 일치하지 않게 된다.
따라서 캐시를 적용하기에 적합한 데이터는 다음과 같다.
- 자주 조회되는 데이터
- 잘 변하지 않는 데이터
- 실시간으로 정확하게 일치하지 않아도 되는 데이터
장기간 데이터가 일치하지 않는 건 문제가 될 수 있다. 따라서 적절한 주기를 설정하여 데이터를 동기화시켜주어야 한다. 이 때 활용하는 기능이 바로 데이터의 만료 시간인 TTL이다.
