[NHN FORWARD 2021] Redis 야무지게 사용하기 정리

June·2023년 5월 3일

Redis

목록 보기

4/4

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

1. Redis 캐시로 사용하기

캐시란

Redis as cache

캐싱 전략

읽기 전략

가장 일반적으로 쓰이는 전략이다. 캐시에서 먼저 확인하고 있으면 가져온다. 없으면 DB에서 가져와서 레디스에 저장한다. lazy loading이라고도 부른다. 레디스가 없어도 db에서 가져올 수 있다. 이때 db에 트래픽이 많이 몰릴 수 있다. 레디스를 새로 투입하면 캐시 미스가 많이 발생해서 성능저하가 발생할 수 있다. 이때 레디스에 데이터를 밀어넣어줄 수 있는데 이를 cache warming이라고 한다. 실제로 상품 오픈 전 미리 올려두는 작업도 한다.

쓰기 전략

Write Around: 모든 데이터는 db에만 저장한다. 캐시 미스가 발생한 경우 캐시의 데이터를 끌어온다. 이때는 캐시의 데이터와 db의 데이터가 다를 수 있다.

Write Through: db에 저장할때 캐시에도 저장한다. 캐시에 항상 데이터가 최신이지만, 두 단계로 저장하기 때문에 성능이 느릴 수 있다.

2. Redis 데이터 타입 야무지게 활용하기

Redis Data Types

streams는 로그를 기록하기 가장 좋은 자료구조다.

Best Practice - Counting

대량의 데이터를 다룰때 적절하다. 저장된 데이터는 다시 확인할 수 없기 때문에 보안용으로도 적절히 다룰 수도 있다. 예를 들어 우리 사이트에 접속한 ip의 개수.

Best Practice - Messaging

LPUSHX나 RPUSHX는 키가 있을때만 저장 가능하다. 키가 이미 있다는건 예전에 사용한 큐라는 거고, 사용한 큐에만 데이터를 넣기 때문에 비효율적인 데이터 이동을 막을 수 있다. 트위터는 내가 팔로한 사람들의 데이터 뜨는데, 이때 RPUSHX를 사용한다. 트위터를 자주 이용하던 유저의 타임레만 새로운 데이터를 캐싱하며, 자주 사용하지 않는 유저는 캐싱 키 자체가 존재하지 않는다.

로그를 저장하기 좋다. 레디스 문서에서는 카프카를 대체해서 간단하게 메세지 스트림을 구현할 수 있다고 한다.

레디스에서 데이터를 영구 저장하려면? (RDB vs AOF)

Redis Persistence Option

AOF는 명령어를 저장하는거고, RDB는 스냅샷을 찍는다고 보면된다.

자동 / 수동 파일 저장 방법

만약 레디스를 캐시로만 사용한다면 굳이 이 기능 사용할 필요가 없다. 데이터 손실을 감수할 수 있으면 RDB를 사용하고, 장애 직전까지 모든 데이터가 보장되어야 하면 AOF를 사용하면 된다.

레디스 아키텍처 선택 노하우 (Replication vs Sentinel vs Cluster)

Replication 구성

복제는 비동기로 진행된다. 장애 상황시 수동으로 복구를 해야한다.

Sentinal 구성

마스터 노드가 죽으면 기존의 replica가 자동으로 마스터가 된다. 어플리케이션에서는 바꿀 필요 없다. 항상 홀수 대로 띄어야 한다.

두 대의 서버에는 일반 서버와 센티널을 함께 띄우고 다른데는 센티널만 띄운다.

Cluster 구성

샤딩을 제공한다. 모든 노드가 서로를 감시하고 있다가, 마스터가 비정상일때 자동으로 페일오버 한다.

아키텍처 선택 기준

Redis 운영 꿀팁과 장애 포이늩

Redis는 Single Thread로 동작

스캔은 재귀적으로 호출한다. hash나 sortedSet은 내부에 아이템이 많아질 수록 성능이 떨어진다. 최대 100만개 정도까지만 넣자. del로 지우면 그동안 아무것도 못하므로 unlink를 사용하면 백그라운드 동작으로 지운다.

변경하면 장애를 막을 수 있는 기본 설정 값

처음 옵션은 레디스를 모니터링 하고 있다면 꺼두는게 오히려 좋다.
두번째 옵션은 메모리가 가득찼을때, volatile-lru는 expire 설정이 있는 키만 lru로 지운다. 만약 expire 설정을 하지 않았으면 결국 장애가난다. 그래서 모든 키를 대상으로 lru 추천