그래서 Redis는 왜 사용해야하고 뭐가 좋은가?(2) - 캐시로 사용하기

0. 이 글의 작성 목적

https://www.youtube.com/watch?v=92NizoBL4uA 

Redis에 대해 알아보다 이 영상이 너무 설명을 잘해주고 있어서 영상의 챕터별로 조금씩 정리해보고자 한다.

 

1. Redis 캐시

대부분 Redis를 캐시로 사용할 텐데 이 부분에 대해 잘 사용하는 방법에 대해 짚고 넘어가고자 한다.

 

우선 Caching이 무엇인지 다시 확인해 보자.

Caching은 사용자 입장에서 데이터를 더 빠르고 효율적으로 액세스 할 수 있는 임시 데이터 저장소다.

이때 이 Cache가 유용하게 사용되려면 당연히 원본에 접근하는 것보다 Cache에 접근하는 게 더 쉽고 빨라야 한다.

또한 동일 데이터에 대해 반복적으로 접근하는 경우 사용하는 것이 좋다.

이 조건에 대해 Redis는 캐시로 사용하기 딱 좋은 조건을 가지고 있다.

• 단순한 Key-Value 구조를 가지고 있어 사용이 간편하다.
• In-memory 데이터 저장(RAM)에 올리고 있어 속도가 빠르다.

Redis의 빠른 성능

• 평균 작업속도 < 1ms
  • 초당 수백만 건의 작업 가능하다는 뜻이다.
    • 지연시간도 감소하고 처리량도 증가한다.

 

2. Caching 전략

Redis를 Cache로 사용할 때 어떻게 배치하는지가 성능을 좌우한다.

이를 Caching전략이라고 하며 데이터의 유형과 해당 데이터에 대한 액세스 패턴을 잘 고려해서 선택해야 한다

 

 

읽기 전략 : look-aside

어플리케이션에서 데이터를 읽는 작업이 많을 때 사용하는 패턴이다.

Redis를 Cahce로 사용할 때 가장 일반적으로 사용하는 방법이다.

1. 어플리케이션은 데이터를 찾을 때 Cahce에서 먼저 확인한다.
2. Cache에 데이터가 있다면 Cache에서 데이터를 가지고 오는 작업을 반복한다.
3. 만약 Redis에 찾는 키가 없다면 어플리케이션은 DB에 접근해서 데이터를 직접 가지고 온 뒤 다시 Redis에 저장한다.

 

이 경우 Cache는 찾는 데이터가 없을 때에만 입력되기 때문에 이를 Lazy loading이라고도 한다.

 

Cache Stampede

Redis가 갑자기 Down 되더라도 장애가 발생하지는 않지만 기존 Redis에 붙어있던 Connection들이 DB로 붙기 때문에 DB에 순간적으로 많은 부하가 발생할 수 있다. 이를 Cache Stampede현상이라 한다.

이런 경우 Cache를 새로 투입하거나 DB에만 새로운 데이터를 저장했다면 처음에 Cache miss가 많이 발생해서 성능에 저하가 올 수 있다.

 

Cache warming

Cache Stampede에 대비하기 위해 DB에서 Cache로 데이터를 밀어 넣어주는 작업을 할 수 있는데 이를 Cache Warming이라고 한다.

실제 NHN의 사례에서는 티켓링크에서는 상품 오픈 전 상품의 정보를 미리 DB에서 Cache로 올려주는 작업을 진행한다.

 

 

쓰기 전략

왼쪽은 Cache miss가 발생한 경우에만 데이터를 Cache로 밀어 넣는다. 이 경우 Cache의 데이터와 DB의 데이터가 다를 수 있다는 단점이 있다.

오른쪽은 DB에 데이터를 저장할 때 Cache에도 함께 저장하는 방법이다. Cache는 항상 최신 정보를 가지고 있지만 저장할 때마다 두 스텝을 거쳐서 저장이 느리다. 또한 사용하지 않을 데이터도 Cache로 들어가기 때문에 리소스 낭비가 크다.

이 경우에는 데이터를 특정 시간(몇 분, 몇 시간)만큼만 보관하겠다는 expired time을 설정해 주는 것이 좋다.