BFF를 말하기 전에 MSA에 대해 간단하게 집고가자.

MSA란?

Micro Service Architecture로 큰 Monolithic 어플리케이션을 마이크로하게 나눈 독립적인 서비스를 연결한 구조를 말한다.

MSA의 목적

서비스의 독립성과 확장성을 통한 효율적인 소프트웨어 개발 및 유지 보수

MSA 장단점

장점

• 배포: 각 서비스를 개별적으로 업데이트하고 확장할 수 있음.
• 확장성: 독립적으로 확장 가능. 자세하게 말하면 특정 서비스에 대한 요청이 증가하면 해당 서비스만 확장하여 처리 가능
• 유연성: 독립적인 실행환경에서 작동하므로 서비스별로 최적화된 기술을 사용하기 좋음
• 시스템의 가용성과 안정성 향상: 에러가 해당 서비스 내에서 제한. 하나의 서비스에 문제가 생기더라도 다른 서비스는 계속 정상적으로 작동.

단점

• 데이터 일관성 유지: 서비스마다 독립된 데이터베이스를 가지므로 전체 시스템에 서 데이터 일관성을 유지하기 힘듬
• 서비스 간의 통신 관리: 서비스 간에 데이터를 주고받는 상황에서 통신과 트랜잭션 관리에 대한 복잡성이 증가. => 추가적인 로직을 구현해야 한다
• 테스트: 서로 독립적이므로 종속성과 호환성을 확인하기 위해 전체 시스템 테스트를 수행하는 것이 어려움
• 배포: 여러 서비스를 배포하고 관리해야 하므로 배포 프로세스가 복잡

MSA를 구현함으로써 Frontend가 받는 영향

1. 클라이언트-서버 통신 복잡성 증가: 프론트엔드는 기능을 구현하기 위해서 다양한 api를 호출해야 한다.
2. 데이터의 일관성 관리: 마이크로서비스는 독립적으로 데이터를 관리하므로 여러 서비스로부터 데이터를 얻어오는 환경에서 데이터 일관성을 유지해야 한다.
3. 성능 이슈: MSA에서는 서비스 간 통신이 필요하므로 네트워크 지연이 발생할 수 있다.

정리하자면, 서비스가 기능별로 나누어져 있기 때문에 기능을 완성하기 위해 호출해야 하는 서비스가 늘어나며 다수의 서비스에 연동을 해야 하기 때문에 여러 서비스에 분산되어 있는 데이터를 가져와서 적절하게 합쳐야 하는 경우도 발생한다.

결과적으로 코드의 복잡성이 증가하고 렌더링 성능에도 영향받을 수 있다.

BFF 패턴이란?

Backend For Frontend로 사용자 인터페이스에 특화된 API를 제공하는 아키텍처 패턴입니다.
말 그대로 프론트엔드를 위한 중간 서버를 구현하는 것.

장점

1. 프론트엔드 특화: 특정 프론트엔드 애플리케이션에 대한 요구사항에 따라 맞춤형 API를 제공할 수 있다. 이로 인해 프론트엔드는 필요한 데이터를 효율적으로 가져올 수 있다.
2. 불필요한 데이터를 숨길 수 있기 때문에 깔끔하다
3. 통신 지연 최소화: 여러 개의 프론트엔드 어플리케이션 인터페이스가 각각의 BFF 서버를 병렬적으로 호출하므로, 각각의 응답이 빨라진다.

단점

• 많은 부분의 코드가 중복되거나 재작성될 수 있다. 이 과정에서 많은 커뮤니케이션 비용이 발생한다.

프로젝트

본 내용을 작성하기 전에 간단하게 프로젝트 환경에 대해 설명하자면...

• 백엔드에서 review, order, member, store, notice, pay까지 6개의 서비스로 나누어서 MSA를 구현
• 두 개의 도메인을 가지고 있음. (사장님 사이트, 손님 사이트)
• Next.js 사용

프로젝트에 BFF를 적용한 이유

클라이언트에 필요한 형태로 제공할 수 있다는 이유가 가장 크다. (필요한 데이터만 받고 싶은 프론트...)
BFF에 대해 찾아보니 클라이언트에서의 데이터 처리 부담도 줄일 수 있고 불필요한 데이터를 숨길 수 있다는 점에서 좋아 보였다.
그리고 최대한 다양한 경험을 해보는 것이 좋다 생각했다.

직접 느낀 BFF 단점

추가적인 개발 및 유지 보수 비용이 많이 든다...!
처음에는 호출한 api 결과를 깔끔하게 만들어서 프론트에 보내는 것이 다라고 생각했지만 아니었다는 사실!
token 처리도 잘 해야 하고 Spring 서버로 요청 보낼 때도 문제가 생기기도 했다.
서버를 만지는 것은 처음이었기 때문에 더더욱 오래 걸렸다. 개발을 하면서 backend 관련 에러가 나면 BFF 쪽 에러인가 Spring 서버 쪽 에러인가 판단해야 했다. 시스템이 복잡해졌다고 느낀 순간이었다.

또한 고객 프론트와 사장 프론트에서 유사한 기능이 필요할 때는 중복 코드가 생기는 꼴이라 개발 효율성도 떨어지는 점이 있다.

최대 2배 정도 할 일이 늘 줄 알았는데 3배는 된 것 같다 ㅇㅅㅇ(문제가 발생했을 때 해결을 위해 시간을 많이 쏟았었다.)

마치며

BFF 패턴을 적용하면서 단점도 느끼긴 했지만, 지금보다 훨씬 큰 서비스에서는 필요한 패턴이라고 생각한다. 현재 프로젝트로써는 데이터를 주고받기만 하는 것이 많았기 때문에 "BFF를 도입하길 너무 잘했다!!!"라는 느낌은 크게 못 받았지만 개발하면서 왜 BFF를 사용해야 하는지는 느꼈다.

마지막에 단점들을 말해서 BFF가 안 좋은 경험이었다는 쪽으로 가는 것 같은데 각각 프론트엔드 (고객님, 사장님)에 특화된 API를 만들 수 있기 때문에 불필요한 데이터 전송을 최소화할 수 있어서 성능 최적화가 되었다고 생각한다!