프런트 엔드 패턴의 백 엔드

프런트 엔드 구현에서 백 엔드 서비스를 분리하여 다양한 클라이언트 인터페이스에 맞게 환경을 조정합니다. 이 패턴은 여러 인터페이스를 제공하는 백 엔드를 사용자 지정하지 않으려는 경우에 유용합니다. 이 패턴은 패턴: 프런트 엔드의 백 엔드 Sam Newman이 설명한 것을 기반으로 합니다.

컨텍스트 및 문제

처음에 데스크톱 웹 UI 및 해당 백 엔드 서비스를 사용하여 디자인된 애플리케이션을 고려합니다. 시간이 지남에 따라 비즈니스 요구 사항이 변경됨에 따라 모바일 인터페이스가 추가되었습니다. 두 인터페이스는 동일한 백 엔드 서비스와 상호 작용하지만 모바일 디바이스의 기능은 화면 크기, 성능 및 표시 제한 측면에서 데스크톱 브라우저와 크게 다릅니다.

백 엔드 서비스는 종종 다양한 프런트 엔드의 경쟁적인 요구에 직면하여 개발 프로세스에서 자주 변경되고 병목 상태가 발생할 수 있습니다. 업데이트가 충돌하고 호환성을 유지해야 하는 경우 배포 가능한 단일 리소스에서 과도한 작업이 수행됩니다.

별도의 팀이 백 엔드 서비스를 관리하면 프런트 엔드와 백 엔드 팀 간의 연결이 끊어질 수 있으므로 합의 및 균형 조정 요구 사항이 지연됩니다. 예를 들어 한 프런트 엔드 팀에서 요청한 변경 내용은 통합하기 전에 다른 프런트 엔드 팀과 함께 유효성을 검사해야 합니다.

해결 방법

인터페이스별 요구 사항만 처리하는 새 계층을 소개합니다. BFF(백 엔드-for-frontend) 서비스라고 하는 이 계층은 프런트 엔드 클라이언트와 백 엔드 서비스 사이에 있습니다. 애플리케이션이 여러 인터페이스를 지원하는 경우 각 인터페이스에 대한 BFF 서비스를 만듭니다. 예를 들어 웹 인터페이스와 모바일 앱이 있는 경우 각각에 대해 별도의 BFF 서비스를 만듭니다.

이 패턴은 다른 인터페이스에 영향을 주지 않고 특정 인터페이스에 대한 클라이언트 환경을 조정합니다. 또한 프런트 엔드 환경의 요구 사항에 가장 잘 맞게 성능을 미세 조정합니다. 각 BFF 서비스는 더 작고 덜 복잡하기 때문에 애플리케이션은 어느 정도 최적화 이점을 경험할 수 있습니다.

프런트 엔드 팀은 자체 BFF 서비스에 대한 자율성을 가지며, 중앙 집중식 백 엔드 개발 팀에 의존하지 않고도 언어 선택, 릴리스 주기, 워크로드 우선 순위 지정 및 기능 통합을 유연하게 수행할 수 있습니다.

많은 BFF가 REST API에 의존하지만 GraphQL 구현이 대안이 되고 있으므로 쿼리 메커니즘에 별도의 엔드포인트가 필요하지 않으므로 BFF 계층이 필요하지 않습니다.

프런트 엔드 패턴의 백 엔드를 보여 주는

자세한 내용은 패턴: 프런트 엔드의 백 엔드참조하세요.

문제 및 고려 사항

• 관련 비용이 발생하므로 최적의 서비스 수를 평가합니다. 더 많은 서비스를 유지 관리하고 배포하면 운영 오버헤드가 증가합니다. 각 개별 서비스에는 고유한 수명 주기, 배포 및 유지 관리 요구 사항 및 보안 요구 사항이 있습니다.

• 새 서비스를 추가할 때 SLO(서비스 수준 목표)를 검토합니다. 클라이언트가 서비스에 직접 연결하지 않고 새 서비스에서 추가 네트워크 홉을 도입하므로 대기 시간이 증가할 수 있습니다.

• 다른 인터페이스가 동일한 요청을 수행할 때 요청을 단일 BFF 서비스로 통합할 수 있는지 여부를 평가합니다. 여러 인터페이스 간에 단일 BFF 서비스를 공유하면 각 클라이언트에 대해 서로 다른 요구 사항이 발생할 수 있으므로 BFF 서비스의 성장과 지원이 복잡해질 수 있습니다.

  코드 중복은 이 패턴의 가능한 결과입니다. 각 클라이언트에 대해 코드 중복과 더 나은 맞춤형 환경 간의 장단 관계를 평가합니다.

• BFF 서비스는 특정 사용자 환경과 관련된 클라이언트별 논리만 처리해야 합니다. BFF 서비스를 밝게 유지하려면 모니터링 및 권한 부여와 같은 교차 절단 기능을 추상화해야 합니다. BFF 서비스에서 나타날 수 있는 일반적인 기능은 게이트키핑, 속도 제한, 라우팅등과 별도로 처리됩니다.

• 이 패턴을 학습하고 구현할 때 개발 팀에 미치는 영향을 고려합니다. 새 백 엔드를 빌드하려면 시간과 노력이 필요하며, 기존 백 엔드 서비스를 유지 관리하는 동안 기술적인 부담이 발생할 수 있습니다.

• 이 패턴이 필요한지 평가합니다. 예를 들어 조직에서 프런트 엔드별 확인자와 함께 GraphQL을 사용하는 경우 BFF는 애플리케이션에 값을 추가하지 않을 수 있습니다.

  또 다른 예로 API 게이트웨이 마이크로 서비스와 결합하는 애플리케이션이 있습니다. 이 방법은 이전에 BFF가 권장된 경우에 충분할 수 있습니다.

이 패턴을 사용하는 경우

다음 경우에 이 패턴을 사용합니다.

• 공유 또는 범용 백 엔드 서비스는 상당한 개발 오버헤드로 유지 관리되어야 합니다.

• 특정 클라이언트 인터페이스의 요구 사항에 맞게 백 엔드를 최적화하려고 합니다.

• 여러 인터페이스를 수용하기 위해 범용 백 엔드에 대한 사용자 지정이 수행됩니다.

• 프로그래밍 언어는 특정 사용자 인터페이스의 백 엔드에 더 적합하지만 일부 사용자 인터페이스에는 적합하지 않습니다.

이 패턴은 적합하지 않을 수 있습니다.

• 인터페이스가 백 엔드에 대해 동일하거나 유사한 요청을 하는 경우

• 백 엔드와 상호 작용하는 데 인터페이스가 하나만 사용되는 경우

워크로드 디자인

설계자는 프런트 엔드용 백 엔드 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야. 다음은 그 예입니다.

디자인 결정과 마찬가지로 이 패턴을 통해 도입 가능한 다른 핵심 요소의 목표에 관한 절충을 고려합니다.

예시

이 예제에서는 두 개의 고유한 클라이언트 애플리케이션인 모바일 앱과 데스크톱 애플리케이션이 있는 패턴에 대한 사용 사례를 보여 줍니다. 두 클라이언트는 추상화 계층 역할을 하는 Azure API Management(데이터 평면 게이트웨이)와 상호 작용하여 다음과 같은 일반적인 교차 절단 문제를 처리합니다.

• 권한 부여 – 적절한 액세스 토큰이 있는 확인된 ID만 Microsoft Entra ID와 함께 APIM(Azure API Management)을 사용하여 보호된 리소스를 호출할 수 있는지 확인합니다.

• 모니터링 – Azure Monitor에 관찰을 위해 요청 및 응답 세부 정보를 캡처하고 보냅니다.

• 요청 캐싱 – APIM 기본 제공 기능을 사용하여 캐시의 응답을 제공하여 반복되는 요청을 최적화합니다.

• 라우팅 & 집계 – 들어오는 요청을 적절한 BFF(프런트 엔드) 서비스로 보냅니다.

각 클라이언트에는 게이트웨이와 기본 마이크로 서비스 간의 중개자 역할을 하는 Azure Function으로 실행되는 전용 BFF 서비스가 있습니다. 이러한 클라이언트별 BFF는 다른 기능 중에서 페이지를 매길 수 있는 맞춤형 환경을 보장합니다. 모바일은 대역폭을 의식하는 앱이고 캐싱은 성능을 향상시키지만 데스크톱은 단일 요청으로 여러 페이지를 집계하여 보다 풍부한 사용자 환경을 최적화합니다.

교차 절단 문제를 처리하는 Azure API Management를 사용하는 Azure BFF 아키텍처를 보여 주는

흐름 A: 모바일 클라이언트 - 첫 번째 페이지 요청

1. 모바일 클라이언트는 권한 부여 헤더에 OAuth 2.0 토큰을 포함하여 페이지 1 대한 GET 요청을 보냅니다.
2. 요청은 Azure APIM 게이트웨이에 도달하여 이를 가로채고 다음을 수행합니다.
   1. 권한 부여 상태 확인 – APIM은 심층 방어를 구현하므로 액세스 토큰의 유효성을 확인합니다.
   2. Azure Monitor에 로그로 요청 활동을 스트리밍합니다. 요청의 세부 정보는 감사 및 모니터링을 위해 기록됩니다.
3. 정책이 적용된 다음, Azure APIM은 요청을 Azure Function Mobile BFF로 라우팅합니다.
4. 그런 다음 Azure Function Mobile BFF는 필요한 마이크로 서비스와 상호 작용하여 단일 페이지를 가져오고 요청된 데이터를 처리하여 간단한 환경을 제공합니다.
5. 응답이 클라이언트에 반환됩니다.

흐름 B: 모바일 클라이언트 – 첫 번째 페이지 캐시된 요청

1. 모바일 클라이언트는 권한 부여 헤더에 OAuth 2.0 토큰을 포함하여 1 페이지에 대해 동일한 GET 요청을 다시 보냅니다.
2. Azure APIM 게이트웨이는 이 요청이 이전과 다음 전에 수행되었음을 인식합니다.
   1. 정책이 적용되고 그 후에 요청 매개 변수와 일치하는 캐시된 응답을 식별합니다.
   2. 캐시된 응답을 즉시 반환하므로 Azure Function Mobile BFF에 요청을 전달할 필요가 없습니다.

흐름 C: 데스크톱 클라이언트 – 첫 번째 요청

1. 데스크톱 클라이언트는 권한 부여 헤더에 OAuth 2.0 토큰을 포함하여 처음으로 GET 요청을 보냅니다.
2. 요청은 유사한 교차 절삭 문제가 처리되는 Azure APIM 게이트웨이에 도달합니다.
   1. 권한 부여 – 토큰 유효성 검사는 항상 필요합니다.
   2. 요청 활동 스트리밍 - 요청 세부 정보는 관찰을 위해 기록됩니다.
3. 모든 정책이 적용되면 Azure APIM은 데이터를 많이 사용하는 애플리케이션 처리를 담당하는 Azure Function Desktop BFF로 요청을 라우팅합니다. Desktop BFF는 여러 페이지 응답으로 클라이언트에 응답하기 전에 기본 마이크로 서비스 호출을 사용하여 여러 요청을 집계합니다.

디자인

• Microsoft Entra ID 클라우드 기반 ID 공급자 역할을 하며, 이후에 권한 부여를 위해 활용되는 모바일 및 데스크톱 클라이언트 모두에 대해 맞춤형 대상 그룹 클레임을 발급합니다.

• Azure API Management 경계를 추가하는 클라이언트와 해당 BBF 간의 프록시 역할을 합니다. JWT(JSON 웹 토큰) 유효성을 검사하는 정책으로 구성되며, 토큰 없이 도착하는 요청을 거부하거나 대상 BFF에 대한 클레임이 유효하지 않습니다. 또한 모든 활동 로그를 Azure Monitor로 스트리밍합니다.

• Azure Monitor 중앙 집중식 모니터링 솔루션으로 작동하여 모든 활동 로그를 집계하여 포괄적인 엔드투엔드 관찰 가능성을 보장하도록.

• Azure Functions 여러 엔드포인트에서 BFF 논리를 원활하게 노출하여 개발을 간소화하고 인프라 오버헤드를 줄이고 운영 비용을 절감하는 서버리스 솔루션입니다.

다음 단계

• 패턴: 프런트 엔드의 백 엔드

관련 리소스

• 게이트웨이 집계 패턴
• 게이트웨이 오프로드 패턴
• 게이트웨이 라우팅 패턴
• Azure API Management의 API에 대한 인증 및 권한 부여
• Azure Application Insights와 Azure API Management를 통합하는 방법
• 서버리스 웹 애플리케이션 참조 아키텍처