Redis 서버의 흔한 실수 법

Redis 서버가 떨어지거나 APP서버가 떨어질지는 상황에 따른다.

1. KEYS 명령과 ZRANGE 명령으로 수만건 이상에 접근하여 I/O대기로 죽는다
2. 데이터 설계를 실패하여 메모리 부족으로 쓸 수 없게 되어 죽는다

Redis 서버에서 장애 발생 시의 기본 대응

우선 메모리 부족하거나 I/O 대기인가를 나눈다.

1. 실행 시간이 걸린 ZRANGE, keys * 명령을 재검토
2. 불필요한 Key를 삭제한다.
3. 서버 추가하고 수직 분할한다.
4. 데이터 설계를 변경하고 데이터 보관 장소를 Redis에서 RDB로 변경

Redis를 사용하고 있다면 경계한다

유저 수가 많은 서비스라면 하나의 데이터 설계 실수로 실전 Redis 서버나 APP 서버가 정지할 가능성이 있다.
Redis를 이용하는 단계에서 최악의 사태를 상상하며 코드 리뷰에서 경계 수위를 높인다.

캐시가 아닌 스토리지로 이용하고 있으면 지적한다

중요한 데이터는 RDB에 기록하고 캐시만 Redis에 저장한다.
기준은 사라져도 좋은 데이터라면 Redis이다.
원래 Redis에 소중한 데이터를 기록하고 있다면 DB의 트랜잭션 롤 백 때 Redis측 데이터가 롤 백 되지 않아서 데이터 부정합이 발생한다.

Expire는 설정되어 있는가?

Redis에서는 key 마다 Expire(TTL)을 설정할 수 있다.
캐시로 이용하고 있으면 최장 한달 정도의 Expire로 문제 없을 것니다.
한달 이상의 Expire를 설정할 필요가 있는 경우는 거의 틀림없이 Redis를 스토리지로 이용하고 있다는 증거이다.
RDB를 이용하도록 설계를 변경한다.

ZRANGEBYSCORE 명령어를 쓰지 않는다

Redis의 SortedSet은 실시간 랭킹과 같은 갱신되는 리스트의 개발에도 편리하다.
RDB에서는 무겁고 실현할 수 없는 기능을 실현할 수 있다.
SortedSet에서 스코어 범위를 지정하여 취득하는 명령이 ZRANGEBYSCORE 이다.
생각지도 않은 데이터 치우침이 있을 때 1쿼리로 수만건을 취득하게 되어 받는 응답 시간이 1초를 넘으면 크게 퇴화하기 때문에 I/O 대기로 APP 서버나 Redis가 죽는다.
경우에 따라 다르지만 기본적으로는 사용해서는 안 된다.
스코어는 없는 단계에서 범위 지정 된 ZREVRANGE 명령으로 취득해야 한다.

keys * 명령어를 사용하지 않는다

keys 명령은 와일드 카드로 매치한 KEY를 반환하는 명령이다.
이쪽도 마찬가지로 데이터의 편향이 있다면 I/O 대기로 서버가 죽는다.
keys 명령으로 선형 탐색하는 정도라면 RDB에 넣어 Index로 WHERE 구문을 발행한다.

아무래도 Redis을 스토리지로 이용해야 하는 경우도 있다

어떤 일에도 예외가 있다.
예를 들면 Redis의 SortedSet처럼 Redis 특유의 기능을 이용하지 않으면 실현할 수 없는 기능은 적지만 존재한다.
그런 때는 다음의 관점에서 검토한다.

롤백에 의한 데이터 정합성에 대비한 설계가 되어 있는가?

DB 거래 중에 문제가 발생하여 롤백 할 때 Redis는 롤백 되지 않는다.
롤백 된 RDB와 Redis 간에 데이터 부정합이 발생했을 때 올바른 데이터로 짤라서 돌아가는 설계가 되어 있는지의 관점에서 확인한다.
RDB와 Redis에 중복 데이터를 갖고, View에서는 Redis에 접속하여 고속화 혜택을 받고, 데이터 갱신 시에 RDB의 값을 기준으로 해서 Redis 데이터를 덮어 쓰면서 해소한다.

Redis의 데이터가 사라졌을 때 복구할 수 있는가?(필수는 아니다)

Redis가 날라간 데이터 부정합이 발생했을 때 복구할 수 있도록 사전에 전 복구 명령을 준비한다.
RDB에 저장 되어 있으면 장애에 일어나서 코드를 써도 문제 없으므로 필수적인 대응은 아니다.