BFF 패턴

회사에서 뭔가 Internal 서버의 정체를 알게되었는데, 아는 언니(멋있는 언니 완전 짱)가 자기 회사는 BFF패턴을 쓴다고 했던 게 생각이 났다. 우리 회사도 서버를 위한 서버를 두는 느낌으로 일맥상통하는 것 같다. 보통 회사들이 BFF 패턴을 많이 쓰는 것 같기도 하고 그런거 같아서, 찾아보니까 거의 다 쓴다.

BFF (Backend For Frontend)

프론트엔드에 표현될 데이터를 위한 백엔드 즉, 프론트엔드 데이터에 대한 책임을 백엔드가 가진다. 즉, BFF는 단순히 데이터를 제공하는 것에서 나아가 프론트엔드 친화적으로 데이터를 제공한다. 화면에 보이는 데이터를 가공하는 책임은 서버가 지고, 프론트엔드는 UI를 그리는데 집중한다.

여러 조건에 대한 처리는 서버가 처리하고 프론트엔드에 보일 데이터만 제공하는 것이 BFF의 역할이다.

BFF 의 장점

• 복잡도 관점에서, 프론트가 UI 로직에만 집중할 수 있다. → 캡슐화 및 유지보수에 좋다.
• Client 별 필요한 데이터 전달 가능(여러 API 호출에 대한 응답 수정, 조합)
• 서비스 별 API 호출을 최소화 처리
• MSA 환경에서 API Endpoint 분리 시, Client 에 변경없이 처리 가능
• Browser 의 CORS 또는 인증 방식 등과 같은 공통 부분 처리

BFF 의 단점

• 코드 중복이나 재 작성을 해야한다.

만약 BFF 패턴이 없다면?

프론트엔드가 각각의 서비스 마다 인증 + 네트워크 비용이 발생한다. → 성능 저하

 

프론트엔드는 BFF서버에게 궁극적으로 한번만 호출하고, 방화벽 내부에서 내부 통신하기 때문에 빠르다.

주의 할 점

BFF가 비동기로 동작해야 한다는 점이다.

non-blocking & 비동기로 동작을 구현하기 위해 Spring webflux를 이용할 수 있다.

 

장애 전파를 Circuit breaker 를 통해 대비해야 한다.

그림과 같이 MYDATA관리 서비스가 고장나면, 2,3번이 연달아 되지 않는다. 따라서 장애 전파를 차단하는 것이 중요하다. 이와 관련된 circuit breaker 구현법은 나중에 필요할 때 찾아볼 예정이다. (참고자료에 1번째 자료)

참고 자료

https://medium.com/finda-tech/금융서비스-msa-전환기-bff-와-circuitbreaker-적용-2편-c409e5fb28c9

https://tech.kakaopay.com/post/bff_webflux_coroutine/