redis 장애 시 대처법

Question

토이프로젝트에서 현재 Redis에 JWT 블랙리스트를 넣어서 토큰 무효화를 생각중인데만약 Redis가 다운될 경우, 블랙리스트 검증 자체가 불가능해지는데이런 상황을 대비해서 실무에서는 보통 어떤 방식으로 설계하나요?예를 들어 캐시어사이드(Cache-aside) 전략처럼 DB fallback을 두나요? 서킷 브레이커나 타임아웃 처리를 넣고 강제로 통과 시키거나 차단하나요? 실무에서 Redis Sentinel 또는 Cluster도 사용하는 것 같은데 토이 프로젝트에서는 오버스펙이나 적용하기 한계가 있어서 고민입니다.보통 어떻게 설계하는지 궁금합니다.

개발잡부 · Answer

구글에 치면 다양한 방법이 나오고, 현재 환경에 맞는 방법 사용하시면 될것 같습니다. 보통은 이렇게 한다와 같은 정답이 없는 부분이라..ex) https://farmfarm1223.tistory.com/153

캐티 · Answer

크래시 원인이 OOM이면 내가 잘못한거 아니나요. 물리 메모리는 비용 가중치가 높아서 일반적으로 이케 하면 안대빈다. sql에 넣고 만료 시간이 되면 비우는 방법이 좋게쩌. sqlite3를 사용하거나 .. 실무에서 돈이차고 넘치었다 하더라도 위에처럼 하면 혼날거여요. 일반적으로 경제에 거품이 일으면 기업에서 돈을 흥청망청 쓰는데 관대하게 서버 요금을 사용하거나 직원 복지 예컨데 비싼 식대 이런거를 하였다가 회사가 기울어서 이케이케 절약하는 정책으로 갔어요.일반적으로 OTP, 큐 같은 고벨류 시스템에 사용하게쩌. 암호화폐, 증권 지수 같은 거에 쓰려나 몰라요. 사실 이쪽은 지연이 앵간하게 없어야 하여서 저수준 제어를 하는거 아니겠나요.

shin7688 · Answer

Redis는 마스터-슬레이브 또는 클러스터 기반의 복제 구성을 하여 마스터 장애시 Cluster를 통해 마스터 장애 발생 시 자동으로 슬레이브를 새 마스터로 복구합니다.Hazelcast같은 경우는 Redis의 마스터-슬레이브와는 다른 분산 데이터 그리드(IMDG) 기반의 복제본을 소유하고 모든 데이타의 복제가 되어 별도의 장애 복구를 고민할 필요가 없습니다. Java로 구현시 Hazelcast 사용도 고려 하시면 좋을 것 같습니다.

zoony · Answer

데이터를 redis에서만 보관하면 장애났을때 답이 없죠많은 경우에 원본은 DB에 저장하고 응답을 빠르게 하기 위해 DB -> Redis로 캐싱해서 사용하는데요.구현자체가 Redis에 없으면 DB데이터 읽어 DB데이터사용하고 Redis에 저장해서 다음 요청에서는 Redis를 사용하게 합니다.다만 Redis가 장애 나면 위의 구조에서 fallback등을 통해 오류가 발생시엔 DB를 읽게 하던가Redis 설정을 통해 아예 처음부터 Redis에서 데이터를 조회하는 과정을 건너뛰고 바로 DB를 보게 하기도 합니다.이후 Redis가 복구되면 다시 캐싱 on 하구요

곰같은개발자 · Answer

일단 장애에 대한 복구시점 과 해당 기능 전제가 필요할 듯 한데요..1.장애 복구 예상 시간이 10분 미만이고2. 블랙리스트의 목적이 단순 로그아웃이나 사용자 차단 용도이런 경우에는 경우에는 fail-safe 원칙에 따라 로컬 캐시(Caffeine 등)를 활용한 임시 fallback 대응이 나쁘지 않다고 생각합니다.반면에 장애가 10분 이상 지속될 것으로 예상되는 경우에는 복구되기 전까지 서비스를 유지해야 하므로 로컬 캐시 지속 사용이 가능한지 여부를 판단하고 불가피하게 DB fallback을 고려해야 할듯 합니다.이때 인덱스 설계가 적절하지 않으면 트래픽 증가 시 성능 문제가 발생 할수 있지만 RDBMS가 Aurora나 샤딩 가능한 구조로 구성되어 있을 경우 크게 문제가 없을듯 하네요.그리고 실무에서는 Aurora 클러스터나 샤딩 기반 설계를 보통 하다보니 DB fallback을 처리하는 것도 나쁘지 않을듯하네요.(가끔 아무생각없이 깡DB를 넣지만 않는다면요....ㅌㅌㅌ)참고로 redis sentinel/cluster 설정으로 어느정도 방어가 될것 같은데... 최악의 경우 아예 redis 서버가 할복(?)한거를 전제로 더 추가하면 저정도 될듯합니다..

스토리 · Answer

여러 방법이 있을 거 같아요.LRU 메모리 캐시,Redis는 캐시로 쓰고, DB에 저장Redis Sentinel or Cluster (요즘은 서버의 성능이 올라가서 딱히 오버스펙인 지는 모르겠습니다.)거의 말씀 하신 내용과 비슷합니다. 서킷 브레이크, 타임아웃은 위의 내용과 맞지 않는 얘기 같습니다.물론 실제로는 Redis 장애가 1년으로 치면 의외로 자주 발생하긴 하지만(Managed 서비스라도 은근 있습니다.), 그만큼 회복력도 빠르기 때문에 topologyRefresh 튜닝을 통해 빠른 접속 회복을 유지해야 할 것 같습니다.Redis 장애로 인한 서킷 브레이크나 타임아웃은 보통 고려하지 않습니다. (Redis를 DB처럼 사용하는 케이스가 아니라면요)

뾰로롱산새 · Answer

서킷브레이커 도 검색해서 보심 좋을거 같습니다.토이프로젝트라 레디스만 사용하셔도 무방하지만 지금처럼 예외케이스를 생각하는건 매우 좋은 자세라고 생각합니다.저같은경우는 redis <-> s3 또는 몽고디비 <-> 원천데이터(RDB) 식으로 3중으로 구성하긴합니다.방법은 너무 많아서 이것저것 지금 내 프로젝트에 맞는 상황을 고려해보심이 좋을거 같습니다.데이터량이라던지, 갱신주기가 얼마나되는지 등등이요!

redis 장애 시 대처법

7개의 답변

Q&A 목록