소비자 서비스 또는 애플리케이션을 대신하여 네트워크 요청을 전송하는 도우미 서비스를 만듭니다. 앰배서더 서비스는 클라이언트와 공동 배치되는 out-of-process 프록시로 간주될 수 있습니다.
이 패턴은 모니터링, 로깅, 라우팅, 보안(예: TLS) 및 복원력 패턴과 같은 일반적인 클라이언트 연결 작업을 언어에 구애받지 않는 방식으로 오프로드하는 데 유용할 수 있습니다. 네트워킹 기능을 확장하기 위해 레거시 애플리케이션 또는 수정하기 어려운 다른 애플리케이션과 함께 사용되는 경우가 많습니다. 특수 팀이 이러한 기능을 구현할 수도 있습니다.
컨텍스트 및 문제점
복원력 있는 클라우드 기반 애플리케이션에는 회로 중단, 라우팅, 계량 및 모니터링과 같은 기능과 네트워크 관련 구성 업데이트를 수행할 수 있는 기능이 필요합니다. 코드가 더 이상 기본 없거나 개발 팀에서 쉽게 수정할 수 없으므로 레거시 애플리케이션 또는 기존 코드 라이브러리를 업데이트하여 이러한 기능을 추가하는 것은 어렵거나 불가능할 수 있습니다.
네트워크 호출에는 연결, 인증 및 권한 부여를 위한 상당한 구성이 필요할 수도 있습니다. 여러 언어 및 프레임워크를 사용하여 빌드된 여러 애플리케이션에서 이러한 호출을 사용하는 경우 이러한 각 인스턴스에 대해 호출을 구성해야 합니다. 또한 조직 내의 중앙 팀에서 네트워크 및 보안 기능을 관리해야 할 수 있습니다. 큰 코드 베이스를 사용하면 해당 팀이 익숙하지 않은 애플리케이션 코드를 업데이트하는 것이 위험할 수 있습니다.
솔루션
클라이언트 프레임워크 및 라이브러리를 애플리케이션과 외부 서비스 간의 프록시 역할을 하는 외부 프로세스에 배치합니다. 라우팅, 복원력, 보안 기능을 제어하고 호스트 관련 액세스 제한을 방지하기 위해 애플리케이션과 동일한 호스트 환경에 프록시를 배포합니다. 앰배서더 패턴을 사용하여 계측을 표준화하고 확장할 수도 있습니다. 프록시는 대기 시간 또는 리소스 사용량과 같은 성능 메트릭을 모니터링할 수 있으며, 이 모니터링은 애플리케이션과 동일한 호스트 환경에서 발생합니다.
앰배서더에 오프로드된 기능은 애플리케이션과 독립적으로 관리할 수 있습니다. 애플리케이션의 레거시 기능을 방해하지 않고 앰배서더를 업데이트하고 수정할 수 있습니다. 또한 별도의 특수 팀에서 특사로 이동된 보안, 네트워킹 또는 인증 기능을 구현하고 유지 관리할 수도 있습니다.
특사 서비스를 사이드카로 배포하여 사용 중인 애플리케이션 또는 서비스의 수명 주기와 함께 수행할 수 있습니다. 또는 공통 호스트의 여러 개별 프로세스에서 앰배서더를 공유하는 경우 디먼 또는 Windows 서비스로 배포할 수 있습니다. 소비 서비스가 컨테이너화된 경우 앰배서더를 통신을 위해 구성된 적절한 링크와 함께 동일한 호스트에 별도의 컨테이너로 만들어야 합니다.
문제 및 고려 사항
- 프록시는 약간의 대기 시간 오버헤드를 추가합니다. 애플리케이션에서 직접 호출하는 클라이언트 라이브러리가 더 좋은 방법인지 고려합니다.
- 프록시에 일반화된 기능을 포함할 경우 발생할 수 있는 영향을 고려합니다. 예를 들어 특사는 재시도를 처리할 수 있지만 모든 작업이 idempotent가 아닌 이상 안전하지 않을 수 있습니다.
- 클라이언트가 프록시에 일부 컨텍스트를 전달하고 클라이언트에 다시 전달할 수 있도록 하는 메커니즘을 고려합니다. 예를 들어 HTTP 요청 헤더를 포함하여 재시도를 옵트아웃하거나 재시도할 최대 횟수를 지정합니다.
- 프록시를 패키지하고 배포하는 방법을 고려합니다.
- 모든 클라이언트에 대해 단일 공유 인스턴스를 사용할지, 각 클라이언트에 인스턴스를 사용할지 여부를 고려합니다.
이 패턴을 사용해야 하는 경우
다음 경우에 이 패턴을 사용합니다.
- 여러 언어 또는 프레임워크에 대한 일반적인 클라이언트 연결 기능 집합을 빌드해야 합니다.
- 크로스 커팅 클라이언트 연결 문제를 인프라 개발자 또는 기타 특수 팀에 오프로드해야 합니다.
- 레거시 애플리케이션 또는 수정하기 어려운 애플리케이션에서 클라우드 또는 클러스터 연결 요구 사항을 지원해야 하는 경우
이 패턴은 적합하지 않을 수 있습니다.
- 네트워크 요청 대기 시간이 중요한 경우. 프록시는 최소한의 오버헤드를 발생시키고 경우에 따라 애플리케이션에 영향을 줄 수 있습니다.
- 단일 언어로 클라이언트 연결 기능을 사용하는 경우. 이 경우 더 나은 옵션은 개발 팀에 패키지로 배포되는 클라이언트 라이브러리일 수 있습니다.
- 연결 기능을 일반화할 수 없고 클라이언트 애플리케이션과 더 심층적인 통합이 필요한 경우
워크로드 디자인
설계자는 앰배서더 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:
| 핵심 요소 | 이 패턴이 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 디자인 결정은 워크로드가 오작동에 대한 복원력을 갖도록 하고 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 하는 데 도움이 됩니다. | 이 패턴에 의해 촉진되는 네트워크 통신 조정 지점은 재시도 또는 버퍼링과 같은 네트워크 통신에 안정성 패턴을 추가할 수 있는 기회를 제공합니다. - RE:07 자기 보존 |
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 이 패턴은 클라이언트에서 직접 처리할 수 없었던 네트워크 통신에 대한 보안을 강화할 수 있는 기회를 제공합니다. - SE:06 네트워크 컨트롤 - SE:07 암호화 |
디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.
예시
다음 다이어그램에서는 앰배서더 프록시를 통해 원격 서비스에 요청하는 애플리케이션을 보여 있습니다. 앰배서더가 라우팅, 회로 차단 및 로깅을 제공합니다. 원격 서비스를 호출한 다음 클라이언트 애플리케이션에 대한 응답을 반환합니다.
