안녕하세요! 좋은 강의 제공해주셔서 도움이 많이 됐습니다! 수강 후 서킷 브레이커를 프로젝트에 적용해보는 과정에서 궁금한 점이 있어 질문드립니다.
현재 캐시 서버에 서킷 브레이커를 도입해서 장애 발생 시 DB로 우회하도록 구현 했습니다.
여기서 만약 레디스 클러스터를 구축한다면 Master 노드 다운 시 Replica가 새로운 마스터로 승격되면서 Failover가 일어날텐데요!
이때
1. Master와 Replica가 서로 health check를 하는 시간의 timeout
2. 승격이 일어나는 시간
3. Redis Cluster의 Topology를 refresh 하는 주기(현재 Redis Client로 Lettuce를 사용중입니다!)
이 시간 동안은 Redis로 정상 요청이 되지 않을 것입니다.
저는 개인적으로 레디스가 자동으로 Failover 되는 과정은 스스로 회복하는 시간이기에 서킷이 OPEN되야하는 상황으로 보기 힘들다 생각하는데, 서킷의 슬라이딩 윈도우를 설정할때 Failover 동안은 OPEN이 열리지 않을 정도로 여유롭게 설정하는게 좋을까요? 물론 구체적인 값은 트래픽을 예상해서 설정해야 한다고 생각합니다!
결론은, 클러스터의 Failover도 장애로 감지하고 OPEN으로 여는게 좋을지 아니면 Failover는 CLOSE 상태로 넘어갈 수 있도록 여유롭게 설정하는게 좋을지 입니다!
아직 실무 경험이 없기도 하고 주변에 의견을 구할수가 없어서 현업자의 입장에서 강사님이라면 어떻게 구성하실지 궁금해서 여쭤봅니다...!! 혼자 고민해본 부분이다 보니 제가 생각하는 방식이 틀렸다면 피드백 주시면 감사합니다:)
jmin님 오래 기다리셨습니다!!
질문 주신 내용에 대해 답변드려볼게요.
우선 제가 일하고 있는 환경에서는 Redis Cluster에 대한 관리 및 기술 지원은 별도로 해주시는 팀이 있어서 Redis Cluster의 Failover 전략에 대해선 제가 정확히 어떤게 좋다라고 이야기 드리긴 어려울 것 같습니다.
다만, 백엔드 애플리케이션에서는 이야기드릴 수 있을 것 같습니다.
클러스터의 Failover도 장애로 감지하고 OPEN으로 여는게 좋을지
Failover는 CLOSE 상태로 넘어갈 수 있도록 여유롭게 설정하는게 좋을지
이 둘중에선 저는 후자가 대부분의 상황에서 적절한 접근이라고 생각합니다. Redis Cluster의 Failover는 설정만 잘 해주면 제법 빠르게(수초 내로) Master 노드로의 승격이 일어납니다. 그 사이에 불필요하게 서킷 상태를 OPEN으로 바꾸는건 불필요하지 않을까 싶습니다. 더구나 OPEN으로 바꿨을 때의 동작이 DB로 요청이 날아가는거라면 DB에 스파이크성 부하가 발생할 수 있습니다. 그럼 DB 역시 문제가 생길 수 있을 것 같아요.
추가적으로 어떻게할지는 해당 서비스의 트래픽 특성에 따라 다르게 적용해야합니다. 높은 Throughput을 가지는 서비스라면 Redis가 아닌 다른 수단이 바로 받았을 때 문제가 생길 수 있습니다. 특히 DB는 높은 확률로 Redis가 버틸만한 수준의 트래픽을 받았을 때 죽어버릴 가능성이 있습니다. 따라서 DB가 바로 부하를 받는게 가능한 수준의 트래픽인지 가늠해보시고 DB로 트래픽이 우회되도록 만드세요.
만약 DB가 받을 수 없는 트래픽이라면 요청을 실패시키거나, 잠시 후 캐시가 복구 됐을 때 요청이 정상적으로 처리될 수 있는 구조로 만드는게 좋은 접근 방법이라고 생각합니다.
질문에 대한 답변이 되었을까요?!
또 궁금한 내용 있으면 질문 남겨주세요.
감사합니다. (_ _)
답글
jmin
2023.12.30헉 감사합니다 강사님!! 고민을 많이 했던 부분인데 드디어 궁금증이 해결되는것 같습니다ㅠㅠ 궁금한 부분이 생기면 또 질문드리겠습니다~~!!
jmin님 안녕하세요~
우선 강의 재미있게 들어주셔서 감사합니다!
그런데 혹시 주말에 답변 드려도 될까요?!
답글
jmin
2023.12.20물론입니다! 강사님 시간 되실때 천천히 답변 남겨주세요~~!!