Azure Machine Learning 유추 라우터 및 연결 요구 사항

아티클
09/03/2024

Azure Machine Learning 유추 라우터는 Kubernetes 클러스터를 사용한 실시간 유추를 위한 중요한 구성 요소입니다. 이 문서에서는 다음에 대해 알아볼 수 있습니다.

Azure Machine Learning 유추 라우터란?
자동 크기 조정 작동 방식
유추 요청 성능(초당 요청 수 및 대기 시간)을 구성하고 충족하는 방법
AKS 추론 클러스터에 대한 연결 요구 사항

Azure Machine Learning 유추 라우터란?

Azure Machine Learning 유추 라우터는 Azure Machine Learning 확장 배포 시 AKS 또는 Arc Kubernetes 클러스터에 배포되는 프런트 엔드 구성 요소(azureml-fe)입니다. 다음과 같은 기능이 있습니다.

클러스터 부하 분산 장치 또는 수신 컨트롤러에서 들어오는 유추 요청을 해당 모델 Pod로 라우팅합니다.
스마트 조정 라우팅을 사용하여 들어오는 모든 유추 요청의 부하를 분산합니다.
모델 Pod 자동 크기 조정을 관리합니다.
내결함성 및 장애 조치(failover) 기능을 통해 중요한 비즈니스 애플리케이션에 대해 유추 요청이 항상 제공되도록 합니다.

다음 단계는 프런트 엔드에서 요청을 처리하는 방법입니다.

클라이언트에서 요청을 부하 분산 장치에 보냅니다.
부하 분산 장치에서 프런트 엔드 중 하나에 보냅니다.
프런트 엔드에서 서비스에 대한 서비스 라우터(코디네이터 역할을 하는 프런트 엔드 인스턴스)를 찾습니다.
서비스 라우터에서 백 엔드를 선택하여 프런트 엔드에 반환합니다.
프런트 엔드에서 요청을 백 엔드에 전달합니다.
요청이 처리되면 백 엔드에서 응답을 프런트 엔드 구성 요소에 보냅니다.
프런트 엔드에서 응답을 클라이언트에 다시 전파합니다.
프런트 엔드에서 백 엔드가 처리를 완료했으며 다른 요청에 사용할 수 있음을 서비스 라우터에 알립니다.

다음 다이어그램에서는 이러한 흐름을 보여 줍니다.

구성 요소 간의 요청 흐름을 보여 주는 다이어그램

위의 다이어그램에서 볼 수 있듯이 기본적으로 3개의 azureml-fe 인스턴스는 Azure Machine Learning 확장 배포 중에 만들어지며, 하나의 인스턴스는 조정 역할을 하고 다른 인스턴스는 들어오는 유추 요청을 처리합니다. 조정 인스턴스는 모델 Pod에 대한 모든 정보를 사용하여 들어오는 요청을 처리할 모델 Pod를 결정하는 반면, 제공되는 azureml-fe 인스턴스는 요청을 선택한 모델 Pod로 라우팅하고 원래 사용자에게 응답을 다시 전파합니다.

자동 확장

Azure Machine Learning 유추 라우터는 Kubernetes 클러스터의 모든 모델 배포에 대한 자동 크기 조정을 처리합니다. 모든 유추 요청이 여기를 거치기 때문에, 여기에는 배포된 모델을 자동으로 스케일링하는 데 필요한 데이터가 있습니다.

Important

모델 배포에 Kubernetes HPA(Horizontal Pod Autoscaler)를 사용하도록 설정하지 마십시오. 그러면 두 가지 자동 스케일링 구성 요소가 서로 경쟁하게 됩니다. Azureml-fe는 Azure Machine Learning에 의해 배포된 모델을 자동 스케일링하도록 설계되었으며, HPA는 CPU 사용량 또는 사용자 지정 메트릭 구성과 같은 일반 메트릭에서 모델 사용률을 추측하거나 대략적으로 추정해야 합니다.
Azureml-fe는 AKS 클러스터의 노드 수를 스케일링하지 않습니다. 예상치 못한 비용 증가로 이어질 수 있기 때문입니다. 대신 물리적 클러스터 경계 내에서 모델의 복제본 수를 스케일링합니다. 클러스터 내 노드 수를 스케일링해야 하는 경우 클러스터를 수동으로 스케일링하거나 AKS 클러스터 자동 스케일러를 구성할 수 있습니다.

자동 크기 조정은 배포 YAML의 scale_settings 속성으로 제어할 수 있습니다. 다음 예는 자동 스케일링을 사용하도록 설정하는 방법을 보여줍니다.

# deployment yaml
# other properties skipped
scale_setting:
  type: target_utilization
  min_instances: 3
  max_instances: 15
  target_utilization_percentage: 70
  polling_interval: 10
# other deployment properties continue

스케일 업 또는 스케일 다운 결정은 utilization of the current container replicas를 기반으로 합니다.

utilization_percentage = (The number of replicas that are busy processing a request + The number of requests queued in azureml-fe) / The total number of current replicas

이 수가 target_utilization_percentage을 초과하면 더 많은 복제본이 생성됩니다. 이보다 낮으면 복제본이 감소됩니다. 기본적으로 목표 사용률은 70%입니다.

복제본 추가에 대한 결정은 열성적이고 빠릅니다(약 1초). 복제본 제거에 대한 결정은 보수적입니다(약 1분).

예를 들어 모델 서비스를 배포하고 많은 인스턴스(Pod/복제본)를 알려고 하는 경우 대상 RPS(초당 요청 수) 및 대상 응답 시간에 대해 구성해야 합니다. 필요한 복제본은 다음 코드를 사용하여 계산할 수 있습니다.

from math import ceil
# target requests per second
targetRps = 20
# time to process the request (in seconds)
reqTime = 10
# Maximum requests per container
maxReqPerContainer = 1
# target_utilization. 70% in this example
targetUtilization = .7

concurrentRequests = targetRps * reqTime / targetUtilization

# Number of container replicas
replicas = ceil(concurrentRequests / maxReqPerContainer)

azureml-fe의 성능

azureml-fe는 평균 3ms, 99% 백분위수에서 15ms를 초과하지 않는 오버헤드를 갖고 양호한 대기 시간으로 5,000 QPS(초당 요청 수)에 도달할 수 있습니다.

참고 항목

RPS 요구 사항이 10K보다 높은 경우 다음 옵션을 고려합니다.

azureml-fe Pod에 대한 리소스 요청/제한을 늘립니다. 기본적으로 2개의 vCPU 및 1.2G 메모리 요청/제한이 있습니다.
azureml-fe의 인스턴스 수를 늘립니다. 기본적으로 Azure Machine Learning은 클러스터당 3개 또는 1개의 azureml-fe 인스턴스를 만듭니다.
- 이 인스턴스 수는 Azure Machine Learning 확장의 inferenceRouterHA 구성에 따라 다릅니다.
- 확장이 업그레이드되면 구성된 값으로 덮어쓰게 되므로 증가된 인스턴스 수를 유지할 수 없습니다.
Microsoft 전문가에게 문의하여 도움을 받습니다.

AKS 추론 클러스터에 대한 연결 요구 사항 이해

AKS 클러스터는 다음 두 네트워크 모델 중 하나를 사용하여 배포됩니다.

Kubenet 네트워킹 - 네트워크 리소스는 일반적으로 AKS 클러스터가 배포될 때 만들어지고 구성됩니다.
Azure CNI(Container Networking Interface) 네트워킹 - AKS 클러스터가 기존 가상 네트워크 리소스 및 구성에 연결됩니다.

Kubenet 네트워킹의 경우 Azure Machine Learning 서비스에 적절하게 네트워크를 만들고 구성합니다. CNI 네트워킹의 경우 연결 요구 사항을 이해하고 AKS 추론에 대한 DNS 확인 및 아웃바운드 연결을 확인해야 합니다. 예를 들어, 방화벽을 사용하여 네트워크 트래픽을 차단하는 경우 추가 단계가 필요할 수 있습니다.

다음 다이어그램에서는 AKS 추론에 대한 연결 요구 사항을 보여 줍니다. 검은색 화살표는 실제 통신을 나타내고 파란색 화살표는 도메인 이름을 나타냅니다. 이러한 호스트에 대한 항목을 방화벽 또는 사용자 지정 DNS 서버에 추가해야 할 수 있습니다.

Azure Kubernetes Services에서 유추하기 위한 연결 요구 사항의 다이어그램

일반적인 AKS 연결 요구 사항은 Azure Kubernetes Service에서 클러스터 노드의 송신 트래픽 제어를 참조하세요.

방화벽 뒤에서 Azure Machine Learning Services에 액세스하려면 인바운드 및 아웃바운드 네트워크 트래픽 구성을 참조하세요.

전체 DNS 확인 요구 사항

기존 VNet 내에서 DNS 확인은 사용자가 제어합니다. 예를 들면 방화벽 또는 사용자 지정 DNS 서버가 있습니다. 다음 호스트에 연결할 수 있어야 합니다.

호스트 이름	사용 대상
`<cluster>.hcp.<region>.azmk8s.io`	AKS API 서버
`mcr.microsoft.com`	MCR(Microsoft Container Registry)
`<ACR name>.azurecr.io`	ACR(Azure Container Registry)
`<account>.blob.core.windows.net`	Azure Storage 계정(Blob 스토리지)
`api.azureml.ms`	Microsoft Entra 인증
`ingest-vienna<region>.kusto.windows.net`	원격 분석 업로드를 위한 Kusto 엔드포인트

연결 요구 사항(시간순): 클러스터 만들기부터 모델 배포까지

azureml-fe가 배포된 직후 시작이 시도되며, 그러려면 다음 작업이 필요합니다.

AKS API 서버에 대한 DNS 확인
AKS API 서버를 쿼리하여 다른 인스턴스 검색(여러 Pod 서비스임)
다른 인스턴스에 연결

azureml-fe가 시작된 후 제대로 작동하려면 다음 연결이 필요합니다.

Azure Storage에 연결하여 동적 구성 다운로드
Microsoft Entra 인증 서버 api.azureml.ms에 대한 DNS를 확인하고 배포된 서비스가 Microsoft Entra 인증을 사용할 때 이와 통신합니다.
AKS API 서버를 쿼리하여 배포된 모델 검색
배포된 모델 POD와 통신

모델 배포 시 성공적인 모델 배포를 위해 AKS 노드는 다음을 수행할 수 있어야 합니다.

고객의 ACR에 대한 DNS 확인
고객의 ACR에서 이미지 다운로드
모델이 저장된 Azure Blob에 대한 DNS 확인
Azure Blob에서 모델 다운로드

모델이 배포되고 서비스가 시작되면 azureml-fe는 AKS API를 사용하여 모델을 자동으로 검색하고 요청을 라우팅할 준비가 됩니다. 모델 POD와 통신할 수 있어야 합니다.

참고 항목

배포된 모델에 연결이 필요한 경우(예: 외부 데이터베이스 또는 기타 REST 서비스 쿼리, BLOB 다운로드 등) 해당 서비스에 대한 DNS 확인 및 아웃바운드 통신을 모두 사용하도록 설정해야 합니다.

다음을 통해 공유