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