기준 OpenAI 엔드투엔드 채팅 참조 아키텍처

엔터프라이즈 채팅 애플리케이션은 대화형 상호 작용을 통해 직원에게 권한을 부여할 수 있습니다. 특히 OpenAI의 GPT 모델 및 Meta의 LLaMA 모델과 같은 언어 모델의 지속적인 발전으로 인해 특히 그렇습니다. 이러한 채팅 애플리케이션은 UI(채팅 사용자 인터페이스), 사용자의 쿼리와 관련된 도메인별 정보를 포함하는 데이터 리포지토리, 도메인별 데이터를 통해 관련 응답을 생성하는 언어 모델 및 이러한 구성 요소 간의 상호 작용을 감독하는 오케스트레이터로 구성됩니다.

이 문서에서는 Azure OpenAI Service 언어 모델을 사용하는 엔터프라이즈 채팅 애플리케이션을 빌드하고 배포하기 위한 기준 아키텍처를 제공합니다. 아키텍처는 프롬프트 흐름을 사용하여 실행 가능한 흐름을 만듭니다. 이러한 실행 파일 흐름은 들어오는 프롬프트에서 데이터 저장소로 워크플로를 오케스트레이션하여 다른 필수 Python 논리와 함께 언어 모델에 대한 접지 데이터를 가져옵니다. 실행 파일 흐름은 관리형 컴퓨팅을 사용하여 관리되는 온라인 엔드포인트에 배포되는 흐름에 배포됩니다.

사용자 지정 UI(채팅 사용자 인터페이스)의 호스팅은 Azure 앱 Service에서 안전하고 영역 중복되고 고가용성 웹 애플리케이션을 배포하기 위한 기준 앱 서비스 웹 애플리케이션 지침을 따릅니다. 이 아키텍처에서 App Service는 프라이빗 엔드포인트를 통한 가상 네트워크 통합을 통해 Azure PaaS(Platform as a Service) 솔루션과 통신합니다. 채팅 UI App Service는 프라이빗 엔드포인트를 통해 흐름에 대한 관리되는 온라인 엔드포인트와 통신합니다. Azure AI Studio에 대한 공용 액세스를 사용할 수 없습니다.

Azure AI Studio 허브는 모든 아웃바운드 연결을 승인해야 하는 관리형 가상 네트워크 격리로 구성됩니다. 이 구성을 사용하면 관리형 가상 네트워크가 작업 공간 Azure Storage, Azure Container Registry 및 Azure OpenAI와 같은 프라이빗 리소스에 연결할 수 있는 관리형 프라이빗 엔드포인트와 함께 만들어집니다. 이러한 프라이빗 연결은 흐름 작성과 테스트 및 Machine Learning 컴퓨팅에 배포된 흐름에 의해 사용됩니다.

허브는 여러 프로젝트에서 보안, 연결 및 기타 문제를 제어하는 중앙 방법을 제공하는 최상위 Azure AI Studio 리소스입니다. 이 아키텍처에는 워크로드에 하나의 프로젝트만 필요합니다. 데이터 저장소와 같은 다른 백 엔드 리소스를 사용할 수 있는 다른 논리를 사용하는 다른 프롬프트 흐름이 필요한 추가 환경이 있는 경우 다른 프로젝트에 구현하는 것이 좋습니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

구성 요소

이 아키텍처의 많은 구성 요소는 기본 Azure OpenAI 엔드투엔드 채팅 아키텍처와 동일합니다. 다음 목록에서는 기본 아키텍처의 변경 내용만 강조 표시합니다.

• Azure OpenAI는 기본 아키텍처와 이 기준 아키텍처 모두에서 사용됩니다. Azure OpenAI는 GPT-4, GPT-3.5 Turbo 및 모델의 포함 모델 세트를 포함하여 Azure OpenAI의 언어 모델에 대한 REST API 액세스를 제공하는 완전 관리형 서비스입니다. 기준 아키텍처는 기본 아키텍처에서 구현하지 않는 가상 네트워크 및 프라이빗 링크와 같은 엔터프라이즈 기능을 활용합니다.
• Azure AI Studio 는 AI 솔루션을 빌드, 테스트 및 배포하는 데 사용할 수 있는 플랫폼입니다. AI Studio는 이 아키텍처에서 채팅 애플리케이션에 대한 프롬프트 흐름 오케스트레이션 논리를 빌드, 테스트 및 배포하는 데 사용됩니다. 이 아키텍처에서 Azure AI Studio는 네트워크 보안을 위해 관리되는 가상 네트워크를 제공합니다. 자세한 내용은 네트워킹 섹션을 참조하세요.
• Application Gateway 는 계층 7(HTTP/S) 부하 분산 장치 및 웹 트래픽 라우터입니다. URL 경로 기반 라우팅을 사용하여 들어오는 트래픽을 가용성 영역에 분산하고 암호화를 오프로드하여 애플리케이션 성능을 향상시킵니다.
• WAF(Web Application Firewall)는 SQL 삽입 및 교차 사이트 스크립팅과 같은 일반적인 악용으로부터 웹 앱을 보호하는 클라우드 네이티브 서비스입니다. 웹 애플리케이션 방화벽은 웹 애플리케이션에서 들어오고 가는 트래픽에 대한 가시성을 제공하므로 애플리케이션을 모니터링하고 보호할 수 있습니다.
• Azure Key Vault는 비밀, 암호화 키, 인증서를 안전하게 저장하고 관리하는 서비스입니다. 중요한 정보의 관리를 중앙 집중화합니다.
• Azure 가상 네트워크는 Azure에서 격리되고 안전한 프라이빗 가상 네트워크를 만들 수 있는 서비스입니다. App Service의 웹 애플리케이션의 경우 리소스 간의 네트워크 보안 통신에 프라이빗 엔드포인트를 사용하는 가상 네트워크 서브넷이 필요합니다.
• Private Link를 사용하면 클라이언트가 공용 IP 주소 지정을 사용하지 않고 프라이빗 가상 네트워크에서 직접 Azure PaaS(Platform as a Service) 서비스에 액세스할 수 있습니다.
• Azure DNS는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공하는 DNS 도메인에 대한 호스팅 서비스입니다. 프라이빗 DNS 영역은 서비스의 FQDN(정규화된 도메인 이름)을 프라이빗 엔드포인트의 IP 주소에 매핑하는 방법을 제공합니다.

대안

이 아키텍처에는 워크로드의 기능 및 비기능적 요구 사항에 더 잘 부합할 수 있는 다른 Azure 서비스에서 사용할 수 있는 여러 구성 요소가 있습니다. 다음은 알아야 할 몇 가지 대안입니다.

Azure Machine Learning 작업 영역(및 포털 환경)

이 아키텍처는 Azure AI Studio를 사용하여 프롬프트 흐름을 빌드, 테스트 및 배포합니다. 또는 두 서비스에 겹치는 기능이 있으므로 Azure Machine Learning 작업 영역을 사용할 수 있습니다. AI Studio는 프롬프트 흐름 솔루션을 설계하는 경우 좋은 선택이지만, 현재 Azure Machine Learning에서 더 나은 지원을 제공하는 몇 가지 기능이 있습니다. 자세한 내용은 기능 비교를 참조하세요. Azure AI Studio 및 Azure Machine Learning을 혼합하고 일치하지 않는 것이 좋습니다. AI Studio에서 작업을 완전히 수행할 수 있는 경우 AI Studio를 사용합니다. Azure Machine Learning 스튜디오 기능이 여전히 필요한 경우 계속해서 Azure Machine Learning 스튜디오 사용합니다.

애플리케이션 계층 구성 요소

채팅 UI 프런트 엔드의 애플리케이션 계층으로 사용할 수 있는 Azure에서 사용할 수 있는 여러 관리되는 애플리케이션 서비스 제품이 있습니다. 모든 컴퓨팅에 대한 Azure 컴퓨팅 서비스 선택 및 컨테이너 솔루션에 대한 Azure 컨테이너 서비스 선택을 참조하세요. 예를 들어 채팅 UI API와 프롬프트 흐름 호스트 둘 다에 대해 Azure Web Apps 및 Web App for Containers가 각각 선택되었지만 AKS(Azure Kubernetes Service) 또는 Azure Container Apps를 사용하여 비슷한 결과를 달성할 수 있습니다. 워크로드의 특정 기능 및 비기능 요구 사항에 따라 워크로드의 애플리케이션 플랫폼을 선택합니다.

프롬프트 흐름 호스팅

프롬프트 흐름 배포는 Machine Learning 컴퓨팅 클러스터로 제한되지 않으며, 이 아키텍처는 Azure 앱 Service의 대안으로 이를 보여 줍니다. 흐름은 궁극적으로 컨테이너화된 애플리케이션을 컨테이너와 호환되는 모든 Azure 서비스에 배포할 수 있습니다. 이러한 옵션에는 AKS(Azure Kubernetes Service), Azure Container Apps 및 Azure 앱 Service와 같은 서비스가 포함됩니다. 오케스트레이션 계층의 요구 사항에 따라 Azure 컨테이너 서비스를 선택합니다.

대체 컴퓨팅에서 호스팅 프롬프트 흐름을 호스팅하는 이유의 예는 이 문서의 뒷부분에서 설명합니다.

접지 데이터 저장소

이 아키텍처는 Azure AI Search로 이어지지만, 접지 데이터에 대한 데이터 저장소 선택은 워크로드와 관련된 아키텍처 결정입니다. 실제로 많은 워크로드는 다각형이며 데이터를 접지하기 위한 서로 다른 원본과 기술을 가지고 있습니다. 이러한 데이터 플랫폼은 Azure AI Search와 같은 특수 솔루션을 통해 기존 OLTP 데이터 저장소, Azure Cosmos DB와 같은 클라우드 네이티브 데이터베이스에 이르기까지 다양합니다. 이러한 데이터 저장소에 대한 일반적인 특성은 필수는 아니지만 벡터 검색입니다. 이 공간의 옵션을 탐색하려면 벡터 검색에 대한 Azure 서비스 선택을 참조하세요.

고려 사항 및 권장 지침

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.

기준 App Service 웹 애플리케이션 아키텍처는 주요 지역 서비스에 대한 영역 중복성에 중점을 둡니다. 가용성 영역은 지역 내에서 물리적으로 분리된 위치입니다. 둘 이상의 인스턴스가 배포될 때 서비스를 지원하기 위해 지역 내에서 중복성을 제공합니다. 한 영역이 가동 중지 시간을 경험하는 경우 지역 내의 다른 영역은 여전히 영향을 받지 않을 수 있습니다. 또한 아키텍처를 통해 Azure 서비스의 인스턴스를 충분히 확보하고 해당 서비스의 구성을 가용성 영역에 분산할 수 있습니다. 자세한 내용은 기준을 참조하여 해당 지침을 검토하세요.

이 섹션에서는 Machine Learning, Azure OpenAI 및 AI Search를 포함하여 App Service 기준에서 다루지 않는 이 아키텍처의 구성 요소 관점에서 안정성을 다룹니다.

흐름 배포에 대한 영역 중복성

엔터프라이즈 배포에는 일반적으로 영역 중복이 필요합니다. Azure에서 영역 중복을 달성하려면 리소스가 가용성 영역을 지원해야 하며, 인스턴스 제어를 사용할 수 없는 경우 리소스의 인스턴스를 3개 이상 배포하거나 플랫폼 지원을 사용하도록 설정해야 합니다. 현재 Machine Learning 컴퓨팅은 가용성 영역에 대한 지원을 제공하지 않습니다. Machine Learning 구성 요소에 대한 데이터 센터 수준 재해의 잠재적 영향을 완화하려면 부하 분산 장치를 배포하여 이러한 클러스터 간에 호출을 분산하는 작업과 함께 다양한 지역에 클러스터를 설정해야 합니다. 상태 검사를 사용하여 호출이 제대로 작동하는 클러스터로만 라우팅되도록 할 수 있습니다.

AKS(Azure Kubernetes Service), Azure Functions, Azure Container Apps 및 Azure 앱 Service와 같은 Machine Learning 컴퓨팅 클러스터에 대한 몇 가지 대안이 있습니다. 이러한 각 서비스는 가용성 영역을 지원합니다. 다중 지역 배포의 복잡성을 추가하지 않고 프롬프트 흐름 실행을 위한 영역 중복성을 달성하려면 해당 서비스 중 하나에 흐름을 배포해야 합니다.

다음 다이어그램에서는 프롬프트 흐름이 App Service에 배포되는 대체 아키텍처를 보여 줍니다. App Service는 워크로드가 이미 채팅 UI에 사용하고 있으며 워크로드에 새로운 기술을 도입하는 이점을 활용하지 못하기 때문에 이 아키텍처에서 사용됩니다. AKS 경험이 있는 워크로드 팀은 특히 AKS가 워크로드의 다른 구성 요소에 사용되는 경우 해당 환경에 배포하는 것을 고려해야 합니다.

다이어그램은 이 아키텍처에서 주목할 만한 영역에 대해 번호가 매겨집니다.

1. 흐름은 프롬프트 흐름에서 계속 작성되며 네트워크 아키텍처는 변경되지 않습니다. 흐름 작성자는 여전히 프라이빗 엔드포인트를 통해 AI Studio 프로젝트의 제작 환경에 연결하며, 관리형 프라이빗 엔드포인트는 흐름을 테스트할 때 Azure 서비스에 연결하는 데 사용됩니다.

2. 이 점선은 컨테이너화된 실행 파일 흐름이 Container Registry로 푸시됨을 나타냅니다. 다이어그램에 표시되지 않는 것은 흐름을 컨테이너화하고 Container Registry로 푸시하는 파이프라인입니다. 이러한 파이프라인이 실행되는 컴퓨팅에는 Azure 컨테이너 레지스트리 및 AI Studio 프로젝트와 같은 리소스에 대한 네트워크 가시선이 있어야 합니다.

3. 이미 채팅 UI를 호스팅하고 있는 동일한 App Service 계획에 배포된 다른 웹앱이 있습니다. 새 웹앱은 컨테이너화된 프롬프트 흐름을 호스트하며, 이미 3개 이상의 인스턴스에서 실행되는 동일한 App Service 계획에 배치되어 가용성 영역에 분산되어 있습니다. 이러한 App Service 인스턴스는 프롬프트 흐름 컨테이너 이미지를 로드할 때 프라이빗 엔드포인트를 통해 Container Registry에 연결됩니다.

4. 프롬프트 흐름 컨테이너는 흐름 실행을 위해 모든 종속 서비스에 연결해야 합니다. 이 아키텍처에서 프롬프트 흐름 컨테이너는 AI Search 및 Azure OpenAI에 연결됩니다. Machine Learning 관리형 프라이빗 엔드포인트 서브넷에만 노출된 PaaS 서비스도 App Service에서 가시선을 설정할 수 있도록 가상 네트워크에 노출되어야 합니다.

Azure OpenAI - 안정성

Azure OpenAI는 현재 가용성 영역을 지원하지 않습니다. Azure OpenAI의 모델 배포에 대한 데이터 센터 수준 재해의 잠재적 영향을 완화하려면 Azure OpenAI를 다양한 지역에 배포하고 부하 분산 장치를 배포하여 지역 간에 호출을 분산해야 합니다. 상태 검사를 사용하여 호출이 제대로 작동하는 클러스터로만 라우팅되도록 할 수 있습니다.

여러 인스턴스를 효과적으로 지원하려면 지역 중복 스토리지 계정과 같은 미세 조정 파일을 외부화하는 것이 좋습니다. 이 방법은 각 지역에 대해 Azure OpenAI에 저장된 상태를 최소화합니다. 모델 배포를 호스트하려면 각 인스턴스에 대한 파일을 미세 조정해야 합니다.

TPM(분당 토큰) 및 RPM(분당 요청) 측면에서 필요한 처리량을 모니터링하는 것이 중요합니다. 배포에 대한 수요를 충족하고 배포된 모델에 대한 호출이 제한되지 않도록 할당량에서 할당된 충분한 TPM이 있는지 확인합니다. Azure API Management와 같은 게이트웨이는 Azure OpenAI 서비스 또는 서비스 앞에 배포할 수 있으며 일시적인 오류 및 제한이 있는 경우 다시 시도하도록 구성할 수 있습니다. API Management를 회로 차단기로 사용하여 서비스가 호출에 과부하가 발생하여 할당량을 초과하지 않도록 할 수도 있습니다. 안정성 문제를 위해 게이트웨이를 추가하는 방법에 대한 자세한 내용은 게이트웨이를 통해 Azure OpenAI 및 기타 언어 모델 액세스를 참조하세요.

AI Search - 안정성

가용성 영역을 지원하는 지역에서 표준 가격 책정 계층 이상을 사용하여 AI Search를 배포하고 3개 이상의 복제본을 배포합니다. 복제본은 가용성 영역에 균등하게 자동으로 분산됩니다.

적절한 수의 복제본 및 파티션을 결정하기 위한 다음 지침을 고려합니다.

• AI 검색을 모니터링합니다.

• 모니터링 메트릭 및 로그 및 성능 분석을 사용하여 적절한 복제본 수를 확인하여 쿼리 기반 제한 및 파티션을 방지하고 인덱스 기반 제한을 방지합니다.

Azure AI Studio - 안정성

Machine Learning 관리형 온라인 엔드포인트 뒤에 있는 컴퓨팅 클러스터에 배포하는 경우 크기 조정에 대한 다음 지침을 고려합니다.

• 수요를 충족하기에 충분한 용량을 사용할 수 있도록 온라인 엔드포인트의 크기를 자동으로 조정합니다. 버스트 사용으로 인해 사용 신호가 적시에 충분하지 않은 경우 너무 적은 수의 인스턴스에서 안정성에 미치는 영향을 방지하기 위해 과잉 프로비전을 고려합니다.

• CPU 로드 및 요청 대기 시간과 같은 엔드포인트 메트릭과 같은 배포 메트릭을 기반으로 크기 조정 규칙을 만드는 것이 좋습니다.

• 활성 프로덕션 배포를 위해 3개 이하의 인스턴스를 배포해야 합니다.

• 사용 중인 인스턴스에 대한 배포를 방지합니다. 대신 새 배포에 배포하고 배포가 트래픽을 수신할 준비가 된 후 트래픽을 전환합니다.

관리형 온라인 엔드포인트는 뒤에서 실행되는 관리형 컴퓨팅에 대한 부하 분산 장치 및 라우터 역할을 합니다. 백분율이 최대 100%까지 추가되는 한 각 배포로 라우팅되어야 하는 트래픽의 비율을 구성할 수 있습니다. 또한 모든 배포로 라우팅되는 트래픽이 0%인 관리형 온라인 엔드포인트를 배포할 수 있습니다. 제공된 참조 구현에서처럼 IaC(Infrastructure as code)를 사용하여 관리되는 온라인 엔드포인트를 포함한 리소스를 배포하는 경우 안정성 문제가 있습니다. 배포로 라우팅하도록 구성된 트래픽(CLI 또는 Azure AI Studio를 통해 생성됨)이 있고 관리되는 온라인 엔드포인트를 포함하는 후속 IaC 배포를 수행하는 경우, 관리되는 온라인 엔드포인트를 어떤 방식으로든 업데이트하지 않더라도 엔드포인트 트래픽은 0% 트래픽 라우팅으로 되돌아갑니다. 즉, 트래픽을 원하는 위치로 다시 조정할 때까지 배포된 프롬프트 흐름에 더 이상 연결할 수 없습니다.

다중 지역 디자인

이 아키텍처는 다중 지역 아키텍처의 지역 스탬프로 빌드되지 않았습니다. 가용성 영역의 완전한 사용으로 인해 단일 지역 내에서 고가용성을 제공하지만 다중 지역 솔루션에 대한 진정한 준비를 위한 몇 가지 주요 구성 요소가 부족합니다. 다음은 이 아키텍처에서 누락된 몇 가지 구성 요소 또는 고려 사항입니다.

• 전역 수신 및 라우팅
• DNS 관리 전략
• 데이터 복제(또는 격리) 전략
• 활성-활성, 활성-수동 또는 활성-콜드 지정
• 워크로드의 RTO 및 RPO를 달성하기 위한 장애 조치(failover) 및 장애 복구 전략
• Azure Studio Hub 리소스의 개발자 환경에 대한 지역 가용성에 대한 결정

워크로드의 요구 사항에 다중 지역 전략이 필요한 경우 이 아키텍처에 제시된 내용에 따라 구성 요소 및 운영 프로세스에 대한 추가 설계 작업에 투자해야 합니다. 다음 계층에서 부하 분산 또는 장애 조치(failover)를 지원하도록 디자인합니다.

• 기반 데이터
• 모델 호스팅
• 오케스트레이션 계층(이 아키텍처의 프롬프트 흐름)
• 클라이언트 연결 UI

또한 준수성, 포털 환경 및 책임 있는 AI 문제(예: 콘텐츠 안전)에서 비즈니스 연속성을 유지해야 합니다.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안성에 대한 디자인 검토 검사 목록을 참조하세요.

이 아키텍처는 Azure OpenAI 아키텍처를 사용하여 기본 엔드투엔드 채팅에서 구현된 보안 공간을 확장합니다. 기본 아키텍처는 시스템 할당 관리 ID 및 시스템 할당 역할 할당을 사용하지만, 이 아키텍처는 수동으로 만든 역할 할당과 함께 사용자 할당 ID를 사용합니다.

아키텍처는 기본 아키텍처에서 구현된 ID 경계와 함께 네트워크 보안 경계를 구현합니다. 네트워크 관점에서 인터넷에서 액세스할 수 있어야 하는 유일한 것은 Application Gateway를 통한 채팅 UI입니다. ID 관점에서 채팅 UI는 요청을 인증하고 권한을 부여해야 합니다. 관리 ID는 가능한 경우 Azure 서비스에 애플리케이션을 인증하는 데 사용됩니다.

이 섹션에서는 네트워킹 고려 사항과 함께 키 회전 및 Azure OpenAI 모델 미세 조정에 대한 보안 고려 사항을 설명합니다.

ID 및 액세스 관리

사용자 할당 관리 ID를 사용하는 경우 다음 지침을 고려합니다.

• 해당하는 경우 다음 Azure AI Studio 및 Machine Learning 리소스에 대해 별도의 관리 ID를 만듭니다.
  • AI Studio Hub
  • 흐름 작성 및 관리를 위한 AI Studio 프로젝트
  • 흐름이 관리되는 온라인 엔드포인트에 배포된 경우 배포된 흐름의 온라인 엔드포인트
• Microsoft Entra ID를 사용하여 채팅 UI에 대한 ID 액세스 제어 구현

권한 관점에서 다른 사용자와 격리하려는 다양한 프롬프트 흐름에 대해 별도의 프로젝트 및 온라인 엔드포인트를 만듭니다. 각 프로젝트 및 관리되는 온라인 엔드포인트에 대해 별도의 관리 ID를 만듭니다. 프롬프트 흐름 작성자에게 필요한 프로젝트에만 액세스할 수 있도록 합니다.

작성 흐름과 같은 기능을 수행하기 위해 사용자를 Azure AI Studio 프로젝트에 온보딩하는 경우 필요한 리소스에 대한 최소 권한 역할 할당을 수행해야 합니다.

Machine Learning 역할 기반 액세스 역할

기본 아키텍처와 마찬가지로 시스템은 시스템 할당 관리 ID에 대한 역할 할당을 자동으로 만듭니다. 시스템은 사용할 수 있는 허브 및 프로젝트의 기능을 모르기 때문에 모든 잠재적 기능을 지원하는 역할 할당을 만듭니다. 자동으로 생성된 역할 할당은 사용 사례에 따라 프로비전 권한을 초과할 수 있습니다. 예를 들어 컨테이너 레지스트리의 허브에 할당된 '기여자' 역할이 있습니다. 여기서는 컨트롤 플레인에 대한 '읽기 권한자' 액세스만 필요할 수 있습니다. 최소 권한 목표를 위해 사용 권한을 추가로 제한해야 하는 경우 사용자 할당 ID를 사용해야 합니다. 이러한 역할 할당을 직접 만들고 유지 관리합니다.

필요한 모든 할당을 관리하는 유지 관리 부담 때문에 이 아키텍처는 절대 최소 권한 역할 할당보다 운영 우수성을 선호합니다. 테이블에 나열된 모든 할당을 만들어야 합니다.

관리 ID	범위	역할 할당
허브 관리 ID	참가자	리소스 그룹
허브 관리 ID	허브	Azure AI 관리자
허브 관리 ID	Container Registry	기여자
허브 관리 ID	Key Vault	기여자
허브 관리 ID	Key Vault	관리자
허브 관리 ID	스토리지 계정	판독기
허브 관리 ID	스토리지 계정	스토리지 계정 기여자
허브 관리 ID	스토리지 계정	Storage Blob 데이터 Contributor
허브 관리 ID	스토리지 계정	스토리지 파일 데이터 권한이 있는 기여자
허브 관리 ID	스토리지 계정	스토리지 테이블 데이터 기여자
프로젝트 관리 ID	프로젝트	Azure AI 관리자
프로젝트 관리 ID	Container Registry	기여자
프로젝트 관리 ID	Key Vault	기여자
프로젝트 관리 ID	Key Vault	관리자
프로젝트 관리 ID	스토리지 계정	판독기
프로젝트 관리 ID	스토리지 계정	스토리지 계정 기여자
프로젝트 관리 ID	스토리지 계정	Storage Blob 데이터 Contributor
프로젝트 관리 ID	스토리지 계정	스토리지 파일 데이터 권한이 있는 기여자
프로젝트 관리 ID	스토리지 계정	스토리지 테이블 데이터 기여자
온라인 엔드포인트 관리 ID	프로젝트	Azure Machine Learning 작업 영역 연결 비밀
온라인 엔드포인트 관리 ID	프로젝트	AzureML 메트릭 기록기
온라인 엔드포인트 관리 ID	Container Registry	ACRPull
온라인 엔드포인트 관리 ID	Azure OpenAI	Cognitive Services OpenAI 사용자
온라인 엔드포인트 관리 ID	스토리지 계정	Storage Blob 데이터 Contributor
온라인 엔드포인트 관리 ID	스토리지 계정	Storage Blob 데이터 읽기 권한자
App Service(프롬프트 흐름이 App Service에 배포되는 경우)	Azure OpenAI	Cognitive Services OpenAI 사용자
포털 사용자(프롬프트 흐름 개발)	Azure OpenAI	Cognitive Services OpenAI 사용자
포털 사용자(프롬프트 흐름 개발)	스토리지 계정	Storage Blob 데이터 기여자(조건부 액세스 사용)
포털 사용자(프롬프트 흐름 개발)	스토리지 계정	스토리지 파일 데이터 권한이 있는 기여자

AI Studio 허브에는 스토리지 계정 및 Container Registry와 같은 프로젝트 간에 공유되는 Azure 리소스가 있음을 이해하는 것이 중요합니다. 프로젝트의 하위 집합에만 액세스해야 하는 사용자가 있는 경우 리소스에 대한 최소 권한 액세스를 제공하기 위해 역할 할당 조건을 사용하는 것이 좋습니다. 예를 들어 Azure Storage의 Blob은 역할 할당 조건을 지원합니다. 컨테이너별로 권한을 할당하는 대신 프로젝트의 하위 집합에 액세스해야 하는 사용자의 경우 역할 액세스 조건을 사용하여 해당 프로젝트에서 사용하는 Blob 컨테이너에 대한 권한을 제한합니다. 각 프로젝트에는 해당 프로젝트에 사용되는 Blob 컨테이너의 이름에 대한 접두사 역할을 하는 고유한 GUID가 있습니다. 해당 GUID는 역할 할당 조건의 일부로 사용할 수 있습니다.

허브에는 허브 및 프로젝트 리소스를 만들고 관리하기 위해 허브 리소스 그룹에 대한 액세스 권한이 있어야 Contributor 합니다. 허브의 부작용은 리소스 그룹의 모든 리소스에 대한 제어 평면 액세스 권한이 있다는 것입니다. 허브 및 해당 프로젝트와 직접 관련되지 않은 모든 Azure 리소스는 별도의 리소스 그룹에 만들어야 합니다. 자체 관리형 Azure AI Studio Hub를 사용하여 워크로드 팀에 대해 최소한 두 개의 리소스 그룹을 만드는 것이 좋습니다. 허브, 해당 프로젝트 및 Azure 컨테이너 레지스트리, Key Vault 등과 같은 모든 직접 종속성을 포함할 하나의 리소스 그룹입니다. 워크로드의 다른 모든 항목을 포함할 하나의 리소스 그룹입니다.

워크로드의 다른 구성 요소에 의한 허브 작업(Container Registry, Storage 계정, Key Vault, Application Insights)에 필요한 Azure 리소스의 사용을 최소화하는 것이 좋습니다. 예를 들어 워크로드의 일부로 비밀을 저장해야 하는 경우 허브와 연결된 키 자격 증명 모음과 별도로 별도의 Key Vault를 만들어야 합니다. 허브 Key Vault는 허브 및 프로젝트 비밀을 저장하기 위해 허브에서만 사용해야 합니다.

각 고유 프로젝트에 대해 해당 종속성에 대한 역할 할당이 포털 사용자 및 관리되는 온라인 엔드포인트 관리 ID에 필요하지 않은 리소스에 대한 액세스를 제공하지 않는지 확인합니다. 예를 들어 Azure OpenAI에 Cognitive Services OpenAI User 대한 역할 할당은 해당 리소스에 대한 모든 배포에 대한 액세스 권한을 부여합니다. Azure OpenAI의 특정 모델 배포에 대한 역할 할당 액세스를 사용하여 흐름 작성자 또는 관리되는 온라인 엔드포인트 관리 ID를 제한할 수 있는 방법은 없습니다. 이와 같은 시나리오의 경우 지침은 프로젝트별로 Azure OpenAI 및 Azure AI Search와 같은 서비스를 배포하고, 흐름 작성자 또는 관리되는 온라인 엔드포인트 관리 ID에 액세스할 수 없어야 하는 서비스에 리소스를 배포하지 않는 것입니다. 예를 들어 프로젝트에 액세스해야 하는 Azure OpenAI 인스턴스 프로젝트에만 모델을 배포합니다. 프로젝트에 액세스해야 하는 프로젝트 Azure AI Search 인스턴스에만 인덱스를 배포합니다.

네트워킹

ID 기반 액세스와 함께 네트워크 보안은 OpenAI를 사용하는 기본 엔드투엔드 채팅 아키텍처의 핵심입니다. 높은 수준에서 네트워크 아키텍처는 다음을 보장합니다.

• 채팅 UI 트래픽에 대한 단일 보안 진입점.
• 네트워크 트래픽이 필터링됩니다.
• 전송 중인 데이터는 TLS(전송 계층 보안)를 사용하여 엔드투엔드로 암호화됩니다.
• Private Link를 사용하여 데이터 반출을 최소화하여 Azure에서 트래픽을 유지합니다.
• 네트워크 리소스는 네트워크 분할을 통해 논리적으로 그룹화되고 서로 격리됩니다.

네트워크 흐름

이 다이어그램의 두 흐름은 기준 App Service 웹 애플리케이션 아키텍처에서 다룹니다. 즉, 최종 사용자에서 채팅 UI로의 인바운드 흐름(1)과 App Service에서 Azure PaaS 서비스로의 흐름(2)입니다. 이 섹션에서는 Machine Learning 온라인 엔드포인트 흐름에 중점을 둡니다. 다음 흐름은 기준 App Service 웹 애플리케이션에서 실행되는 채팅 UI에서 Machine Learning 컴퓨팅에 배포된 흐름으로 이동합니다.

1. App Service 호스팅 채팅 UI의 호출은 프라이빗 엔드포인트를 통해 Machine Learning 온라인 엔드포인트로 라우팅됩니다.
2. 온라인 엔드포인트는 배포된 흐름을 실행하는 서버로 호출을 라우팅합니다. 온라인 엔드포인트는 부하 분산 장치와 라우터의 역할을 모두 수행합니다.
3. 배포된 흐름에 필요한 Azure PaaS 서비스에 대한 호출은 관리형 프라이빗 엔드포인트를 통해 라우팅됩니다.

Machine Learning으로 수신

이 아키텍처에서는 Machine Learning 작업 영역에 대한 공용 액세스를 사용할 수 없습니다. 아키텍처가 Machine Learning 작업 영역 구성에 대한 프라이빗 엔드포인트를 따르므로 사용자는 프라이빗 액세스를 통해 작업 영역에 액세스할 수 있습니다. 실제로 프라이빗 엔드포인트는 ID 기반 보안을 보완하기 위해 이 아키텍처 전체에서 사용됩니다. 예를 들어 App Service 호스팅 채팅 UI는 Machine Learning 엔드포인트를 포함하여 공용 인터넷에 노출되지 않는 PaaS 서비스에 연결할 수 있습니다.

흐름 작성을 위해 Machine Learning 작업 영역에 연결하는 데도 프라이빗 엔드포인트 액세스가 필요합니다.

다이어그램은 Azure Bastion을 통해 가상 머신 점프 상자에 연결하는 프롬프트 흐름 작성자를 보여줍니다. 이 점프 상자에서 작성자가 점프 상자와 동일한 네트워크의 프라이빗 엔드포인트를 통해 Machine Learning 작업 영역에 연결할 수 있습니다. ExpressRoute 또는 VPN Gateway 및 가상 네트워크 피어링을 통해 가상 네트워크에 연결할 수도 있습니다.

Azure AI Studio 관리형 가상 네트워크에서 Azure PaaS 서비스로 흐름

모든 아웃바운드 연결을 승인해야 하는 관리형 가상 네트워크 격리를 위해 Azure AI Studio 허브를 구성하는 것이 좋습니다. 이 아키텍처는 해당 권장 사항을 따릅니다. 승인된 아웃바운드 규칙에는 두 가지 유형이 있습니다. 필요한 아웃바운드 규칙은 컨테이너 레지스트리 및 스토리지와 같은 솔루션이 작동하는 데 필요한 리소스에 대한 것입니다. 사용자 정의 아웃바운드 규칙은 워크플로에서 사용할 Azure OpenAI 또는 AI Search와 같은 사용자 지정 리소스에 대한 것입니다. 사용자 정의 아웃바운드 규칙을 구성해야 합니다. 필요한 아웃바운드 규칙은 관리형 가상 네트워크를 만들 때 구성됩니다. 관리되는 가상 네트워크는 처음 사용할 때 주문형으로 배포되고 그 때부터 지속됩니다.

아웃바운드 규칙은 외부 퍼블릭 엔드포인트에 대한 프라이빗 엔드포인트, 서비스 태그 또는 FQDN(정규화된 도메인 이름)일 수 있습니다. 이 아키텍처에서는 Container Registry, Storage, Azure Key Vault, Azure OpenAI 및 AI Search와 같은 Azure 서비스에 대한 연결이 프라이빗 링크를 통해 연결됩니다. 이 아키텍처에는 없지만 FQDN 아웃바운드 규칙을 구성해야 하는 몇 가지 일반적인 작업은 pip 패키지를 다운로드하거나 GitHub 리포지토리를 복제하거나 외부 리포지토리에서 기본 컨테이너 이미지를 다운로드하는 것입니다.

가상 네트워크 분할 및 보안

이 아키텍처의 네트워크에는 다음과 같은 용도로 별도의 서브넷이 있습니다.

• Application Gateway

• App Service 통합 구성 요소

• 프라이빗 엔드포인트

• Azure Bastion

• 점프 박스 가상 머신

• 학습 및 점수 매기기 서브넷 - 둘 다 학습 및 추론과 관련된 고유한 컴퓨팅을 가져오기 위한 것입니다. 이 아키텍처에서는 학습을 수행하지 않고 관리형 컴퓨팅을 사용합니다.

• 점수 매기기

각 서브넷에는 해당 서브넷의 인바운드 및 아웃바운드 트래픽을 모두 필요한 것으로 제한하는 NSG(네트워크 보안 그룹)가 있습니다. 다음 표에서는 기준이 각 서브넷에 추가하는 NSG 규칙의 간소화된 보기를 보여 줍니다. 테이블은 규칙 이름과 함수를 제공합니다.

서브넷	인바운드	아웃바운드
snet-appGateway	채팅 UI 사용자 원본 IP(예: 공용 인터넷)에 대한 허용량과 서비스에 필요한 항목.	App Service 프라이빗 엔드포인트에 대한 액세스 및 서비스에 필요한 항목.
snet-PrivateEndpoints	가상 네트워크로부터의 트래픽만 허용합니다.	가상 네트워크로의 트래픽만 허용합니다.
snet-AppService	가상 네트워크로부터의 트래픽만 허용합니다.	프라이빗 엔드포인트 및 Azure Monitor에 대한 액세스를 허용합니다.
AzureBastionSubnet	NSG 액세스 및 Azure Bastion 작업의 지침을 참조하세요.	NSG 액세스 및 Azure Bastion 작업의 지침을 참조하세요.
snet-jumpbox	Azure Bastion 호스트 서브넷에서 인바운드 RDP(원격 데스크톱 프로토콜) 및 SSH를 허용합니다.	프라이빗 엔드포인트에 대한 액세스 허용
snet-agents	가상 네트워크로부터의 트래픽만 허용합니다.	가상 네트워크로의 트래픽만 허용합니다.
snet-training	가상 네트워크로부터의 트래픽만 허용합니다.	가상 네트워크로의 트래픽만 허용합니다.
snet-scoring	가상 네트워크로부터의 트래픽만 허용합니다.	가상 네트워크로의 트래픽만 허용합니다.

그 외의 모든 트래픽은 명시적으로 거부됩니다.

가상 네트워크 세분화 및 보안을 구현할 때 다음 사항을 고려합니다.

• 공용 IP 주소를 사용하는 애플리케이션 게이트웨이의 일부인 서브넷이 있는 가상 네트워크에 DDoS Protection을 사용하도록 설정합니다.

• 가능한 경우 모든 서브넷에 NSG를 추가합니다. 전체 솔루션 기능을 사용하도록 설정하는 가장 엄격한 규칙을 사용합니다.

• 애플리케이션 보안 그룹을 사용하여 NSG를 그룹화합니다. NSG를 그룹화하면 복잡한 환경에서 규칙을 더 쉽게 만들 수 있습니다.

키 회전

이 아키텍처에는 키 기반 인증을 사용하는 하나의 서비스인 Machine Learning 관리형 온라인 엔드포인트가 있습니다. 이 서비스에 키 기반 인증을 사용하므로 다음을 수행해야 합니다.

• 프롬프트 흐름 컨테이너를 호스팅하는 Azure Web App과 같은 권한 있는 클라이언트의 주문형 액세스를 위해 Key Vault와 같은 보안 저장소에 키를 저장합니다.

• 키 회전 전략을 구현합니다. 키를 수동으로 회전하는 경우 키 만료 정책을 만들고 Azure Policy를 사용하여 키가 회전되었는지 여부를 모니터링합니다.

OpenAI 모델 미세 조정

구현에서 OpenAI 모델을 미세 조정하는 경우 다음 지침을 고려합니다.

• 미세 조정을 위해 학습 데이터를 업로드하는 경우 고객 관리형 키를 사용하여 해당 데이터를 암호화하는 것이 좋습니다.

• Azure Blob Storage와 같은 저장소에 학습 데이터를 저장하는 경우 데이터 암호화에 고객 관리형 키, 데이터에 대한 액세스를 제어하는 관리 ID 및 데이터에 연결할 프라이빗 엔드포인트를 사용하는 것이 좋습니다.

정책을 통한 거버넌스

보안에 맞게 조정하려면 배포가 워크로드의 요구 사항에 맞게 조정되도록 Azure Policy 및 네트워크 정책을 사용하는 것이 좋습니다. 정책을 통해 플랫폼 자동화를 사용하면 수동 유효성 검사 단계의 부담을 줄이고 파이프라인이 무시되더라도 거버넌스를 보장합니다. 다음 보안 정책을 고려합니다.

• Azure AI 서비스 및 Key Vault와 같은 서비스에서 키 또는 기타 로컬 인증 액세스를 사용하지 않도록 설정합니다.
• 네트워크 액세스 규칙 또는 NSG의 특정 구성이 필요합니다.
• 고객 관리형 키 사용과 같은 암호화가 필요합니다.

Azure Key Vault에 대한 Azure AI Studio 역할 할당

Azure AI Studio 관리 ID에는 컨트롤 플레인(기여자) 및 데이터 평면(Key Vault 관리자) 역할 할당이 모두 필요합니다. 즉, 이 ID는 Azure Key Vault에 저장된 모든 비밀, 키 및 인증서에 대한 읽기 및 쓰기 액세스 권한이 있습니다. 워크로드에 Key Vault의 비밀, 키 또는 인증서에 액세스해야 하는 Azure AI Studio 이외의 서비스가 있는 경우 워크로드 또는 보안 팀은 해당 아티팩트 액세스 권한이 있는 Azure AI Studio 허브 관리 ID에 익숙하지 않을 수 있습니다. 이 경우 워크로드의 다른 부분에 적합한 Azure AI Studio 허브 및 기타 Azure Key Vault 인스턴스에 대해 Key Vault 인스턴스를 배포하는 것이 좋습니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화를 위한 디자인 검토 검사 목록을 참조하세요.

이 시나리오에 대한 가격 책정 예제를 보려면 Azure 가격 계산기를 사용합니다. 이 예제에는 아키텍처에 포함된 구성 요소만 포함되므로 사용량과 일치하도록 예제를 사용자 지정해야 합니다. 이 시나리오에서 가장 비용이 많이 드는 구성 요소는 DDoS Protection 및 관리되는 온라인 엔드포인트의 일부로 배포되는 방화벽입니다. 다른 주목할 만한 비용은 채팅 UI 및 프롬프트 흐름 컴퓨팅 및 AI Search입니다. 이러한 리소스를 최적화하여 가장 많은 비용을 절감합니다.

Compute

프롬프트 흐름은 실행 파일을 호스트하는 여러 옵션을 지원합니다. 옵션에는 Machine Learning, AKS, App Service 및 Azure Kubernetes Service의 관리되는 온라인 엔드포인트가 포함됩니다. 이러한 각 옵션에는 고유한 청구 모델이 있습니다. 컴퓨팅 선택은 솔루션의 전체 비용에 영향을 줍니다.

Azure OpenAI

Azure OpenAI는 사용량 기준 서비스이며, 사용량 기준 서비스와 마찬가지로 공급에 대한 수요를 제어하는 것이 기본 비용 제어입니다. 특히 Azure OpenAI에서 이 작업을 수행하려면 다음 방법의 조합을 사용해야 합니다.

• 클라이언트를 제어합니다. 클라이언트 요청은 소비 모델의 기본 비용 원본이므로 클라이언트 동작을 제어하는 것이 중요합니다. 모든 클라이언트는 다음을 수행해야 합니다.

  • 승인되어야 합니다. 무료 액세스를 지원하는 방식으로 서비스를 노출하지 않도록 합니다. 키 또는 RBAC(역할 기반 액세스 제어)와 같은 네트워크 및 ID 제어를 통해 액세스를 제한합니다.

  • 자체 제어해야 합니다. 클라이언트가 API 호출에서 제공하는 토큰 제한 제약 조건(예: max_tokens 및 max_completions)을 사용해야 합니다.

  • 가능한 경우 일괄 처리를 사용합니다. 클라이언트를 검토하여 프롬프트를 적절하게 일괄 처리하고 있는지 확인합니다.

  • 프롬프트 입력 및 응답 길이를 최적화합니다. 프롬프트가 길어질수록 더 많은 토큰이 사용되어 비용이 발생하지만 충분한 컨텍스트가 누락된 프롬프트는 모델이 좋은 결과를 생성하는 데 도움이 되지 않습니다. 모델이 유용한 응답을 생성할 수 있도록 충분한 컨텍스트를 제공하는 간결한 프롬프트를 만듭니다. 마찬가지로 응답 길이 제한을 최적화해야 합니다.

• Azure OpenAI 플레이그라운드 사용은 프로덕션 비용이 발생하지 않도록 필요한 경우 사전 프로덕션 인스턴스에 사용해야 합니다.

• 올바른 AI 모델을 선택합니다. 모델 선택은 Azure OpenAI의 전체 비용에서도 큰 역할을 합니다. 모든 모델에는 강점과 약점이 있으며 개별적으로 가격이 책정됩니다. 사용 사례에 올바른 모델을 사용하여 저렴한 모델이 허용 가능한 결과를 생성할 때 더 비싼 모델에 과도하게 지출하지 않도록 합니다. 이 채팅 참조 구현에서 GPT 3.5 터보는 충분한 결과를 달성하면서 모델 배포 비용의 크기를 절약하기 위해 GPT-4를 통해 선택되었습니다.

• 청구 중단점을 이해합니다. 미세 조정은 시간당으로 청구됩니다. 가장 효율적이려면 시간당 사용 가능한 시간을 최대한 많이 사용하여 다음 청구 기간으로 넘어가지 않도록 하면서 미세 조정 결과를 개선하려고 합니다. 마찬가지로 이미지 생성에서 이미지 100개에 대한 비용은 한 이미지에 대한 비용과 동일합니다. 가격 브레이크 포인트를 최대화하여 이점을 얻을 수 있습니다.

• 청구 모델을 이해합니다. Azure OpenAI는 프로비전된 처리량 제품을 통해 약정 기반 청구 모델에서도 사용할 수 있습니다. 예측 가능한 사용 패턴이 있으면 사용량 볼륨에서 비용 효율적인 경우 이 사전 구매 청구 모델로 전환하는 것이 좋습니다.

• 프로비저닝 제한을 설정합니다. 모든 프로비저닝 할당량이 모델별로 워크로드의 일부가 될 것으로 예상되는 모델에만 할당되었는지 확인합니다. 동적 할당량을 사용하는 동안 이미 배포된 모델에 대한 처리량은 프로비전된 할당량으로 제한되지 않습니다. 할당량은 비용에 직접 매핑되지 않으며 해당 비용은 다를 수 있습니다.

• 종량제 사용량을 모니터링합니다. 종량제 가격을 사용하는 경우 TPM 및 RPM의 사용량을 모니터링합니다. 이 정보를 사용하여 사용할 모델과 같은 아키텍처 디자인 결정을 알리고 프롬프트 크기를 최적화합니다.

• 프로비전된 처리량 사용량을 모니터링합니다. 프로비전된 처리량을 사용하는 경우 프로비전 관리 사용량을 모니터링하여 구입한 프로비전된 처리량을 사용하지 않도록 합니다.

• Cost Management. OpenAI에서 비용 관리 기능 사용에 대한 지침에 따라 비용을 모니터링하고, 예산을 설정하여 비용을 관리하고, 관련자에게 위험이나 변칙을 알리는 경고를 만듭니다.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 Operational Excellence에 대한 디자인 검토 검사 목록을 참조하세요.

기본 제공 프롬프트 흐름 런타임

기본 아키텍처와 마찬가지로 이 아키텍처는 자동 런타임을 사용하여 운영 부담을 최소화합니다. 자동 런타임은 Machine Learning 내에서 컴퓨팅 관리를 간소화하고 프롬프트 흐름 구성의 대부분을 실행 중인 애플리케이션의 requirements.txt 파일 및 flow.dag.yaml 구성에 위임하는 서버리스 컴퓨팅 옵션입니다. 이렇게 하면 낮은 유지 관리, 임시 및 애플리케이션 기반이 선택됩니다. 이 아키텍처와 같이 컴퓨팅 인스턴스 런타임 또는 외부화된 컴퓨팅을 사용하려면 컴퓨팅의 더 많은 워크로드 팀 관리 수명 주기가 필요하며 워크로드 요구 사항이 자동 런타임 옵션의 구성 기능을 초과하는 경우 선택해야 합니다.

모니터링

기본 아키텍처와 마찬가지로 진단은 모든 서비스에 대해 구성됩니다. App Service를 제외한 모든 서비스는 모든 로그를 캡처하도록 구성됩니다. App Service는 AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs 및 AppServicePlatformLogs를 캡처하도록 구성됩니다. 프로덕션 환경에서는 모든 로그가 과도할 수 있습니다. 운영 요구 사항에 맞게 로그 스트림을 조정합니다. 이 아키텍처의 경우 관심 있는 Azure AI Studio 프로젝트에서 사용하는 Azure Machine Learning 로그에는 AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent 및 AmlModelsEvent가 포함됩니다.

Azure Monitor 기준 경고에 있는 것과 같이 이 아키텍처의 리소스에 대한 사용자 지정 경고 빌드를 평가합니다. 예시:

• Container Registry 경고
• Machine Learning 및 Azure OpenAI 경고
• Azure Web Apps 경고

Azure OpenAI 모델 배포에 대한 토큰 사용을 추적해야 합니다. 이 아키텍처에서 프롬프트 흐름은 Azure 애플리케이션 Insights와의 통합을 통해 토큰 사용량을 추적합니다.

언어 모델 작업

이 아키텍처와 같은 Azure OpenAI 기반 채팅 솔루션의 배포는 Azure DevOps 및 GitHub를 사용하는 프롬프트 흐름이 있는 GenAIOps의 지침을 따라야 합니다. 또한 CI/CD(연속 통합 및 지속적인 업데이트) 및 네트워크 보안 아키텍처에 대한 모범 사례를 고려해야 합니다. 다음 지침에서는 GenAIOps 권장 사항에 따라 흐름 및 관련 인프라의 구현을 다룹니다. 이 배포 지침에는 가용성이 높은 기준 영역 중복 웹 애플리케이션 아키텍처에서 변경되지 않은 프런트 엔드 애플리케이션 요소가 포함되지 않습니다.

개발

프롬프트 흐름은 Azure AI Studio 또는 Visual Studio Code 확장을 통해 브라우저 기반 제작 환경을 모두 제공합니다. 두 옵션 모두 흐름 코드를 파일로 저장합니다. Azure AI Studio를 사용하는 경우 파일은 Storage 계정에 저장됩니다. Microsoft Visual Studio Code에서 작업하는 경우 파일은 로컬 파일 시스템에 저장됩니다.

공동 개발 모범 사례를 따르려면 GitHub와 같은 온라인 소스 코드 리포지토리에서 원본 파일을 유지 관리해야 합니다. 이 방법을 사용하면 모든 코드 변경 내용 추적, 흐름 작성자 간의 공동 작업 및 모든 코드 변경 내용을 테스트하고 유효성을 검사하는 배포 흐름과의 통합을 쉽게 추적할 수 있습니다.

엔터프라이즈 개발의 경우 개발을 위해 Microsoft Visual Studio Code 확장 및 프롬프트 흐름 SDK/CLI를 사용합니다. 프롬프트 흐름 작성자는 Microsoft Visual Studio Code에서 흐름을 빌드 및 테스트하고 로컬로 저장된 파일을 온라인 소스 제어 시스템 및 파이프라인과 통합할 수 있습니다. 브라우저 기반 환경은 예비 개발에 적합하지만 일부 작업에서는 소스 제어 시스템과 통합할 수 있습니다. 흐름 폴더는 Files 패널의 흐름 페이지에서 다운로드하고 압축을 풀고 소스 제어 시스템으로 푸시할 수 있습니다.

평가

다른 소프트웨어 아티팩트를 테스트하는 것처럼 채팅 애플리케이션에서 사용되는 흐름을 테스트합니다. 언어 모델 출력에 대해 "올바른" 단일 답변을 지정하고 어설션하는 것은 어려운 일이지만 언어 모델 자체를 사용하여 응답을 평가할 수 있습니다. 언어 모델 흐름에 대한 다음과 같은 자동화된 평가를 구현하는 것이 좋습니다.

• 분류 정확도: 언어 모델이 "올바른" 또는 "잘못된" 점수를 제공하는지 여부를 평가하고 결과를 집계하여 정확도 등급을 생성합니다.

• 일관성: 모델의 예측 답변에 있는 문장이 얼마나 잘 쓰여지고 서로 일관되게 연결되는지 평가합니다.

• 유창성: 문법 및 언어 정확도에 대한 모델의 예측 답변을 평가합니다.

• 컨텍스트에 대한 근거: 미리 구성된 컨텍스트를 기반으로 모델의 예측 답변이 얼마나 잘 계산되는지 평가합니다. 언어 모델 응답이 올바른 경우에도 지정된 컨텍스트에 대해 유효성을 검사할 수 없는 경우 이러한 응답은 접지되지 않습니다.

• 관련성: 모델의 예측 답변이 질문과 얼마나 잘 일치하는지 평가합니다.

자동화된 평가를 구현할 때 다음 지침을 고려합니다.

• 평가에서 점수를 생성하고 미리 정의된 성공 임계값에 대해 측정합니다. 이러한 점수를 사용하여 파이프라인에서 테스트 통과/실패를 보고합니다.

• 이러한 테스트 중 일부는 질문, 컨텍스트 및 지상 진리의 미리 구성된 데이터 입력이 필요합니다.

• 테스트 결과가 신뢰할 수 있도록 충분한 질문-답변 쌍을 포함하며, 최소 100~150쌍이 권장됩니다. 이러한 질문-답변 쌍을 "골든 데이터 세트"라고 합니다. 데이터 세트의 크기와 도메인에 따라 더 많은 모집단이 필요할 수 있습니다.

• 언어 모델을 사용하여 골든 데이터 세트의 데이터를 생성하지 않도록 합니다.

배포 흐름

1. 프롬프트 엔지니어/데이터 과학자는 특정 작업이나 기능을 담당하는 기능 분기를 엽니다. 프롬프트 엔지니어/데이터 과학자는 Microsoft Visual Studio Code의 프롬프트 흐름을 사용하여 흐름을 반복하고, 주기적으로 변경 내용을 커밋하고 해당 변경 내용을 기능 분기에 푸시합니다.

2. 로컬 개발과 실험이 완료되면, 프롬프트 엔지니어/데이터 과학자는 기능 분기에서 기본 분기로 끌어오기 요청을 엽니다. PR(끌어오기 요청)은 PR 파이프라인을 트리거합니다. 이 파이프라인은 다음을 포함하는 빠른 품질 검사를 실행합니다.

   • 실험 흐름 실행
   • 구성된 단위 테스트 실행
   • 코드베이스의 컴파일
   • 정적 코드 분석

3. 파이프라인에는 병합하기 전에 최소 한 명의 팀 멤버가 PR을 수동으로 승인해야 하는 단계가 포함될 수 있습니다. 승인자는 커미터가 될 수 없으며, 프롬프트 흐름에 대한 전문 지식과 프로젝트 요구 사항에 대한 익숙함이 필요합니다. PR이 승인되지 않으면 병합이 차단됩니다. PR이 승인되거나 승인 단계가 없으면 기능 분기는 기본 분기에 병합됩니다.

4. 기본 분기에 병합하면 개발 환경에 대한 빌드 및 릴리스 프로세스가 시작됩니다. 특별한 사항

   1. CI 파이프라인은 기본 분기로 병합되어 트리거됩니다. CI 파이프라인은 PR 파이프라인에서 수행된 모든 단계를 수행하고 다음 단계를 수행합니다.
   • 실험 흐름
   • 평가 흐름
   • 변경 내용이 검색되면 Machine Learning 레지스트리에 흐름을 등록합니다.
   1. CD 파이프라인은 CI 파이프라인이 완료된 후 트리거됩니다. 이 흐름은 다음 단계를 수행합니다.
   • Machine Learning 레지스트리에서 Machine Learning 온라인 엔드포인트로 흐름을 배포합니다.
   • 온라인 엔드포인트를 대상으로 하는 통합 테스트를 실행합니다.
   • 온라인 엔드포인트를 대상으로 하는 스모크 테스트를 실행합니다.

5. 릴리스 승격 프로세스에는 승인 프로세스가 기본 제공되어 있습니다. 승인 후 4.a 단계에 설명된 CI 및 CD 프로세스가 진행됩니다. & 4.b.는 테스트 환경을 대상으로 반복됩니다. a. 및 b. 단계는 동일하지만, 테스트 환경에서 스모크 테스트 후에 사용자 승인 테스트가 실행된다는 점이 다릅니다.

6. 4.a 단계에 설명된 CI 및 CD 프로세스 & 4.b.는 테스트 환경이 검증되고 승인된 후, 프로덕션 환경으로 릴리스를 승격하기 위해 실행됩니다.

7. 실제 환경에 릴리스한 후에는 성능 메트릭을 모니터링하고 배포된 언어 모델을 평가하는 운영 작업이 진행됩니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.

   • 데이터 드리프트 검색
   • 인프라 관찰
   • 비용 관리
   • 관련자에게 모델의 성능 전달

배포 지침

Machine Learning 엔드포인트를 사용하여 프로덕션에 릴리스할 때 유연성을 가능하게 하는 방식으로 모델을 배포할 수 있습니다. 최상의 모델 성능과 품질을 보장하려면 다음 전략을 고려하세요.

• 파란색/녹색 배포: 이 전략을 사용하면 모든 트래픽을 새 배포로 전달하기 전에 제한된 사용자 또는 요청 그룹에 새 버전의 웹 서비스를 안전하게 배포할 수 있습니다.

• A/B 테스트: 파란색/녹색 배포는 변경 내용을 안전하게 롤아웃하는 데 효과적일 뿐만 아니라 사용자의 하위 집합이 변경의 영향을 평가할 수 있는 새 동작을 배포하는 데도 사용할 수 있습니다.

• 파이프라인에서 프롬프트 흐름의 일부인 Python 파일의 린팅을 포함합니다. 린팅은 스타일 표준, 오류, 코드 복잡성, 사용되지 않는 가져오기 및 변수 명명 준수를 확인합니다.

• 네트워크 격리 Machine Learning 작업 영역에 흐름을 배포하는 경우 자체 호스팅 에이전트를 사용하여 Azure 리소스에 아티팩트를 배포합니다.

• Machine Learning 모델 레지스트리는 모델이 변경된 경우에만 업데이트해야 합니다.

• 언어 모델, 흐름 및 클라이언트 UI를 느슨하게 결합해야 합니다. 흐름 및 클라이언트 UI에 대한 업데이트는 모델에 영향을 주지 않고 수행할 수 있고, 그 반대의 경우도 마찬가지입니다.

• 여러 흐름을 개발하고 배포할 때 각 흐름에는 자체 수명 주기가 있어야 하며, 이를 통해 실험에서 프로덕션으로 흐름을 승격할 때 느슨하게 결합된 환경을 사용할 수 있습니다.

인프라

기준 Azure OpenAI 엔드투엔드 채팅 구성 요소를 배포할 때 프로비전된 서비스 중 일부는 아키텍처 내에서 기본적이고 영구적인 반면, 다른 구성 요소는 본질적으로 더 임시적인 반면, 해당 존재는 배포에 연결됩니다. 또한 관리되는 가상 네트워크는 기본이지만 몇 가지 고려 사항으로 이어지는 컴퓨팅 인스턴스를 만들 때 자동으로 프로비전됩니다.

기본 구성 요소

이 아키텍처의 일부 구성 요소는 개별 프롬프트 흐름 또는 모델 배포를 넘어 확장되는 수명 주기와 함께 존재합니다. 이러한 리소스는 일반적으로 워크로드 팀에서 기본 배포의 일부로 한 번 배포되며 프롬프트 흐름 또는 모델 배포에 대한 새 업데이트, 제거 또는 업데이트와 별도로 유지 관리됩니다.

• Machine Learning 작업 영역
• Machine Learning 작업 영역에 대한 스토리지 계정
• Container Registry
• AI Search
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• 점프 상자용 Azure Virtual Machine

임시 구성 요소

일부 Azure 리소스는 특정 프롬프트 흐름의 디자인과 더 긴밀하게 결합됩니다. 이 방법을 사용하면 이러한 리소스를 구성 요소의 수명 주기에 바인딩하고 이 아키텍처에서 임시로 사용할 수 있습니다. Azure 리소스는 흐름이 추가 또는 제거되거나 새 모델이 도입될 때와 같이 워크로드가 진화할 때 영향을 받습니다. 이러한 리소스는 다시 만들어지고 이전 인스턴스는 제거됩니다. 이러한 리소스 중 일부는 직접 Azure 리소스이고 일부는 포함된 서비스 내의 데이터 평면 매니페스트입니다.

• 변경된 경우 Machine Learning 모델 레지스트리의 모델을 CD 파이프라인의 일부로 업데이트해야 합니다.

• 컨테이너 이미지는 CD 파이프라인의 일부로 컨테이너 레지스트리에서 업데이트해야 합니다.

• Machine Learning 엔드포인트는 배포가 존재하지 않는 엔드포인트를 참조하는 경우 프롬프트 흐름이 배포될 때 만들어집니다. 공용 액세스를 끄려면 해당 엔드포인트를 업데이트해야 합니다.

• Machine Learning 엔드포인트의 배포는 흐름이 배포되거나 삭제될 때 업데이트됩니다.

• 새 엔드포인트를 만들 때 클라이언트 UI의 키 자격 증명 모음을 엔드포인트에 대한 키로 업데이트해야 합니다.

주문형 관리형 가상 네트워크

관리형 가상 네트워크는 컴퓨팅 인스턴스를 처음 만들 때 자동으로 프로비전됩니다. 인프라를 코드로 사용하여 허브를 배포하고 Bicep에 AI Studio 컴퓨팅 리소스가 없는 경우 관리되는 가상 네트워크가 배포되지 않으며 Azure AI Studio에 연결할 때 오류가 발생합니다. IaC 배포 후 관리형 가상 네트워크를 수동으로 프로비전하려면 일회성 작업을 수행해야 합니다.

리소스 조직

허브가 워크로드 팀이 아닌 다른 팀에서 중앙에서 소유하는 시나리오가 있는 경우 프로젝트를 별도의 리소스 그룹에 배포하도록 선택할 수 있습니다. 인프라를 코드로 사용하는 경우 Bicep에서 다른 리소스 그룹을 설정하여 이를 수행할 수 있습니다. 포털을 사용하는 경우 프로젝트를 만들려는 리소스 그룹에 따라 workspaceHubConfig 속성을 설정할 defaultWorkspaceResourceGroup 수 있습니다.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성에 대한 디자인 검토 검사 목록을 참조하세요.

이 섹션에서는 Azure Search, Azure OpenAI 및 Machine Learning의 관점에서 성능 효율성을 설명합니다.

Azure Search - 성능 효율성

지침에 따라 AI Search의 성능을 분석합니다.

Azure OpenAI - 성능 효율성

• 애플리케이션에 프로비전된 처리량 또는 공유 호스팅 또는 사용량 모델이 필요한지 확인합니다. 프로비전된 처리량은 OpenAI 모델 배포를 위한 예약된 처리 용량을 보장하여 모델에 대한 예측 가능한 성능과 처리량을 제공합니다. 이 청구 모델은 공유 호스팅 또는 소비, 모델과 다릅니다. 소비 모델은 최선의 노력이며 플랫폼에서 노이지 네이버 또는 기타 스트레스 요소의 영향을 받을 수 있습니다.

• 프로비전된 처리량에 대한 프로비전 관리 사용률을 모니터링합니다.

Machine Learning - 성능 효율성

Machine Learning 온라인 엔드포인트에 배포하는 경우:

• 온라인 엔드포인트를 자동크기조정하는 방법에 대한 지침을 따릅니다. 특히 사용량이 적은 기간에 과도한 과잉 프로비전 없이 수요와 긴밀하게 일치하도록 하려면 이 작업을 수행합니다.

• 성능 목표를 충족하기 위해 온라인 엔드포인트에 적합한 가상 머신 SKU를 선택합니다. 더 낮은 인스턴스 수와 더 큰 SKU와 더 큰 인스턴스 수 및 더 작은 SKU의 성능을 테스트하여 최적의 구성을 찾습니다.

시나리오 배포

참조 구현을 배포하고 실행하려면 OpenAI 엔드투엔드 기준 참조 구현의 단계를 따릅니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

• Rob Bagby | 패턴 & 사례 - Microsoft
• Freddy Ayala | 클라우드 솔루션 아키텍트 - Microsoft
• Prabal Deb | 선임 소프트웨어 엔지니어 - Microsoft
• Raouf Aliouat | 소프트웨어 엔지니어 II - Microsoft
• Ritesh Modi | 수석 소프트웨어 엔지니어 - Microsoft
• Ryan Pfalz | 선임 솔루션 설계자 - Microsoft

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

관련 참고 자료

• Azure OpenAI
• Azure OpenAI 언어 모델
• Azure AI Studio의 프롬프트 흐름
• 작업 영역 관리형 가상 네트워크 격리
• Machine Learning 작업 영역용 프라이빗 엔드포인트 구성
• 콘텐츠 필터링