특정 프런트 엔드 애플리케이션 또는 인터페이스에서 사용할 별도의 백 엔드 서비스를 만듭니다. 이 패턴은 여러 인터페이스에 대해 단일 백 엔드를 사용자 지정하지 않으려는 경우에 유용합니다. 이 패턴은 샘 뉴먼에 의해 처음 설명되었다.
컨텍스트 및 문제점
애플리케이션은 처음에 데스크톱 웹 UI를 대상으로 할 수 있습니다. 일반적으로 백 엔드 서비스는 해당 UI에 필요한 기능을 제공하는 병렬로 개발됩니다. 애플리케이션의 사용자 기반이 증가함에 따라 동일한 백 엔드와 상호 작용해야 하는 모바일 애플리케이션이 개발됩니다. 백 엔드 서비스는 데스크톱 및 모바일 인터페이스의 요구 사항을 모두 충족하는 범용 백 엔드가 됩니다.
그러나 모바일 디바이스의 기능은 화면 크기, 성능 및 디스플레이 제한 측면에서 데스크톱 브라우저와 크게 다릅니다. 결과적으로 모바일 애플리케이션 백 엔드에 대한 요구 사항은 데스크톱 웹 UI와 다릅니다.
이러한 차이로 인해 백 엔드에 대한 경쟁 요구 사항이 발생합니다. 백 엔드는 데스크톱 웹 UI와 모바일 애플리케이션을 모두 제공하기 위해 일반적이고 중요한 변경이 필요합니다. 종종 별도의 인터페이스 팀이 각 프런트 엔드에서 작업하므로 개발 프로세스에서 백 엔드가 병목 상태가 됩니다. 업데이트 요구 사항이 충돌하고, 서비스가 프런트 엔드 둘 다에서 작동되도록 해야 하기 때문에 배포 가능한 단일 리소스에 많은 노력을 투입될 수 있습니다.
개발 활동이 백 엔드 서비스에 중점을 두기 때문에 백 엔드를 관리하고 기본 위해 별도의 팀을 만들 수 있습니다. 결과적으로 인터페이스와 백 엔드 개발 팀 간의 연결이 끊어지게 되어 백 엔드 팀이 서로 다른 UI 팀의 경쟁 요구 사항의 균형을 맞추는 부담을 줍니다. 한 인터페이스 팀이 백 엔드를 변경해야 하는 경우 백 엔드에 통합되기 전에 다른 인터페이스 팀에서 해당 변경 내용의 유효성을 검사해야 합니다.
솔루션
사용자 인터페이스당 하나의 백 엔드를 만듭니다. 다른 프런트 엔드 환경에 영향을 미치지 않고도 프런트 엔드 환경의 요구에 가장 잘 맞도록 각 백 엔드의 동작 및 성능을 미세 조정합니다.
각 백 엔드는 하나의 인터페이스에만 적용되므로 해당 인터페이스에 맞게 최적화할 수 있습니다. 따라서 모든 인터페이스에 대한 요구 사항을 충족하려고 하는 일반 백 엔드보다 더 작고 덜 복잡하며 더 빠를 수 있습니다. 각 인터페이스 팀은 자체 백 엔드를 제어할 수 있는 자율성을 가지고 있으며 중앙 집중식 백 엔드 개발 팀에 의존하지 않습니다. 이렇게 하면 인터페이스 팀이 백 엔드에서 언어 선택, 릴리스 주기, 워크로드 우선 순위 지정 및 기능 통합을 유연하게 수행할 수 있습니다.
자세한 내용은 패턴: 프런트 엔드의 백 엔드를 참조 하세요.
문제 및 고려 사항
- 배포할 백 엔드 수를 고려합니다.
- 다른 인터페이스(예: 모바일 클라이언트)가 동일한 요청을 하는 경우 각 인터페이스에 대한 백 엔드를 구현해야 하는지 또는 단일 백 엔드로 충분할지 여부를 고려합니다.
- 이 패턴을 구현할 때 서비스 간 코드 중복 가능성이 높습니다.
- 프런트 엔드 중심 백 엔드 서비스에는 클라이언트별 논리 및 동작만 포함되어야 합니다. 일반 비즈니스 논리 및 기타 글로벌 기능은 애플리케이션의 다른 곳에서 관리해야 합니다.
- 이 패턴이 개발 팀의 책임에 어떻게 반영될 수 있는지 생각해 보세요.
- 이 패턴을 구현하는 데 걸리는 시간을 고려합니다. 기존 일반 백 엔드를 계속 지원하는 동안 새 백 엔드를 빌드하는 데 기술적인 부채가 발생합니까?
이 패턴을 사용해야 하는 경우
다음 경우에 이 패턴을 사용합니다.
- 공유 또는 범용 백 엔드 서비스는 상당한 개발 오버헤드를 기본 합니다.
- 특정 클라이언트 인터페이스의 요구 사항에 맞게 백 엔드를 최적화하려고 합니다.
- 여러 인터페이스를 수용하기 위해 범용 백 엔드에 대한 사용자 지정이 수행됩니다.
- 프로그래밍 언어는 특정 사용자 인터페이스의 백 엔드에 더 적합하지만 일부 사용자 인터페이스에는 적합하지 않습니다.
이 패턴은 적합하지 않을 수 있습니다.
- 인터페이스가 백 엔드에 대해 동일하거나 유사한 요청을 하는 경우
- 백 엔드와 상호 작용하는 데 인터페이스가 하나만 사용되는 경우
워크로드 디자인
설계자는 프런트 엔드용 백 엔드 패턴을 워크로드 디자인에 사용하여 Azure 잘 설계된 프레임워크 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:
| 핵심 요소 | 이 패턴이 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 디자인 결정은 워크로드가 오작동에 대한 복원력을 갖도록 하고 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 하는 데 도움이 됩니다. | 특정 프런트 엔드 인터페이스에만 적용되는 별도의 서비스가 있으면 오작동이 있으므로 한 클라이언트의 가용성이 다른 클라이언트의 액세스 가용성에 영향을 미치지 않을 수 있습니다. 또한 다양한 클라이언트를 다르게 처리할 때 예상되는 클라이언트 액세스 패턴에 따라 안정성 작업의 우선 순위를 지정할 수 있습니다. - RE:02 중요 흐름 - RE:07 자기 보존 |
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 이 패턴에 도입된 서비스 분리로 인해 한 클라이언트를 지원하는 서비스 계층의 보안 및 권한 부여는 해당 클라이언트에 필요한 기능에 맞게 조정되어 잠재적으로 API의 노출 영역과 다른 기능을 노출할 수 있는 여러 백 엔드 간의 횡적 이동을 줄일 수 있습니다. - SE:04 구분 - SE:08 강화 리소스 |
| 성능 효율성은 크기 조정, 데이터, 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족하는 데 도움이 됩니다. | 백 엔드 분리를 사용하면 공유 서비스 계층에서 불가능할 수 있는 방식으로 최적화할 수 있습니다. 개별 클라이언트를 다르게 처리하는 경우 특정 클라이언트의 제약 조건 및 기능에 대한 성능을 최적화할 수 있습니다. - PE:02 용량 계획 - PE:09 중요 흐름 |
디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.