여기어때, BFF 도입으로 프론트엔드 복잡성 해결!

여기어때는 MSA(Microservices Architecture) 환경에서 화면 구성(Screen Composition)을 위한 다수 API 호출 문제에 직면함

BFF(Backend For Frontend)를 도입하여 클라이언트(Client)가 여러 도메인 API를 호출하는 대신, 단일 API 호출(Single API Call)로 화면을 구성하도록 개선

장애 전파(Cascading Failures) 및 메모리 과부하(Memory Overload)와 같은 BFF 구조의 문제점을 해결하기 위해 재시도(Retry) 전략, 서킷 브레이커(Circuit Breaker), 캐싱(Caching) 기술을 적용

BFF 아키텍처의 핵심 원리

여기어때는 MSA 환경에서 화면을 구성하기 위한 다수의 API 호출로 인한 클라이언트(Client)의 복잡성을 해결하기 위해 BFF(Backend For Frontend)를 도입했다. BFF는 여러 도메인 API를 호출하여 데이터를 조합하고, 클라이언트가 필요로 하는 형태로 가공하는 UI-Driven 서버 계층(UI-Driven Server Layer)이다.

데이터 조합(Data Aggregation): 여러 도메인 API의 결과를 통합하여 클라이언트에게 필요한 데이터를 제공

뷰 모델 변환(View Model Transformation): 도메인 모델을 클라이언트의 뷰 모델(View Model)로 변환하여 데이터 구조를 최적화

비즈니스 로직 처리(Business Logic Handling): 화면 단위의 비즈니스 분기 로직을 서버 측에서 처리하여 클라이언트의 부담을 줄임

이러한 과정을 통해 클라이언트는 단일 API 호출만으로 화면을 구성할 수 있게 되었다.

BFF 도입 전후 구조 비교

기존 여기어때의 API 구조는 클라이언트(Client) → Gateway → 각 도메인 API로 구성되어, 클라이언트가 여러 API를 직접 호출하고 데이터를 조합해야 했다. 이로 인해 네트워크 오버헤드(Network Overhead), 클라이언트 복잡도 증가, 중복 개발 및 유지보수 난이도 증가, 에러 처리의 어려움 등의 문제가 발생했다.

BFF 도입 구조: 클라이언트 → BFF → (내부망) → 각 도메인 API

BFF 도입 효과: 클라이언트는 단일 BFF API 호출로 화면을 구성, 복잡한 메쉬업 로직(Mesh-up Logic)을 알 필요가 없어짐

BFF는 내부망에서 여러 도메인 API를 호출하고, 클라이언트가 필요로 하는 형태로 데이터를 가공하여 제공함으로써, 화면 단위 복잡성(Screen-Level Complexity)을 효과적으로 해결했다.

BFF 구조의 문제점과 해결 방안

BFF는 여러 하위 도메인 API에 의존하므로, 특정 API의 지연이나 실패가 전체 시스템에 영향을 미치는 장애 전파(Cascading Failures)의 위험이 있다. 또한, 여러 마이크로서비스에서 데이터를 가져와 조합하는 과정에서 메모리 및 힙(Heap) 과부하(Memory Overload)가 발생할 수 있다.

장애 전파 방지: Spring Retry 기반의 지수 백오프(Exponential Backoff) 재시도 전략, 빠른 실패(Fast Fail) 또는 대체 응답(Fallback) 적용, 서킷 브레이커(Circuit Breaker) 도입

메모리 과부하 방지: 도메인 팀과의 협업을 통한 하위 API 페이징 처리 강제, Caffeine cache를 활용한 불필요한 외부 호출 및 객체 생성 감소

BFF는 화면 단위 편의성을 제공하지만, 데이터 집중으로 인한 문제점을 해결하기 위한 기술적 노력이 필요하다.