BFF & MSA 란?

박정호·2023년 1월 16일

Development

목록 보기

1/3

🚀 Start

최근들어 채용공고를 보면 MSA 또는 BFF의 개념을 잘 이해하고 있는지에 대한 조건을 확인할 수 있었다. 또한 최근에 GraphQL에 대해 공부하며 자연스럽게 BFF라는 단어를 많이 접하게 되었는데 이번에 정확히 MSA는 무엇이고, BFF란 무엇인지 알아보려 한다.

⭐️ MSA

이전까지는 화면부터 데이터베이스까지 전체가 하나의 흐름으로 묶인 Monolithic Architecture을 사용하였다.

이 특성의 문제는 부분 장애가 전체 서비스의 장애로 확대될 수 있고, 부분적인 서비스의 변경이 어려우며, 수정시 장애의 영향도 파악하기 힘들다는 것이었다.

이런 문제점들을 보완하기 위해 등장한 것이 MSA이다.
MSA는 Micro Service Architecture의 약자로, 각각의 마이크로하게 나눈 독립적인 서비스를 연결한 구조를 뜻한다.

이러한 특성으로 시스템 전체의 중단 없이 민첩하게 필요한 부분만 독립적으로 업데이트, 배포가 가능하다고 한다.

💡 마이크로 서비스
: 서비스를 비즈니스 경계에 맞게 세분화하고, 서비스 간 통신은 네트워크 호출을 통해 진행하여 확장 가능하고 회복적이며 유연한 어플리케이션을 구성하는 것

✔️ MSA 목적

1️⃣ 시스템 전체를 종료하지 않고 서비스 별로 배포 가능하여, 요구사항이 신속하게 반영될 수 있다.

2️⃣ 특정 서비스에 대해서만 자원 확장성을 통해 투자할 수 있다. (클라우드와 잘 어울림)

3️⃣ 부분적 장애를 격리하여, 시스템 전체로 확장되는 것을 예방할 수 있다.

✔️ MSA 장,단점

✅ 장점

향상된 모듈성 유지
- API라는 국경선으로 서비스가 나뉘어져 있어 기존 모놀리식에 비해 애플리케이션의 모듈성을 유지하기 쉽다.
새로운 기술 스택 도입에 유리
- 서비스를 독립적으로 배포하며 서비스 간 통신은 API로 하기 때문에 가능
도롱뇽 꼬리 아키텍처
- 장애가 발생하면 적어도 장애가 난 곳만 죽는다
서비스가 작아 관리에 유리
- IDE가 느려지지도 않고 애플리케이션 시동 시간이 짧아 생상성이 향상

✅ 단점

도입이 어려움
복잡한 운영
트랜잭션 유지의 어려움
헬모드 디버깅

✔️ MSA 구성요소

✅ MSA를 구성하는 주요 Component

Config Management
- 서비스의 재빌드,재부팅 없이 설정사항을 반영
- Netflix Archaius, Kubernetes Configmap
Service Discovery
- MSA 기반 서비스 배포시 서비스 검색 및 등록
- Netflix Eureka, Kubernetes Service, Istio
API Management
- 클라이언트 접근 요청을 일원화
- Netflix Zuul, Kubernetes ingress
Centralized Logging
- 서비스별 로그의 중앙집중화
- ELK Stack
Distributed Tracing
- 마이크로서비스 간의 호출 추적
- Spring Cloud Steuth, Zipkin
Centralized Monitoring
- 서비스별 메트릭 정보의 중앙집중화(Netflix Spectator, Heapster)
Resilience & Fault Tolerance
- MSA 구조에서 하나의 실패한 서비스가 체인에 연결된 전체 서비스들에 파급 효과를 발생시키지 않도록 하기 위한 계단식 실패 방지 구조
- Netflix Hystrix, Kubernetes Health check
Auto-Scaling & Self-Healing
- 자동 스케일링, 복구 자동화를 통한 서비스 관리 효율화

⭐️ BFF

MSA 형태의 개발을 하다 보면, 다음과 같은 상황이 펼쳐질 수 있다.

여러 프레임워크(Web, Android, iOS, Desktop 등)을 지원하게 되면서 각각 특정 데이터가 필요한 상황
원하는 데이터 형태에 도달하기 위해 여러 API 호출의 응답을 조작, 혼합, 일치시키는 상황
이런 상황들이 겹쳐 프론트엔드에서 복잡한 계산이나 비즈니스 로직을 작성하는 상황

다시말하자면, MSA는 각 서비스를 도메인별로 분리시키고, 서비스가 각 기능별로 흩어져 있기 때문에 화면을 완성하기 위해 호출해야하는 서비스도 늘어나게 된다.

따라서, 다수의 서비스에 연동을 해야하며 여러 서비스에 분산되어 있는 데이터를 가져와서 적절히 합쳐야 하는 경우도 발생한다.

이는 코드 베이스는 커지고 복잡성은 증가하며 프론트엔드에서 복잡한 계산을 수행하는 경우 렌더링 성능에도 영향을 줄 수 있다.

✅ 이러한 점들을 해결하기 위해 나타난 아키텍처가 BFF(BackEnd For FrontEnd)이다.

BFF는 프론트엔드 프레임워크(Web, Android, iOS, Desktop, 스마트 워치 등) 별로 필요에 맞게 각각 백엔드를 구성하는 아키텍처 방법론이다.

BFF는 MSA의 여러 패턴 중 하나로, 하나의 인터페이스로 구성되어있던 모노리스 서비스에서 마이크로서비스로 전환되면서 여러 UI기반 시스템이 여러 서비스의 API를 호출하고 통신하는 형태로 발전되어, 이때 API에 다이렉트로 의존할 때 발생하는 이슈들을 해결하고자 BFF가 등장한 것이다.

BFF를 쉽게 말하면 말 그대로 프론트엔드를 위한 중간 서버를 구현하는 것이라고 생각하면 된다.

💡 API 의존 이슈

MSA(Micro Service Architecture) 환경에서 API 엔드포인트가 분리될 때 팔로업 이슈

브라우저의 숙명인 CORS 이슈

API 입장에서 여러 플랫폼과 스펙을 맞출 때의 커뮤니케이션 비용

플랫폼별로 다를 수 밖에 없는 인증 방식을 통합하려는 무리한 시도

클라이언트의 꿈인 ‘화면에 필요한 데이터만 받는’ partial response를 하기 어려운 이슈

✔️ BFF with GraphQL

간단한 예시로 아래와 같이 일반적인 API통신을 보자.

// GET/user/get_profile
{
  message: "성공"
  profile: {
    uid: 1234,
    nickname: "치즈",
    email: "cheese@test.com",
    create_dt: "1995-01-31 00:00:00" // 실제 화면에는 필요하지 않은 값
    user_id: "5678" // 실제 화면에는 필요하지 않은 값
  }
  response_time: "2022-03-03 17:49:39" // 실제 화면에는 필요하지 않은 값
  result_code: 0
}

실제로 프론트엔드에서는 사용되지 않는 데이터 정보까지 함께 전달된다.(Over- fetching)
반면, GraphQL로 처리할 경우에는 아래와 같이 필요에 다른 데이터로 가공한다.

query userAndCash() {
  userAndCash() {
    user() {
      ...User
    }
    cash() {
      ...Cash
    }
  }
}

fragment User on User {
  uid
  nickname
  email
}

위에서 본 예시를 보면 알 수 있듯이, GraphQL은 REST API와 달리 클라이언트가 응답 형태를 정의할 수 있어서 데이터를 효율적으로 로드할 수 있다.

따라서, 데이터를 과도하게 가져오거나 작게 가져오지 않도록 UI 콘텐츠를 표시하는데 필요한 데이터를 지정할 수 있도록 효율적으로 쿼리를 만든다.

특히 클라이언트가 단 하나의 엔드포인트로 백엔드와 통신한다는 부분에서 BFF와 연관이 있는 것 같다.

클라이언트 환경이 다양해지며서 모든 클라이언트의 요구사항을 대응하는 API 서버를 만드는 것은 어렵다, 이러한 상황을 감안하여 프론트엔드 측에서 클라이언트 별 요구 사항에 대응하기 위한 서버를 구성하고 백엔드 API 서버와 연동하는 역할을 하는 BFF 아키텍처를 개발한 것이고, 통신간 Request를 줄일 수 있는 GraphQL이 하나의 방법인 것 같다.

✔️ BFF 장,단점