BFF란?

BFF는 Backend For Frontend의 약자로,
주로 MSA 환경에서 클라이언트가 각 서비스에 여러번 요청하는 대신, 한번의 요청으로 원하는 형식의 응답을 받도록 하기위해 사용된다.

MSA
Micro Service Architecture의 약자로 여러개의 서비스를 가진 하나의 서버 대신, 여러개의 서비스를 각각 서버로 개발/배포하는 아키텍처이다.

사용이유

위처럼 BFF를 사용하지 않았을때에는 몇가지 문제가 발생한다.

• 클라이언트에서 각각의 서비스에 한번씩 요청을 날리므로 응답시간이 오래걸린다.
• 각 서비스의 응답을 조합해야하므로 응답 파싱이 어렵다.
• MSA 서비스중 한개가 일시중단되면 따로 예외처리를 해야하고 UI 제공이 중단될 수 있다.
• 여러 서비스가 노출되어 보안 취약점이 생기기 쉽다.

반면 BFF를 사용하면 위 문제들을 해결할 수 있다.

• 내부망에서 서비스들을 호출하므로 응답시간이 짧아질 수 있다.
• 서비스의 응답을 필요한 데이터 형식으로 바꿔서 전달하므로 FE의 구현이 간단해진다.
• MSA 서비스가 잠깐 중단되더라도, BFF에 서킷브레이커와 캐싱을 도입하여 장애에 대응할 수 있다.
• BFF만 외부에 노출하여 보안 취약점 관리에 용이하다.
• MSA 내부에서 사용되는 비공개 key가 있다면 이를 숨길 수 있다.

써도 되나?

BFF의 개념을 처음 알게 되었을때 하나의 의문이 들었다.

BFF를 사용하게 되면 MSA의 의미가 퇴색되고, 단일장애지점이 발생할 수 있지 않을까?

실제로 BFF에 대한 단점으로 단일장애지점이 될 수 있다는 문제가 있다.
이를 해결하기 위해서는 BFF를 수평확장하고 로드벨런싱을 통해 가용성을 확보해야한다. 물론 그만큼 더 많은 자원을 소모하게 될것이다.

또 이러한 패턴을 도입하게 되면서 서비스-BFF 또는 서비스-서비스 사이의 의존성이 생겨나지 않도록 주의해야한다.

BFF의 개발이 FE의 역할로 분류되는 경우가 많은데, BE의 MSA 서버와 같은은 망에서 배포되도록 하지 않으면 응답속도에 큰 영향이 있을 수 있다.

결론

BFF는 MSA의 단점을 해결하기 위해 나온 패턴이지만, 그만큼 MSA의 사용 이유를 퇴색시키는 단점을 같이 가지고 있다.

BFF의 가용성을 확보하는데에도 자원이 소모되므로, 도입하기 위해서는 상당히 많은 트래픽이 있어야 수지타산이 맞을듯 하다.
물론 MSA가 대용량 트래픽 처리를 위해 사용되는 패턴이므로 BFF는 충분히 고려할만한 패턴이다.