작성
·
37
1
안녕하세요 🙂
Resilience4J 를 학습한 후 실무에 적용해보려 하는 주니어 백엔드 개발자입니다.
제가 생각하는 예시가 서킷 브레이커를 도입하기 적절한 예시인지 궁금해서 질문을 남깁니다!
현재 제가 고려하는 상황입니다.
A 서버 혹은 B 서버로 요청을 보내도 되는 상황 (A서버로 요청 보내는 것이 비용이 저렴하기 때문에 기본적으로 A사 요청)
A사로 요청을 보냈지만 장애 발생 -> 서킷 OPEN 상태로 변경
서킷이 OPEN일 때 B 서버로 요청
HALF OPEN일 때 A서버로 요청을 보냄
A서버에서 정상적인 응답이 올 경우 서킷 CLOSE
이러한 방식으로 Resilience4J를 도입하려고 하는데, resilience4J가 개발된 의도에 맞게 사용하는걸까요?
혹시 아니라면, 다른 어떤 방법을 사용하면 좋을지 궁금해서 질문 남기게 되었습니다
답변 1
0
dlkfjan님 안녕하세요~
질문주신 내용에 대해 답변드리겠습니다.
결론부터 이야기하면 적어주신 상황은 Resilience4j의 서킷 브레이커를 적용하기에 적절한 상황이라고 생각됩니다.
왜냐하면, 서킷 브레이커는 주로 외부 시스템에 장애가 발생했을 때 그 시스템으로의 요청을 차단해서 불필요한 대기 시간을 줄이고, 시스템의 안정성을 유지하는 데 사용되기 때문입니다. A 서버로 요청을 보냈을 때 장애가 발생하면 서킷을 OPEN 상태로 전환해서 더 이상 A 서버로 요청을 보내지 않는 건 서킷 브레이커의 기본적인 역할에 잘 맞습니다.
B 서버로 Fallback을 하는 것 역시 Resilience4j에서 제공하는 서킷 브레이커에 대한 기능을 잘 활용하셨습니다~
다만 A 서버가 저렴하다고 하셨으니 너무 자주 B 서버로 전환되진 않을지 확인이 필요합니다. 우선 A 서버로 몇번정도 재시도 한 후 B 서버로 Fallback이 되도록 하는게 어떨까 싶네요. 물론 사용자가 요청을 한거라서 대기중인 상태라면 너무 많이 재시도를 할 수는 없을텐데 상황에 맞게 하시면 됩니다.
즉, Resilience4j의 서킷 브레이커 + Retry를 함께 사용하시면 좋을 것 같습니다.
질문에 대한 답변이 됐을까요?
또 질문 있으면 질문 남겨주세요~
감사합니다. 😃
감사합니다 큰 도움 되었습니다 🙂