대규모 환경에서 레디스 캐시 성능을 높이기
(meetup.toast.com)레디스(Redis)는 온라인 서비스의 캐싱에 널리 쓰이는 인메모리(In-Memory) 데이터베이스입니다. 하지만 잘못 사용할 경우 예상치 못한 문제가 생기거나 심지어 큰 장애가 발생할 수도 있죠. 제가 최근에 서점에 갔다가 우연히 모 기업의 SRE팀에서 일하는 현업 엔지니어와 만났는데, 대화 중에 그 분이 “레디스는 사실 필요악이다. 언젠가는 관련 장애가 한번쯤 터질 거라고 생각하면서 써야 한다.”고 말할 정도인 모양이더라고요.
참고 - 카카오 "레디스, 잘못쓰면 망한다":
https://zdnet.co.kr/view/?no=20131119174125
참고 - 쿠팡 오류 원인은 오픈소스 '레디스 DB' 때문:
http://www.digitaltoday.co.kr/news/articleView.html?idxno=212904
이렇듯 레디스는 잘 알고 섬세하게 사용해야만 하는 물건입니다.
서론이 길었습니다. NHN에서 RedisConf 2020의 발표 내용을 바탕으로 대규모 트래픽 환경에서 레디스를 캐시로 사용할 때 성능 이슈가 발생할 수 있는 부분을 3가지 지적하고, 그 해결법을 설명한 문서를 소개합니다. (한국어)
* Cache Stampede: 캐시 공간은 한정되어 있으므로 저장된 데이터에 만료시간(TTL)을 정하는 것이 보통인데, 해당 데이터에 계속 읽기 요청이 들어오고 있을 때 캐시 만료시간이 닥치면 순간적으로 DB에 그 읽기 요청이 집중되고 그게 다시 레디스에 중복된 쓰기 요청으로 몰리게 됩니다. 이를 캐시 스탬피드(Cache Stampede)라 부르는데, 해결방법으로는 확률분포에 기반한 알고리즘으로 TTL값을 미리 갱신하거나 혹은 디바운스(Debounce, 여러 번 반복되는 이벤트 중 마지막 이벤트만 실행하기) 개념을 도입하는 방법이 있습니다.
* Hot Keys: 하나의 키에 읽기가 집중될 때도 성능이 떨어질 수 있습니다. 위 글에서는 그 대책으로 키 이름 앞에 Prefix를 붙여 여러 복제본을 만든 뒤, 그 Prefix가 붙은 복제본에 랜덤으로 읽기를 분산시키는 방법을 소개하고 있습니다.
* Compression: 크기가 큰 데이터를 레디스에 저장할 때도 성능 저하가 발생할 수 있습니다. 이때 적절한 압축을 적용하는 것만으로도 속도와 메모리 사용량에서 큰 이득을 볼 수 있습니다. 적절한 압축 방법과 비율은 상황과 환경에 따라 다를 수 있기 때문에, 이를 적용할 때는 사용 환경을 재현한 벤치마크 테스트가 필수입니다.
참고 - 위에서 언급된 확률분포 기반 알고리즘(Probablistic Early Recomputation)의 예제 코드가 나오는 글:
https://engineering.linecorp.com/ko/blog/…