Apresentando melhorias no escalamento gerenciado do Amazon EMR


Escalabilidade gerenciada do Amazon EMR tem ajudado os clientes a redimensionar automaticamente seus clusters para otimizar o desempenho e reduzir custos. Temos o prazer de apresentar uma melhoria significativa neste recurso: Dimensionamento Avançado para Amazon EMR. Esse novo recurso oferece flexibilidade adicional para configurar a utilização de recursos ou os níveis de desempenho desejados para seu cluster usando um controle deslizante de desempenho de utilização. Depois que o controle deslizante é definido, o EMR Managed Scaling dimensiona o cluster de forma inteligente e otimiza os recursos do cluster com base no desempenho configurado ou nos níveis de utilização de recursos.

Os clientes apreciam a simplicidade do EMR Managed Scaling, onde especificam os limites mínimo e máximo de computação para seus clusters e o EMR Managed Scaling redimensiona automaticamente o cluster. O EMR Managed Scaling amostra continuamente as principais métricas associadas às cargas de trabalho em execução em clusters e aumenta ou diminui de acordo. No entanto, as cargas de trabalho dos clientes estão cada vez mais complexas, com variabilidade em dimensões como volumes de dados e custos versus requisitos de SLA. Consequentemente, os clientes preferem ter alavancas adicionais para ajustar o comportamento de escalabilidade mais adequado à sua carga de trabalho. Nesta postagem, discutimos os benefícios do Superior Scaling para Amazon EMR e demonstramos como ele funciona por meio de alguns exemplos de cenários.

Dimensionamento avançado para Amazon EMR

Anteriormente, os clientes que desejavam ajustar o comportamento padrão do EMR Managed Scaling não tinham outra opção a não ser desabilitar o EMR Managed Scaling e criar regras personalizadas de escalabilidade automática. As regras personalizadas de escalonamento automático criaram vários problemas:

  • As regras de escalonamento automático personalizadas não reconhecem o embaralhamento e os dados do embaralhamento são perdidos.
  • O escalonamento automático personalizado não reconhece o driver do aplicativo e pode encerrá-lo, causando falha em todo o trabalho.
  • O escalonamento automático personalizado pode ser mais lento para responder às necessidades em tempo actual.

Esses são alguns dos motivos pelos quais o escalonamento automático personalizado não é a opção certa. Os clientes queriam suporte pronto para uso para escalabilidade gerenciada para lidar com a escalabilidade que otimiza o objetivo closing do cliente de otimizar custo ou desempenho. O novo recurso Superior Scaling aprimora os benefícios existentes do EMR Managed Scaling introduzindo controles adicionais e ajudando você a configurar a utilização de recursos desejada ou o nível de desempenho para seu cluster usando um controle deslizante de desempenho de utilização. O EMR Superior Scaling traduz internamente a intenção em uma estratégia de algoritmo personalizada (UtilizationPerformanceIndex), como a rapidez com que escalar, quanto escalar e assim por diante, para tomar decisões de escalabilidade para o cluster. Isso ajuda a otimizar os recursos do cluster e, ao mesmo tempo, garante que atendamos ao desempenho ou à intenção de utilização de recursos definida pelo cliente.

Por exemplo, para um cluster que executa várias tarefas de duração relativamente curta (ordem de segundos), o EMR Managed Scaling period usado anteriormente para aumentar o cluster de forma agressiva e conservadora para evitar impacto negativo nos tempos de execução do trabalho. Embora esta seja a abordagem correta para cargas de trabalho sensíveis ao SLA, ela pode não ser a perfect para clientes que aceitam poucos atrasos, mas preferem economizar custos. Agora, você pode configurar o comportamento do EMR Managed Scaling adequado para seus tipos de carga de trabalho, e aplicaremos a otimização personalizada para adicionar ou remover nós dos clusters de maneira inteligente. Isso ajuda você a obter o melhor custo-benefício para seus clusters, juntamente com maior flexibilidade de controles de usuário adicionais.

O valor definido para Superior Scaling otimiza seu cluster de acordo com seus requisitos. Os valores variam de 1 a 100. Os valores suportados são 1, 25, 50, 75 e 100. Se você definir o índice com valores diferentes desses, isso resultará em um erro de validação. Os valores de escala são mapeados para estratégias de utilização de recursos. A lista a seguir outline vários deles:

  • Utilização otimizada (1) – Essa configuração evita o provisionamento excessivo de recursos. Use um valor baixo quando quiser manter os custos baixos e priorizar a utilização eficiente de recursos. Isso faz com que o cluster aumente de forma menos agressiva. Isso funciona bem para o caso de uso quando há picos de carga de trabalho que ocorrem regularmente e você não deseja que os recursos aumentem muito rapidamente.
  • Equilibrado (50) – Isso equilibra a utilização de recursos e o desempenho do trabalho. Essa configuração é adequada para cargas de trabalho estáveis, nas quais a maioria dos estágios tem um tempo de execução estável. Também é adequado para cargas de trabalho com uma combinação de estágios de curta e longa duração. Recomendamos começar com esta configuração se você não tiver certeza de qual escolher.
  • Desempenho otimizado (100) – Esta estratégia prioriza o desempenho. O cluster aumenta agressivamente para garantir que os trabalhos sejam concluídos rapidamente e atinjam as metas de desempenho. O desempenho otimizado é adequado para cargas de trabalho sensíveis ao acordo de nível de serviço (SLA), onde o tempo de execução rápido é crítico.

Os clientes também podem escolher valores intermediários (25 e 75) para um controle mais sutil. Os valores intermediários disponíveis fornecem um meio-termo entre estratégias para ajustar o comportamento do Superior Scaling do seu cluster.

Apresentando melhorias no escalamento gerenciado do Amazon EMR

Casos de uso e benefícios

O recurso Superior Scaling do Amazon EMR melhora o gerenciamento de clusters, oferecendo adaptação dinâmica a diversos requisitos de negócios em todos os setores. O recurso permite um cronograma estratégico de políticas de escalabilidade ao longo do dia, com as primeiras horas da manhã dedicadas à preparação da carga de trabalho, horários comerciais de pico focados no desempenho máximo, períodos noturnos mantendo escalabilidade moderada para processamento pós-negócio e horas noturnas otimizadas para operações em lote econômicas. Essa abordagem abrangente permite que as organizações ajustem sua alocação de recursos com base em padrões operacionais específicos, proporcionando, em última análise, um equilíbrio perfect entre desempenho e economia, garantindo ao mesmo tempo que as necessidades de negócios sejam atendidas em diferentes fusos horários e padrões de uso.

Configuração de escalonamento

Nas seções a seguir, percorremos uma série de cenários de teste em um conjunto de dados TPC-DS de 3 TB e, em seguida, orientamos você nos resultados do teste de um trabalho de amostra. Queríamos avaliar como o Amazon EMR responderia com políticas de escalabilidade avançadas em cenários que otimizassem a utilização do cluster, equilibrando desempenho com utilização e requisitos agressivos de desempenho.

Com o Superior Scaling atualmente disponível por meio de API e suporte de console em breve, atualizamos as configurações de cluster existentes. Nós modificamos UtilizationPerformanceIndex com 1, 50 e 100, para corresponder às diferentes estratégias de escalonamento usando o put-managed-scaling-policy API com estratégia de escalabilidade avançada, como pode ser visto nos exemplos a seguir:

Cenário 1: Utilização otimizada

Neste cenário, usamos uma configuração otimizada para utilização definindo UtilizationPerformanceIndex para 1:

aws emr put-managed-scaling-policy --cluster-id <'cluster-id'>  
  --managed-scaling-policy '{ 
  "ComputeLimits": { 
    "UnitType": "Cases", 
    "MinimumCapacityUnits": 2, 
    "MaximumCapacityUnits": 50, 
    "MaximumOnDemandCapacityUnits": 50, 
    "MaximumCoreCapacityUnits": 2 
  	}, 
  }' 

O resultado do teste rendeu um pico de 16 nós em execução e 16 solicitados. O processo de aumento e redução de escala é conservador. Demora 15 minutos para liberar completamente os nós depois que a métrica solicitada diminui, conforme mostrado na figura a seguir. O trabalho foi concluído em 12 minutos e 39 segundos. UtilizationPerformanceIndex de 1 ou 25 pode ser útil quando o cluster está executando uma sequência de trabalhos com pouco ou nenhum tempo ocioso. Isso pode evitar a rotatividade frequente de nós porque os nós estarão disponíveis para o próximo conjunto de trabalhos.

Cenário 2: Equilibrado

Neste cenário, usamos uma configuração balanceada definindo UtilizationPerformanceIndex a 50:

aws emr put-managed-scaling-policy --cluster-id <'cluster-id'>  
  --managed-scaling-policy '{ 
  "ComputeLimits": { 
    "UnitType": "Cases", 
    "MinimumCapacityUnits": 2, 
    "MaximumCapacityUnits": 50, 
    "MaximumOnDemandCapacityUnits": 50, 
    "MaximumCoreCapacityUnits": 2 
  	}, 
  }' 
  

O resultado do teste rendeu um pico de 43 nós em execução e 32 solicitados. UtilizationPerformanceIndex de 50 utiliza uma abordagem equilibrada para dimensionar os recursos. Os nós solicitados e em execução são maiores, de modo que você pode obter uma melhor relação preço-desempenho. O trabalho foi concluído em 7 minutos e 1 segundo.

Cenário 3: Desempenho otimizado

Neste cenário, usamos uma configuração otimizada para desempenho definindo UtilizationPerformanceIndex para 100:

aws emr put-managed-scaling-policy --cluster-id <'cluster-id'>  
  --managed-scaling-policy '{ 
  "ComputeLimits": { 
    "UnitType": "Cases", 
    "MinimumCapacityUnits": 2, 
    "MaximumCapacityUnits": 50, 
    "MaximumOnDemandCapacityUnits": 50, 
    "MaximumCoreCapacityUnits": 2 
	  }, 
  }' 

O resultado do teste rendeu um pico de 50 nós em execução e 46 solicitados. UtilizationPerformanceIndex de 100 oferece o mais alto desempenho ao aumentar e diminuir agressivamente os recursos. Você pode esperar os nós mais altos solicitados e em execução nesta configuração. A redução seguirá de perto a métrica solicitada pelo nó e, portanto, poderá levar à rotatividade frequente de nós se houver curtos períodos de inatividade entre os envios de trabalhos. Essa configuração é perfect para cargas de trabalho sensíveis à latência que precisam ser concluídas sob SLA. O trabalho de exemplo foi concluído em 6 minutos e 16 segundos.

Comparação

A tabela a seguir resume as diferenças entre esses métodos de dimensionamento e o tempo gasto para cada um.

Método de dimensionamentoÍndice de utilizaçãoPico complete de nós solicitadosPico complete de nós em execuçãoTempo de execução do trabalho (segundos)Custo para executar o trabalhoCaso de uso
Cenário 1 – Utilização otimizada11616759BaixoCargas de trabalho com picos regulares; prioriza a eficiência de custos com escala conservadora
Cenário 2 – Equilibrado503243421MédioCargas de trabalho constantes com durações de estágio mistas; ponto de partida recomendado
Cenário 3 – Desempenho Otimizado1004650376AltoCargas de trabalho sensíveis ao SLA que exigem tempos de conclusão rápidos

A escalabilidade gerenciada avançada no Amazon EMR apresenta uma abordagem mais diferenciada para o gerenciamento de cluster por meio de estratégias de escalabilidade personalizadas para atender aos seus requisitos de negócios. Esse espectro oferece controle refinado sobre como os clusters respondem às demandas de carga de trabalho. Por um lado, com uma configuração de utilização otimizada de 1, o sistema prioriza o uso eficiente de recursos, aumentando de forma conservadora para manter a economia e aproveitando os recursos de cluster existentes. Na configuração equilibrada aos 50 anos, a estratégia visa encontrar um equilíbrio entre a utilização de recursos e o desempenho no trabalho. Para atender aos SLAs de desempenho, o valor de desempenho otimizado de 100 apresentou escalabilidade agressiva, respondendo rapidamente ao aumento da demanda por recursos, independentemente do consumo de recursos. Esse controle granular ajuda você a ajustar o comportamento do seu cluster com base em suas necessidades específicas, equilibrando custo, eficiência e desempenho.

Conclusão

Resumindo, o Superior Scaling for Amazon EMR representa um avanço no gerenciamento de clusters, oferecendo maior controle e eficiência. Ao ajustar o comportamento de seus clusters, você pode obter um processamento de massive knowledge mais econômico e com melhor desempenho. Incentivamos você a experimentar esse novo recurso e descobrir como ele pode otimizar suas cargas de trabalho de EMR. Comece experimentando diferentes UtilizationPerformanceIndex valores e monitore de perto o desempenho e as métricas de custo do seu cluster. Com o tempo, você poderá encontrar o equilíbrio perfeito que atenda às suas necessidades específicas.

Para saber mais sobre o Amazon EMR Managed Scaling e o Superior Scaling, consulte nosso documentação. Estamos entusiasmados em ver como você usará esse novo recurso para aprimorar seu processamento de massive knowledge na AWS e aguardamos seu suggestions à medida que continuamos a evoluir e melhorar nossos serviços.


Sobre os autores

Amit Maindola

Amit é arquiteto de dados sênior da equipe AWS ProServe com foco em engenharia de dados, análise e IA/ML na AWS. Ele ajuda os clientes em sua jornada de transformação digital e permite que eles criem soluções analíticas baseadas em nuvem altamente escaláveis, robustas e seguras na AWS para obter insights oportunos e tomar decisões de negócios críticas.

Bret Pontillo

Bret é arquiteto de soluções sênior na AWS. Ele trabalha em estreita colaboração com clientes empresariais criando knowledge lakes e aplicações analíticas na plataforma AWS. Em seu tempo livre, Bret gosta de viajar, assistir esportes e experimentar novos restaurantes.

Vishal Vyas

Vishal é engenheiro principal de desenvolvimento de software program na Amazon Internet Companies.

Mukesh Punhani

Mukesh é gerente sênior de software program na Amazon Internet Companies.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *