Azure OpenAI 서비스는 애플리케이션이 OpenAI의 언어 모델을 사용하여 포함 또는 완료를 수행할 수 있도록 하는 HTTP API를 노출합니다. 지능형 애플리케이션은 클라이언트 또는 오케스트레이터에서 직접 이러한 HTTP API를 호출합니다. 클라이언트의 예로는 채팅 UI 코드 및 사용자 지정 데이터 처리 파이프라인이 있습니다. 오케스트레이터의 예로는 Azure AI Foundry의 LangChain, 의미 체계 커널 및 프롬프트 흐름이 있습니다. 워크로드가 하나 이상의 Azure OpenAI 인스턴스에 연결하는 경우 이러한 소비자가 직접 연결할지 또는 역방향 프록시 API 게이트웨이를 통해 연결할지 결정해야 합니다.
이 가이드를 사용하여 워크로드 디자인에 소비자가 Azure OpenAI 데이터 평면 API에 직접 액세스하는 경우 발생하는 Azure Well-Architected Framework의 5가지 핵심 요소에 대한 주요 과제에 대해 알아봅니다. 그런 다음 아키텍처에 게이트웨이를 도입하면 새로운 과제를 도입하면서 이러한 직접 액세스 문제를 해결하는 데 어떻게 도움이 되는지 알아봅니다. 이 문서에서는 아키텍처 패턴을 설명하지만 게이트웨이를 구현하는 방법은 설명하지 않습니다.
게이트웨이를 사용하여 모든 워크로드에 없는 특정 시나리오를 해결할 수 있으므로 게이트웨이의 특정 사용 사례를 자세히 살펴보는 특정 시나리오 지침을 참조하세요.
주요 과제
API 게이트웨이 또는 Azure OpenAI HTTP API에 논리를 추가하는 기능이 없으면 클라이언트는 재시도 메커니즘 또는 회로 차단기를 포함하는 API 클라이언트 논리를 처리해야 합니다. 클라이언트 코드를 직접 제어하지 않거나 코드가 특정 SDK 사용으로 제한되는 시나리오에서는 이 상황이 어려울 수 있습니다. 여러 클라이언트 또는 여러 Azure OpenAI 인스턴스 및 배포는 안전한 배포 조정 및 관찰 가능성과 같은 추가적인 과제를 제시합니다.
이 섹션에서는 아키텍처가 소비자의 Azure OpenAI에 대한 직접 액세스만 지원하는 경우 발생할 수 있는 특정 주요 아키텍처 문제의 예를 제공합니다. 문제는 Azure 잘 설계된 프레임워크 핵심 요소를 사용하여 구성됩니다.
안정성 문제
워크로드의 안정성은 복제 및 장애 조치(failover) 메커니즘을 통해 구현되는 자체 보존 및 자체 복구를 위한 용량을 포함하여 여러 가지 요인에 따라 달라집니다. 게이트웨이가 없으면 클라이언트 논리 및 Azure OpenAI 서비스 기능을 사용하여 모든 안정성 문제를 단독으로 해결해야 합니다. 두 표면 중 하나에서 사용 가능한 안정성 제어가 충분하지 않으면 워크로드 안정성이 손상됩니다.
부하 분산 또는 중복성: 서비스 가용성에 따라 여러 Azure OpenAI 인스턴스 간에 장애 조치(failover)는 구성 및 사용자 지정 논리를 통해 제어해야 하는 클라이언트 책임입니다.
표준 또는 프로비저닝된
데이터 영역 표준 또는 프로비저닝된 글로벌지역 엔드포인트 가용성 관점에서 Azure OpenAI 서비스의 가용성에 영향을 주지 않습니다.장애 조치(failover) 논리를 직접 구현할 책임이 있습니다. 급증을 처리하도록 스케일 아웃: 제한될 때 용량을 사용하여 Azure OpenAI 인스턴스로 장애 조치(failover)하는 것은 구성 및 사용자 지정 논리를 통해 제어해야 하는 또 다른 클라이언트 책임입니다. 새 Azure OpenAI 인스턴스에 대한 여러 클라이언트 구성을 업데이트하는 경우 더 큰 위험이 발생하며 적시 문제가 있습니다. 클라이언트 코드를 업데이트하여 높은 수요 기간 동안 낮은 우선 순위 요청을 큐로 전송하는 등 논리의 변경 내용을 구현하는 경우도 마찬가지입니다.
제한: Azure OpenAI API는 HTTP 429 오류 응답 코드를 표준 모델의 TPM(토큰Per-Minute) 또는 RPM(Requests-Per-Minute)을 초과하는 요청에 반환하여 요청을 제한합니다. 또한 Azure OpenAI API는 미리 프로비전된 청구 모델에 대해 프로비전된 용량을 초과하는 요청을 제한합니다. 적절한 백오프 및 재시도 논리 처리는 클라이언트 구현에만 남아 있습니다.
대부분의 워크로드는 Azure OpenAI 배포를
전역 및데이터 영역을 사용하여 이 특정 문제를 해결해야 합니다. 이러한 배포는 각 요청에 충분한 용량을 가진 데이터 센터의 모델 용량을 사용합니다. 전역 및 데이터 영역 배포를 사용하면 사용자 지정 게이트웨이의 복잡성이 추가되지 않고 서비스 제한이 크게 줄어듭니다. 전역 및 데이터 영역 배포 자체는 게이트웨이 구현입니다.
보안 문제
보안 제어는 워크로드 기밀성, 무결성 및 가용성을 보호하는 데 도움이 되어야 합니다. 게이트웨이가 없으면 모든 보안 문제는 클라이언트 논리 및 Azure OpenAI 서비스 기능에서만 해결해야 합니다. 워크로드 요구 사항은 직접 통신을 위해 클라이언트 구분, 클라이언트 제어 또는 서비스 보안 기능에 사용할 수 있는 것보다 더 많은 것을 요구할 수 있습니다.
ID 관리 - 인증 범위: Azure OpenAI에서 노출하는 데이터 평면 API는 API 키 또는 Azure RBAC(역할 기반 액세스 제어)의 두 가지 방법 중 하나로 보호될 수 있습니다. 두 경우 모두 인증은 개별 배포 수준이 아닌 Azure OpenAI 인스턴스 수준에서 수행되며, 특정 배포 모델에 대해 최소 권한 있는 액세스 및 ID 구분을 제공하기 위한 복잡성이 발생합니다.
ID 관리 - ID 공급자: Azure OpenAI 인스턴스를 지원하는 Microsoft Entra 테넌트에 있는 ID를 사용할 수 없는 클라이언트는 단일 전체 액세스 API 키를 공유해야 합니다. API 키에는 보안 유용성 제한이 있으며 여러 클라이언트가 관련되어 있고 모두 동일한 ID를 공유하는 경우 문제가 됩니다.
네트워크 보안: Azure OpenAI 인스턴스에 상대적인 클라이언트 위치에 따라 언어 모델에 대한 공용 인터넷 액세스가 필요할 수 있습니다.
데이터 주권: Azure OpenAI의 컨텍스트에서 데이터 주권은 특정 국가 또는 지역의 지리적 경계 내에서 데이터의 스토리지 및 처리와 관련된 법적 및 규제 요구 사항을 의미합니다. 워크로드는 클라이언트가 데이터 보존 및 주권 법을 준수할 수 있도록 지역 선호도를 보장해야 합니다. 이 프로세스에는 여러 Azure OpenAI 배포가 포함됩니다.
Azure OpenAI 배포를
전역 또는데이터 영역을 사용하는 경우 미사용 데이터는 지정된 Azure 지리에 남아 있지만 모든 Azure OpenAI 위치에서 유추를 위해 데이터를 전송하고 처리할 수 있습니다.
비용 최적화 과제
워크로드는 아키텍처가 낭비를 최소화하고 유틸리티를 최대화할 때 이점을 제공합니다. 강력한 비용 모델링 및 모니터링은 모든 워크로드에 대한 중요한 요구 사항입니다. 게이트웨이가 없으면 Azure OpenAI 인스턴스 사용량 원격 분석을 집계하는 것에서만 프로비전된 또는 클라이언트별 비용 추적의 사용률을 신뢰할 수 있습니다.
비용 추적: Azure OpenAI 사용량에 대한 재무적 관점을 제공할 수 있는 것은 Azure OpenAI 인스턴스 사용량 원격 분석에서 집계된 데이터로 제한됩니다. 차지백 또는 쇼백을 수행해야 하는 경우 다중 테넌트 시나리오의 경우 여러 부서 또는 고객에 걸쳐 다양한 클라이언트를 사용하여 사용량 원격 분석을 특성화해야 합니다.
프로비전된 처리량 사용률: 워크로드는 사용자가 지불한 프로비전된 처리량을 완전히 활용하여 낭비를 방지하려고 합니다. 즉, 모든 표준 모델 배포로 분산하기 전에 프로비전된 모델 배포를 사용하도록 클라이언트를 신뢰하고 조정해야 합니다.
운영 우수성 과제
게이트웨이, 관찰성, 변경 제어 및 개발 프로세스가 없으면 직접 클라이언트-서버 통신에서 제공하는 프로세스로 제한됩니다.
할당량 제어: 클라이언트는 HTTP API가 제한될 때 Azure OpenAI에서 직접 429개의 응답 코드를 받습니다. 워크로드 운영자는 합법적인 사용에 충분한 할당량을 사용할 수 있고 잘못된 동작 클라이언트가 초과 소비하지 않도록 할 책임이 있습니다. 워크로드가 여러 모델 배포 또는 여러 데이터 영역으로 구성된 경우 할당량 사용량 및 할당량 가용성을 이해하기 어려울 수 있습니다.
모니터링 및 관찰 가능성: Azure OpenAI 기본 메트릭은 Azure Monitor를 통해 사용할 수 있습니다. 그러나 데이터의 가용성에 대한 대기 시간이 있으며 실시간 모니터링을 제공하지 않습니다.
안전한 배포 방법: GenAIOps 프로세스에는 클라이언트와 Azure OpenAI에 배포된 모델 간의 조정이 필요합니다. 청록색 또는 카나리아와 같은 고급 배포 방법의 경우 클라이언트 쪽에서 논리를 처리해야 합니다.
성능 효율성 문제
게이트웨이가 없으면 워크로드는 클라이언트가 개별적으로 잘 행동하고 제한된 용량에 대해 다른 클라이언트와 공정하게 동작할 책임이 있습니다.
성능 최적화 - 우선 순위 트래픽: 우선 순위가 높은 클라이언트가 우선 순위가 낮은 클라이언트보다 우선적으로 액세스할 수 있도록 클라이언트 요청의 우선 순위를 지정하려면 광범위하고 불합리한 클라이언트 간 조정이 필요합니다. 일부 워크로드는 모델 사용률이 낮을 때 우선 순위가 낮은 요청을 큐에 대기하여 실행할 수 있습니다.
성능 최적화 - 클라이언트 규정 준수: 용량을 공유하려면 클라이언트가 잘 작동해야 합니다. 이 예는 클라이언트가 이를 확인하고
max_tokensbest_of승인된 값으로 설정된 경우입니다. 게이트웨이가 없으면 클라이언트가 Azure OpenAI 인스턴스의 용량을 보존하는 데 최선의 이익을 위해 작동하도록 신뢰해야 합니다.대기 시간 최소화: 네트워크 대기 시간은 일반적으로 전체 프롬프트 및 완료 요청 흐름의 작은 구성 요소이지만 클라이언트가 네트워크 엔드포인트로 라우팅되고 가까운 모델이 도움이 될 수 있습니다. 게이트웨이가 없으면 클라이언트는 사용할 모델 배포 엔드포인트와 해당 특정 Azure OpenAI 데이터 평면 API에 필요한 자격 증명을 자체 선택해야 합니다.
솔루션
그림 1: 게이트웨이를 통해 Azure OpenAI에 액세스하는 개념 아키텍처
주요 과제에 나열된 많은 문제를 해결하기 위해 역방향 프록시 게이트웨이를 삽입하여 Azure OpenAI에서 지능형 애플리케이션을 분리할 수 있습니다. 이 게이트웨이 오프로드를 사용하면 책임, 복잡성 및 관찰 가능성을 클라이언트에서 멀어지게 하고 기본 제공되지 않은 다른 기능을 제공하여 Azure OpenAI를 보강할 수 있습니다. 다음은 몇 가지 예입니다.
페더레이션 인증을 구현할 가능성이 있습니다.
속도 제한을 통해 모델에 대한 압력을 제어하는 기능.
교차 절단 및 모델 간 모니터링.
큐 기반 부하 평준화를 위해 낮은 우선 순위 메시지를 큐로 라우팅하거나 작업을 수행하기 위해 컴퓨팅하는 등 여러 서비스에 게이트웨이 집계 및 고급 라우팅을 도입하는 기능.
상태 엔드포인트 모니터링 사용하여 회로가 사용할 수 없거나 오버로드된 모델 배포에서 중단하는정상 엔드포인트로만 라우팅하는 부하 분산
일부 특정 시나리오에는 API 게이트웨이 및 Azure OpenAI 인스턴스를 직접 해결하는 더 많은 지침을 사용할 수 있습니다. 이러한 시나리오는 다음 단계 섹션에 나열됩니다.
고려 사항
아키텍처에 새 구성 요소를 도입할 때 새로 도입된 절충을 평가해야 합니다. 주요 문제를 해결하기 위해 클라이언트와 Azure OpenAI 데이터 평면 간에 API 게이트웨이를 삽입하면 아키텍처에 새로운 고려 사항이 도입됩니다. 이러한 아키텍처 고려 사항에서 워크로드가 게이트웨이의 부가 가치 또는 유틸리티를 정당화하는지 신중하게 평가합니다.
안정성
안정성을 통해 애플리케이션이 고객에 대한 약정을 충족할 수 있습니다. 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.
게이트웨이 솔루션은 단일 실패 지점을 도입할 수 있습니다. 이 오류는 게이트웨이 플랫폼의 서비스 가용성, 코드 또는 구성 배포로 인한 중단 또는 게이트웨이에서 잘못 구성된 중요한 API 엔드포인트의 원본일 수 있습니다. 워크로드의 가용성 요구 사항을 충족하도록 구현을 디자인해야 합니다. 워크로드의 오류 모드 분석에 게이트웨이를 포함하여 구현에서 복원력 및 내결함성 기능을 고려합니다 .
지역 가동 중단 시 요청을 계속 처리할 수 있는 기능과 같이 Azure OpenAI 엔드포인트의 가용성을 높이기 위해 아키텍처에 여러 지역의 Azure OpenAI 인스턴스가 필요한 경우 솔루션에 글로벌 라우팅 기능이 필요할 수 있습니다. 이 상황은 정규화된 추가 도메인 이름, TLS 인증서 및 더 많은 글로벌 라우팅 구성 요소를 관리하여 토폴로지의 복잡해질 수 있습니다.
Important
이렇게 하면 합의된 SLO(서비스 수준 목표)를 충족하는 워크로드의 기능이 위태로울 경우 게이트웨이를 구현하지 마세요.
보안
API 게이트웨이가 아키텍처의 이점을 고려할 때 보안에 대한 디자인 검토 검사 목록을 사용하여 디자인을 평가합니다. 다음과 같은 보안 고려 사항을 해결해야 합니다.
게이트웨이가 추가되면 워크로드의 노출 영역이 증가합니다. 이 노출 영역은 Azure 리소스의 추가 ID 및 액세스 관리(IAM) 고려 사항, 강화 노력 증가 등을 제공합니다.
게이트웨이는 클라이언트 네트워크 공간과 프라이빗 Azure OpenAI 네트워크 공간 간의 네트워크 경계 전환 역할을 할 수 있습니다. 게이트웨이가 Azure Private Link를 사용하여 이전에 인터넷 연결 Azure OpenAI 엔드포인트를 비공개로 설정하더라도 이제는 새로운 진입점이 되며 적절하게 보호되어야 합니다.
게이트웨이는 원시 요청 데이터와 언어 모델의 공식화된 응답을 볼 수 있는 고유한 위치에 있으며, 여기에는 두 원본의 기밀 데이터가 포함될 수 있습니다. 이제 데이터 규정 준수 및 규정 범위가 이 다른 구성 요소로 확장되었습니다.
게이트웨이는 Microsoft Entra ID 및 API 키 인증을 넘어 IdP(여러 ID 공급자)에서 클라이언트 권한 부여 및 인증의 범위를 확장할 수 있습니다.
데이터 주권은 다중 지역 구현에서 구현에 고려되어야 합니다. 게이트웨이 컴퓨팅 및 라우팅 논리가 워크로드에 적용되는 주권 요구 사항을 준수하는지 확인합니다.
Important
이렇게 하면 워크로드가 자체 또는 사용자의 데이터의 기밀성, 무결성 또는 가용성을 보호할 수 없는 경우 게이트웨이를 구현하지 마세요.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화를 위한 디자인 검토 검사 목록을 참조하세요.
구현된 모든 API 게이트웨이에는 예산을 책정하고 고려해야 하는 런타임 비용이 있습니다. 이러한 비용은 일반적으로 추가된 APIOps 관리와 함께 도입된 운영 비용과 함께 게이트웨이 자체의 안정성, 보안 및 성능을 해결하기 위해 추가된 기능으로 증가합니다. 이러한 추가 비용은 게이트웨이를 사용하여 시스템에서 전달되는 새 값에 대해 측정해야 합니다. 게이트웨이를 사용하여 도입된 새로운 기능이 게이트웨이를 구현하고 유지 관리하는 비용보다 더 큰 지점에 도달하려고 합니다. 사용자와의 워크로드 관계에 따라 사용량을 청구할 수 있습니다.
게이트웨이를 개발하고 테스트할 때 비용을 관리하려면 Azure OpenAI에 대해 시뮬레이션된 엔드포인트를 사용하는 것이 좋습니다. 예를 들어 Azure OpenAI API 시뮬레이터 GitHub 리포지토리에서 솔루션을 사용합니다.
운영 우수성
API 게이트웨이가 아키텍처의 이점을 고려하는 경우 운영 우수성에 대한 디자인 검토 검사 목록을 사용하여 디자인을 평가합니다. 다음과 같은 운영 우수성 고려 사항을 해결해야 합니다.
게이트웨이 자체는 워크로드의 모니터링 솔루션 및 잠재적으로 클라이언트에서 모니터링해야 합니다. 즉, 게이트웨이 컴퓨팅 및 작업이 워크로드의 상태 모델링에 포함되어야 합니다.
이제 안전한 배포 방법은 API 게이트웨이 인프라의 배포와 게이트웨이 라우팅의 코드 또는 구성을 해결해야 합니다. 인프라 자동화 및 IaC(Infrastructure as Code) 솔루션은 게이트웨이를 워크로드에서 수명이 긴 리소스로 처리하는 방법을 고려해야 합니다.
게이트웨이에 노출된 API를 포함하려면 APIOps 접근 방식을 빌드하거나 확장해야 합니다.
Azure AI 서비스 리소스 또는 Azure OpenAI 데이터 영역 부하 분산 기능과 같은 솔루션을 통해 사용할 수 있는 기능을 복제합니다.
성능 효율성
API 게이트웨이가 아키텍처의 이점을 고려하는 경우 성능 효율성에 대한 디자인 검토 검사 목록을 사용하여 디자인을 평가합니다. 다음과 같은 성능 효율성 고려 사항을 해결해야 합니다.
게이트웨이 서비스는 처리량 병목 현상을 일으킬 수 있습니다. 게이트웨이가 전체 동시 부하를 처리할 수 있는 적절한 성능을 가지고 있고 성장 기대에 맞게 쉽게 확장할 수 있는지 확인합니다. 게이트웨이가 영업일 사용량과 같이 수요가 낮은 경우 공급을 줄이거나 축소할 수 있도록 솔루션의 탄력성을 보장합니다.
게이트웨이 서비스에는 요청별로 수행해야 하는 처리가 있으며 API 호출당 대기 시간이 추가됩니다. 라우팅 논리를 최적화하여 요청이 잘 수행되도록 해야 합니다.
대부분의 경우 게이트웨이는 대기 시간을 줄이기 위해 사용자와 Azure OpenAI 인스턴스 둘 다에 지리적으로 가까워야 합니다. 네트워크 대기 시간은 일반적으로 언어 모델에 대한 전체 API 호출에서 약간의 시간이지만 워크로드의 경쟁 요인이 될 수 있습니다.
Azure OpenAI 기능에 대한 게이트웨이의 영향을 평가합니다(예: Assistants API와 같은 상태 저장 상호 작용에 대한 스트리밍 응답 또는 인스턴스 고정).
Important
이렇게 하면 협상된 성능 목표를 달성할 수 없거나 다른 절충에 너무 타협하는 경우 게이트웨이를 구현하지 마세요.
구현 옵션
Azure는 이러한 모든 시나리오를 다루기 위해 Azure OpenAI의 HTTP API 또는 기타 사용자 지정 언어 모델 추론 API를 프록시하도록 특별히 설계된 턴키 솔루션을 제공하지 않습니다. 하지만 Azure의 게이트웨이와 같이 워크로드 팀이 구현할 수 있는 몇 가지 옵션이 여전히 있습니다.
Azure API Management 사용
Azure API Management 는 HTTP 기반 API에 대한 교차 절단 문제를 오프로드하도록 설계된 플랫폼 관리 서비스입니다. 구성 기반이며 인바운드 및 아웃바운드 요청 처리 정책 시스템을 통한 사용자 지정을 지원합니다. 단일 컨트롤 플레인을 사용하여 고가용성 영역 중복 및 다중 지역 복제본도 지원합니다.
대부분의 게이트웨이 라우팅 및 요청 처리 논리는 API Management의 정책 시스템에서 구현되어야 합니다. Azure OpenAI API 토큰 사용
Azure API Management와 관련된 솔루션을 디자인할 때 API Management에 대한 잘 설계된 프레임워크 서비스 가이드를 사용합니다. 워크로드가 애플리케이션 랜딩 존의 일부로 존재하는 경우 Azure API Management 랜딩 존 구현에 대한 Azure 클라우드 채택 프레임워크 사용할 수 있는 지침을 검토합니다.
게이트웨이 구현에 Azure API Management를 사용하는 것은 일반적으로 Azure OpenAI 게이트웨이를 빌드하고 운영하는 데 선호되는 방법입니다. 이 서비스는 풍부한 기본 제공 기능, 고가용성 및 네트워킹 옵션을 제공하는 PaaS(Platform as a Service) 제품이므로 선호됩니다. 또한 완성 API를 관리하는 강력한 APIOps 접근 방식도 있습니다.
사용자 지정 코드 사용
사용자 지정 코드 접근 방식을 사용하려면 소프트웨어 개발 팀이 사용자 지정 코딩된 솔루션을 만들고 해당 솔루션을 선택한 Azure 애플리케이션 플랫폼에 배포해야 합니다. 게이트웨이 논리를 처리하는 자체 관리형 솔루션을 빌드하는 것은 네트워크 및 라우팅 코드를 관리하는 데 능숙한 워크로드 팀에 적합할 수 있습니다.
워크로드는 일반적으로 Azure 앱 Service, Azure Container Apps 또는 Azure Kubernetes Service에서 게이트웨이 코드를 호스팅하는 것과 같이 익숙한 컴퓨팅을 사용할 수 있습니다.
API Management가 클라이언트와 사용자 지정 코드 간의 핵심 HTTP API 게이트웨이 기능에만 사용되는 경우 사용자 지정 코드 배포를 API Management와 함께 사용할 수도 있습니다. 이렇게 하면 사용자 지정 코드가 필요한 비즈니스 논리에 따라 Azure OpenAI HTTP API와 단독으로 인터페이스됩니다.
Azure에서 기본적으로 제공되지 않는 제품 또는 서비스인 타사 게이트웨이 기술의 사용은 이 방법의 일부로 간주될 수 있습니다.
예제 아키텍처
그림 2: Azure API Management 기반 게이트웨이를 통해 Azure OpenAI에 액세스하는 예제 아키텍처
다음 단계
인텔리전트 애플리케이션과 Azure OpenAI 배포 간에 게이트웨이를 배포하여 워크로드 요구 사항을 해결하는 특정 시나리오에 대해 알아봅니다.
Azure OpenAI 모델에 대한 로깅 및 모니터링을 구현하는 방법을 알아봅니다.