부하 테스트를 위한 모범 사례 Amazon SageMaker 실시간 추론 엔드포인트

아마존 세이지 메이커 완전 관리형 기계 학습(ML) 서비스입니다. SageMaker를 사용하면 데이터 과학자와 개발자가 ML 모델을 빠르고 쉽게 구축 및 교육한 다음 프로덕션 준비가 된 호스팅 환경에 직접 배포할 수 있습니다. 탐색 및 분석을 위해 데이터 소스에 쉽게 액세스할 수 있도록 통합 Jupyter 저작 노트북 인스턴스를 제공하므로 서버를 관리할 필요가 없습니다. 또한 일반적인 ML 알고리즘 분산 환경에서 매우 큰 데이터에 대해 효율적으로 실행되도록 최적화되었습니다.

SageMaker 실시간 추론은 지연 시간이 짧은 실시간 대화형 요구 사항이 있는 워크로드에 이상적입니다. SageMaker 실시간 추론을 사용하면 특정 양의 컴퓨팅 및 메모리를 사용하여 특정 인스턴스 유형이 지원하는 REST 엔드포인트를 배포할 수 있습니다. SageMaker 실시간 엔드포인트를 배포하는 것은 많은 고객을 위한 프로덕션 경로의 첫 번째 단계일 뿐입니다. 대기 시간 요구 사항을 준수하면서 목표 TPS(초당 트랜잭션)를 달성하기 위해 엔드포인트의 성능을 최대화할 수 있기를 원합니다. 추론을 위한 성능 최적화의 많은 부분은 적절한 인스턴스 유형을 선택하고 엔드포인트를 지원하는지 확인하는 것입니다.

이 게시물에서는 인스턴스 수 및 크기에 적합한 구성을 찾기 위해 SageMaker 끝점을 로드 테스트하는 모범 사례를 설명합니다. 이는 대기 시간 및 TPS 요구 사항을 충족하기 위한 최소 프로비저닝 인스턴스 요구 사항을 이해하는 데 도움이 될 수 있습니다. 여기에서 다음을 활용하여 SageMaker 엔드포인트의 지표와 성능을 추적하고 이해하는 방법에 대해 알아봅니다. 아마존 클라우드 워치 측정 항목.

먼저 단일 인스턴스에서 모델의 성능을 벤치마킹하여 허용되는 대기 시간 요구 사항에 따라 처리할 수 있는 TPS를 식별합니다. 그런 다음 결과를 추정하여 프로덕션 트래픽을 처리하는 데 필요한 인스턴스 수를 결정합니다. 마지막으로 프로덕션 수준 트래픽을 시뮬레이션하고 실시간 SageMaker 엔드포인트에 대한 부하 테스트를 설정하여 엔드포인트가 프로덕션 수준 부하를 처리할 수 있는지 확인합니다. 예제의 전체 코드 세트는 다음에서 사용할 수 있습니다. GitHub 저장소.

솔루션 개요

이 게시물에서는 사전 훈련된 포옹 얼굴 DistilBERT 모델 인사말 허깅 페이스 허브. 이 모델은 다양한 작업을 수행할 수 있지만 감정 분석 및 텍스트 분류를 위해 특별히 페이로드를 보냅니다. 이 샘플 페이로드를 사용하여 1000 TPS를 달성하기 위해 노력합니다.

실시간 엔드포인트 배포

이 게시물은 모델 배포 방법에 익숙하다고 가정합니다. 인용하다 엔드포인트 생성 및 모델 배포 엔드포인트 호스팅 이면의 내부를 이해합니다. 지금은 Hugging Face Hub에서 이 모델을 빠르게 가리키고 다음 코드 스니펫을 사용하여 실시간 엔드포인트를 배포할 수 있습니다.

# Hub Model configuration. https://huggingface.co/models
hub = { 'HF_MODEL_ID':'distilbert-base-uncased', 'HF_TASK':'text-classification'
} # create Hugging Face Model Class
huggingface_model = HuggingFaceModel(
transformers_version='4.17.0',
pytorch_version='1.10.2',
py_version='py38',
env=hub,
role=role,
) # deploy model to SageMaker Inference
predictor = huggingface_model.deploy(
initial_instance_count=1, # number of instances
instance_type='ml.m5.12xlarge' # ec2 instance type
)

로드 테스트에 사용하려는 샘플 페이로드로 엔드포인트를 빠르게 테스트해 보겠습니다.

import boto3
import json
client = boto3.client('sagemaker-runtime')
content_type = "application/json"
request_body = {'inputs': "I am super happy right now."}
data = json.loads(json.dumps(request_body))
payload = json.dumps(data)
response = client.invoke_endpoint(
EndpointName=predictor.endpoint_name,
ContentType=content_type,
Body=payload)
result = response['Body'].read()
result

우리는 단일 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2) 5.12개의 vCPU와 48GiB의 메모리를 포함하는 ml.m192xlarge 유형의 인스턴스. vCPU 수는 인스턴스가 처리할 수 있는 동시성을 잘 나타냅니다. 일반적으로 다른 인스턴스 유형을 테스트하여 적절하게 활용되는 리소스가 있는 인스턴스가 있는지 확인하는 것이 좋습니다. 실시간 추론을 위한 SageMaker 인스턴스 및 해당 컴퓨팅 성능의 전체 목록을 보려면 다음을 참조하십시오. Amazon SageMaker 요금.

추적할 지표

부하 테스트를 시작하기 전에 SageMaker 엔드포인트의 성능 분석을 이해하기 위해 추적할 메트릭을 이해하는 것이 중요합니다. CloudWatch는 엔드포인트의 성능을 설명하는 다양한 지표를 이해하는 데 도움이 되도록 SageMaker에서 사용하는 기본 로깅 도구입니다. CloudWatch 로그를 활용하여 엔드포인트 호출을 디버깅할 수 있습니다. 추론 코드에 있는 모든 로깅 및 인쇄 문이 여기에서 캡처됩니다. 자세한 내용은 다음을 참조하십시오. Amazon CloudWatch 작동 방식.

SageMaker에 대해 CloudWatch가 다루는 두 가지 유형의 지표인 인스턴스 수준 및 호출 지표가 있습니다.

인스턴스 수준 지표

고려해야 할 첫 번째 매개변수 세트는 인스턴스 수준 지표입니다. CPUUtilization 과 MemoryUtilization (GPU 기반 인스턴스의 경우 GPUUtilization). 용 CPUUtilization, CloudWatch에서 처음에는 100% 이상의 백분율을 볼 수 있습니다. 위해 깨닫는 것이 중요하다 CPUUtilization, 모든 CPU 코어의 합계가 표시됩니다. 예를 들어 엔드포인트 뒤의 인스턴스에 4개의 vCPU가 포함된 경우 활용 범위가 최대 400%임을 의미합니다. MemoryUtilization반면에 는 0–100% 범위에 있습니다.

구체적으로 다음을 사용할 수 있습니다. CPUUtilization 충분한 양의 하드웨어가 있는지 또는 과도한 양의 하드웨어가 있는지 더 깊이 이해할 수 있습니다. 사용률이 낮은 인스턴스(30% 미만)가 있는 경우 잠재적으로 인스턴스 유형을 축소할 수 있습니다. 반대로 사용률이 약 80~90%인 경우 컴퓨팅/메모리가 더 큰 인스턴스를 선택하는 것이 좋습니다. 테스트 결과 하드웨어의 약 60–70% 사용률을 제안합니다.

호출 지표

이름에서 알 수 있듯이 호출 메트릭은 엔드포인트에 대한 모든 호출의 종단 간 대기 시간을 추적할 수 있는 곳입니다. 호출 메트릭을 활용하여 엔드포인트에서 발생할 수 있는 오류 수와 오류 유형(5xx, 4xx 등)을 캡처할 수 있습니다. 더 중요한 것은 엔드포인트 호출의 대기 시간 분석을 이해할 수 있다는 것입니다. 이것으로 많은 것을 포착할 수 있습니다. ModelLatency 과 OverheadLatency 다음 다이어그램에 설명된 대로 측정항목입니다.

XNUMXD덴탈의 ModelLatency 메트릭은 SageMaker 엔드포인트 뒤에 있는 모델 컨테이너 내에서 추론에 걸리는 시간을 캡처합니다. 모델 컨테이너에는 추론을 위해 전달한 모든 사용자 지정 추론 코드 또는 스크립트도 포함됩니다. 이 단위는 마이크로초 단위로 호출 지표로 캡처되며 일반적으로 CloudWatch(p99, p90 등)에서 백분위수를 그래프로 표시하여 목표 지연 시간을 충족하는지 확인할 수 있습니다. 다음과 같은 몇 가지 요인이 모델 및 컨테이너 대기 시간에 영향을 미칠 수 있습니다.

• 사용자 지정 추론 스크립트 – 자체 컨테이너를 구현했든 사용자 지정 추론 핸들러와 함께 SageMaker 기반 컨테이너를 사용했든 관계없이 특히 지연 시간에 많은 시간을 추가하는 작업을 포착하도록 스크립트를 프로파일링하는 것이 가장 좋습니다.
• 통신 프로토콜 – 모델 컨테이너 내에서 모델 서버에 대한 REST 대 gRPC 연결을 고려하십시오.
• 모델 프레임워크 최적화 – 이것은 예를 들어 프레임워크에 따라 다릅니다. TensorFlow, TF Serving에 따라 조정할 수 있는 여러 환경 변수가 있습니다. 사용 중인 컨테이너를 확인하고 스크립트 내에서 또는 컨테이너에 주입할 환경 변수로 추가할 수 있는 프레임워크별 최적화가 있는지 확인하십시오.

OverheadLatency SageMaker가 요청을 수신한 시간부터 클라이언트에 대한 응답을 반환할 때까지 측정되며 모델 대기 시간을 뺀 값입니다. 이 부분은 대부분 사용자가 제어할 수 없으며 SageMaker 오버헤드에 소요되는 시간에 속합니다.

엔드투엔드 대기 시간은 전체적으로 다양한 요인에 따라 달라지며 반드시 다음의 합계는 아닙니다. ModelLatency ...을 더한 OverheadLatency. 예를 들어 클라이언트가 InvokeEndpoint 인터넷을 통한 API 호출, 클라이언트의 관점에서 엔드투엔드 대기 시간은 인터넷 + ModelLatency + OverheadLatency. 따라서 엔드포인트 자체를 정확하게 벤치마킹하기 위해 엔드포인트를 로드 테스트할 때 엔드포인트 지표(ModelLatency, OverheadLatency및 InvocationsPerInstance) SageMaker 엔드포인트를 정확하게 벤치마킹합니다. 엔드투엔드 대기 시간과 관련된 모든 문제는 별도로 분리할 수 있습니다.

종단 간 대기 시간에 대해 고려해야 할 몇 가지 질문:

• 끝점을 호출하는 클라이언트는 어디에 있습니까?
• 클라이언트와 SageMaker 런타임 사이에 중간 계층이 있습니까?

자동 스케일링

이 게시물에서는 Auto Scaling을 구체적으로 다루지 않지만 워크로드에 따라 정확한 수의 인스턴스를 프로비저닝하기 위해서는 중요한 고려 사항입니다. 트래픽 패턴에 따라 자동 확장 정책 SageMaker 엔드포인트에 연결합니다. 다음과 같은 다양한 스케일링 옵션이 있습니다. TargetTrackingScaling, SimpleScaling및 StepScaling. 이렇게 하면 트래픽 패턴에 따라 엔드포인트가 자동으로 확장 및 축소될 수 있습니다.

일반적인 옵션은 CloudWatch 지표 또는 정의한 사용자 지정 지표를 지정하고 이를 기반으로 확장할 수 있는 대상 추적입니다. Auto Scaling의 빈번한 활용은 InvocationsPerInstance 메트릭. 특정 TPS에서 병목 현상을 식별한 후에는 이를 지표로 사용하여 최대 트래픽 부하를 처리할 수 있도록 더 많은 수의 인스턴스로 확장할 수 있습니다. Auto Scaling SageMaker 엔드포인트에 대한 자세한 분석은 다음을 참조하십시오. Amazon SageMaker에서 자동 확장 추론 엔드포인트 구성.

부하 테스트

Locust를 활용하여 대규모로 로드 테스트를 수행할 수 있는 방법을 표시하지만 엔드포인트 뒤에 있는 인스턴스의 크기를 적절하게 조정하려는 경우 SageMaker 추론 추천자 더 효율적인 옵션입니다. 타사 로드 테스트 도구를 사용하면 여러 인스턴스에 엔드포인트를 수동으로 배포해야 합니다. Inference Recommender를 사용하면 로드 테스트하려는 인스턴스 유형의 배열을 전달하기만 하면 SageMaker가 실행됩니다. 작업 이러한 각 인스턴스에 대해.

메뚜기

이 예에서는 다음을 사용합니다. 메뚜기, Python을 사용하여 구현할 수 있는 오픈 소스 부하 테스트 도구입니다. Locust는 다른 많은 오픈 소스 부하 테스트 도구와 유사하지만 몇 가지 구체적인 이점이 있습니다.

• 설정하기 쉬운 – 이 게시물에서 시연하는 것처럼 특정 엔드포인트 및 페이로드에 대해 쉽게 리팩터링할 수 있는 간단한 Python 스크립트를 전달합니다.
• 분산 및 확장 가능 – Locust는 이벤트 기반이며 게벤트 후드. 이는 고도의 동시 작업 부하를 테스트하고 수천 명의 동시 사용자를 시뮬레이션하는 데 매우 유용합니다. Locust를 실행하는 단일 프로세스로 높은 TPS를 달성할 수 있지만 분산 부하 생성 이 게시물에서 살펴볼 것처럼 여러 프로세스 및 클라이언트 시스템으로 확장할 수 있는 기능입니다.
• 로커스트 지표 및 UI – Locust는 종단 간 대기 시간도 메트릭으로 캡처합니다. 이를 통해 CloudWatch 메트릭을 보완하여 테스트의 전체 그림을 그릴 수 있습니다. 이것은 동시 사용자, 작업자 등을 추적할 수 있는 Locust UI에서 모두 캡처됩니다.

Locust를 더 자세히 이해하려면 다음을 확인하세요. 선적 서류 비치.

아마존 EC2 설정

호환되는 모든 환경에서 Locust를 설정할 수 있습니다. 이 게시물에서는 EC2 인스턴스를 설정하고 여기에 Locust를 설치하여 테스트를 수행합니다. 우리는 c5.18xlarge EC2 인스턴스를 사용합니다. 클라이언트 측 컴퓨팅 성능도 고려해야 합니다. 클라이언트 측에서 컴퓨팅 성능이 부족할 때 종종 캡처되지 않고 SageMaker 엔드포인트 오류로 오인됩니다. 테스트 중인 로드를 처리할 수 있는 컴퓨팅 성능이 충분한 위치에 클라이언트를 배치하는 것이 중요합니다. EC2 인스턴스의 경우 Ubuntu Deep Learning AMI를 사용하지만 시스템에서 Locust를 올바르게 설정할 수 있는 한 모든 AMI를 활용할 수 있습니다. EC2 인스턴스를 시작하고 연결하는 방법을 이해하려면 자습서를 참조하십시오. Amazon EC2 Linux 인스턴스 시작하기.

Locust UI는 포트 8089를 통해 액세스할 수 있습니다. EC2 인스턴스에 대한 인바운드 보안 그룹 규칙을 조정하여 이를 열 수 있습니다. 또한 SSH를 통해 EC22 인스턴스에 연결할 수 있도록 포트 2를 엽니다. 소스 범위를 EC2 인스턴스에 액세스하는 특정 IP 주소로 낮추는 것이 좋습니다.

EC2 인스턴스에 연결되면 Python 가상 환경을 설정하고 CLI를 통해 오픈 소스 Locust API를 설치합니다.

virtualenv venv #venv is the virtual environment name, you can change as you desire
source venv/bin/activate #activate virtual environment
pip install locust

이제 엔드포인트 부하 테스트를 위해 Locust와 협력할 준비가 되었습니다.

메뚜기 테스트

모든 Locust 부하 테스트는 메뚜기 파일 당신이 제공하는. 이 Locust 파일은 부하 테스트에 대한 작업을 정의합니다. 여기에서 Boto3를 정의합니다. invoke_endpoint API 호출. 다음 코드를 참조하십시오.

config = Config(
retries = { 'max_attempts': 0, 'mode': 'standard'
}
) self.sagemaker_client = boto3.client('sagemaker-runtime',config=config)
self.endpoint_name = host.split('/')[-1]
self.region = region
self.content_type = content_type
self.payload = payload

앞의 코드에서 특정 모델 호출에 맞게 호출 엔드포인트 호출 매개 변수를 조정합니다. 우리는 InvokeEndpoint Locust 파일에서 다음 코드를 사용하는 API 이것이 부하 테스트 실행 지점입니다. 우리가 사용하고 있는 Locust 파일은 locust_script.py.

def send(self): request_meta = { "request_type": "InvokeEndpoint", "name": "SageMaker", "start_time": time.time(), "response_length": 0, "response": None, "context": {}, "exception": None,
}
start_perf_counter = time.perf_counter() try:
response = self.sagemaker_client.invoke_endpoint(
EndpointName=self.endpoint_name,
Body=self.payload,
ContentType=self.content_type
)
response_body = response["Body"].read()

이제 Locust 스크립트가 준비되었으므로 분산 Locust 테스트를 실행하여 단일 인스턴스를 스트레스 테스트하여 인스턴스가 처리할 수 있는 트래픽 양을 확인하려고 합니다.

Locust 분산 모드는 단일 프로세스 Locust 테스트보다 약간 더 미묘합니다. 분산 모드에서는 하나의 기본 작업자와 여러 작업자가 있습니다. 기본 작업자는 요청을 보내는 동시 사용자를 생성하고 제어하는 ​​방법에 대해 작업자에게 지시합니다. 우리의 distribution.sh 스크립트에서 기본적으로 240명의 사용자가 60명의 작업자에게 분산되는 것을 볼 수 있습니다. 참고 --headless Locust CLI의 플래그는 Locust의 UI 기능을 제거합니다.

#replace with your endpoint name in format https://<<endpoint-name>>
export ENDPOINT_NAME=https://$1 export REGION=us-east-1
export CONTENT_TYPE=application/json
export PAYLOAD='{"inputs": "I am super happy right now."}'
export USERS=240
export WORKERS=60
export RUN_TIME=1m
export LOCUST_UI=false # Use Locust UI .
.
. locust -f $SCRIPT -H $ENDPOINT_NAME --master --expect-workers $WORKERS -u $USERS -t $RUN_TIME --csv results &
.
.
. for (( c=1; c<=$WORKERS; c++ ))
do
locust -f $SCRIPT -H $ENDPOINT_NAME --worker --master-host=localhost &
done

./distributed.sh huggingface-pytorch-inference-2022-10-04-02-46-44-677 #to execute Distributed Locust test

먼저 엔드포인트를 지원하는 단일 인스턴스에서 분산 테스트를 실행합니다. 여기서 아이디어는 대기 시간 요구 사항을 유지하면서 목표 TPS를 달성하는 데 필요한 인스턴스 수를 이해하기 위해 단일 인스턴스를 완전히 최대화하려는 것입니다. UI에 액세스하려면 Locust_UI 환경 변수를 True로 설정하고 EC2 인스턴스의 퍼블릭 IP를 가져오고 포트 8089를 URL에 매핑합니다.

다음 스크린샷은 CloudWatch 지표를 보여줍니다.

결국 처음에는 200의 TPS를 달성했지만 다음 스크린샷과 같이 EC5 클라이언트 측 로그에서 2xx 오류를 발견하기 시작했습니다.

또한 인스턴스 수준 메트릭을 살펴봄으로써 이를 확인할 수 있습니다. 특히 CPUUtilization.

여기에서 우리는 주목 CPUUtilization 거의 4,800%. ml.m5.12x.large 인스턴스에는 48개의 vCPU가 있습니다(48 * 100 = 4800~). 이것은 전체 인스턴스를 포화시키고 있으며 5xx 오류를 설명하는 데 도움이 됩니다. 우리는 또한 ModelLatency.

단일 인스턴스가 무너지고 있고 우리가 관찰하고 있는 200 TPS를 초과하는 부하를 유지할 수 있는 컴퓨팅이 없는 것 같습니다. 목표 TPS는 1000이므로 인스턴스 수를 5로 늘려 보겠습니다. 특정 지점 이후 200TPS에서 오류를 관찰했기 때문에 프로덕션 환경에서는 더 많아야 할 수도 있습니다.

Locust UI와 CloudWatch 로그 모두에서 엔드포인트를 지원하는 1000개의 인스턴스로 TPS가 거의 XNUMX인 것을 볼 수 있습니다.

이 하드웨어 설정에서도 오류가 발생하기 시작하면 모니터링하십시오. CPUUtilization 엔드포인트 호스팅 이면의 전체 그림을 이해합니다. 확장 또는 축소가 필요한지 확인하려면 하드웨어 사용률을 이해하는 것이 중요합니다. 때때로 컨테이너 수준 문제로 인해 5xx 오류가 발생하지만 CPUUtilization 낮으면 하드웨어가 아니라 이러한 문제를 일으킬 수 있는 컨테이너 또는 모델 수준의 무언가(예: 설정되지 않은 작업자 수에 대한 적절한 환경 변수)를 나타냅니다. 반면에 인스턴스가 완전히 포화 상태가 되면 현재 인스턴스 플릿을 늘리거나 더 작은 플릿으로 더 큰 인스턴스를 시도해야 한다는 신호입니다.

5 TPS를 처리하기 위해 인스턴스 수를 100로 늘렸지만 ModelLatency 지표는 여전히 높습니다. 이는 인스턴스가 포화 상태이기 때문입니다. 일반적으로 인스턴스 리소스를 60~70% 활용하는 것을 목표로 하는 것이 좋습니다.

정리

부하 테스트 후 SageMaker 콘솔 또는 delete_endpoint Boto3 API 호출. 또한 추가 비용이 발생하지 않도록 EC2 인스턴스 또는 클라이언트 설정을 중지해야 합니다.

요약

이 게시물에서는 SageMaker 실시간 엔드포인트를 로드 테스트하는 방법을 설명했습니다. 또한 성능 분석을 이해하기 위해 엔드포인트를 로드 테스트할 때 평가해야 하는 지표에 대해서도 논의했습니다. 꼭 확인하세요 SageMaker 추론 추천자 인스턴스 크기 조정 및 성능 최적화 기술을 더 깊이 이해할 수 있습니다.

저자에 관하여

마크 카프 SageMaker 서비스 팀의 ML 설계자입니다. 그는 고객이 규모에 맞게 ML 워크로드를 설계, 배포 및 관리하도록 돕는 데 중점을 둡니다. 여가 시간에는 여행과 새로운 장소 탐색을 즐깁니다.

램 베기라주 SageMaker 서비스 팀의 ML 설계자입니다. 그는 고객이 Amazon SageMaker에서 AI/ML 솔루션을 구축하고 최적화하도록 돕는 데 중점을 두고 있습니다. 여가 시간에는 여행과 글쓰기를 좋아합니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/machine-learning/best-practices-for-load-testing-amazon-sagemaker-real-time-inference-endpoints/