MSA and BFF 이해하기

기존에 MSA아키텍쳐의 경우 정말 많은 기업에서 활용하기에 알아본적이 있지만 BFF는 처음 들어보기에 이번 기회에 새로이 공부하고자 한다.

MSA(MicroService Architecture)

MSA의 가장 큰 특징은 독립적으로 배포가 가능한 작은 서비스의 모음이다.

Why? Monolithic Architecture처럼 모든 구성요소가 통합되어 있다면 한부분의 오류가 모든 부분에 영향을 줄 수 있고, Scale out, 책임, 배포시간 등 여러 부분에서 한계를 보인다. 이를 해결하기 위해 MSA를 사용한다.

MSA특징?

1. 오직 노출된 API를 통해서 사용가능하다.
2. 실질적인 세부사항은 추상화한다.
3. 하나의 MicroService는 하나의 비즈니스 범위에 맞춰서 만들어진다.
4. 위처럼 만들어진 서비스는 여러 어플리케이션에서 사용 가능하다.
5. 통신에는 REST등 가벼운 방법을 이용한다.
6. 서비스 간 통신은 RPC 또는 message-driven API등을 이용한다.
7. MicroService를 통해 서로 다른 기술스택을 사용할 수 있다.

MSA단점?

1. 구현이 복잡하다. 분산된 서비스로 인해 부하, 장애에 따른 무결성 유지가 힘들어진다.
2. 통합테스트가 힘들어진다.
3. 1개의 MicroService의 변경 후 다른 서비스와 문제가 없는지 확인해야한다.

그렇다면 BFF와는 무슨 관계일까?

BFF(BackEnd For FrontEnd)

BFF는 MSA의 패턴 중 하나이다. 여러 프론트의 요구사항을 처리해주는 중간 다리 역할의 서버이다.

Why? 쇼핑몰을 MSA로 구현했다고 생각해보자 재고, 유저정보, 장바구니 등 다양하게 구현한 서비스가 있다.

여기서 구매라는 기능을 구현해 요청한다면 내가 구매한 물품의 수량, 정보, 장바구니에서 사라짐, 최근 유저정보에 구매항목 추가 등 다양한 요청/응답을 해야한다.

또 보안측면에서 유저의 숨겨야하는 개인정보가 있을 수 있고 복잡한 연산을 프론트측에 다뤄야 할 수도 있다.

이 모든 것을 BFF서버에 넘겨버려 사용자에게 정말 필요한 부분만 쓰도록 해준다.

즉 다음과 같은 장점이 생기는 것이다.

프론트 엔드에서 복잡한 로직을 감추고 추상화된 인터페이스를 사용 가능하다.

연동하는 백엔드 API의 인터페이스가 변경되는 경우 BFF에서 수정사항을 반영하면 되므로 프론트엔드는 관심사를 분리하여 본연의 비즈니스 로직에 집중할 수 있다.

데이터를 전송하는 과정에서 민감하거나 불필요한 데이터는 숨길 수 있다.

즉 프론트 측에서 복잡한 연산을 해야하는 대시보드, 물류 시스템, OpenAPI를 사용하는 서비스 등에 사용하면 효과적으로 사용할 수 있을 것이다.