MSA에서 BFF(Backend for Frontend) 패턴

MSA (Micro Service Architecture)

MSA는 큰 서비스를 잘게 쪼개어 개발/운영 하는 아키텍처입니다. 하나의 큰 서비스는 수십~수백개의 작은 서비스로 나뉘어집니다. 또한 PC뿐만 아니라 다양한 모바일 장치를 비롯해 다양한 클라이언트를 고려해야 합니다. 또한 데이터 처리를 위해 여러 API를 조합하거나 처리하는 과정이 필요합니다. 실제 프로덕트에서 MSA를 이용한 어플리케이션을 구축할 때 여러가지 문제에 직면하게 됩니다. 만약 여러 API를 클라이언트(FE)단에서 전부 호출하게 된다면 어떤 일이 발생할까요?

 만약 이를 클라이언트에서 서비스를 직접 호출하는 형태라면 다음과 같은 문제가 발생할 수 있습니다.

• 각각의 서비스마다 인증/인가 등 공통된 로직을 구현해야하는 번거로움이 있습니다.
• 수많은 API 호출을 기록하고 관리하기가 어렵습니다.
• 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야합니다.
• 내부의 비즈니스 로직이 드러나게 되어 보안에 취약해집니다.

특히 이러한 문제점들은 마이크로 서비스의 갯수가 많아질 수록 기하급수적으로 늘어나게 됩니다.

 

API Gateway

어느 규모 이상 MSA 어플리케이션에는 API Gateway를 도입하게 됩니다.

API Gateway는 API 서버 앞단에서 모든 API 서버들의 도메인과 엔드포인트를 단일화 해주는 또다른 서버입니다. API에 대한 인증과 인가 기능을 가지고 있으며, 메세지의 내용에 따라 어플리케이션 내부에 있는 마이크로 서비스로 라우팅하는 역할을 담당합니다. 만약 API Gateway가 없었다면 클라이언트는 여러 서비스들에 대해 요청을 하고, 여러 서비스의 도메인과 엔드포인트들을 관리해야 했을 것입니다.  하지만 API Gateway는 아래와 같은 단점을 가지고 있습니다.

• 여러 서비스 중 응답이 수정되면 API Gateway와 클라이언트도 함께 대응을 해야합니다.
• 클라이언트 네트워크 장애로 특정 서비스(Gateway)를 호출하지 않을 수 있습니다.
• 여러 프로토콜을 지원하기 어렵다. ex. GraphQL, gRPC 등

이런 문제 위한 해결 방법으로 BFF(Backend For Frontend) 패턴이 생기게 되었습니다.

 

BFF(Backend For Frontend)

큰 관점에서 API Gateway와 BFF 패턴은 동일한 목표를 따릅니다. 두 패턴은 시스템을 사용하는 실제 클라이언트로부터 시스템의 서비스를 분리하고 있습니다. 이러한 분리는 클라이언트가 각 마이크로서비스와 직접 통신하는 경우 각 서비스의 위치, 도메인 등을 알아야하고 모든 서비스가 클라이언트의 통신 프로토콜을 지원해야 하거나 클라이언트가 서로 다른 서비스에서 제공하는 여러 통신 프로토콜을 지원해야 합니다.

API Gateway를 사용할 때 클라이언트는 API Gateway의 위치만 알면 됩니다. 요청이 서비스 A에서 제공되는지 서비스 B에서 제공되는지 여부는 클라이언트에게 중요하지 않으므로 서비스 A와 클라이언트 간에 직접적인 통신이 없어야 합니다.

 

BFF의 역할

BFF는 프론트엔드와 마이크로서비스 간의 간단한 인터페이스 역할을 합니다. BFF의 인터페이스는 UI에 중점을 둡니다. 결과적으로 프론트엔드를 단순하게 유지하고 백엔드를 통해 UI에 필요한 데이터만 얻는데 도움이 됩니다. 즉 아래와 같이 다른 UI별로 BFF 패턴으로 구현할 수 있습니다.

 

BFF의 장점

BFF의 장점은 아래와 같습니다.

• 관심사 분리
  프론트엔드에서 어떤 서비스에 요청을 하는지 알 수 없습니다. 관심사 분리덕에 유지보수가 더 쉽습니다.
• 더 쉬운 API 유지보수
  클라이언트에서 API 구조에 대해 덜 알 되므로 해당 API의 변경 사항에 대한 리소스가 덜 들어가게 됩니다.
• 프론트엔드에서 더 나은 오류 처리
  서버 오류는 대부분 프론트엔드에서 무의미하게 사용됩니다. BFF 패턴을 사용하게 된다면 사용자에게 표시해야 하는 오류를 매핑할 수 있습니다.
• 브라우저 BFF 서버가 다운되어도 모바일 BFF 서버는 영향을 받지 않음
  서비스 안정성 향상에 도움이 됩니다.
• 더 나은 보안
  응답에서 특정 민감한 정보를 숨길 수 있습니다. 프론트엔드에 응답을 다시 보낼 때 프론트엔드에 불필요한 데이터를 생략할 수 있습니다. 추상화는 공격을 더욱 어렵게합니다.

 

API Gateway vs BFF Pattern

API Gateway 또는 BFF 패턴 중 어떤 방식을 사용할지 결정해야 할 때 아래의 보기를 참조하시면 좋을 것 같습니다.

• 각 클라이언트의 요구 사항은 얼마나 다른가요?
  • 서로 다른 통신 프로토콜을 지원해야하나요?
  • 한 클라이언트는 GraphQL, 다른 하나는 REST API를 사용해야 하나요?
  • 향후 일부 요청의 프로토콜을 변경할 가능성이 있나요?
• 클라이언트 코드가 다른 팀의 소유인가요?
  • 그렇다면 BFF 패턴을 사용하는 것이 합리적입니다.
• 클라이언트마다 다른 인증/인가 체제인가요?
  • 이 경우 단일 클라이언트에서만 사용되는 여러 인증 메커니즘을 지원하는 API Gateway 대신 BFF를 사용하는 것이 합리적입니다.