금융 서비스 MSA 전환기 - BFF와 CircuitBreaker 적용(2편)

자산/신용관리 PT에서는 BFF(Backend For Frontend) 를 도입해 WEB과 Mobile APP에 필요한 데이터만 조합해 서빙했다. 여러 API를 한곳에서 묶어 응답을 구성하고, 서비스별 호출 수를 줄이며, 프런트엔드의 복잡한 로직과 공통 처리(CORS, 인증 등)를 BFF로 모았다.

BFF는 일반적인 API Gateway 와 달리 프런트엔드의 요청을 그대로 전달하는 데 그치지 않고, UI/UX에 맞게 응답 형태 자체를 바꾼다. 이 구조를 통해 FINDA APP의 메인 홈에서 여신·수신·MYDATA 정보를 조합해 보여주고, 향후 WEB 전용 BFF를 추가할 여지도 남겼다.

대량 트래픽 상황에서는 MYDATA 관리 서비스의 지연과 오류가 다른 서비스로 연쇄 전파되면서 POD가 Up & Down 되고, 앱 전체 렌더링까지 느려지는 문제가 발생했다. 특히 대환대출 오픈을 앞두고 이런 전파를 막기 위해 CircuitBreaker 를 도입하기로 했다.

외부 통신부는 WebClient 기반으로 구성하고, Resilience4J 의 CircuitBreaker를 적용해 장애가 난 서비스로의 호출을 차단했다. DmsWebClientApiComponent 에 @CircuitBreaker(name = "dms-api-service", fallbackMethod = "callApiMonoFallback") 를 붙여 실패 시 fallback으로 넘기고, FallbackMethodInvokedException 을 던져 실패율 집계에 반영했다.

설정은 서비스별로 분리했으며 기본값은 다음과 같았다.

• failureRateThreshold: 20
• slowCallRateThreshold: 20
• slowCallDurationThreshold: 60s
• permittedNumberOfCallsInHalfOpenState: 10
• slidingWindowType: COUNT_BASED
• slidingWindowSize: 100
• minimumNumberOfCalls: 10
• waitDurationInOpenState: 30s
• recordFailurePredicate: 커스터마이징 Predicate
• recordExceptions: HttpServerErrorException, TimeoutException
• ignoreExceptions: FindaHttpErrorException

실패율은 실패횟수 / slidingWindowSize 또는 minimumNumberOfCalls × 100 으로 계산하며, 조건에 따라 더 작은 분모를 사용한다. 예를 들어 100번 호출 중 20번 실패하면 실패율 20%로 CircuitBreaker가 OPEN 상태로 전환된다.

적용 후에는 오류율이 높아져도 운영 POD가 불안정하게 흔들리지 않았고, Grafana에서 CircuitBreaker failure rate를 확인하며 Slack 알람으로 OPEN 상태도 추적할 수 있었다. 결과적으로 불필요한 재시도와 Thread 낭비가 줄었고, 외부 장애가 자산관리 서비스 전체로 번지는 것을 효과적으로 막았다.