O blog da AWS

Configurando endpoints de inferência de escalonamento automático no Amazon SageMaker

por Chaitanya Hazarey, Rama Thamman e Pavan Kumar Sundar

 

O Amazon SageMaker é um serviço totalmente gerenciado que oferece a todos os desenvolvedores e cientistas de dados a capacidade de criar, treinar e implantar rapidamente modelos de aprendizado de máquina (ML) em escala. O Amazon SageMaker remove o trabalho pesado de cada etapa do processo de ML para facilitar o desenvolvimento de modelos de alta qualidade. Você pode implantar seus modelos de ML com um clique para fazer inferências de baixa latência em tempo real em endpoints totalmente gerenciados. O escalonamento automático é um recurso pronto para uso que monitora suas cargas de trabalho e ajusta dinamicamente a capacidade de manter um desempenho estável e previsível ao menor custo possível. Quando a carga de trabalho aumenta, o escalonamento automático coloca mais instâncias online. Quando a carga de trabalho diminui, o escalonamento automático remove instâncias desnecessárias, ajudando você a reduzir o custo de computação.

O diagrama a seguir é uma arquitetura de exemplo que mostra como um modelo é chamado para inferência usando um endpoint do Amazon SageMaker.

 

 

O Amazon SageMaker tenta distribuir automaticamente suas instâncias entre zonas de disponibilidade. Portanto, é altamente recomendável que você implante várias instâncias para cada endpoint de produção para alta disponibilidade. Se você estiver usando uma VPC, configure pelo menos duas sub-redes em diferentes zonas de disponibilidade para que o Amazon SageMaker possa distribuir sua infraestrutura entre essas zonas de disponibilidade.

O Amazon SageMaker oferece suporte a quatro maneiras diferentes de implementar o dimensionamento horizontal dos endpoints do Amazon SageMaker. Você pode configurar algumas dessas políticas usando o console do Amazon SageMaker, a AWS Command Line Interface (AWS CLI) ou a API Application Auto Scaling do AWS SDK para as opções avançadas. Neste post, mostramos como configurar usando o SDK boto3 para Python e delinear diferentes políticas e padrões de escalabilidade.

Pré-requisitos

Esta publicação pressupõe que você tenha um endpoint funcional do Amazon SageMaker implantado. Os modelos são hospedados em um endpoint do Amazon SageMaker; você pode ter várias versões de modelo sendo servidas por meio do mesmo endpoint. Cada modelo é referido como uma variante de produção.

Se você é novo no Amazon SageMaker e ainda não criou um endpoint, conclua as etapas em Identificação de espécies de aves na borda usando o algoritmo interno de detecção de objetos do Amazon SageMaker e o AWS DeepLens até a seção Testando o modelo para desenvolver e hospede um modelo de detecção de objetos.

Se você quiser começar diretamente com este post, você também pode buscar um modelo do zoológico modelo MXNet. Por exemplo, se você planeja usar ResidualNet152, precisará da definição do modelo e dos pesos do modelo dentro de um tarball. Você também pode criar modelos personalizados que podem ser hospedados como um endpoint do Amazon SageMaker. Para obter instruções sobre como criar um tarball com o Gluon e o Apache MXNet, consulte Implantação de modelos personalizados criados com Gluon e Apache MXNet no Amazon SageMaker.

Configurando o escalonamento automático

A seguir estão as etapas de alto nível para criar um modelo e aplicar uma política de escalabilidade:

  1. Use o Amazon SageMaker para criar um modelo ou trazer um modelo personalizado.
  2. Implante o modelo.

Se você usar o estimador MXNet para treinar o modelo, você pode chamar deploy para criar um endpoint do Amazon SageMaker:

# Treine meu 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/')




# Implante meu estimador em um endpoint do Amazon SageMaker e obtenha um Predictor

predictor = mxnet_estimator.deploy (instance_type='ml.m5.xlarge',

                initial_instance_count=1)

#Instance_count =1 não é recomendado para uso em produção. Use isso apenas para experimentação.

Se você usar um modelo pré-treinado como ResidualNet152, poderá criar um objeto MXNetModel e chamar a implantação para criar o endpoint do 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)
  1. Crie uma política de escalabilidade e aplique a política de escalabilidade ao endpoint. A seção a seguir discute suas opções de política de escalabilidade.

 

Opções de dimensionamento

Você pode definir o número mínimo, desejado e máximo de instâncias por endpoint e, com base nas configurações de escalonamento automático, as instâncias são gerenciadas dinamicamente. O diagrama a seguir ilustra essa arquitetura.

 

 

Para escalar o endpoint do Amazon SageMaker implantado, primeiro busque seus detalhes:

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)




#Vamos definir um cliente para jogar com opções de escalonamento automático

client = boto3.client ('application-autoscaling')

# Classe comum representando Application Auto Scaling para SageMaker entre outros serviços

Escalamento simples ou TargetTrackingScaling

Use essa opção quando quiser dimensionar com base em uma métrica específica do Amazon CloudWatch . Você pode fazer isso escolhendo uma métrica específica e definindo valores de limite. As métricas recomendadas para essa opção são CPUUtilization médio ou SageMakerVariantInvocationSperInstance.

SageMakerVariantInvocationSperInstance é o número médio de vezes por minuto que cada instância de uma variante é chamada. CPUUtilization é a soma do trabalho tratado por uma CPU.

Os trechos de código a seguir mostram como dimensionar usando essas métricas. Você também pode enviar métricas personalizadas para o CloudWatch ou usar outras métricas. Para obter mais informações, consulte Monitorar o Amazon SageMaker com o Amazon CloudWatch.

resource_id=’endpoint/’ + endpoint_name + ‘/variant/’ + ‘allTraffic’

# Este é o formato no qual o escalonamento automático do aplicativo faz referência ao 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', # O namespace do serviço da AWS que fornece o recurso.

    resourceId=Resource_ID, # Nome do endpoint

    scalableDimension='sageMaker:variant:DesiredInstanceCount', # SageMaker suporta apenas Contagem de Instâncias

    policyType='targetTrackingScaling', # 'stepsCaling'|'TargetTrackingScaling'

    targetTrackingScalingPolicyConfiguration= {

        'targetValue': 10.0, # O valor de destino para a métrica. - aqui a métrica é - SageMakerVariantInvocationSperInstance

        'PredefinedMetricSpecification': {

            'predefinedMetricType': 'SageMakerVariantInvocationSperInstance', # é o número médio de vezes por minuto que cada instância de uma variante é chamada.

        },

        'ScaleInCoolDown': 600, # O período de recarga ajuda você a evitar que seu grupo Auto Scaling inicie ou encerre

                                # instâncias adicionais antes que os efeitos das atividades anteriores sejam visíveis.

                                # Você pode configurar o período de tempo com base no tempo de inicialização da instância ou em outras necessidades de aplicativos.

                                # ScaleIncoolDown - A quantidade de tempo, em segundos, depois que uma escala na atividade é concluída antes que outra escala na atividade possa começar.

        'scaleOutCoolDown': 300 # ScaleOutCoolDown - A quantidade de tempo, em segundos, após a conclusão de uma atividade de escala para fora antes que outra atividade de escala possa começar.

       

        # 'disableScaleIn': True|False - determina se a escala pela política de rastreamento de destino está desativada.

                            # Se o valor for verdadeiro, a escala em será desativada e a política de rastreamento de destino não removerá a capacidade do recurso escalável.

    }

)




# Exemplo 2 - Métrica CPUUtilization

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': 'CPUUtilization',

            'Namespace': '/AWS/SageMaker/Endpoints',

            “Dimensions”: [

                {'Name': 'endpointName', 'Value': endpoint_name},

                {'Name': 'VariantName', 'Value': 'allTraffic'}

            ],

            'Statistic': 'Mean', # Possível - 'Estatística': 'Mean'|'Minimum'|'Maximum'|'SampleCount'|'Sum'

            'Unity': 'Percent'

        },

        'ScaleInCooldown': 600,

        'ScaleOutcooldown': 300

    }

)

 

Com o ScaleInCooldow, a intenção é aumentar de forma conservadora para proteger a disponibilidade da sua aplicação, de modo que as atividades de expansão sejam bloqueadas até o período de recarga expirar. Com o ScaleOutcooldown, a intenção é escalar continuamente (mas não excessivamente). Depois que o Application Auto Scaling for dimensionado com sucesso usando uma política de escalabilidade de rastreamento de destino, ele começa a calcular o tempo de recarga.

Escalamento de etapas

Este é um tipo avançado de escala onde você define políticas adicionais para ajustar dinamicamente o número de instâncias a serem dimensionadas com base no tamanho da violação de alarme. Isso ajuda você a configurar uma resposta mais agressiva quando a demanda atinge um determinado nível. O código a seguir é um exemplo de uma política de escalonamento de etapas com base na métrica OverheadLatency :

# Exemplo 3 - Métrica de OverheadLatency e política de escalonamento

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 se o valor ScalingAdjustment em um stepAdjustment

                                              # é um número absoluto ou uma porcentagem da capacidade atual.

        'StepAdjustments': [# Um conjunto de ajustes que permitem dimensionar com base no tamanho da violação de alarme.

            {

                'MetricIntervalLowerBound': 0.0, # O limite inferior para a diferença entre o limite de alarme e a métrica do CloudWatch.

                 # 'MetricIntervalUpperBound': 100.0, # O limite superior para a diferença entre o limite de alarme e a métrica do CloudWatch.

                'ScalingAdjustment': 1 # A quantidade pela qual escalar, com base no tipo de ajuste especificado.

                                       # Um valor positivo adiciona à capacidade atual enquanto um número negativo remove da capacidade atual.

            },

        ],

        # 'minAdjustmentMagnitude': 1, # O número mínimo de instâncias a serem dimensionadas. - somente para 'PercentChangeInCapacity'

        “CoolDown”: 120,

        'MetricAggregationType': 'Mean', # ' Minimum '|'Maximum'

    }

)

Dimensionamento agendado

Você pode usar essa opção quando souber que a demanda segue uma programação específica no dia, semana, mês ou ano. Isso ajuda você a especificar uma programação única ou uma programação recorrente ou expressões cron juntamente com os horários de início e término, que formam os limites de quando a ação de escalonamento automático é iniciada e interrompida. Consulte o seguinte código:

# Exemplo 4 - Dimensionamento com base em um determinado cronograma.

response = client.put_scheduled_action (

    serviceNamespace='SageMaker',

    schedule='at (2020-10-07T 06:20:00) ', # AAAA-MM-DDTHH:MM:SS Você pode usar um horário, cron ou taxa

    scheduledActionName='scheduledScalingTest',

    resourceId=Resource_ID,

    scalableDimension='sageMaker:variant:DesiredInstanceCount',

    #StartTime =datetime (2020, 10, 7), #Start data e hora para quando a programação deve começar

    #EndTime =datetime (2020, 10, 8), #End data e hora para quando a programação recorrente deve terminar

    ScalableTargetAction= {

        'MinCapacity': 2,

        'MaxCapacity': 3

    }

)

Dimensionamento sob demanda

Use essa opção somente quando quiser aumentar ou diminuir o número de instâncias manualmente. Isso atualiza os pesos e as capacidades do valor-limite sem definir um gatilho. Consulte o seguinte código:

response = client.update_endpoint_weights_and_capacities (endpointName=Endpoint_name,

                            DesiredWeightSandCapacities= [

                                {

                                    'variantName': 'string',

                                    “Desiredweight”: ...,

                                    'DesiredInstanceCount': 123

                                }

                            ])

Comparando métodos de dimensionamento

Cada um desses métodos, quando aplicado com sucesso, resulta na adição de instâncias a um endpoint do Amazon SageMaker já implantado. Quando você faz uma solicitação para atualizar seu endpoint com configurações de escalonamento automático, o status do endpoint é movido para Atualização. Enquanto o endpoint estiver nesse estado, outras operações de atualização neste endpoint falham. Você pode monitorar o estado usando a API DescribeEndPoint. Não há interrupção de tráfego enquanto as instâncias estão sendo adicionadas ou removidas de um endpoint.

Ao criar um endpoint, especificamos initial_instance_count; esse valor só é usado no momento da criação do endpoint. Esse valor é ignorado posteriormente, e o escalonamento automático ou o dimensionamento sob demanda usa a alteração em DesiredInstanceCount para definir a contagem de instâncias atrás de um endpoint.

Finalmente, se você usar updateEndPoint para implantar um novo EndPointConfig em um endpoint, para manter o número atual de instâncias, você deve definir retainAllVariantProperties como true.

 

Considerações para projetar uma política de escalonamento automático para dimensionar sua carga de trabalho de ML

Você deve considerar o seguinte ao projetar uma política eficiente de escalonamento automático para minimizar interrupções de tráfego e ser econômico:

  • Padrões e métricas de tráfego — Considere especialmente os padrões de tráfego que envolvem a invocação da lógica de inferência. Em seguida, determine quais métricas esses padrões de tráfego afetam mais. Ou a que métrica a lógica de inferência é sensível (como GPUUtilization, CPUUtilization, MemoryUtilizationou Invocations) por instância? A lógica de inferência GPU está vinculada, vinculada à memória ou à CPU?
  • Métricas personalizadas — Se for uma métrica personalizada que precisa ser definida com base no domínio do problema, temos a opção de implantar um coletor de métricas personalizadas. Com um coletor de métricas personalizado, você tem uma opção adicional de ajustar a granularidade da coleta e publicação de métricas.
  • Limite — Depois de decidirmos sobre nossas métricas, precisamos decidir sobre o limite. Em outras palavras, como detectar o aumento na carga, com base na métrica anterior, dentro de uma janela de tempo que permite a adição de uma instância e que sua lógica de inferência esteja pronta para servir inferência. Essa consideração também governa a medida do período de recarga de escala e de expansão.
  • Escalonamento automático — Dependendo da tolerância da lógica do aplicativo ao escalonamento automático, deve haver um equilíbrio entre o excesso de provisionamento e o escalonamento automático. Dependendo da carga de trabalho, se você selecionar uma instância especializada, como Inferentia, os ganhos de taxa de transferência podem aliviar a necessidade de escala automática até certo ponto.
  • Dimensionamento horizontal — Quando temos essas estimativas, é hora de considerar uma ou mais estratégias que nos alistamos neste post para implantar para escalonamento horizontal. Alguns funcionam particularmente bem em determinadas situações. Por exemplo, é altamente recomendável que você use uma política de escalabilidade de rastreamento de destino para dimensionar em uma métrica, como a utilização média da CPU ou a métrica SageMakerVariantInvocationSperInstance . Mas uma boa diretriz é derivar empiricamente uma política de escalabilidade apt com base em sua carga de trabalho específica e fatores acima. Você pode começar com uma política simples de dimensionamento de rastreamento de destino e ainda tem a opção de usar o dimensionamento de etapas como uma política adicional para uma configuração mais avançada. Por exemplo, você pode configurar uma resposta mais agressiva quando a demanda atingir um determinado nível.

 

Recuperando seu log de atividades de escalabilidade

Quando você quiser ver todas as políticas de escalabilidade anexadas ao endpoint do Amazon SageMaker, você pode usar describe_scaling_policies, o que ajuda você a entender e depurar o comportamento das diferentes configurações de escalabilidade:

response = client.describe_scaling_policies (

    serviceNamespace='SageMaker'

)




for i in response ['ScalingPolicies']:

    print (“)

    pp.pprint (i ['policyName'])

    print (“)

    if ('targetTrackingScalingPolicyConfiguration' in i):

        pp.pprint (i ['targetTrackingScalingPolicyConfiguration'])

    else:

        pp.pprint (i ['StepsCalingPolicyConfiguration'])

    print (“)

 

Conclusão

Para modelos que enfrentam tráfego imprevisível, o escalonamento automático do Amazon SageMaker ajuda a responder economicamente à demanda e remove o trabalho pesado indiferenciado do gerenciamento da infraestrutura de inferência. Uma das práticas recomendadas de implantação do modelo é realizar testes de carga. Determine os limites apropriados para suas políticas de escalabilidade e escolha métricas com base em testes de carga. Para obter mais informações sobre testes de carga, consulte Política de teste e teste de carga do Amazon EC2 e otimizar um endpoint do Amazon SageMaker usando escalabilidade automática.

 

Referências

Para obter referências adicionais, consulte o seguinte:

 

Este artigo foi traduzido do Blog da AWS em Inglês.

 

 

Sobre os Autores

Chaitanya Hazarey é arquiteto de soluções de aprendizado de máquina com a equipe de gerenciamento de produtos do Amazon SageMaker. Ele se concentra em ajudar os clientes a projetar e implantar pipelines de ML de ponta a ponta em produção na AWS. Ele configurou vários desses fluxos de trabalho em torno de problemas nas áreas de PNL, Visão Computacional, Sistemas Recommender e AutoML Pipelines.

 

 

 

Pavan Kumar Sunder é engenheiro sênior de pesquisa e desenvolvimento da Amazon Web Services. Ele fornece orientação técnica e ajuda os clientes a acelerar sua capacidade de inovar mostrando a arte do possível na AWS. Ele construiu vários protótipos em torno de AI/ML, IoT e Robótica para nossos clientes.

 

 

 

Rama Thamman é Gerente de Desenvolvimento de Software com a equipe de Plataformas de IA, liderando a equipe de Migrações ML.

 

 

 

 

 

Revisor

Joao Martins é arquiteto de soluções na AWS e atua no segmento Enterprise auxiliando clientes de Retail e CPG em geral para empresas que estão iniciando sua jornada para a nuvem.