Usar o ajuste de escala gerenciado no Amazon EMR

A seguir Regiões da AWS, a escalabilidade gerenciada do Amazon EMR está disponível com o Amazon EMR 6.14.0 e superior:

A seguir Regiões da AWS, a escalabilidade gerenciada do Amazon EMR está disponível com o Amazon EMR 5.30.0 e 6.1.0 ou superior:

O Ajuste de Escala Gerenciado do Amazon EMR só funciona com aplicações YARN, como Spark, Hadoop, Hive e Flink. Ele não oferece suporte a aplicativos que não sejam baseados no YARN, como o Presto e. HBase

Minimum (MinimumCapacityUnits) — O limite inferior da EC2 capacidade permitida em um cluster. É medido por meio de núcleos ou instâncias da unidade central de processamento virtual (vCPU) para grupos de instâncias. É medido por meio de unidades para frotas de instâncias.

Máximo (MaximumCapacityUnits) — O limite superior da EC2 capacidade permitida em um cluster. É medido por meio de núcleos ou instâncias da unidade central de processamento virtual (vCPU) para grupos de instâncias. É medido por meio de unidades para frotas de instâncias.

Limite sob demanda (MaximumOnDemandCapacityUnits) (opcional) — O limite superior da EC2 capacidade permitida para o tipo de mercado sob demanda em um cluster. Se este parâmetro não for especificado, o valor MaximumCapacityUnits será usado como padrão.

Máximo de nós principais (MaximumCoreCapacityUnits) (opcional) — O limite superior da EC2 capacidade permitida para o tipo de nó principal em um cluster. Se este parâmetro não for especificado, o valor MaximumCapacityUnits será usado como padrão.

A escalabilidade gerenciada é suportada em versões limitadas Regiões da AWS e do Amazon EMR. Para obter mais informações, consulte Disponibilidade gerenciada de ajuste de escala.

Você deve configurar os parâmetros necessários para o Ajuste de Escala Gerenciado do Amazon EMR. Para obter mais informações, consulte Parâmetros do ajuste de escala gerenciado.

Para usar o ajuste de escala gerenciado, o processo coletor de métricas deve ser capaz de se conectar ao endpoint público da API para o ajuste de escala gerenciado no API Gateway. Se você usar um nome DNS privado com Amazon Virtual Private Cloud, o escalonamento gerenciado não funcionará corretamente. Para garantir que o ajuste de escala gerenciado funcione, é recomendável executar uma das seguintes ações:

Se os trabalhos do YARN ficarem intermitentemente lentos durante a redução da escala verticalmente e os logs do YARN Resource Manager mostrarem que a maioria dos nós foram listados como negados durante o período, você poderá ajustar o limite do tempo limite de desativação.

Reduza spark.blacklist.decommissioning.timeout de uma hora para um minuto para disponibilizar o nó para que outros contêineres pendentes continuem o processamento de tarefa.

Defina também YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs como um valor maior para garantir que o Amazon EMR não force o término do nó enquanto a “Tarefa do Spark” mais longa ainda estiver em execução no nó. O padrão atual é 60 minutos, o que significa que o YARN força o término do contêiner após 60 minutos, quando o nó entra no estado de desativação.

O exemplo a seguir da linha de log do YARN Resource Manager mostra os nós adicionados ao estado de desativação:

2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []

Veja mais detalhes sobre como o Amazon EMR se integra à lista de negação do YARN durante o desativação de nós, casos em que nós no Amazon EMR podem ser listados como negados e como configurar o comportamento de desativação de nós do Spark.

A utilização excessiva dos volumes do EBS pode causar problemas de ajuste de escala gerenciado. É recomendável manter o volume do EBS abaixo de 90% de utilização. Para obter mais informações, consulte Opções e comportamento de armazenamento de instâncias no Amazon EMR.

CloudWatch As métricas da Amazon são essenciais para a operação da escalabilidade gerenciada do Amazon EMR. Recomendamos que você monitore de perto CloudWatch as métricas da Amazon para garantir que os dados não estejam ausentes. Para obter mais informações sobre como você pode configurar CloudWatch alarmes para detectar métricas ausentes, consulte Usando CloudWatch alarmes da Amazon.

As operações de ajuste de escala gerenciado nos clusters das versões 5.30.0 e 5.30.1 sem o Presto instalado podem causar falhas na aplicação ou fazer com que um grupo de instâncias ou uma frota de instâncias uniforme permaneça no estado ARRESTED, sobretudo quando uma operação de redução da escala verticalmente logo é seguida por uma operação de aumento da escala verticalmente.

Como solução alternativa, escolha o Presto como uma aplicação a ser instalada ao criar um cluster com as versões 5.30.0 e 5.30.1 do Amazon EMR, mesmo que o trabalho não exija o Presto.

Ao definir o nó central máximo e o limite sob demanda para o Ajuste de Escala Gerenciado do Amazon EMR, leve em consideração as diferenças entre grupos de instâncias e frotas de instâncias. Cada grupo de instâncias consiste no mesmo tipo de instância e na mesma opção de compra para instâncias: sob demanda ou spot. Para cada frota de instâncias, você pode especificar até cinco tipos de instâncias, que podem ser configurados como instâncias sob demanda e spot. Para obter mais informações, consulte Create a cluster with instance fleets or uniform instance groups, Instance fleet options e Cenários de alocação de nós.

Com o Amazon EMR 5.30.0 e versões posteriores, ao remover a regra de saída Permitir tudo padrão para 0.0.0.0/ para o grupo de segurança principal, você deverá adicionar uma regra que permita a conectividade TCP de saída ao grupo de segurança para acesso ao serviço na porta 9443. O grupo de segurança para acesso ao serviço também deve permitir tráfego TCP de entrada na porta 9443 do grupo de segurança principal. Para obter mais informações sobre como configurar grupos de segurança, consulte Amazon EMR-managed security group for the primary instance (private subnets).

Você pode usar AWS CloudFormation para configurar a escalabilidade gerenciada do Amazon EMR. Consulte mais informações em AWS::EMR::Cluster no Guia de Usuário AWS CloudFormation .

Caso esteja usando nós spot, considere usar rótulos de nós para evitar que o Amazon EMR remova processos de aplicações quando o Amazon EMR remover nós spot. Para obter mais informações sobre rótulos de nós, consulte Task nodes.

Por padrão, a rotulagem de nós não é compatível com as versões 6.15 ou inferiores do Amazon EMR. Para obter mais informações, consulte Understand node types: primary, core, and task nodes.

Caso esteja usando as versões 6.15 ou inferiores do Amazon EMR, só poderá atribuir rótulos de nós por tipo de nó, como nós centrais e de tarefa. No entanto, se estiver usando o Amazon EMR versão 7.0 ou superior, poderá configurar rótulos de nós por tipo de nó e tipo de mercado, como sob demanda e spot.

Se a demanda do processo da aplicação aumentar e a demanda do executor diminuir ao restringir o processo da aplicação aos nós centrais, você poderá adicionar novamente os nós centrais e remover os nós de tarefa na mesma operação de redimensionamento. Para obter mais informações, consulte Understanding node allocation strategy and scenarios.

O Amazon EMR não rotula os nós de tarefas, então você não pode definir as propriedades do YARN para restringir os processos da aplicação somente para nós de tarefas. No entanto, caso queira usar tipos de mercado como rótulos de nós, poderá usar os rótulos ON_DEMAND ou SPOT para o posicionamento do processo da aplicação. Não recomendamos usar nós spot nos processos primários da aplicação.

Ao usar rótulos de nós, o total de unidades em execução no cluster pode exceder temporariamente a computação máxima definida na sua política de ajuste de escala gerenciado, enquanto o Amazon EMR desativa algumas de suas instâncias. O total de unidades solicitadas sempre permanecerá igual ou abaixo da computação máxima da política.

O ajuste de escala gerenciado é compatível apenas com os rótulos dos nós ON_DEMAND e SPOT ou CORE e TASK. Não há suporte para rótulos de nós personalizados.

O Amazon EMR cria rótulos de nós ao criar o cluster e provisionar recursos. O Amazon EMR não oferece suporte à adição de rótulos de nós ao reconfigurar o cluster. Você também não pode modificar os rótulos dos nós ao configurar o ajuste de escala gerenciado após executar o cluster.

O ajuste de escala gerenciado dimensiona os nós centrais e de tarefas de forma independente, com base no processo da aplicação e na demanda do executor. Para evitar problemas de perda de dados do HDFS durante a redução vertical da escala central, siga a prática padrão para os nós centrais. Para saber mais sobre as práticas recomendadas para nós centrais e replicação do HDFS, consulte Considerations and best practices.

Você não pode colocar o processo da aplicação e os executores somente no nó core ou ON_DEMAND. Caso queira adicionar o processo da aplicação e os executores em um dos nós, não use a configuração yarn.node-labels.am.default-node-label-expression.

Por exemplo, para colocar o processo da aplicação e os executores em nós ON_DEMAND, defina a computação máxima como a máxima no nó ON_DEMAND. Remova também a configuração yarn.node-labels.am.default-node-label-expression.

Para adicionar o processo da aplicação e os executores nos nós core, remova a configuração yarn.node-labels.am.default-node-label-expression.

Ao usar o ajuste de escala gerenciado com rótulos de nós, defina a propriedade yarn.scheduler.capacity.maximum-am-resource-percent: 1 se planeja executar várias aplicações em paralelo. Isso garante que os processos da aplicação utilizem totalmente os nós CORE ou ON_DEMAND disponíveis.

Caso use ajuste de escala gerenciado com rótulos de nós, defina a propriedade yarn.resourcemanager.decommissioning.timeout para um valor maior do que a aplicação de execução mais longa no cluster. Isso reduz a chance de o ajuste de escala gerenciado do Amazon EMR precisar reprogramar suas aplicações para desativar nós CORE ou ON_DEMAND.

Para reduzir o risco de falhas no aplicativo devido à perda aleatória de dados, o Amazon EMR coleta métricas do cluster para determinar os nós que têm dados aleatórios transitórios existentes do estágio atual e anterior. Em casos raros, as métricas podem continuar relatando dados obsoletos de aplicativos que já foram concluídos ou encerrados. Isso pode afetar a redução oportuna das instâncias em seu cluster. Para clusters que têm uma grande quantidade de dados aleatórios, considere usar as versões 6.13 e posteriores do EMR.