인프런 커뮤니티 질문&답변

dlkfjan님의 프로필 이미지
dlkfjan

작성한 질문수

장애 없는 서비스를 만들기 위한 Resilience4j - CircuitBreaker

Resilience4J 적절한 적용 예시인지 질문드립니다.

작성

·

37

1

안녕하세요 🙂

Resilience4J 를 학습한 후 실무에 적용해보려 하는 주니어 백엔드 개발자입니다.

제가 생각하는 예시가 서킷 브레이커를 도입하기 적절한 예시인지 궁금해서 질문을 남깁니다!

 

현재 제가 고려하는 상황입니다.

  1. A 서버 혹은 B 서버로 요청을 보내도 되는 상황 (A서버로 요청 보내는 것이 비용이 저렴하기 때문에 기본적으로 A사 요청)

  2. A사로 요청을 보냈지만 장애 발생 -> 서킷 OPEN 상태로 변경

  3. 서킷이 OPEN일 때 B 서버로 요청

  4. HALF OPEN일 때 A서버로 요청을 보냄

  5. A서버에서 정상적인 응답이 올 경우 서킷 CLOSE

이러한 방식으로 Resilience4J를 도입하려고 하는데, resilience4J가 개발된 의도에 맞게 사용하는걸까요?

혹시 아니라면, 다른 어떤 방법을 사용하면 좋을지 궁금해서 질문 남기게 되었습니다

답변 1

0

이준형(Foo)님의 프로필 이미지
이준형(Foo)
지식공유자

dlkfjan님 안녕하세요~

질문주신 내용에 대해 답변드리겠습니다.

결론부터 이야기하면 적어주신 상황은 Resilience4j의 서킷 브레이커를 적용하기에 적절한 상황이라고 생각됩니다.

왜냐하면, 서킷 브레이커는 주로 외부 시스템에 장애가 발생했을 때 그 시스템으로의 요청을 차단해서 불필요한 대기 시간을 줄이고, 시스템의 안정성을 유지하는 데 사용되기 때문입니다. A 서버로 요청을 보냈을 때 장애가 발생하면 서킷을 OPEN 상태로 전환해서 더 이상 A 서버로 요청을 보내지 않는 건 서킷 브레이커의 기본적인 역할에 잘 맞습니다.

 

B 서버로 Fallback을 하는 것 역시 Resilience4j에서 제공하는 서킷 브레이커에 대한 기능을 잘 활용하셨습니다~

다만 A 서버가 저렴하다고 하셨으니 너무 자주 B 서버로 전환되진 않을지 확인이 필요합니다. 우선 A 서버로 몇번정도 재시도 한 후 B 서버로 Fallback이 되도록 하는게 어떨까 싶네요. 물론 사용자가 요청을 한거라서 대기중인 상태라면 너무 많이 재시도를 할 수는 없을텐데 상황에 맞게 하시면 됩니다.

 

즉, Resilience4j의 서킷 브레이커 + Retry를 함께 사용하시면 좋을 것 같습니다.

질문에 대한 답변이 됐을까요?

 

또 질문 있으면 질문 남겨주세요~

감사합니다. 😃

dlkfjan님의 프로필 이미지
dlkfjan
질문자

감사합니다 큰 도움 되었습니다 🙂

dlkfjan님의 프로필 이미지
dlkfjan

작성한 질문수

질문하기