[Redis] Redis 캐싱 전략이 궁금해!

Redis의 기본 개념을 다지면서 Redis의 장점도 알게 되었고 기본 명령어 7가지와 Key의 네이밍 컨벤션까지 다지게 되었다.
이제 어떤 전략이 실무에서 자주 활용되는지 머릿속에 넣어보자!

 

1. 캐시(Cache)란?

원본 저장소보다 데이터를 빠르게 가져올 수 있는 임시 데이터 저장소를 의미한다.

Chrome에서도 사용자에게 웹브라우저를 빠르게 제공하기 위해 브라우저에 이미지와 파일들을 캐시해둔다.

 

캐시는 Redis에서만 사용되는 용어는 아니고 전반적인 개발 분야에서는 통용되어서 사용되는 용어라 개발 분야에서는 굉장히 중요하다.

 

2. 캐싱(Caching)이란?

임시 데이터 저장소에서 빠르게 데이터를 가져오는 방식이라고 이해하면 된다.

 

3. 현업에서 가장 많이 사용되는 Caching 전략

Caching 전략은 구글에 검색만 해봐도 너무 많은 전략이 나온다.

따라서 현업에서 가장 많이 사용되는 Caching 전략에 대해서 먼저 알아놓기로!

 

3.1. Cache Aside( = Lock Aside, Lazy Loading) 전략

Cache Aside 전략은 데이터를 어떻게 조회할지에 대한 전략을 의미한다.

Cache Aside 전략의 방식을 이해하기 위해서 게시판 프로젝트를 예로 정리해보자.

1. 사용자가 게시판에 게시글을 등록하기 전에는 데이터베이스와 Redis에 아무런 데이터도 존재하지 않는다.
2. 사용자가 게시판에 게시글을 등록하면 데이터베이스에 해당 게시글이 존재하게 된다.
3. 사용자가 등록한 게시글에 대한 조회를 요청하는 경우 Redis에서 해당 데이터를 먼저 찾는다.
4. Redis에 데이터가 없는 경우 데이터베이스에서 데이터를 찾아 사용자에게 응답을 주고 Redis에 해당 데이터를 저장한다.
5. 추후 사용자가 같은 게시글에 대한 조회를 요청하는 경우에는 Redis에서 찾아 응답을 줄 수 있게 된다.

 

그림으로 다시 복습해보자.

Redis Cache에 요청한 데이터가 있는 경우(= Cache HIT)

 

Redis Cache에 요청한 데이터가 없는 경우(=Cache Miss)

 

3.2. Write Around 전략

Write Around 전략은 데이터를 어떻게 쓸지에 대한 전략을 의미한다.

데이터를 저장, 수정, 삭제할 때 Redis에는 저장하지 않고 데이터베이스에만 저장하는 방식이다.

 

그림으로 알아보자.

이처럼 데이터 쓰기 작업(저장, 수정, 삭제)시 Redis에 반영하지 않고 데이터베이스에만 반영하고,

데이터 조회시 Redis에서 먼저 찾고 데이터가 없으면 데이터베이스에서 데이터를 찾아 Redis에 저장해준다.

 

4. Cache Aside, Write Around 전략의 한계점

Cache Aside와 Write Around 전략을 함께 쓰면 2가지의 한계점이 발생한다.

 

데이터베이스와 Redis간의 데이터가 일치하지 않을 수 있다(일관성이 보장되지 않는다).

Write Around는 쓰기 작업을 데이터베이스에만 반영하기 때문에 추후 사용자가 게시글을 수정할 경우 Redis에 수정사항이 반영되지 않는다.

 

Redis에 저장할 수 있는 공간이 작다.

데이터베이스는 디스크(Disk)에 데이터를 저장하기 때문에 많은 양을 저장할 수 있지만, Redis는 메모리(RAM)에 데이터를 저장하기 때문에 데이터베이스에 비해 많은 양을 저장할 수 없다.

 

5. 해결 방안

위에서 확인 2가지의 한계점에 대한 해결 방안은 어떻게 되는지 확인해볼 필요가 있다.

 

데이터베이스와 Redis간의 데이터가 일치하지 않을 수 있다(일관성이 보장되지 않는다).

데이터가 일치하지 않는다고 해서 데이터베이스와 Redis 모두 데이터를 최신화하는 방식은 성능을 느리게 만들고 성능을 향상시키기 위해서 데이터베이스만 데이터를 최신화 하는 방식은 데이터의 일관성이 보장되지 않는다.

하지만, 어떤 선택을 하든 Trade Off(기회 비용)가 발생하고 Redis를 선택한 이유는 조회 성능 개선을 위함이니 Redis를 적용시키기에 적합한 데이터를 우선 알아보자.

• 자주 조회되는 데이터
• 수정이 자주 일어나지 않는 데이터
• 실시간으로 정확하게 일치하지 않아도 되는 데이터

 

하지만 데이터가 일치하지 않는건 문제가 될 수 있다.

따라서, 적절한 시기에 데이터를 동기화해야 하는데 이때 사용되는 방식이 만료시간(TTL)을 설정하는 것이다.

 

만료 시간을 초과하면 데이터는 Redis에서 삭제되고 사용자의 요청은 Cache Miss되어 데이터베이스를 통해 다시 최신 데이터로 동기화되는 효과를 얻게 되는 것이다.

 

Redis에 저장할 수 있는 공간이 작다.

위에서 언급한 것처럼 저장 공간에 대한 한계점도 만료시간(TTL)을 활용하는 것이다.

만료시간(TTL)을 활용하면 자주 조회되지 않는 데이터는 Redis에서 제거되고 자주 조회되는 데이터만 남아 공간 활용을 효율적으로 할 수 있게 되는 것이다.

 

요약

따라서 Cache Aside와 Write Around 전략을 사용할 때는 만료시간(TTL)을 함께 활용해야 한다.

 

6. Caching으로 조회 성능 개선 전 제일 먼저 고려해야 하는 것!

우선 조회 성능을 개선할 수 있는 방법들에 대해서 먼저 정리해보자.

• SQL 튜닝
• Caching 서버 활용(Redis 등)
• 레플리케이션(Master/slave 구조)
• 샤딩
• DB 스케일 업(CPU, Memory, SSD 등 하드웨어 업그레이드)

 

방법은 많지만! 제일 먼저 SQL 튜닝을 고려하자!

이유는

1. 추가적인 시스템 구축으로 발생하는 비용을 줄이고 성능을 개선할 수 있다.
2. 근본적인 문제가 SQL 튜닝에 있을 가능성이 높다. SQL 자체가 비효율적이면 시스템 성능 개선에 한계가 있다.

따라서, 가장 가성비 좋은 성능 개선 방법이 SQL 튜닝이니 이를 먼저 고려하고 난 후에 Caching 서버를 활용하자.

 

Reference.

https://www.inflearn.com/course/%EB%B9%84%EC%A0%84%EA%B3%B5%EC%9E%90-redis-%EC%9E%85%EB%AC%B8-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

비전공자도 이해할 수 있는 Redis 입문/실전 (조회 성능 최적화편) 강의 | JSCODE 박재성 - 인프런