API Gateway와 BFF(Backend For Frontend)

여러분, 안녕하세요. 이 기사에서는 API 게이트웨이 가 무엇이며 마이크로 서비스 아키텍처 에서 클라이언트-서버 통신 에 API 게이트웨이가 어떻게 사용되는지 살펴보겠습니다 . 또한 API 게이트웨이 패턴의 장점과 단점도 살펴보겠습니다. 그런 다음 API Gateway 패턴의 변형인 Front End용 Backend 라는 패턴을 살펴보고 API GW와 BFF가 필요한 시점을 살펴보며 글을 마무리하겠습니다. 시작하자.

[

](https://javarevisited.blogspot.com/2021/09/microservices-design-patterns-principles.html)

이미지 출처: https://raw.githubusercontent.com/abpio/abp-commercial-docs/rel-4.3/en/images/gateway-bff.png

API 게이트웨이란 무엇입니까?

API 게이트웨이는 클라이언트가 상호 작용할 수 있도록 단일 위치에서 많은 기능을 처리하는 서버입니다. 또한 클라이언트 애플리케이션과 백엔드 마이크로서비스 아키텍처 간의 리버스 프록시 로도 작동합니다.

리버스  프록시 는 웹 서버 앞에 있는 서버 구성 요소 이며 클라이언트 요청 을 해당 웹 서버 로 전달 하고 응답 을 다시 클라이언트 로 보내는 역할  을 합니다 . 리버스 프록시 는 추가 수준 의 추상화 및 제어 를 제공 하여 _ _ _ _ _ _                                클라이언트 와 서버 간의 원활한  네트워크 트래픽 흐름 . _

서버 API를 호출하는 여러 클라이언트가 있을 수 있으며 API 게이트웨이는 요청을 관련 마이크로 서비스로 라우팅한 다음 응답을 받아 클라이언트로 보내는 구성 요소입니다.

모든 단일 마이크로 서비스에서 이러한 기능을 구현하는 대신 보안, 로깅 , 캐싱 등과 같은 모든 교차 기능을 단일 위치에서 처리합니다 . 또한 클라이언트가 통신할 수 있는 단일 엔드포인트를 사용하여 여러 마이크로 서비스 집계에서 데이터를 통합하고 집계할 수 있습니다 .

마이크로서비스 아키텍처가 발전하기 전에는 대부분의 시스템이 모노리스 패턴을 사용했으며 단일 또는 두 개의 서버에서 교차 절단 문제를 처리할 수도 있었습니다. 그러나 마이크로서비스를 사용하면 더 큰 메모리 공간으로 인해 시스템 성능이 저하되어 작업 속도가 느려지는 각 마이크로서비스의 교차 절단 문제를 처리할 여유가 없습니다.

API 게이트웨이를 사용하지 않고 클라이언트에서 마이크로서비스로의 통신

API 게이트웨이가 없는 마이크로서비스 아키텍처의 시나리오를 살펴보겠습니다. 아래 다이어그램에서 클라이언트는 API 게이트웨이 없이 마이크로서비스와 직접 통신합니다.

[

](https://www.java67.com/2021/02/microservices-interview-questions-answers-java-spring.html)

이미지 출처: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/media/direct-client-to-microservice-communication.png

거기에는 많은 단점이 있습니다.

마이크로서비스가 커지고 시스템이 복잡해지면 클라이언트는 모든 엔드포인트를 기억해야 합니다.
클라이언트는 대기 시간을 증가시킬 수 있고 사용자에게 좋은 경험을 제공하지 않을 수 있는 데이터를 로드하기 위해 다양한 마이크로 서비스에 대한 많은 API 호출을 수행해야 합니다.
위에서 논의한 바와 같이 권한 부여, 로깅, 캐싱 등과 같은 교차 편집 문제는 모든 마이크로 서비스에서 구현되어야 합니다.
일반적으로 마이크로서비스는 인터넷에 연결되어 있지 않으며 사설 IP가 있는 사설 서브넷 내부에 배치됩니다. 대중에게 마이크로서비스를 공개하는 것은 공격자에게 문제를 요구하는 것입니다.
클라이언트는 AMQP 또는 이진 프로토콜과 같은 특정 프로토콜만 지원하는 마이크로 서비스와 통신하지 못할 수 있습니다.

마이크로서비스 아키텍처에서 API 게이트웨이를 사용한 클라이언트 서버 통신

이미지 출처: https://hub.packtpub.com/wp-content/uploads/2018/02/B04926_02_05-600x427.png

우리는 마이크로서비스 아키텍처에서 API 게이트웨이를 사용하지 않으면 많은 단점을 보았습니다. 이러한 단점을 없애고 우리의 삶을 편리하게 만들기 위해서는 Client와 Services 사이의 Layer로서 API Gateway가 반드시 필요합니다.

API 게이트웨이의 이점

이미지 출처: https://educosta.dev/wp-content/uploads/API-Gatey-Architecture.jpg

API 게이트웨이는 많은 일을 할 수 있으며 아래에서 이점을 살펴보겠습니다.

1. 백엔드 시스템의 복잡성으로부터 클라이언트 추상화

2. 전체 시스템에 대한 사용자 인증 및 권한 부여를 한 곳에서 처리

3. 필요한 형식에 따라 요청 및 응답 변환

4. 백엔드 서비스에 대한 부하를 방지하기 위해 각 API에 대한 속도 제한

5. DDOS 공격을 방지하기 위해 단일 사용자의 API 요청 제한

6. 반복되는 요청에 대한 응답을 Caching하여 서비스의 부하를 줄입니다.

7. 다양한 프로토콜 지원

8. 개별 API를 측정하여 사용량에 따라 클라이언트에 청구

9. 단일 위치에서 시스템에 대한 API 호출 로깅 및 추적

10. 오류 처리

11. 마이크로서비스 전반에 걸쳐 데이터를 집계 하고 단일 API 호출로 클라이언트에 데이터를 응답합니다. 이렇게 하면 클라이언트가 만들어야 하는 여러 API 호출을 피할 수 있습니다.

API 게이트웨이의 단점

모든 장점에는 단점이 있으며 API 게이트웨이도 마찬가지입니다.

API 게이트웨이는 전체 시스템의 단일 실패 지점이 될 수 있습니다.

2. API 게이트웨이에서 너무 많은 작업을 수행하면 성능 문제가 발생하고 API 호출 대기 시간이 늘어날 수 있습니다 .

3. 마이크로서비스가 너무 많으면 너무 많은 경로를 관리하는 것이 복잡해질 수 있습니다.

4. 클라이언트에서 서버로의 API 호출에는 항상 추가 홉이 있습니다 .

5. 관련된 추가 서버 구성 요소로 인한 추가 비용

FrontEnd(BFF) 패턴용 백엔드란 무엇입니까?

우리는 API Gateway에 대해 자세히 보았고 웹이나 모바일과 같은 단일 클라이언트가 있는 경우 이 접근 방식이 좋습니다. 우리 애플리케이션이 웹, 모바일, IoT 등과 같은 여러 클라이언트에서 사용되는 경우 모든 유형의 클라이언트에 대해 단일 API 게이트웨이를 사용하는 것은 좋지 않습니다. 이는 더 커질 수 있으며 API 게이트웨이 서비스를 하나의 큰 Monolith 서비스로 만들어 부풀릴 수 있습니다.

이러한 유형의 시나리오에 대한 더 나은 접근 방식은 각 클라이언트 유형에 대해 별도의 API 게이트웨이를 사용하는 것입니다. 이 아키텍처 패턴은 BFF(Backend for FrontEnd) 패턴이라고 하며 유행어가 되었습니다.

BFF 패턴은 API 게이트웨이 패턴의 변형인 아키텍처 패러다임 이며구성하다데스크톱, 브라우저, 기본 모바일 애플리케이션, IOT 장치 등과 같은 특정 프런트 엔드 애플리케이션의 요구 사항을 충족하도록 설계된 여러 백엔드

이미지 출처: https://tsh.io/wp-content/uploads/2019/09/backend-for-frontend-design-pattern.png

언제 API GW와 BFF를 사용해야 합니까?

음, 이것은 열린 질문이며 전적으로 조직에 달려 있습니다.

1. 응용 프로그램이 새로운 경우 사전에 사용법을 알 수 없습니다. 따라서 처음에는 API 게이트웨이가 단일 구성 요소가 될 수 있으며 클라이언트 전체에서 사용량이 증가하면 클라이언트용 API를 BFF와 같은 개별 구성 요소로 이동할 수 있습니다.

2. 클라이언트마다 다른 유형의 인증이 필요한 경우 단일 API GW를 사용하는 것보다 BFF를 사용하는 것이 확실히 좋습니다.

3. 클라이언트 응용 프로그램이 다른 팀에서 소유하는 경우 BFF를 사용하는 것이 합리적입니다. 그렇지 않으면 단일 API GW가 있을 때 많은 상호 작용과 오버헤드가 발생합니다.

이 기사에서는 API 게이트웨이가 무엇인지 살펴보고 API 게이트웨이를 사용하거나 사용하지 않고 클라이언트와 마이크로 서비스 간의 통신 시나리오를 살펴보았습니다. API Gateway 패턴의 장단점도 살펴보았습니다. 그런 다음 API Gateway 패턴의 변형인 Backend for Front End 라는 패턴을 살펴보고 API GW와 BFF를 사용해야 하는 경우를 살펴보며 글을 마무리했습니다.

https://medium.com/javarevisited/api-gateway-vs-backend-for-frontend-bff-everything-you-need-to-know-90154a1e693f