Redis ‐ Redis 캐싱 전략 - dnwls16071/Backend_Study_TIL GitHub Wiki

📚 캐시(Cache), 캐싱(Caching)이란?

• 캐시(Cache) : 원본 저장소보다 빠르게 가져올 수 있는 임시 데이터 저장소를 의미한다.
• 캐싱(Caching) : 캐시에 접근해서 데이터를 빠르게 가져오는 방식을 의미한다.

📚 데이터를 캐싱할 때 사용하는 전략(Cache Aside, Write Around)

Ex. 게시판 서비스를 배포했다고 가정하고 Cache Aside 작동 방식을 이해

[Cache Aside 전략]

- 처음 게시판을 배포하면 데이터베이스와 레디스에는 아무런 데이터도 존재하지 않는다.
- 일부 사용자가 들어와 게시글 작성을 함으로써 데이터를 저장한다. 이 데이터는 데이터베이스에 저장된다.(레디스에는 저장되지 않는다.)
- 사용자가 데이터를 조회하려고 요청한다. 이 때, 데이터베이스로부터 바로 데이터 조회를 하기 전에 레디스에 있는지 먼저 확인한다.
- 레디스에 데이터가 없는 걸 확인한 뒤에 데이터베이스로부터 데이터를 조회해서 응답한다.
- 데이터베이스로부터 조회한 데이터를 응답한 뒤에 레디스에도 데이터를 저장해둔다.
- 다시 한 번 사용자가 데이터를 조회하려고 요청한다.
- 레디스에 조회하고자 하는 데이터가 있는지 확인했더니, 데이터가 존재해서 레디스로부터 데이터를 바로 가져온다.

• 아래와 같이 데이터를 요청했을 때 캐시에 데이터가 있는 경우를 Cache Hit이라고 한다.

• 아래와 같이 데이터를 요청했을 때 캐시에 데이터가 없어서 데이터베이스로부터 조회해야 하는 경우를 Cache Miss라고 한다.

[Write Around 전략]

• Cache Aside 전략이 데이터를 어떻게 조회할지에 대한 전략이라면 Write Around 전략은 데이터를 어떻게 쓸지(저장,수정,삭제)에 대한 전략을 말한다.
• Write Around 전략은 Cache Aside 전략과 같이 자주 활용되는 전략이다.
• 아래와 같이 데이터를 저장할 때, 레디스에 저장하지 않고 데이터베이스에만 저장하는 방식이다. 그러다 데이터를 조회할 때, 레디스에 데이터가 없으면 데이터베이스로부터 데이터를 조회해와서 레디스에 저장시켜주는 방식이다.

📚 Cache Aside, Write Around 전략의 한계점과 해결 방법

[한계점]

• Cache Aside 전략과 Write Around 전략을 같이 썼을 때 한계점 중 하나는 캐시된 데이터와 DB 데이터가 일관성이 없다는 것이다.
• Write Around 전략에 따르면 데이터를 레디스에 저장하지 않고 DB에 데이터를 저장하고 수정하기 때문에 레디스와 DB에 저장된 상태가 다를 수 밖에 없다.
• 또한 DB는 디스크에 저장해서 많은 양을 저장할 수 있지만 캐시는 메모리에 저장하기 때문에 DB에 비해 많은 양의 데이터를 저장할 수가 없다.

[해결책]

• 캐시된 데이터와 DB 데이터가 일치하지 않는 점은 어쩔 수 없는 부분이다. 모든 기술에는 기회 비용(Trade Off)이 발생한다.
• 무언가를 얻으면 무언가를 포기해야 한다. 따라서 데이터 조회 성능 개선 목적으로 레디스를 쓰는 경우에는 데이터의 일관성을 포기하고 성능 향상을 택한 것이라고 볼 수 있다.
• 무작정 데이터를 빠르게 가져오겠다고 캐싱을 활용한다기보다 해당 데이터의 특성을 명확히 파악하고 캐싱을 하는 것이 좋다.
  • 자주 조회되는 데이터
  • 잘 안 변하는 데이터
  • 실시간으로 정확하게 일치하지 않아도 되는 데이터
• 하지만 장기간 데이터가 일치하지 않는 것은 문제가 될 수 있다. 따라서 적절한 주기로 데이터를 동기화시켜주어야 한다. 레디스의 TTL 기능을 활용하면 해결할 수 있다.
• 데이터를 저장할 수 있는 공간의 한계 역시 TTL 기능을 활용하면 캐시 공간을 효율적으로 쓸 수 있다.