여러 Azure OpenAI 배포 또는 인스턴스 앞에서 게이트웨이 사용

Azure OpenAI 서비스를 포함하는 워크로드 아키텍처는 단일 Azure OpenAI 모델 배포를 직접 사용하는 하나 이상의 클라이언트 애플리케이션만큼 간단할 수 있지만, 이러한 단순성으로 모든 워크로드를 설계할 수 있는 것은 아닙니다. 더 복잡한 시나리오에는 여러 클라이언트가 있는 토폴로지, 여러 Azure OpenAI 배포 또는 여러 Azure OpenAI 인스턴스가 포함됩니다. 이러한 상황에서 Azure OpenAI 앞에 게이트웨이를 도입하면 워크로드 디자인에 도움이 될 수 있습니다.

여러 Azure OpenAI 인스턴스 또는 모델 배포는 워크로드 아키텍처의 특정 요구 사항을 해결합니다. 4가지 주요 토폴로지로 분류할 수 있습니다.

• 단일 Azure OpenAI 인스턴스에서 여러 모델 배포
• 단일 지역 및 단일 구독의 여러 Azure OpenAI 인스턴스
• 여러 구독에서 단일 지역의 여러 Azure OpenAI 인스턴스
• 여러 지역에 걸쳐 여러 Azure OpenAI 인스턴스

이러한 토폴로지 자체에서는 게이트웨이를 사용할 필요가 없습니다. 게이트웨이 선택은 워크로드가 아키텍처에 포함되는 이점을 얻을 수 있는지 여부에 따라 달라집니다. 이 문서에서는 네 토폴로지 각각이 해결하는 과제와 각 토폴로지에서 게이트웨이를 포함하는 이점 및 비용을 설명합니다.

단일 Azure OpenAI 인스턴스에서 여러 모델 배포

여러 모델 배포에 대한 토폴로지 세부 정보

• Azure OpenAI 모델 배포: 여러
• Azure OpenAI 인스턴스: 1개
• 구독: 1개
• 지역: 1

여러 모델 배포에 대한 토폴로지 사용 사례

단일 Azure OpenAI 인스턴스를 포함하지만 동시에 배포된 모델이 둘 이상 포함된 토폴로지는 다음과 같은 사용 사례를 지원합니다.

• 다양한 모델 기능(예: gpt-35-turbogpt-4사용자 지정 미세 조정된 모델)을 노출합니다.

• 워크로드 진화 또는 청록색 배포를 지원하기 위해 다양한 모델 버전(예: 06131106사용자 지정 미세 조정된 모델)을 노출합니다.

• 여러 클라이언트에서 소비 제한을 지원하기 위해 할당된 다양한 할당량(TPM(분당 토큰 30,000개), TPM 60,000개)을 노출합니다.

여러 모델 배포를 위한 게이트웨이 소개

이 토폴로지로 게이트웨이를 도입하는 것은 주로 인스턴스에서 사용 가능한 배포 중 특정 모델 인스턴스를 자체 선택하지 않도록 클라이언트를 추상화하기 위한 것입니다. 게이트웨이를 사용하면 클라이언트 코드를 다시 배포하거나 클라이언트 구성을 변경할 필요 없이 서버 쪽 컨트롤에서 클라이언트 요청을 특정 모델로 보낼 수 있습니다.

게이트웨이는 클라이언트 코드를 제어하지 않는 경우에 특히 유용합니다. 또한 게이트웨이 라우팅 구성에 변경 내용을 배포하는 것보다 클라이언트 구성을 배포하는 것이 더 복잡하거나 위험할 때 유용합니다. 새 미세 조정된 모델을 롤아웃하거나 동일한 모델의 X 버전 X에서 X+1로 전환하는 등 모델 버전의 파란색-녹색 롤아웃 전략에 따라 클라이언트가 가리키는 모델을 변경할 수 있습니다.

게이트웨이는 게이트웨이가 클라이언트를 식별할 수 있도록 하는 단일 API 진입점으로 사용할 수도 있습니다. 그런 다음, 해당 클라이언트의 ID 또는 HTTP 요청의 다른 정보를 기반으로 프롬프트를 제공하는 데 사용되는 모델 배포를 확인할 수 있습니다. 예를 들어 다중 테넌트 솔루션에서 테넌트는 특정 처리량으로 제한될 수 있으며 아키텍처 구현은 특정 할당량이 있는 테넌트당 모델 배포입니다. 이 경우 테넌트 모델에 대한 라우팅은 HTTP 요청의 정보를 기반으로 게이트웨이의 책임이 됩니다.

이 토폴로지에서 게이트웨이를 사용하면 클라이언트 기반 사용량을 추적할 수 있습니다. 클라이언트가 고유한 Microsoft Entra 서비스 주체를 사용하지 않는 한 Azure OpenAI에 대한 액세스 로그는 여러 클라이언트를 구분할 수 없습니다. 배포 앞에 게이트웨이가 있으면 워크로드가 사용 가능한 다양한 모델 배포에서 클라이언트당 사용량을 추적하여 차지백 또는 쇼백 모델을 지원할 수 있습니다.

여러 모델 배포 토폴로지의 팁

• 게이트웨이가 사용 중인 모델(예: gpt-35-turbo 사용 중인 모델)을 완전히 변경할 수 gpt-4있는 위치에 있는 동안 해당 변경 내용은 클라이언트의 호환성이 손상되는 변경으로 간주될 수 있습니다. 게이트웨이의 새로운 기능 기능이 항상 이 워크로드에 대해 안전한 배포 사례를 수행하는 데 방해가 되지 않도록 합니다 .

• 이 토폴로지는 일반적으로 사용자 지정 코드 솔루션 대신 Azure API Management 정책을 통해 구현할 수 있을 만큼 간단합니다.

• 게시된 Azure OpenAI API 사양에서 네이티브 SDK 사용을 지원하려면 Azure OpenAI API와의 API 호환성을 기본. 팀이 워크로드 클라이언트의 코드를 모두 작성하지 않는 경우 이 상황은 더 큰 문제입니다. 게이트웨이에 대한 HTTP API 설계를 결정할 때 Azure OpenAI HTTP API 호환성을 기본 이점을 고려합니다.

• 이 토폴로지에서는 Azure OpenAI 인스턴스에 대한 통과 클라이언트 자격 증명(액세스 토큰 또는 API 키)을 기술적으로 지원하지만 자격 증명 종료 및 다시 설정 구현을 강력하게 고려합니다. 이렇게 하면 클라이언트가 게이트웨이에서 권한을 부여한 다음, Azure RBAC를 통해 Azure OpenAI 인스턴스로 게이트웨이에 권한이 부여됩니다.

• 게이트웨이가 통과 자격 증명을 사용하도록 설계된 경우 클라이언트가 게이트웨이 또는 클라이언트를 기반으로 하는 모델 제한을 무시할 수 없는지 확인합니다.

• Azure OpenAI 인스턴스와 동일한 지역에 게이트웨이를 배포합니다.

• Azure OpenAI 인스턴스와 분리된 구독의 전용 리소스 그룹에 게이트웨이를 배포합니다. 백 엔드에서 구독을 격리하면 우려의 분리를 통해 APIOps 접근 방식을 구동하는 데 도움이 될 수 있습니다.

• Azure OpenAI 인스턴스의 Azure Private Link 프라이빗 엔드포인트에 대한 서브넷이 포함된 가상 네트워크에 게이트웨이를 배포합니다. 해당 서브넷에 NSG(네트워크 보안 그룹) 규칙을 적용하여 해당 프라이빗 엔드포인트에 대한 게이트웨이 액세스만 허용합니다. Azure OpenAI 인스턴스에 대한 다른 모든 데이터 평면 액세스는 허용되지 않습니다.

여러 모델 배포에 대한 게이트웨이를 피해야 하는 이유

클라이언트의 구성을 제어하는 것이 게이트웨이 수준에서 라우팅을 제어하는 것보다 쉽고 쉬운 경우 게이트웨이의 추가된 안정성, 보안, 비용, 기본 테넌트 및 성능 영향은 추가된 아키텍처 구성 요소에 가치가 없을 수 있습니다.

또한 일부 워크로드 시나리오는 여러 모델 배포 접근 방식에서 여러 Azure OpenAI 인스턴스 배포 접근 방식으로 마이그레이션하는 것이 도움이 될 수 있습니다. 예를 들어 다른 RBAC 또는 액세스 키를 사용하여 모델에 액세스해야 하는 클라이언트가 여러 개 있는 경우 여러 Azure OpenAI 인스턴스를 고려합니다. 단일 Azure OpenAI 인스턴스에서 여러 배포를 사용하고 게이트웨이 수준에서 논리 ID 분할을 처리할 수 있지만 고유한 Azure OpenAI 인스턴스를 사용하여 물리적 RBAC 분할 방법을 사용할 수 있는 경우 과도할 수 있습니다.

단일 지역 및 단일 구독의 여러 Azure OpenAI 인스턴스

단일 지역 및 단일 구독의 여러 인스턴스에 대한 토폴로지 세부 정보

• Azure OpenAI 모델 배포: 하나 이상
• Azure OpenAI 인스턴스: 여러 개
• 구독: 1개
• 지역: 1

단일 지역 및 단일 구독의 여러 인스턴스에 대한 토폴로지 사용 사례

단일 지역 및 단일 구독에 여러 Azure OpenAI 인스턴스를 포함하는 토폴로지에서는 다음과 같은 사용 사례를 지원합니다.

• 클라이언트당 키 또는 RBAC와 같은 보안 구분 경계를 사용하도록 설정합니다.

• 다른 클라이언트에 대해 간편한 차지백 모델을 사용하도록 설정

• 특정 인스턴스에 영향을 주는 플랫폼 중단, 네트워킹 구성 오류 또는 실수로 삭제된 배포와 같은 Azure OpenAI 가용성에 대한 장애 조치(failover) 전략을 사용하도록 설정합니다.

• 분산을 위해 PTU 기반 인스턴스와 소비 기반 인스턴스를 페어링하는 등 Azure OpenAI 할당량 가용성에 대한 장애 조치(failover) 전략을 사용하도록 설정합니다.

단일 지역 및 구독에서 여러 인스턴스에 대한 게이트웨이 소개

여러 가지 이유로 클라이언트에서 모델에 액세스할 수 없을 수 있습니다. 이러한 이유로는 Azure OpenAI 서비스의 중단, Azure OpenAI 제한 요청 또는 네트워크 구성 오류 또는 모델 배포의 실수로 삭제와 같은 워크로드 작업과 관련된 문제가 포함됩니다. 이러한 문제를 해결하려면 재시도 및 회로 중단 논리를 구현해야 합니다.

이 논리는 게이트웨이의 클라이언트 또는 서버 쪽에서 구현할 수 있습니다. 게이트웨이에서 논리를 구현하면 클라이언트에서 논리가 추상화되어 반복 코드가 없고 논리를 테스트할 수 있는 단일 위치가 생성됩니다. 클라이언트 코드를 소유하든 그렇지 않더라도 이러한 전환은 워크로드의 안정성을 높일 수 있습니다.

단일 지역 및 구독에서 여러 Azure OpenAI 인스턴스가 있는 게이트웨이를 사용하면 모든 백 엔드를 활성-수동 장애 조치(failover)에서 사용하는 것이 아니라 활성-활성 배포로 처리할 수 있습니다. 여러 Azure OpenAI 인스턴스에 동일한 PTU 기반 모델을 배포하고 게이트웨이를 사용하여 부하를 분산할 수 있습니다.

Azure OpenAI를 프로비전할 때 워크로드 팀이 가지는 한 가지 옵션은 청구 및 처리량 모델이 PTU 기반인지 또는 소비 기반인지를 결정하는 것입니다. 사용되지 않는 PTU를 통한 낭비를 방지하기 위한 비용 최적화 전략은 PTU 인스턴스를 약간 아래에 프로비전하고 함께 소비 기반 인스턴스를 배포하는 것입니다. 이 토폴로지의 목표는 클라이언트가 먼저 사용 가능한 모든 PTU를 사용한 다음 초과분에 대한 소비 기반 배포로 "버스트"하도록 하는 것입니다. 이러한 형식의 계획된 장애조치 이 섹션의 여는 단락에 멘션 것과 동일한 이유로 인해 이러한 복잡성을 클라이언트 코드에서 제외할 수 있습니다.

게이트웨이가 관련되면 클라이언트가 상호 작용하는 모든 모델 배포에 대한 세부 정보를 캡처할 수 있는 고유한 위치에 있습니다. Azure OpenAI의 모든 인스턴스는 자체 원격 분석을 캡처할 수 있지만, 게이트웨이 내에서 이를 통해 워크로드 팀은 사용된 모든 모델에 대한 원격 분석 및 오류 응답을 단일 저장소에 게시하여 통합 대시보드 및 경고를 더 쉽게 수행할 수 있습니다.

단일 지역 및 구독 토폴로지의 여러 인스턴스에 대한 팁

• 게이트웨이에서 장애 조치(failover) 시나리오를 지원할 때 게이트웨이가 Azure OpenAI의 HTTP 응답에서 사용할 수 있는 정보를 사용하고 Retry-After 있는지 확인합니다. 해당 신뢰할 수 있는 정보를 사용하여 회로 차단기 구현을 제어합니다. 를 반환 429 Too Many Requests하는 엔드포인트에 지속적으로 적중하지 마세요. 대신 해당 모델 인스턴스에 대한 회로를 중단합니다.

• 이전 요청을 통해 모델 소비를 추적하여 발생하기 전에 제한 이벤트를 예측하려는 시도는 게이트웨이에서 가능하지만 에지 사례가 내포되어 있습니다. 대부분의 경우 예측하지 않고 HTTP 응답 코드를 사용하여 향후 라우팅 결정을 내리는 것이 가장 좋습니다.

• PTU를 포함하여 다른 엔드포인트로 라운드 로빈 또는 장애 조치(failover)하는 경우 항상 해당 엔드포인트가 동일한 버전에서 동일한 모델을 사용하고 있는지 확인합니다. 예를 들어 버전 X에서 gpt-4 버전 X+1로 gpt-35-turbo 장애 조치(failover)하거나 X+1 버전 간에 부하를 분산하지 마세요. 이 버전 변경으로 인해 클라이언트에서 예기치 않은 동작이 발생할 수 있습니다.

• 부하 분산 및 장애 조치(failover) 논리는 Azure API Management 정책 내에서 구현할 수 있습니다. 코드 기반 게이트웨이 솔루션을 사용하여 보다 정교한 방법을 제공할 수 있지만 이 사용 사례에는 API Management로 충분합니다.

• Azure OpenAI 인스턴스와 동일한 지역에 게이트웨이를 배포합니다.

• Azure OpenAI 인스턴스와 분리된 구독의 전용 리소스 그룹에 게이트웨이를 배포합니다. 게이트웨이를 백 엔드에서 격리하면 우려의 분리를 통해 APIOps 접근 방식을 구동하는 데 도움이 될 수 있습니다.

• 모든 Azure OpenAI 인스턴스 Private Link 프라이빗 엔드포인트를 게이트웨이의 가상 네트워크의 단일 서브넷에 공동 배치합니다. 해당 서브넷에 NSG 규칙을 적용하여 해당 프라이빗 엔드포인트에 대한 게이트웨이 액세스만 허용합니다. Azure OpenAI 인스턴스에 대한 다른 모든 데이터 평면 액세스는 허용되지 않습니다.

• 게이트웨이 라우팅 코드에서 논리를 간소화하려면 동일한 모델 배포 이름을 사용하여 HTTP 경로 간의 차이를 최소화합니다. 예를 들어 모델 이름은 gpt4-v1 사용량 기반이든 PTU 기반이든 관계없이 모든 부하 분산 또는 스필오버 인스턴스에서 사용할 수 있습니다.

단일 지역 및 구독에서 여러 인스턴스에 대한 게이트웨이를 피해야 하는 이유

게이트웨이 자체는 이 특정 토폴로지의 다른 클라이언트에 대해 모델을 충전하는 기능을 향상하지 않습니다. 이 토폴로지에서 클라이언트는 워크로드 팀이 차지백 또는 쇼백을 수행하는 기능을 지원하는 고유한 전용 Azure OpenAI 인스턴스에 대한 액세스 권한을 부여받을 수 있습니다. 이 모델은 고유 ID 및 네트워크 경계를 지원하므로 세분화를 위해 게이트웨이를 특별히 도입할 필요가 없습니다.

코드를 제어하는 영역에 클라이언트가 몇 명 있고 클라이언트를 쉽게 업다이팅할 수 있는 경우 게이트웨이에 빌드해야 하는 논리를 코드에 직접 추가할 수 있습니다. 클라이언트 코드를 소유하지 않거나 클라이언트가 처리하기에 너무 복잡할 때 주로 장애 조치(failover) 또는 부하 분산에 게이트웨이 접근 방식을 사용하는 것이 좋습니다.

여러 구독에서 단일 지역의 여러 Azure OpenAI 인스턴스

여러 구독에서 단일 지역의 여러 Azure OpenAI 인스턴스에 대한 토폴로지 세부 정보

• Azure OpenAI 모델 배포: 하나 이상
• Azure OpenAI 인스턴스: 여러 개
• 구독: 다중
• 지역: 1

여러 구독에서 단일 지역의 여러 Azure OpenAI 인스턴스에 대한 토폴로지 사용 사례

여러 구독에서 단일 지역에 여러 Azure OpenAI 인스턴스를 포함하는 토폴로지에서는 다음과 같은 사용 사례를 지원합니다.

• 단일 지역 및 단일 구독의 여러 Azure OpenAI 인스턴스에 대해 나열된 모든 사용 사례를 포함합니다.

• 구독 경계가 소비 모델에 사용할 수 있는 요소이므로 더 많은 소비 기반 할당량을 얻을 수 있습니다. 이 추가 할당량을 사용하여 동시 사용량을 지원할 수 있습니다.

단일 지역 및 여러 구독의 여러 인스턴스에 대한 게이트웨이 소개

단일 지역 및 구독의 여러 인스턴스에 대한 게이트웨이 소개에서 다루는 동일한 이유가 이 토폴로지에 적용됩니다.

이러한 이유 외에도 이 토폴로지에서 게이트웨이를 추가하면 조직에 "Azure OpenAI as a Service" 모델을 제공하는 중앙 집중식 팀이 지원됩니다. 소비 기반 할당량은 구독에 바인딩되어 있으므로 소비 기반 모델을 사용하는 Azure OpenAI 서비스를 제공하는 중앙 집중식 팀은 필요한 할당량을 얻기 위해 여러 구독에 Azure OpenAI 인스턴스를 배포해야 합니다. 게이트웨이 논리는 여전히 거의 동일하게 기본.

단일 지역 및 여러 구독 토폴로지의 여러 인스턴스에 대한 팁

• 이상적으로 구독은 모두 동일한 Microsoft Entra ID 테넌트로 지원되어 Azure RBAC 및 Azure Policy의 일관성을 지원해야 합니다.

• Azure OpenAI 인스턴스와 동일한 지역에 게이트웨이를 배포합니다.

• Azure OpenAI 인스턴스와 별개의 전용 구독에 게이트웨이를 배포합니다. 이렇게 하면 Azure OpenAI 인스턴스를 해결하는 데 일관성을 적용하고 Azure OpenAI 배포와 해당 라우팅 간에 업무의 논리적 구분을 제공합니다.

• 구독 간에 게이트웨이에서 요청을 라우팅하는 경우 프라이빗 엔드포인트에 연결할 수 있는지 확인합니다. 허브를 통해 각 스포크에서 백 엔드에 대한 프라이빗 엔드포인트로의 전이적 라우팅을 사용할 수 있습니다. 구독 간에 Private Link 연결을 사용하여 게이트웨이 구독에서 직접 Azure OpenAI 서비스에 대한 프라이빗 엔드포인트를 노출할 수 있습니다. 아키텍처 및 조직에서 이 방법을 지원하는 경우 구독 간 Private Link 연결이 선호됩니다.

단일 지역 및 여러 구독의 여러 인스턴스에 대한 게이트웨이를 방지하는 이유

단일 지역 및 구독의 여러 인스턴스에 대한 게이트웨이를 방지하는 모든 이유가 이 토폴로지에 적용됩니다.

여러 지역에 걸쳐 여러 Azure OpenAI 인스턴스

여러 지역에 걸쳐 여러 Azure OpenAI 인스턴스에 대한 토폴로지 세부 정보

• Azure OpenAI 모델 배포: 여러
• Azure OpenAI 인스턴스: 여러 개
• 구독: 하나 이상
• 지역: 다중

여러 지역에 걸쳐 여러 Azure OpenAI 인스턴스에 대한 토폴로지 사용 사례

둘 이상의 Azure 지역에 분산된 여러 Azure OpenAI 인스턴스를 포함하는 토폴로지에서는 다음과 같은 사용 사례를 지원합니다.

• 여러 구독에서 단일 지역의 여러 Azure OpenAI 인스턴스에 대해 나열된 모든 사용 사례를 포함합니다.

• 지역 간 쌍 사용 과 같은 서비스 가용성에 대한 장애 조치(failover) 전략을 사용하도록 설정합니다.

• 데이터 상주 및 규정 준수 디자인을 사용하도록 설정합니다.

• 혼합 모델 가용성을 사용하도록 설정합니다. 일부 지역에는 모델이 다르고 모델에 사용할 수 있는 할당량이 다릅니다.

기술적으로 다른 Azure 지역은 아니지만, 이 토폴로지는 온-프레미스 또는 다른 클라우드와 같은 크로스 프레미스 상황에서 AI 모델을 노출하는 경우에도 적용됩니다.

여러 지역의 여러 인스턴스에 대한 게이트웨이 소개

전체 지역 가동 중단에서 벗어나야 하는 중요 비즈니스용 아키텍처의 경우 전역 통합 게이트웨이는 클라이언트 코드에서 장애 조치(failover) 논리를 제거하는 데 도움이 됩니다. 이 구현을 수행하려면 게이트웨이가 지역 가동 중단의 영향을 받지 않고 다시 기본 합니다.

지역 간 부하 분산은 일반적인 것은 아니지만 전략적으로 사용하여 지역 간 사용량 기반 배포에서 사용 가능한 할당량을 결합할 수 있습니다. 이 시나리오에서는 게이트웨이가 지역 가동 중단의 영향을 받지 기본 필요가 없지만 워크로드 안정성을 극대화하는 것이 좋습니다.

Azure API Management 사용(단일 지역 배포)

이 토폴로지에서 Azure API Management는 게이트웨이 기술에 특별히 사용됩니다. 여기서 API Management는 단일 지역에 배포됩니다. 해당 게이트웨이 인스턴스에서 지역 간에 활성-활성 부하 분산을 수행합니다. 게이트웨이의 정책은 모든 Azure OpenAI 인스턴스를 참조합니다. 게이트웨이는 지역 간 가상 네트워크 피어링 또는 프라이빗 엔드포인트를 통해 지역 전체의 각 백 엔드에 대한 네트워크 시야를 필요로 합니다. 이 게이트웨이에서 다른 지역의 Azure OpenAI 인스턴스로 호출하면 네트워크 대기 시간 및 송신 요금이 더 많이 발생합니다.

게이트웨이는 Azure OpenAI 인스턴스의 제한 및 가용성 신호를 적용하고 장애 또는 제한된 Azure OpenAI 인스턴스를 다시 추가하기 위해 안전할 때까지 풀에서 결함이 있는 백 엔드를 제거해야 합니다. 게이트웨이는 게이트웨이 오류를 반환하기 전에 오류 발생 시 풀의 다른 백 엔드 인스턴스에 대해 현재 요청을 다시 시도해야 합니다. 백 엔드 Azure OpenAI 인스턴스를 사용할 수 없는 경우 게이트웨이의 상태 검사 비정상 신호를 보내야 합니다.

이 토폴로지는 단일 실패 지점(게이트웨이)을 도입하므로 이 특정 아키텍처의 유틸리티는 상당히 제한됩니다. 이 모델은 PTU 할당을 예측하는 것이 너무 어려울 수 있는 경우 Azure OpenAI의 소비 기반 청구에 유용합니다.

활성-수동 변형

이 모델을 사용하여 Azure OpenAI만의 지역 오류를 구체적으로 처리하는 활성-수동 접근 방식을 제공할 수도 있습니다. 이 모드에서 트래픽은 일반적으로 게이트웨이에서 API 관리 서비스와 동일한 지역의 Azure OpenAI 인스턴스로 흐릅니다. Azure OpenAI의 해당 인스턴스는 지역 오류가 발생하지 않고 예상되는 모든 트래픽 흐름을 처리합니다. 기본 청구 모델에 따라 PTU 기반 또는 소비 기반일 수 있습니다. Azure OpenAI만 지역 오류가 발생할 경우 게이트웨이는 이미 사용 모드로 배포된 Azure OpenAI를 사용하여 트래픽을 다른 지역으로 리디렉션할 수 있습니다.

Azure API Management 사용(다중 지역 배포)

이전 Azure API Management 기반 아키텍처의 안정성을 개선하기 위해 API Management는 여러 Azure 지역에 인스턴스 배포를 지원합니다. 이 배포 옵션은 단일 API Management 인스턴스를 통해 단일 제어 평면을 제공하지만 선택한 지역에 복제본(replica)ted 게이트웨이를 제공합니다. 이 토폴로지에서는 활성-활성 게이트웨이 아키텍처를 제공하는 Azure OpenAI 인스턴스를 포함하는 각 지역에 게이트웨이 구성 요소를 배포합니다.

라우팅 및 요청 처리 논리와 같은 정책은 각 개별 게이트웨이에 복제본(replica). 현재 게이트웨이와 동일한 지역에서 Azure OpenAI 인스턴스를 호출하려면 모든 정책 논리에 조건부 논리가 있어야 합니다. 자세한 내용은 지역 백 엔드 서비스에 대한 Route API 호출을 참조 하세요. 그런 다음 게이트웨이 구성 요소는 일반적으로 프라이빗 엔드포인트를 통해 자체 지역의 Azure OpenAI 인스턴스에만 네트워크 가시줄이 필요합니다.

API Management는 가장 낮은 대기 시간을 기준으로 기본 제공 FQDN(정규화된 기본 이름) 라우팅을 제공합니다. 활성-활성 게이트웨이 배포에 이 기본 제공 성능 기반 기능을 사용합니다. 이 기본 제공 기능은 성능을 해결하고 지역 게이트웨이 중단을 처리하는 데 도움이 됩니다. 기본 제공 글로벌 라우터는 개별 게이트웨이를 사용하지 않도록 설정하여 지역을 시뮬레이트할 수 있으므로 재해 복구 테스트도 지원합니다. 클라이언트가 FQDN의 TTL을 준수하고 최근 DNS 장애 조치(failover)를 처리하기 위한 적절한 재시도 논리가 있는지 확인합니다.

이 아키텍처에 WAF(웹 애플리케이션 방화벽)를 도입해야 하는 경우에도 기본 제공 FQDN 라우팅 솔루션을 WAF를 구현하는 글로벌 라우터의 백 엔드 원본으로 사용할 수 있습니다. 전역 라우터는 장애 조치(failover) 책임을 API Management에 위임합니다. 또는 지역 게이트웨이 FQDN을 백 엔드 풀 멤버로 사용할 수 있습니다. 후자의 아키텍처에서 각 지역 게이트웨이 또는 다른 사용자 지정 상태 API 엔드포인트에서 기본 제공 /status-0123456789abcdef 엔드포인트를 사용하여 지역 장애 조치(failover)를 지원합니다. 확실하지 않은 경우 단일 원본 백 엔드 FQDN 접근 방식을 시작합니다.

이 아키텍처는 지역을 완전히 사용 가능하거나 완전히 사용할 수 없는 것으로 처리할 수 있는 경우에 가장 적합합니다. 즉, API Management 게이트웨이 또는 Azure OpenAI 인스턴스를 사용할 수 없는 경우 클라이언트 트래픽을 해당 지역의 API Management 게이트웨이로 더 이상 라우팅하지 않도록 합니다. 다른 프로비저닝이 이루어지지 않는 한 Azure OpenAI를 사용할 수 없는 동안 지역 게이트웨이에서 트래픽을 계속 허용하는 경우 오류가 클라이언트로 전파되어야 합니다. 클라이언트 오류를 방지하려면 활성-활성 게이트웨이의 향상된 접근 방식과 활성-수동 Azure OpenAI 변형을 참조하세요.

지역에 API Management 게이트웨이 가동 중단이 발생하거나 비정상으로 플래그가 지정된 경우 다시 기본 사용 가능한 지역은 해당 다른 지역의 트래픽의 100%를 흡수해야 합니다. 즉, PTU 기반 Azure OpenAI 인스턴스를 과도하게 프로비전하여 새 트래픽 버스트를 처리하거나 장애 조치(failover)에 대해 활성-수동 접근 방식을 사용해야 합니다. 용량 계획에 Azure OpenAI 용량 계산기를 사용합니다.

Azure API Management를 포함하는 리소스 그룹이 API Management 인스턴스 자체와 동일한 위치인지 확인하여 게이트웨이에 대한 리소스 공급자에 액세스하는 기능에 영향을 주는 관련 지역 중단의 폭발 반경을 줄입니다.

활성-활성 게이트웨이 및 활성-수동 Azure OpenAI 변형

이전 섹션에서는 활성-활성 게이트웨이 토폴로지 제공을 통해 게이트웨이의 가용성을 설명합니다. 이 토폴로지에서는 활성-활성 게이트웨이를 비용 효율적인 활성-수동 Azure OpenAI 토폴로지와 결합합니다. PTU 기반 배포에서 소비 기반 Azure OpenAI 배포로 장애 조치(failover)하기 위해 게이트웨이에 활성-수동 논리를 추가하면 워크로드의 안정성이 크게 향상될 수 있습니다. 이 모델을 통해 클라이언트는 여전히 성능 기반 라우팅을 위해 API Management의 기본 제공 FQDN 라우팅 솔루션을 사용할 수 있습니다.

사용자 지정 코딩된 게이트웨이 사용

게이트웨이별 라우팅 규칙이 너무 복잡하여 팀이 API Management 정책으로 합리적이라고 간주할 수 없을 경우 사용자 고유의 솔루션을 배포하고 관리해야 합니다. 이 아키텍처는 게이트웨이의 다중 지역 배포여야 하며 지역당 하나의 고가용성 스케일 단위가 있어야 합니다. 일반적으로 대기 시간 기반 라우팅 및 게이트웨이 가용성의 적절한 상태 검사 사용하여 Azure Front Door(Anycast) 또는 Azure Traffic Manager(DNS)를 사용하여 이러한 배포를 선행해야 합니다.

WAF 및 공용 인터넷 액세스가 필요한 경우 Azure Front Door를 사용합니다. WAF가 필요하지 않고 DNS TTL이 충분한 경우 Traffic Manager를 사용합니다. Azure Front Door(또는 역방향 프록시)를 사용하여 게이트웨이 인스턴스를 프런트링할 때 게이트웨이를 바이패스할 수 없는지 확인합니다. Azure Front Door를 사용하는 경우 프라이빗 엔드포인트를 통해서만 게이트웨이 인스턴스를 사용할 수 있도록 하고 게이트웨이 구현에서 HTTP 헤더의 X_AZURE_FDID 유효성 검사를 추가합니다.

지역별 리소스 그룹의 사용자 지정 게이트웨이에 사용되는 지역별 리소스를 배치합니다. 이렇게 하면 해당 지역의 게이트웨이 리소스에 대한 리소스 공급자에 액세스하는 기능에 영향을 주는 관련 지역 중단의 폭발 반경이 줄어듭니다.

TLS, 인증, 상태 검사 또는 라운드 로빈 부하 분산과 같은 API Management의 다른 이점에 대해 API Management를 사용하여 게이트웨이 논리 구현을 미리 고려할 수도 있습니다. 이렇게 하면 일반적인 API 문제가 게이트웨이의 사용자 지정 코드에서 벗어나고 게이트웨이가 특히 Azure OpenAI 인스턴스 및 모델 배포 라우팅을 처리할 수 있습니다.

데이터 상주 규정 준수의 경우 각 지정학적 경계에 이 아키텍처의 격리된 배포가 있고 클라이언트가 권한 있는 엔드포인트에만 도달할 수 있는지 확인합니다.

여러 지역의 여러 인스턴스에 대한 게이트웨이를 방지해야 하는 이유

데이터 상주 및 규정 준수가 필요한 경우 지정학적 지역에 통합 게이트웨이를 구현하지 마세요. 이렇게 하면 데이터 상주 요구 사항을 위반합니다. 지역당 개별적으로 주소 지정 가능한 게이트웨이를 사용하고 이전 섹션 중 하나의 지침을 따릅니다.

클라이언트가 지역 간에 장애 조치(failover)될 것으로 예상되지 않고 클라이언트에 사용할 특정 게이트웨이를 제공하는 기능이 있는 경우, 대신 지역당 하나씩 여러 게이트웨이를 사용하고 이전 섹션 중 하나의 지침을 따릅니다. 게이트웨이를 포함하는 지역에 다른 지역의 가용성을 단일 실패 지점으로 연결하지 마세요.

게이트웨이에서 노출하는 모든 지역에서 모델 및 버전을 사용할 수 없는 경우 통합 게이트웨이를 구현하지 마세요. 클라이언트는 동일한 모델 및 동일한 모델 버전으로 라우팅되어야 합니다. 다중 지역 부하 분산 및 장애 조치(failover) 게이트웨이의 경우 관련된 모든 지역에서 사용할 수 있는 공통 모델 및 모델 버전을 선택해야 합니다. 자세한 내용은 모델 가용성을 참조 하세요. 모델 및 모델 버전을 표준화할 수 없는 경우 게이트웨이의 이점이 제한됩니다.

일반 권장 사항

워크로드에 필요한 토폴로지와 관계없이 게이트웨이 솔루션을 빌드할 때 고려해야 할 몇 가지 교차 절삭 권장 사항이 있습니다.

상태 저장 상호 작용

클라이언트가 Assistants API와 같은 Azure OpenAI의 상태 저장 기능을 사용하는 경우 해당 상호 작용 중에 클라이언트를 특정 백 엔드에 고정하도록 게이트웨이를 구성해야 합니다. 이렇게 하려면 쿠키에 인스턴스 데이터를 저장하여 수행할 수 있습니다. 이러한 시나리오에서는 다른 Azure OpenAI 인스턴스로 리디렉션하는 대신 고정된 클라이언트와 같은 429 Azure OpenAI API 응답을 반환하는 것이 좋습니다. 이렇게 하면 클라이언트가 갑작스런 사용 불가를 명시적으로 처리하고 숨기고 기록이 없는 모델 인스턴스로 라우팅할 수 있습니다.

게이트웨이 상태 검사

토폴로지와 관계없이 고려해야 할 두 가지 상태 검사 관점이 있습니다.

게이트웨이가 라운드 로빈링 또는 엄격하게 수행되는 서비스 가용성 장애 조치(failover)를 중심으로 빌드된 경우 가용성 상태 Azure OpenAI 인스턴스(또는 모델)를 사용하는 방법을 원합니다. Azure OpenAI는 요청을 처리할 수 있는지 선제적으로 알 수 있는 상태 검사 엔드포인트를 제공하지 않습니다. 가상 전환을 보낼 수 있지만 모델 용량을 사용합니다. Azure OpenAI 인스턴스 및 모델 가용성에 대한 또 다른 신뢰할 수 있는 신호 원본이 없는 한 게이트웨이는 Azure OpenAI 인스턴스가 작동 중이라고 가정한 다음429, 500503 HTTP 상태 코드를 해당 인스턴스 또는 모델의 향후 요청에 대한 회로 중단 신호로 간주해야 합니다. 제한 상황의 경우 회로 중단 논리의 응답 코드에 Retry-After 대한 429 Azure OpenAI API 응답에 있는 헤더의 데이터를 항상 적용합니다. Azure API Management를 사용하는 경우 기본 제공 회로 차단기 기능을 사용하여 평가합니다.

클라이언트 또는 워크로드 운영 팀은 자체 라우팅 또는 내성 목적으로 게이트웨이에 상태 검사 노출하려고 할 수 있습니다. API Management를 사용하는 경우 기본값 /status-0123456789abcdef 은 주로 백 엔드가 아닌 API Management 게이트웨이 인스턴스를 해결하므로 충분히 자세히 설명하지 못할 수 있습니다. 게이트웨이 또는 게이트웨이의 특정 경로 가용성에 대한 클라이언트 또는 관찰성 시스템에 의미 있는 데이터를 반환할 수 있는 전용 상태 검사 API를 추가하는 것이 좋습니다.

안전한 배포 사례

게이트웨이 구현을 사용하여 업데이트된 모델의 청록색 배포를 오케스트레이션할 수 있습니다. Azure OpenAI 모델은 새 모델 버전 및 새 모델로 업데이트되며, 새로운 미세 조정된 모델이 있을 수 있습니다.

사전 프로덕션에서 변경의 영향을 테스트한 후 프로덕션 클라이언트를 새 모델 버전으로 "잘라내야 하는지" 또는 대신 트래픽을 이동해야 하는지 평가합니다. 앞에서 설명한 게이트웨이 패턴을 사용하면 백 엔드에서 두 모델을 동시에 배포할 수 있습니다. 모델을 동시에 배포하면 증분 롤아웃에 대한 워크로드 팀의 안전한 배포 사례에 따라 트래픽을 리디렉션할 수 있는 게이트웨이가 제공됩니다.

청록색 배포를 사용하지 않더라도 워크로드의 APIOps 접근 방식을 정의하고 백 엔드 인스턴스 및 모델 배포의 변경 속도에 맞게 충분히 자동화해야 합니다.

충분한 구현

이 문서에 도입된 많은 시나리오는 클라이언트 복잡성을 줄이고 안정적인 자체 보존 기술을 구현하여 워크로드의 잠재적인 SLO(서비스 수준 목표)를 높이는 데 도움이 됩니다. 다른 사용자는 액세스 제어를 Azure OpenAI에서 멀리 떨어진 특정 모델로 이동하여 워크로드의 보안을 향상시킵니다. 게이트웨이의 도입이 이러한 목표에 대응하지 않는지 확인합니다. 게이트웨이의 서비스 오류 또는 사용자로 인한 구성 문제, 복잡한 라우팅 논리 또는 의도한 것보다 권한이 없는 클라이언트에 더 많은 모델을 노출하는 위험을 통해 새 단일 실패 지점을 추가하는 위험을 이해합니다.

데이터 주권

워크로드에 대한 데이터 상주 준수 관점에서 다양한 활성-활성 및 활성-수동 접근 방식을 평가해야 합니다. 관련된 지역이 지정학적 경계 내에서 다시 기본 경우 이러한 패턴 중 대부분은 워크로드 아키텍처에 적용할 수 있습니다. 이 시나리오를 지원하려면 지정학적 경계를 격리된 스탬프로 처리하고 해당 스탬프 내에서만 활성-활성 또는 활성-수동 처리를 적용해야 합니다.

특히 성능 기반 라우팅은 데이터 주권 준수에 대해 매우 면밀히 조사해야 합니다. 데이터 주권 시나리오에서는 다른 지리적 위치로 클라이언트를 서비스하고 기본 준수할 수 없습니다. 데이터 상주와 관련된 모든 게이트웨이 아키텍처는 클라이언트가 해당 지정학적 지역의 엔드포인트만 사용하도록 적용해야 합니다. 클라이언트가 다른 게이트웨이 엔드포인트를 사용하지 못하도록 차단해야 하며 게이트웨이 자체는 지정학적 간 요청을 하여 클라이언트의 신뢰를 위반하지 않습니다. 이 구분을 구현하는 가장 신뢰할 수 있는 방법은 지정학적 지역별로 완전히 독립적이고 고가용성 게이트웨이를 중심으로 아키텍처를 빌드하는 것입니다.

Azure OpenAI 권한 부여

게이트웨이는 인터페이스하는 모든 Azure OpenAI 인스턴스를 사용하여 인증해야 합니다. 통과 인증을 수행하도록 게이트웨이를 설계하지 않는 한 게이트웨이는 자격 증명에 관리 ID를 사용해야 합니다. 따라서 각 Azure OpenAI 인스턴스는 게이트웨이의 관리 ID에 대해 최소 권한 RBAC를 구성해야 합니다. 활성-활성 및 장애 조치(failover) 아키텍처의 경우 게이트웨이의 ID에 관련된 모든 Azure OpenAI 인스턴스에 대해 동일한 권한이 있는지 확인합니다.

Azure Policy

모델 배포와 Azure OpenAI 인스턴스 간의 일관성은 활성-활성 또는 활성-수동 상황에서 중요합니다. Azure Policy를 사용하여 다양한 Azure OpenAI 인스턴스 또는 모델 배포 간에 일관성을 적용할 수 있습니다. Azure OpenAI에 대한 기본 제공 정책이 둘 간의 일관성을 보장하기에 충분하지 않은 경우 커뮤니티에서 만든 사용자 지정 정책을 만들거나 사용하는 것이 좋습니다.

게이트웨이 중복성

여러 백 엔드에만 해당되지는 않지만 각 지역의 게이트웨이 구현은 항상 중복성을 사용하여 빌드되어야 하며 배율 단위 내에서 고가용성이어야 합니다. 가용성 영역이 있는 지역을 선택하고 게이트웨이가 해당 지역에 분산되어 있는지 확인합니다. 단일 실패 지점이 게이트웨이의 단일 컴퓨팅 인스턴스의 오류가 아닌 전체 지역 중단으로 제한되도록 게이트웨이의 여러 인스턴스를 배포합니다. API Management의 경우 둘 이상의 영역에 둘 이상의 단위를 배포합니다. 사용자 지정 코드 구현의 경우 가용성 영역에 배포하는 데 가장 적합한 세 개 이상의 인스턴스를 배포합니다.

게이트웨이 구현

Azure는 이러한 게이트웨이를 빌드하기 위한 턴키 솔루션 또는 참조 아키텍처를 제공하지 않습니다. 소개 문서에 멘션 워크로드 팀은 이 게이트웨이를 빌드하고 운영해야 합니다. 다음은 이전에 멘션 사용 사례 중 일부를 다루는 커뮤니티 지원 샘플 구현의 몇 가지 예입니다. 고유한 개념 증명을 빌드할 때 이러한 GitHub 샘플을 참조하는 것이 좋습니다.

구현	예시
Azure API Management	Azure API Management 를 사용하여 Azure OpenAI에 대한 스마트 부하 분산 - 이 GitHub 리포지토리에는 구독에 배포하기 위한 샘플 정책 코드 및 지침이 포함되어 있습니다. Azure API Management 를 사용하여 Azure OpenAI 크기 조정 - 이 GitHub 리포지토리에는 PTU 및 소비 분산에 대한 샘플 정책 코드 및 지침이 포함되어 있습니다. 사용할 수 있는 몇 가지 커뮤니티 지원 Azure OpenAI API Management 정책 도 있습니다.
사용자 지정 코드	Azure Container Apps를 사용하여 Azure OpenAI에 대한 스마트 부하 분산 이 GitHub 리포지토리에는 컨테이너를 빌드하고 구독에 배포하기 위한 샘플 C# 코드 및 지침이 포함되어 있습니다.

다음 단계

워크로드에 대한 게이트웨이 구현을 사용하면 이 문서에 설명된 전술적 다중 백 엔드 라우팅 이점을 넘어서는 이점을 얻을 수 있습니다. 게이트웨이에서 해결할 수 있는 다른 주요 과제에 대해 알아봅니다.

관련 참고 자료

• Azure OpenAI 서비스
• Azure API Management의 API 게이트웨이
• Azure OpenAI API Management 정책