Blog de Amazon Web Services (AWS)
Configuración de auto escalado automático de enpoints de inferencia en Amazon SageMaker
Por Chaitanya Hazarey, Rama Thamman y Pavan Kumar Sundar
Amazon SageMaker es un servicio totalmente gestionado que ofrece a todos los desarrolladores y científicos de datos la capacidad de crear, entrenar e implementar rápidamente modelos de Machine Learning (ML) a escala. Amazon SageMaker elimina el trabajo pesado de cada paso del proceso de ML para facilitar el desarrollo de modelos de alta calidad. Puede implementar con un solo clic sus modelos de ML para hacer inferencias de baja latencia en tiempo real en endpoints de inferencia totalmente administrados. El escalado automático es una función lista para usar que supervisa sus cargas de trabajo y ajusta dinámicamente la capacidad para mantener un rendimiento estable y predecible al menor costo posible. Cuando aumenta la carga de trabajo, el escalado automático pone en línea más instancias. Cuando la carga de trabajo disminuye, el escalado automático elimina instancias innecesarias, lo que le ayuda a reducir el costo de cómputo.
El siguiente diagrama es una arquitectura de ejemplo que muestra cómo se invoca un modelo para inferir mediante un endpoint de Amazon SageMaker.
Amazon SageMaker intenta distribuir automáticamente sus instancias entre las zonas de disponibilidad. Por lo tanto, se recomienda encarecidamente que implemente varias instancias para cada endpoint de producción para obtener alta disponibilidad. Si utiliza una VPC, configure al menos dos subredes en zonas de disponibilidad diferentes para que Amazon SageMaker pueda distribuir sus instancias entre esas zonas de disponibilidad.
Amazon SageMaker admite cuatro formas diferentes de implementar el escalado horizontal de los endpoints de Amazon SageMaker. Puede configurar algunas de estas políticas mediante la consola de Amazon SageMaker, la interfaz de línea de comandos de AWS (CLI de AWS) o la API de Application Auto Scaling del SDK de AWS para las opciones avanzadas. En esta publicación, mostramos cómo configurar usando el SDK boto3 para Python y delineamos diferentes políticas y patrones de escala.
Requisitos previos
En esta publicación se asume que tiene implementado un endpoint funcional de Amazon SageMaker. Los modelos se alojan en endpoint de Amazon SageMaker; puede tener varias versiones de modelo que se sirvan a través del mismo endpoint. Cada modelo se conoce como una variante de producción.
Si es nuevo en Amazon SageMaker y aún no ha creado un enpoint, complete los pasos de Identificación de especies de aves en el borde mediante el algoritmo de detección de objetos integrado de Amazon SageMaker y AWS DeepLens hasta que aparezca la sección Probar el modelo para desarrollar y hospedar un modelo de detección de objetos.
Si quieres empezar directamente con este post, también puedes buscar un modelo desde el zoológico de modelos de MXNet. Por ejemplo, si planea utilizar ResidualNet152, necesitará la definición del modelo y los pesos del modelo dentro de un archivo tarball. También puede crear modelos personalizados que se pueden alojar como un endpoint de Amazon SageMaker. Para obtener instrucciones sobre cómo crear un archivo tarball con Gluon y Apache MXNet, consulte Implementación de modelos personalizados creados con Gluon y Apache MXNet en Amazon SageMaker.
Configuración de escalado automático
A continuación se indican los pasos de alto nivel para crear un modelo y aplicar una política de escalamiento:
- Utilice Amazon SageMaker para crear un modelo o llevar un modelo personalizado.
- Implemente el modelo.
Si utiliza el estimador MXNet para entrenar el modelo, puede llamar a el método deploy para crear un endpoint de Amazon SageMaker:
# Entrena a mi estimador
mxnet_estimator = MXNet ('train.py',
framework_version='1.6.0',
py_version='py3',
instance_type='ml.p2.xlarge',
instance_count=1)
mxnet_estimator.fit ('s3: //my_bucket/my_training_data/')
# Implemente mi estimador en un endpoint de Amazon SageMaker y obtenga un predictor
predictor = mxnet_estimator.deploy (instance_type='ml.m5.xlarge',
initial_instance_count=1)
#Instance_count =1 no se recomienda para su uso en producción. Usa esto solo para experimentación.
Si utiliza un modelo preformado como ResidualNet152, puede crear un objeto MXNetModel y llamar el método deploy para crear el endpoint de Amazon SageMaker:
mxnet_model = mxNetModel (model_data='s3: //my_bucket/pretrained_model/model.tar.gz', role=role, entry_point='inference.py', framework_version='1.6.0', py_version='py3') predictor = mxnet_model.deploy (instance_type='ml.m5.xlarge', initial_instance_count=1)
3. Cree una política de escalado y aplique la política de escala al endpoint. En la siguiente sección se describen las opciones de la política de escalado.
Opciones de escalado
Puede definir el número mínimo, deseado y máximo de instancias por endpoint y, en función de las configuraciones de escalado automático, las instancias se gestionan dinámicamente. El siguiente diagrama ilustra esta arquitectura.
Para escalar el enpoint de Amazon SageMaker implementado, primero obtenga sus detalles:
import pprint
import boto3
from sagemaker import get_execution_role
import sagemaker
import json
pp = Pprint.prettyPrinter (indent=4, profundidade = 4)
role = get_execution_role ()
sagemaker_client = boto3.session () .client (service_name='sagemaker')
endpoint_name = 'nome-do-endpoint'
response = sagemaker_client.describe_endpoint (endpointName=Endpoint_name)
pp.pprint (response)
#Definimos un cliente para jugar con opciones de autoescalado
client = boto3.client ('application-autoscaling') # Clase común que representa
Application Auto Scaling para SageMaker entre otros servicios
Escalado simple o TargetTrackingScaling
Utilice esta opción cuando desee escalar según una métrica específica de Amazon CloudWatch . Puede hacerlo seleccionando una métrica específica y estableciendo valores de umbral. Las métricas recomendadas para esta opción son promedio de CPUUtilization o sageMakerVariantInvocationsPerInstance.
SageMakerVariantInvocationsPerInstance es el promedio de veces por minuto que se invoca cada instancia de una variante. CPUUtilización es la suma del trabajo manejado por un CPU.
Los siguientes fragmentos de código muestran cómo escalar utilizando estas métricas. También puede insertar métricas personalizadas a CloudWatch o utilizar otras métricas. Para obtener más información, consulte Supervisar Amazon SageMaker con Amazon CloudWatch.
resource_id=’endpoint/’ + endpoint_name + ‘/variant/’ + ‘allTraffic’
# Este es el formato en el que el escalado automático de la aplicación hace referencia al endpoint
response = client.register_scalable_target (
serviceNamespace='SageMaker',
resourceId=Resource_ID,
scalableDimension='sageMaker:variant:DesiredInstanceCount',
MinCapacity=1,
MaxCapacity=2
)
# Exemplo 1 - Métrica SageMakerVariantInvocationSperInstance
response = client.put_scaling_policy (
policyName='Invocations-scalingPolicy',
serviceNamespace='sageMaker', # El espacio de nombres del servicio de AWS que proporciona el recurso.
resourceId=Resource_ID, # nombre del endpoint
scalableDimension='sageMaker:variant:DesiredInstanceCount', # SageMaker admite sólo el recuento de instancias
policyType='targetTrackingScaling', # 'stepsCaling'|'TargetTrackingScaling'
targetTrackingScalingPolicyConfiguration= {
'targetValue': 10.0, # El valor objetivo de la métrica. - aquí la métrica es - sageMakerVariantInvocationsPerInstance
'PredefinedMetricSpecification': {
'predefinedMetricType': 'SageMakerVariantInvocationSperInstance', # es el promedio de veces por minuto que se invoca cada instancia de una variante.
},
'ScaleInCoolDown': 600, #
El período de reutilización te ayuda a evitar que tu grupo de Auto Scaling se inicie o termine
# instancias adicionales antes de que los efectos de actividades anteriores sean visibles.
# Puede configurar el período de tiempo en función del tiempo de inicio de la instancia u otras necesidades de la aplicación.
# ScaleInCoolDown - La cantidad de tiempo, en segundos, después de que se complete una escala en la actividad antes de que otra escala en la actividad pueda comenzar.
'ScaleOutCoolDown': 300 # ScaleOutCoolDown - La cantidad de tiempo, en segundos, después de que se completa una actividad de escalado horizontal antes de que otra actividad de escala horizontal pueda comenzar.
# 'DisableEscaleIn': True|False: indica si la escala en la política de seguimiento de destino está deshabilitada.
# Si el valor es verdadero, la escala en está deshabilitada y la política de seguimiento de destino no eliminará la capacidad del recurso escalable.
}
)
#Ejemplo 2 - Métrica de utilización de CPU
response = client.put_scaling_policy (
PolicyName='CPUutil-scalingPolicy',
servicenamespace='SageMaker',
resourceId=Resource_ID,
ScalableDimension='sageMaker:Variant:DesiredInstanceCount',
policyType='targetTrackingScaling',
targetTrackingScalingPolicyConfiguration= {
'TargetValue': 90.0,
'CustomizedMetricSpecification':
{
'MetricName': 'CPUUtilización',
'Namespace': '/aws/sageMaker/Endpoints',
«Dimensiones»: [
{'Name': 'EndpointName', 'Valor': endpoint_name},
{'Name': 'VariantName', 'Valor': 'AllTraffic'}
],
'Estadística': 'Promedio', # Posible - 'Estadística': 'Promedia' |'Minimum'|'Máximo' |'Recuento de sample'|'Suma'
'Unidad': 'Porcentaje'
},
'ScaleIncooldown': 600,
'ScaleOutCooldown': 300
}
)
)
Con el período de enfriamiento de escalado, la intención es escalar de forma conservadora para proteger la disponibilidad de la aplicación, de modo que las actividades de escalado se bloqueen hasta que finalice el período de enfriamiento. Con el período de enfriamiento de escalado horizontal, la intención es escalar horizontalmente continuamente (pero no excesivamente). Después de que Application Auto Scaling se escale correctamente mediante una política de escalado de seguimiento de destino, comienza a calcular el tiempo de enfriamiento.
Escalado por pasos
Se trata de un tipo avanzado de escala en el que se definen políticas adicionales para ajustar dinámicamente el número de instancias a escalar según el tamaño de la brecha de alarma. Esto le ayuda a configurar una respuesta más agresiva cuando la demanda alcanza un cierto nivel. El código siguiente es un ejemplo de una política de escalado de pasos basada en la métrica OverheadLatency :
#Ejemplo 3 - Métrica OverheadLatency y Política StepScaling
response = client.put_scaling_policy (
PolicyName='OverheadLatency-scalingPolicy',
servicenamespace='SageMaker',
resourceId=Resource_ID,
ScalableDimension='sageMaker:Variant:DesiredInstanceCount',
policyType='StepScaling',
StepScalingPolicyConfiguration= {
'AdjustmentType': 'ChangeIncapacity', # 'PercentChangeIncapacity'|'ExactCapacity' Especifica si el valor ScalingAdjustment en un StepJustment
# es un número absoluto o un porcentaje de la capacidad actual.
'StepadJustments': [# Un conjunto de ajustes que le permiten escalar en función del tamaño de la brecha de alarma.
{
'MetricIntervallowerBound': 0.0, # El límite inferior para la diferencia entre el umbral de alarma y la métrica CloudWatch.
# 'MetricIntervalUpperbound': 100.0, # El límite superior de la diferencia entre el umbral de alarma y la métrica CloudWatch.
'ScalingAdjument': 1 # La cantidad por la que se escala, basado en el tipo de ajuste especificado.
# Un valor positivo se suma a la capacidad actual mientras que un número negativo elimina de la capacidad actual.
},
],
# 'minAdjustmentMagnitude': 1, # El número mínimo de instancias a escalar. - sólo para 'PercentChangeIncapacity'
'Refrigeración': 120,
'MetricAggregationType': 'Average', # 'Minimum'|'Máximo'
}
)
Escalado calendarizado
Puede utilizar esta opción cuando se sabe que la demanda sigue una calendarización determinada en el día, semana, mes o año. Esto le ayuda a especificar una calendarización única o una calendarización periódica o expresiones cron junto con las horas de inicio y finalización, que forman los límites de cuándo comienza y se detiene la acción de escalado automático. Consulte el siguiente código:
#Example 4 - Escalado basado en un horario determinado.
response = client.put_scheduled_action (
servicenamespace='SageMaker',
Schedule='at (2020-10-07T 06:20:00) ', # aaaa-mm-ddthh:mm:ss Puede usar una calendarización de una sola vez, cron o tasa
ScheduledActionName='ScheduledScalingTest',
resourceId=Resource_ID,
ScalableDimension='sageMaker:Variant:DesiredInstanceCount',
#StartTime =datetime (2020, 10, 7), #Fecha y hora de inicio de la calendarización
#EndTime =datetime (2020, 10, 8), #Fecha y hora de fin de la calendarización
ScalableTargetAction= {
«Mincapacidad»: 2,
'MáxCapacidad': 3
}
)
Escalado bajo demanda
Utilice esta opción sólo cuando desee aumentar o disminuir manualmente el número de instancias. Esto actualiza las ponderaciones y capacidades del endpoint sin definir un desencadenador. Consulte el siguiente código:
response = client.update_endpoint_weights_and_capacities (endpointName=Endpoint_name,
DesiredWeightsandCapacities= [
{
'VariantName': 'string',
'Peso deseado': ...,
'DesiredInstanceCount': 123
}
])
Comparación de métodos de escala
Cada uno de estos métodos, cuando se aplica correctamente, da como resultado la adición de instancias a un endpoint de Amazon SageMaker ya implementado. Cuando realiza una solicitud para actualizar el endpoint con configuraciones de escalado automático, el estado del endpoint pasa a Actualizando. Mientras el endpoint se encuentra en este estado, otras operaciones de actualización en este endpoint fallan. Puede supervisar el estado mediante la API DescribeEndPoint. No hay interrupción del tráfico mientras se agregan o eliminan instancias de un endpoint.
Al crear un endpoint, especificamos initial_instance_count; este valor sólo se utiliza en el momento de la creación del endpoint. Ese valor se omite posteriormente y el escalado automático o el escalado bajo demanda utiliza el cambio en DesiredInstanceCount para establecer el recuento de instancias detrás de un endpoint.
Por último, si utiliza UpdateEndPoint para implementar un nuevo endpointConfig en un endpoint, para conservar el número actual de instancias, debe establecer RetainAllVariantProperties en true.
Consideraciones para diseñar una política de autoescalado para escalar la carga de trabajo de ML
Debe tener en cuenta lo siguiente al diseñar una política de escalado automático eficiente para minimizar las interrupciones del tráfico y ser rentable:
- Patrones y métricas de tráfico: considere especialmente los patrones de tráfico que implican invocar la lógica de inferencia. A continuación, determine qué métricas afectan más estos patrones de tráfico. ¿O a qué métrica es sensible la lógica de inferencia (como GPUUtilización, CPUUtilización, MemoryUtilizacióno Invocations) por instancia? ¿La lógica de inferencia está vinculada a la GPU, a la memoria o a la CPU?
- Métricas personalizadas: si se trata de una métrica personalizada que necesita definirse en función del dominio problemático, tenemos la opción de implementar un recopilador de métricas personalizado. Con un recopilador de métricas personalizado, tiene una opción adicional para ajustar la granularidad de la recopilación y publicación de métricas.
- Umbral : después de decidir sobre nuestras métricas, tenemos que decidir sobre el umbral. En otras palabras, cómo detectar el aumento de la carga, basado en la métrica anterior, dentro de una ventana de tiempo que permite la adición de una instancia y que su lógica de inferencia esté lista para servir la inferencia. Esta consideración también rige la medida del período de reutilización de escalado y escalado horizontal.
- Escalado automático : en función de la tolerancia de la lógica de la aplicación al escalado automático, debe haber un equilibrio entre el sobreaprovisionamiento y el escalado automático. Dependiendo de la carga de trabajo, si selecciona una instancia especializada como Inferentia, las ganancias de rendimiento podrían aliviar la necesidad de escalar automáticamente hasta cierto punto.
- Escala horizontal : cuando tenemos estas estimaciones, es hora de considerar una o más estrategias que alistamos en esta publicación para implementarlas para escalar horizontal. Algunos funcionan particularmente bien en ciertas situaciones. Por ejemplo, se recomienda encarecidamente que utilice una política de escalado de seguimiento de destino para escalar en una métrica como el uso medio de CPU o la métrica SageMakerVariantInvocationsPerInstance . Pero una buena pauta es derivar empíricamente una política de escalado adecuada basada en su carga de trabajo particular y factores anteriores. Puede comenzar con una política de escalado de seguimiento de destino simple y todavía tiene la opción de utilizar el escalado de pasos como política adicional para una configuración más avanzada. Por ejemplo, puede configurar una respuesta más agresiva cuando la demanda alcanza un cierto nivel.
Recuperar el registro de actividad de escalado
Cuando desee ver todas las políticas de escalado asociadas a su endpoint de Amazon SageMaker, puede utilizar describe_scaling_policies, que le ayuda a comprender y depurar el comportamiento de las diferentes configuraciones de escalado:
response = client.describe_scaling_policies (
servicenamespace='SageMaker'
)
para i en respuesta ['ScalingPolicies']:
print («)
pp.pprint (i ['PolicyName'])
print («)
if ('targetTrackingScalingPolicyConfiguration' en i):
pp.pprint (i ['targetTrackingScalingPolicyConfiguration'])
otra cosa:
pp.pprint (i ['StepScalingPolicyConfiguration'])
print («)
Conclusión
En el caso de modelos que enfrentan tráfico impredecible, el escalado automático de Amazon SageMaker ayuda a responder económicamente a la demanda y elimina la carga pesada indiferenciada de administrar la infraestructura de inferencia. Una de las mejores prácticas de implementación de modelos es realizar pruebas de carga. Determine los umbrales adecuados para sus políticas de escalado y elija métricas basadas en pruebas de carga. Para obtener más información acerca de las pruebas de carga, consulte Amazon EC2 Testing Policy and Load test y optimice un endpoint de Amazon SageMaker mediante escalado automático.
Referencias
Para obtener referencias adicionales, consulte lo siguiente:
Este artículo fue traducido del Blog de AWS en Inglês
Sobre los autores
Chaitanya Hazarey es Arquitecto de Soluciones de aprendizaje automático del equipo de gestión de productos de Amazon SageMaker. Se centra en ayudar a los clientes a diseñar e implementar canalizaciones de ML end-to-end en producción en AWS. Ha configurado múltiples flujos de trabajo en torno a problemas en las áreas de PNL, Computer Vision, Recommender Systems y AutoML Pipelines.
Pavan Kumar Sunder es Ingeniero Senior de I+D de Amazon Web Services. Proporciona orientación técnica y ayuda a los clientes a acelerar su capacidad para innovar mostrando el arte de lo posible en AWS. Ha creado varios prototipos alrededor de AI/ML, IoT y Robótica para nuestros clientes.
Rama Thamman es Gerente de Desarrollo de Software con el equipo de Plataformas AI, liderando el equipo de Migraciones de ML.
Revisor
Edzon Sanchez es Arquitecto de Soluciones en AWS México