Redis 주의사항

Cache Stampede

Stampede를 해석하면 우르르 몰려오는 소떼등을 의미합니다.

stampede

우리는 레디스를 캐시로 사용할 때 데이터의 갱신을 위해 대부분의 서비스에서는 키에 대해 Expire Time(만료시간)인 TTL을 설정합니다.

 

키가 Expire Time이 도래하기전까지는 DB에 부하를 주지 않고 Redis에 부하를 주면서 빠른 응답을 제공하는 것이죠

 

하지만 대규모 트래픽 환경에서 이 TTL 값은 예상치 못한 문제를 발생시킬 수 있습니다.

대규모 트래픽에서 키가 만료되는 순간 Redis에 조회되지 않기 때문에 DB에는 순간적인 duplicate read가 발생하게 됩니다.

그리고 다시 이는 Redis에 키를 적재하기 위한 Duplicate write를 발생시킵니다.

 

 

Cache Stampede를 해결하기 위한 방법 1 : PER

PER은 Probablistic Early Recomputation의 약자로 TTL이 실제로 만료되기 전에 일정 확률로 캐시를 갱신하는 방법입니다.

데이터베이스에서 키가 완전히 만료되기 전에 데이터를 먼저 읽어오게 함으로써 Cache Stampede 현상을 막을 수 있습니

다.

 

실제로 LINE에서 성능테스트했을 때, 이 알고리즘을 도입하면 세배 정도의 응답 시간 개선이 있었다고 합니다.

 

Cache Stampede를 해결하기 위한 방법 2 : Debouncing

디바운싱은 단위시간 내에서 호출되는 마지막 함수만 호출하는 방법입니다.

인터벌이 100ms라면 100ms동안의 모든 이벤트는 무시되고, 마지막 이벤트만 동작시킵니다.

 

예를 들어 특정 키 miss가 발생해도 바로 DB에 질의하지 않습니다.

키 ID에 대해 debouncer를 생성하여 첫 번째 reader가 이 함수를 반환할 때까지 다른 reader들은 기다립니다.

 

Hot Keys

하나의 키에 대한 접근이 너무 많을 때도 문제가 발생할 수 있으며, 캐시 성능을 저하시킬 수 있습니다.

해결방법으로는 키의 복제본을 만드는 방식이 있습니다.

hot key를 저장할 때는 앞에 prefix를 붙여 여러 개의 키를 만들어내고, 키를 읽을 때는 해당 prefix를 랜덤 하게 접근하는 로직을 추가합니다.

 

예를 들면 이벤트를 준비 중인 상품을 hot key로 잡고 대응한다면 다음과 같이 여러 개의 키를 만들어낼 수 있습니다.

• copy-0-product
• copy-1-product
• copy-2-product

기존에 라면 product라는 키에 모든 요청이 몰리겠지만 이제는 트래픽이 3개의 키로 분산됩니다.

 

Compression

Redis에서 러신러닝 모델, HTTP 페이지, 메시지 큐 등으로 사용하여 크기가 큰 데이터를 저장할 때 캐시 성능 저하가 발생할 수 있습니다.

이때 세 가지 사항을 고려하여 압축을 수행할 수 있습니다.

 

https://meetup.nhncloud.com/posts/251

 

압축만 수행해도 2배의 성능 향상이 일어난 모습입니다.

 

 

 

 

 

참고자료

https://meetup.nhncloud.com/posts/251

캐시 성능 향상기 (Improving Cache Speed at Scale) : NHN Cloud Meetup

https://engineering.linecorp.com/ko/blog/atomic-cache-stampede-redis-lua-script#footnote-3

Atomic 처리와 cache stampede 대책을 위해 Redis Lua script를 활용한 이야기