As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Usar o ajuste de escala gerenciado no Amazon EMR **Importante** É altamente recomendável que você use a versão mais recente do Amazon EMR (Amazon EMR 7.12.0) para escalabilidade gerenciada. Em versões anteriores, você pode enfrentar falhas de aplicações intermitentes ou atrasos no ajuste de escala. O Amazon EMR resolveu esse problema nas versões 5.x: 5.30.2, 5.31.1, 5.32.1, 5.33.1 e posteriores, e nas versões 6.x: 6.1.1, 6.2.1, 6.3.1 e posteriores. Para ter mais informações sobre Regiões e disponibilidade de versões, consulte [Disponibilidade gerenciada de ajuste de escala](#emr-managed-scaling-availability). ## Visão geral do Com o Amazon EMR 5.30.0 e versões posteriores (exceto para o Amazon EMR 6.0.0), você pode habilitar o Ajuste de Escala Gerenciado do Amazon EMR. Com o ajuste de escala gerenciado, é possível aumentar ou diminuir automaticamente o número de instâncias ou unidades no cluster com base na workload. O Amazon EMR avalia continuamente as métricas do cluster para tomar decisões de ajuste de escala que otimizam os clusters em termos de custo e velocidade. O ajuste de escala gerenciado está disponível para clusters compostos por grupos de instâncias ou frotas de instâncias. ## Disponibilidade gerenciada de ajuste de escala + A seguir Regiões da AWS, a escalabilidade gerenciada do Amazon EMR está disponível com o Amazon EMR 6.14.0 e superior: + Ásia-Pacífico (Taipei) (ap-east-2) + Ásia-Pacífico (Melbourne) (ap-southeast-4) + Ásia-Pacífico (Malásia) (ap-southeast-5) + Ásia-Pacífico (Nova Zelândia) (ap-southeast-6) + Ásia-Pacífico (Tailândia) (ap-southeast-7) + Oeste do Canadá (Calgary) ca-west-1 + Europa (Espanha) (eu-south-2) + México (Centro) (mx-central-1) + 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: + Leste dos EUA (Norte da Virgínia) (us-east-1) + Leste dos EUA (Ohio) (us-east-2) + Oeste dos EUA (Oregon) (us-west-2) + Oeste dos EUA (Norte da Califórnia) (us-west-1) + África (Cidade do Cabo) (af-south-1) + Ásia-Pacífico (Hong Kong) (ap-east-1) + Ásia-Pacífico (Mumbai) (ap-south-1) + Ásia-Pacífico (Hyderabad) (ap-south-2) + Ásia-Pacífico (Seul) (ap-northeast-2) + Ásia-Pacífico (Singapura) (ap-southeast-1) + Ásia-Pacífico (Sydney) (ap-southeast-2) + Ásia-Pacífico (Jacarta) (ap-southeast-3) + Ásia Pacific (Tóquio) (ap-northeast-1) + Ásia-Pacífico (Osaka) (ap-northeast-3) + Canadá (Central) (ca-central-1) + América do Sul (São Paulo) (sa-east-1) + Europa (Frankfurt) (eu-central-1) + Europa (Zurique) (eu-central-2) + Europa (Irlanda) (eu-west-1) + Europa (Londres) (eu-west-2) + UE (Milão) (eu-south-1) + Europa (Paris) (eu-west-3) + UE (Estocolmo) (eu-north-1) + Israel (Tel Aviv) (il-central-1) + Oriente Médio (EAU) (me-central-1) + China (Pequim) (cn-north-1) + China (Ningxia) (cn-northwest-1) + AWS GovCloud (Leste dos EUA) (us-gov-east-1) + AWS GovCloud (Oeste dos EUA) (us-gov-west-1) + 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 ## Parâmetros do ajuste de escala gerenciado É necessário configurar os parâmetros a seguir para ajuste de escala gerenciado. O limite só se aplica aos nós core e de tarefa. Não é possível escalar o nó primário após a configuração inicial. + **Mínimo** (`MinimumCapacityUnits`): o limite inferior da capacidade permitida do EC2 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 capacidade permitida do EC2 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 capacidade permitida do EC2 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. + Esse parâmetro é usado para dividir a alocação de capacidade entre instâncias sob demanda e spot. Por exemplo, se você definir o parâmetro mínimo como duas instâncias, o parâmetro máximo como cem instâncias e o limite sob demanda como dez instâncias, o Ajuste de Escala Gerenciado do Amazon EMR escalará até dez instâncias sob demanda e alocará a capacidade restante para instâncias spot. Para obter mais informações, consulte [Cenários de alocação de nós](managed-scaling-allocation-strategy.md#node-allocation-scenarios). + **Máximo de nós centrais** (`MaximumCoreCapacityUnits`) (opcional): o limite superior da capacidade permitida do EC2 para o tipo de nó central em um cluster. Se este parâmetro não for especificado, o valor `MaximumCapacityUnits` será usado como padrão. + Esse parâmetro é usado para dividir a alocação de capacidade entre nós de centrais e de tarefa. Por exemplo, se você definir o parâmetro mínimo como duas instâncias, o máximo como cem instâncias e o nó central máximo como 17 instâncias, o Ajuste de Escala Gerenciado do Amazon EMR escalará até 17 nós principais e alocará as 83 instâncias restantes aos nós de tarefa. Para obter mais informações, consulte [Cenários de alocação de nós](managed-scaling-allocation-strategy.md#node-allocation-scenarios). Para obter mais informações sobre parâmetros de ajuste de escala gerenciado, consulte [https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html). ## Considerações sobre Ajuste de Escala Gerenciado do Amazon EMR + 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](#emr-managed-scaling-availability). + 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](#emr-managed-scaling-parameters). + 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: + Remova o endpoint da VPC de interface do API Gateway da Amazon VPC. + Siga as instruções em [Por que recebo um erro HTTP 403 Proibido ao me conectar ao meu API Gateway a APIs partir de uma VPC](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-vpc-connections/)? para desativar a configuração do nome DNS privado. + Em vez disso, inicie o cluster em sua sub-rede privada. Para obter mais informações, consulte o tópico em [Sub-redes privadas](emr-clusters-in-a-vpc.md#emr-vpc-private-subnet). + 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](https://aws.amazon.com/blogs/big-data/spark-enhancements-for-elasticity-and-resiliency-on-amazon-emr/), [casos em que nós no Amazon EMR podem ser listados como negados](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-troubleshoot-error-resource-3.html) e [como configurar o comportamento de desativação de nós do Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-decommissioning). + Para workloads do Spark, desabilitar o Spark Dynamic Resource Allocator (DRA) alterando a propriedade Spark **spark.dynamicAllocation.enabled** para `FALSE` pode causar problemas de ajuste de escala gerenciado, em que os clusters podem aumentar a escala verticalmente mais do que o necessário para suas workloads (até a computação máxima). Ao usar o ajuste de escala gerenciado para essas workloads, recomendamos que você mantenha o Spark DRA habilitado, que é o estado padrão dessa propriedade. + 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](emr-plan-storage.md). + 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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). + 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-group-configuration.html), [Instance fleet options](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html#emr-instance-fleet-options) e [Cenários de alocação de nós](managed-scaling-allocation-strategy.md#node-allocation-scenarios). + 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)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-master-private). + Você pode usar AWS CloudFormation para configurar a escalabilidade gerenciada do Amazon EMR. Consulte mais informações em [AWS::EMR::Cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticmapreduce-cluster.html) 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html#emr-plan-task). + 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.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html) + 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html). + 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-considerations.html). + 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 na aplicação devido à perda de dados de shuffle, 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 do anterior. Em casos raros, as métricas podem continuar relatando dados obsoletos de aplicações que já foram concluídas ou encerradas. Isso pode afetar a redução oportuna da escala vertical das instâncias no seu cluster. Para clusters com grandes quantidades de dados de shuffle, considere usar as versões 6.13 e posteriores do EMR. ## Histórico de recursos Esta tabela lista as atualizações na funcionalidade de ajuste de escala gerenciado do Amazon EMR. | Data de lançamento | Recurso | Versões do Amazon EMR | | --- | --- | --- | | 20 de novembro de 2024 | O ajuste de escala gerenciado está disponível nas regiões il-central-1 Israel (Tel Aviv), me-central-1 Oriente Médio (Emirados Árabes Unidos) e ap-northeast-3 Ásia-Pacífico (Osaka). | 5.30.0, 6.1.0 e superiores | | 15 de novembro de 2024 | O ajuste de escala gerenciado está disponível na região eu-central-2 Europa (Zurique). | 5.30.0, 6.1.0 e superiores | | 20 de agosto de 2024 | Os rótulos de nós já estão disponíveis no ajuste de escala gerenciado, para que você possa rotular instâncias com base no tipo de mercado ou de nó para melhorar o ajuste de escala automático. | Versão 7.2.0 e posterior | | 31 de março de 2024 | O ajuste de escala gerenciado está disponível na região ap-south-2 Ásia-Pacífico (Hyderabad). | 6.14.0 e posterior | | 13 de fevereiro de 2024 | O ajuste de escala gerenciado está disponível na região eu-south-2 Europa (Espanha). | 6.14.0 e posterior | | 10 de outubro de 2023 | Ajuste de Escala Gerenciado disponível na região ap-southeast-3 Ásia-Pacífico (Jacarta). | 6.14.0 e posterior | | 28 de julho de 2023 | O ajuste de escala gerenciado foi aprimorado para alternar para um grupo de instâncias de tarefa diferente ao aumentar a escala verticalmente quando o Amazon EMR sofre um atraso ao aumentar a escala verticalmente com o grupo de instâncias atual. | 5.34.0 e posteriores, 6.4.0 e posteriores | | 16 de junho de 2023 | O ajuste de escala gerenciado foi aprimorado para reconhecer os nós que executam a aplicação principal, de forma que esses nós não sejam reduzidos. Para obter mais informações, consulte [Noções básicas da estratégia e dos cenários de alocação de nós do Amazon EMR](managed-scaling-allocation-strategy.md). | 5.34.0 e posteriores, 6.4.0 e posteriores | | 21 de março de 2022 | Foi adicionado o reconhecimento de dados de shuffle do Spark usado ao reduzir a escala verticalmente de clusters. Para clusters do Amazon EMR com o Apache Spark e o atributo de ajuste de escala gerenciado habilitado, o Amazon EMR monitora continuamente os executores do Spark e os locais intermediários de dados de shuffle. Com essas informações, o Amazon EMR reduz a escala verticalmente apenas das instâncias subutilizadas que não contêm dados de shuffle usados ativamente. Isso evita o recálculo de dados de shuffle perdidos, ajudando a reduzir custos e melhorar a performance do trabalho. Para obter mais informações, consulte o [Spark Programming Guide](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). | 5.34.0 e posteriores, 6.4.0 e posteriores | # Configuração do ajuste de escala gerenciado para o Amazon EMR As seções a seguir explicam como iniciar um cluster do EMR que usa escalabilidade gerenciada com o Console de gerenciamento da AWS AWS SDK para Java, o ou o. AWS Command Line Interface **Topics** + [ ## Use o Console de gerenciamento da AWS para configurar o escalonamento gerenciado ](#managed-scaling-console) + [ ## Use o AWS CLI para configurar o escalonamento gerenciado ](#managed-scaling-cli) + [ ## Use AWS SDK para Java para configurar o escalonamento gerenciado ](#managed-scaling-sdk) ## Use o Console de gerenciamento da AWS para configurar o escalonamento gerenciado Você pode usar o console do Amazon EMR para configurar o ajuste de escala gerenciado ao criar um cluster ou para alterar uma política de ajuste de escala gerenciado para um cluster em execução. ------ #### [ Console ] **Para configurar o ajuste de escala gerenciado ao criar um cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e depois **Criar cluster**. 1. Escolha uma versão **emr-5.30.0** ou posterior do Amazon EMR, exceto a versão **emr-6.0.0**. 1. Em **Opção de ajuste de escala e provisionamento de clusters**, escolha **Usar ajuste de escala gerenciado pelo EMR**. Especifique o número **mínimo** e **máximo** de instâncias, o **máximo de instâncias do nó central** e o **máximo de instâncias sob demanda**. 1. Escolha qualquer outra opção que se aplique ao cluster. 1. Para iniciar o cluster, escolha **Criar cluster**. **Para configurar o ajuste de escala gerenciado em um cluster existente usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e selecione o cluster que você deseja atualizar. 1. Na guia **Instâncias** da página de detalhes do cluster, encontre a seção **Configurações do grupo de instâncias**. Na seção **Editar ajuste de escala do cluster**, especifique novos valores para os números **Mínimo** e **Máximo** de instâncias e o limite **Sob demanda**. ------ ## Use o AWS CLI para configurar o escalonamento gerenciado Você pode usar AWS CLI comandos do Amazon EMR para configurar a escalabilidade gerenciada ao criar um cluster. Você pode usar uma sintaxe abreviada, especificando a configuração do JSON nas linhas dos comandos relevantes, ou pode fazer referência a um arquivo que contém a configuração do JSON. Também é possível aplicar uma política de escalabilidade gerenciada a um cluster existente e remover uma política de escalabilidade gerenciada que foi aplicada anteriormente. Além disso, você pode recuperar os detalhes da configuração de uma política de escalabilidade de um cluster em execução. **Habilitar a escalabilidade gerenciada durante a execução do cluster** É possível habilitar a escalabilidade gerenciada durante a execução do cluster, conforme demonstra o exemplo a seguir. ``` aws emr create-cluster \ --service-role EMR_DefaultRole \ --release-label emr-7.12.0 \ --name EMR_Managed_Scaling_Enabled_Cluster \ --applications Name=Spark Name=Hbase \ --ec2-attributes KeyName=keyName,InstanceProfile=EMR_EC2_DefaultRole \ --instance-groups InstanceType=m4.xlarge,InstanceGroupType=MASTER,InstanceCount=1 InstanceType=m4.xlarge,InstanceGroupType=CORE,InstanceCount=2 \ --region us-east-1 \ --managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=2,MaximumCapacityUnits=4,UnitType=Instances}' ``` Você também pode especificar uma configuração de política gerenciada usando a managed-scaling-policy opção -- ao usar`create-cluster`. **Aplicar uma política de escalabilidade gerenciada a um cluster existente** É possível aplicar uma política de escalabilidade gerenciada a um cluster existente, conforme demonstra o exemplo a seguir. ``` aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=1, MaximumCapacityUnits=10, MaximumOnDemandCapacityUnits=10, UnitType=Instances}' ``` Também é possível aplicar uma política de escalabilidade gerenciada a um cluster existente usando o comando `aws emr put-managed-scaling-policy`. O exemplo a seguir usa uma referência a um arquivo JSON `managedscaleconfig.json`, que especifica a configuração da política de escalabilidade gerenciada. ``` aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy file://./managedscaleconfig.json ``` O exemplo a seguir mostra o conteúdo do arquivo `managedscaleconfig.json`, que define a política de escalabilidade gerenciada. ``` { "ComputeLimits": { "UnitType": "Instances", "MinimumCapacityUnits": 1, "MaximumCapacityUnits": 10, "MaximumOnDemandCapacityUnits": 10 } } ``` **Recuperar uma configuração de política de escalabilidade gerenciada** O comando `GetManagedScalingPolicy` recupera a configuração da política. Por exemplo, o comando a seguir recupera a configuração de um cluster com o ID `j-123456`. ``` aws emr get-managed-scaling-policy --cluster-id j-123456 ``` Este comando gera o seguinte exemplo de saída. ``` 1. { 2. "ManagedScalingPolicy": { 3. "ComputeLimits": { 4. "MinimumCapacityUnits": 1, 5. "MaximumOnDemandCapacityUnits": 10, 6. "MaximumCapacityUnits": 10, 7. "UnitType": "Instances" 8. } 9. } 10. } ``` Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr) **Remover a política de escalabilidade gerenciada** O comando `RemoveManagedScalingPolicy` remove a configuração da política. Por exemplo, o comando a seguir remove a configuração de um cluster com o ID `j-123456`. ``` aws emr remove-managed-scaling-policy --cluster-id j-123456 ``` ## Use AWS SDK para Java para configurar o escalonamento gerenciado O trecho do programa a seguir mostra como configurar a escalabilidade gerenciada usando o AWS SDK para Java: ``` package com.amazonaws.emr.sample; import java.util.ArrayList; import java.util.List; import com.amazonaws.AmazonClientException; import com.amazonaws.auth.AWSCredentials; import com.amazonaws.auth.AWSStaticCredentialsProvider; import com.amazonaws.auth.profile.ProfileCredentialsProvider; import com.amazonaws.regions.Regions; import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduce; import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClientBuilder; import com.amazonaws.services.elasticmapreduce.model.Application; import com.amazonaws.services.elasticmapreduce.model.ComputeLimits; import com.amazonaws.services.elasticmapreduce.model.ComputeLimitsUnitType; import com.amazonaws.services.elasticmapreduce.model.InstanceGroupConfig; import com.amazonaws.services.elasticmapreduce.model.JobFlowInstancesConfig; import com.amazonaws.services.elasticmapreduce.model.ManagedScalingPolicy; import com.amazonaws.services.elasticmapreduce.model.RunJobFlowRequest; import com.amazonaws.services.elasticmapreduce.model.RunJobFlowResult; public class CreateClusterWithManagedScalingWithIG { public static void main(String[] args) { AWSCredentials credentialsFromProfile = getCreadentials("AWS-Profile-Name-Here"); /** * Create an Amazon EMR client with the credentials and region specified in order to create the cluster */ AmazonElasticMapReduce emr = AmazonElasticMapReduceClientBuilder.standard() .withCredentials(new AWSStaticCredentialsProvider(credentialsFromProfile)) .withRegion(Regions.US_EAST_1) .build(); /** * Create Instance Groups - Primary, Core, Task */ InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig() .withInstanceCount(1) .withInstanceRole("MASTER") .withInstanceType("m4.large") .withMarket("ON_DEMAND"); InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig() .withInstanceCount(4) .withInstanceRole("CORE") .withInstanceType("m4.large") .withMarket("ON_DEMAND"); InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig() .withInstanceCount(5) .withInstanceRole("TASK") .withInstanceType("m4.large") .withMarket("ON_DEMAND"); List igConfigs = new ArrayList<>(); igConfigs.add(instanceGroupConfigMaster); igConfigs.add(instanceGroupConfigCore); igConfigs.add(instanceGroupConfigTask); /** * specify applications to be installed and configured when Amazon EMR creates the cluster */ Application hive = new Application().withName("Hive"); Application spark = new Application().withName("Spark"); Application ganglia = new Application().withName("Ganglia"); Application zeppelin = new Application().withName("Zeppelin"); /** * Managed Scaling Configuration - * Using UnitType=Instances for clusters composed of instance groups * * Other options are: * UnitType = VCPU ( for clusters composed of instance groups) * UnitType = InstanceFleetUnits ( for clusters composed of instance fleets) **/ ComputeLimits computeLimits = new ComputeLimits() .withMinimumCapacityUnits(1) .withMaximumCapacityUnits(20) .withUnitType(ComputeLimitsUnitType.Instances); ManagedScalingPolicy managedScalingPolicy = new ManagedScalingPolicy(); managedScalingPolicy.setComputeLimits(computeLimits); // create the cluster with a managed scaling policy RunJobFlowRequest request = new RunJobFlowRequest() .withName("EMR_Managed_Scaling_TestCluster") .withReleaseLabel("emr-7.12.0") // Specifies the version label for the Amazon EMR release; we recommend the latest release .withApplications(hive,spark,ganglia,zeppelin) .withLogUri("s3://path/to/my/emr/logs") // A URI in S3 for log files is required when debugging is enabled. .withServiceRole("EMR_DefaultRole") // If you use a custom IAM service role, replace the default role with the custom role. .withJobFlowRole("EMR_EC2_DefaultRole") // If you use a custom Amazon EMR role for EC2 instance profile, replace the default role with the custom Amazon EMR role. .withInstances(new JobFlowInstancesConfig().withInstanceGroups(igConfigs) .withEc2SubnetId("subnet-123456789012345") .withEc2KeyName("my-ec2-key-name") .withKeepJobFlowAliveWhenNoSteps(true)) .withManagedScalingPolicy(managedScalingPolicy); RunJobFlowResult result = emr.runJobFlow(request); System.out.println("The cluster ID is " + result.toString()); } public static AWSCredentials getCredentials(String profileName) { // specifies any named profile in .aws/credentials as the credentials provider try { return new ProfileCredentialsProvider("AWS-Profile-Name-Here") .getCredentials(); } catch (Exception e) { throw new AmazonClientException( "Cannot load credentials from .aws/credentials file. " + "Make sure that the credentials file exists and that the profile name is defined within it.", e); } } public CreateClusterWithManagedScalingWithIG() { } } ``` # Ajuste de escala avançado para o Amazon EMR Começando com o Amazon EMR no EC2 versão 7.0, é possível utilizar o Ajuste de escala avançado para controlar o uso de recursos do cluster. O Advanced Scaling introduz uma escala de utilização-desempenho para ajustar a utilização dos recursos e o nível de desempenho de acordo com as necessidades da sua empresa. O valor que você define determina se seu cluster é mais voltado para a conservação de recursos ou para a escalabilidade para lidar com cargas de trabalho sensíveis service-level-agreement (SLA), onde a conclusão rápida é essencial. Quando o valor do ajuste de escala é ajustado, o ajuste de escala gerenciado interpreta sua intenção e escala de maneira inteligente para otimizar os recursos. Para obter mais informações sobre o Ajuste de escala gerenciado, consulte [Configurar o Ajuste de escala gerenciado para o Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-configure.html). ## Configurações avançadas de dimensionamento O valor que você definiu para o Ajuste de escala avançado otimiza o cluster de acordo com seus requisitos. Os valores variam de **1** a **100**. Os valores possíveis são **1**, **25**, **50**, **75** e **100**. Se você definir o índice para valores diferentes, isso resultará em um erro de validação. Valores de ajuste de escala são mapeados para estratégias de utilização de recursos. A lista a seguir define várias delas: + **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 dos recursos. Isso faz com que o cluster aumente a escala verticalmente de maneira menos agressiva. Isso funciona bem para o caso de uso em que costumam ocorrer picos de workload e você não quer que os recursos aumentem muito rapidamente. + **Equilibrada [50]**: equilibra a utilização de recursos e a performance dos trabalhos. Essa configuração é adequada para workloads estáveis em que a maioria dos estágios tem um runtime estável. Também é adequado para workloads com uma combinação de estágios de curta e longa duração. Recomendamos começar com essa configuração se você não tem certeza de qual escolher. + **Otimizad para performance [100]**: essa estratégia prioriza a performance. O cluster se expande de maneira agressiva para garantir que os trabalhos sejam concluídos rapidamente e atendam às metas de performance. O desempenho otimizado é adequado para cargas de trabalho sensíveis service-level-agreement (SLA), nas quais o tempo de execução rápido é essencial. **nota** Os valores intermediários disponíveis fornecem um meio termo entre essas estratégias para ajustar o comportamento de Ajuste de escala avançado do cluster. ## Benefícios do escalonamento avançado Como há variabilidade no ambiente e nos requisitos, como alterações nos volumes de dados, ajustes nas metas de custos e implementações de SLAs, o ajuste de escala do cluster pode ajudar você a ajustar a configuração do cluster para atingir os seus objetivos. Os benefícios importantes incluem: + **Controle granular aprimorado**: a introdução da configuração de performance de utilização permite ajustar facilmente o comportamento de ajuste de escala do cluster de acordo com os seus requisitos. Você pode aumentar a escala verticalmente para atender à demanda por recursos de computação ou reduzir a escala verticalmente para economizar recursos com base em seus padrões de uso. + **Otimização de custos aprimorada**: você pode escolher um valor de utilização baixo, conforme os requisitos, para atender com mais facilidade aos seus objetivos de custo. ## Conceitos básicos sobre otimização **Instalação e configuração** Use estas etapas para definir o índice de performance e otimizar sua estratégia de ajuste de escala. 1. O comando a seguir atualiza um cluster existente com a estratégia de ajuste de escala `[1]` otimizada para utilização: ``` aws emr put-managed-scaling-policy --cluster-id 'cluster-id' \ --managed-scaling-policy '{ "ComputeLimits": { "UnitType": "Instances", "MinimumCapacityUnits": 1, "MaximumCapacityUnits": 2, "MaximumOnDemandCapacityUnits": 2, "MaximumCoreCapacityUnits": 2 }, "ScalingStrategy": "ADVANCED", "UtilizationPerformanceIndex": "1" }' \ --region "region-name" ``` Os atributos `ScalingStrategy` e `UtilizationPerformanceIndex` são novos e relevantes para a otimização de ajuste de escala. Você pode selecionar diferentes estratégias de ajuste de escala definindo valores correspondentes (1, 25, 50, 75 e 100) para o atributo `UtilizationPerformanceIndex` na política de ajuste de escala gerenciada. 1. Para reverter para a estratégia padrão de ajuste de escala gerenciado, execute o comando `put-managed-scaling-policy` sem incluir os atributos `ScalingStrategy` e `UtilizationPerformanceIndex`. (Isso é opcional.) Este exemplo mostra como fazer isso: ``` aws emr put-managed-scaling-policy \ --cluster-id 'cluster-id' \ --managed-scaling-policy '{"ComputeLimits":{"UnitType":"Instances","MinimumCapacityUnits":1,"MaximumCapacityUnits":2,"MaximumOnDemandCapacityUnits":2,"MaximumCoreCapacityUnits":2}}' \ --region "region-name" ``` **Usar métricas de monitoramento para rastrear a utilização do cluster** A partir da versão 7.3.0 do EMR, o Amazon EMR publica quatro novas métricas relacionadas à memória e à CPU virtual. Você pode usá-las para medir a utilização do cluster em todas as estratégias de ajuste de escala. Essas métricas estão disponíveis para qualquer caso de uso, mas você pode usar os detalhes fornecidos aqui para monitorar o Ajuste de escala avançado. As métricas úteis disponíveis incluem: + **YarnContainersUsedMemoryGBSeconds**— Quantidade de memória consumida por aplicativos gerenciados pelo YARN. + **YarnContainersTotalMemoryGBSeconds**— Capacidade total de memória alocada ao YARN dentro do cluster. + **YarnNodesUsedVCPUSeconds**— Total de segundos de VCPU para cada aplicativo gerenciado pelo YARN. + **YarnNodesTotalVCPUSeconds**— Total agregado de segundos de VCPU para memória consumida, incluindo a janela de tempo em que o fio não está pronto. Você pode analisar métricas de recursos usando o Amazon CloudWatch Logs Insights. Os recursos incluem uma linguagem de consulta específica que ajuda a extrair métricas específicas para uso e ajuste de escala de recursos. A consulta a seguir, que você pode executar no Amazon CloudWatch console, usa matemática métrica para calcular a utilização média da memória (e1) dividindo a soma contínua da memória consumida (e2) pela soma da memória total (e3): ``` { "metrics": [ [ { "expression": "e2/e3", "label": "Average Mem Utilization", "id": "e1", "yAxis": "right" } ], [ { "expression": "RUNNING_SUM(m1)", "label": "RunningTotal-YarnContainersUsedMemoryGBSeconds", "id": "e2", "visible": false } ], [ { "expression": "RUNNING_SUM(m2)", "label": "RunningTotal-YarnContainersTotalMemoryGBSeconds", "id": "e3", "visible": false } ], [ "AWS_EMR_ManagedResize", "YarnContainersUsedMemoryGBSeconds", "ACCOUNT_ID", "793684541905", "COMPONENT", "ManagerService", "JOB_FLOW_ID", "cluster-id", { "id": "m1", "label": "YarnContainersUsedMemoryGBSeconds" } ], [ ".", "YarnContainersTotalMemoryGBSeconds", ".", ".", ".", ".", ".", ".", { "id": "m2", "label": "YarnContainersTotalMemoryGBSeconds" } ] ], "view": "timeSeries", "stacked": false, "region": "region", "period": 60, "stat": "Sum", "title": "Memory Utilization" } ``` Para consultar registros, você pode selecionar CloudWatch no AWS console. Para obter mais informações sobre como escrever consultas para CloudWatch, consulte [Análise de dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) no Guia do usuário do Amazon CloudWatch Logs. A imagem a seguir mostra essas métricas para um cluster de exemplo: ![\[Gráfico mostrando estatísticas de utilização.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/scaling_graph_EMR.png) ## Considerações e limitações + A eficácia das estratégias de ajuste de escala pode variar dependendo das características exclusivas da workload e da configuração do cluster. Recomendamos que você experimente a configuração de ajuste de escala para determinar um valor de índice ideal para o seu caso de uso. + O Ajuste de escala automático do Amazon EMR é particularmente adequado para workloads em lotes. Para workloads de SQL/data warehouse e streaming, recomendamos usar a estratégia padrão de ajuste de escala gerenciado para obter performance ideal. + O Amazon EMR Advanced Scaling não é suportado quando as configurações de rótulos de nós estão habilitadas no cluster. Se as configurações Advanced Scaling e Node Label estiverem habilitadas juntas em um cluster, o comportamento de escalabilidade seria como se a configuração padrão de escalabilidade gerenciada estivesse ativada. + A estratégia de ajuste de escala otimizada para performance permite a execução mais rápida do trabalho, mantendo recursos de alta computação por um período mais longo do que a estratégia padrão de ajuste de escala gerenciado. Esse modo prioriza o aumento rápido da escala vertical para atender a demandas de recursos, resultando na conclusão mais rápida do trabalho. Isso pode resultar em custos mais altos em comparação com a estratégia padrão. + Nos casos em que o cluster já está otimizado e totalmente utilizado, habilitar o Ajuste de escala avançado pode não oferecer benefícios adicionais. Em algumas situações, habilitar o Ajuste de escala avançado pode aumentar os custos, pois as workloads podem durar mais. Nesses casos, recomendamos usar a estratégia padrão de ajuste de escala gerenciado para garantir a alocação ideal de recursos e a eficiência dos custos. + **No contexto do Ajuste de escala gerenciado, a ênfase muda para a utilização de recursos ao longo do tempo de execução, à medida que a configuração é ajustada de otimizada para performance [**100**] para otimizada para utilização [1**]. Porém, é importante observar que os resultados podem variar com base na natureza da workload e na topologia do cluster. Para garantir resultados ideais para seu caso de uso, é altamente recomendável testar as estratégias de ajuste de escala com suas workloads para determinar a configuração mais adequada. + O **PerformanceUtilizationIndex**aceita somente os seguintes valores: + **1** + **25** + **50** + **75** + **100** Quaisquer outros valores enviados resultam em um erro de validação. # Noções básicas da estratégia e dos cenários de alocação de nós do Amazon EMR Esta seção fornece uma visão geral da estratégia de alocação de nós e dos cenários comuns de ajuste de escala que você pode usar com o Ajuste de Escala Gerenciado do Amazon EMR. ## Estratégia de alocação de nós O Ajuste de Escala Gerenciado do Amazon EMR aloca nós centrais e de tarefa com base nas seguintes estratégias de aumento e redução da escala verticalmente: **Estratégia de aumento da escala verticalmente** + Para as versões 7.2 e superiores do Amazon EMR, o ajuste de escala gerenciado primeiro adiciona nós com base nos rótulos dos nós e na propriedade do YARN de restrição do processo de aplicação. + Para as versões 7.2 e superiores do Amazon EMR, caso tenha habilitado rótulos de nós e restringido processos de aplicações a nós `CORE`, o Ajuste de Escala Gerenciado do Amazon EMR aumenta a escala verticalmente de nós centrais e os nós de tarefas se a demanda do processo da aplicação e a demanda do executor aumentarem. Da mesma forma, caso tenha habilitado os rótulos de nós e restringido os processos da aplicação aos nós `ON_DEMAND`, o ajuste de escala gerenciado ampliará verticalmente os nós sob demanda se a demanda do processo da aplicação aumentar e escalará os nós spot se a demanda do executor crescer. + Se os rótulos de nós não estiverem habilitados, o posicionamento do processo da aplicação não estará restrito a nenhum nó ou tipo de mercado. + Ao usar rótulos de nós, o ajuste de escala gerenciado pode aumentar e reduzir a escala verticalmente de diferentes grupos de instâncias e frotas de instâncias na mesma operação de redimensionamento. Por exemplo, em um cenário em que `instance_group1` tem um nó `ON_DEMAND` e `instance_group2` tem um nó `SPOT`, os rótulos dos nós estão habilitados e os processos da aplicação são restritos aos nós com o rótulo `ON_DEMAND`. O ajuste de escala gerenciado reduzirá a escala verticalmente de `instance_group1` e aumentará a escala verticalmente de `instance_group2` se a demanda do processo da aplicação diminuir e a demanda do executor aumentar. + Quando o Amazon EMR sofre um atraso ao aumentar a escala verticalmente com o grupo de instâncias atual, os clusters que usam o ajuste de escala gerenciado alternam automaticamente para outro grupo de instâncias de tarefa. + Se o parâmetro `MaximumCoreCapacityUnits` estiver definido, o Amazon EMR escalará os nós centrais até que as unidades centrais atinjam o limite máximo permitido. Toda a capacidade restante é adicionada aos nós de tarefa. + Se o parâmetro `MaximumOnDemandCapacityUnits` estiver definido, o Amazon EMR escalará o cluster usando as instâncias sob demanda até que as unidades sob demanda atinjam o limite máximo permitido. Toda a capacidade restante é adicionada usando instâncias spot. + Se os parâmetros `MaximumCoreCapacityUnits` e `MaximumOnDemandCapacityUnits` estiverem definidos, o Amazon EMR considerará os dois limites durante o ajuste de escala. Por exemplo, se `MaximumCoreCapacityUnits` for menor que `MaximumOnDemandCapacityUnits`, o Amazon EMR primeiro escala os nós centrais até atingir o limite de capacidade do núcleo. Para a capacidade restante, o Amazon EMR primeiro usa instâncias sob demanda para escalar nós de tarefa até atingir o limite sob demanda e usa instâncias spot para nós de tarefa. **Estratégia de redução da escala verticalmente** + Semelhante à estratégia de aumento vertical da escala, o Amazon EMR remove nós com base nos rótulos dos nós. Para obter mais informações sobre os rótulos de nós, consulte [Understand node types: primary, core, and task nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html). + Se você não habilitou os rótulos de nós, o ajuste de escala gerenciado remove os nós de tarefa e depois os nós centrais até alcançar a capacidade desejada de redução da escala verticalmente. O ajuste de escala gerenciado nunca reduz verticalmente a escala do cluster abaixo das restrições mínimas especificadas na política de ajuste de escala gerenciado. + O Amazon EMR 5.34.0 e versões posteriores e o Amazon EMR 6.4.0 e versões posteriores oferecem suporte ao reconhecimento de dados de shuffle do Spark, o que impede que a escala vertical de uma instância seja reduzida enquanto o ajuste de escala gerenciado reconhece dados de shuffle existentes. Para obter mais informações sobre operações de shuffle, consulte o [Guia de programação do Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). O Ajuste de escala gerenciado se esforça ao máximo para evitar reduzir a escala verticalmente de nós com dados de shuffle do estágio atual e anterior de qualquer aplicação Spark ativa por até um máximo de 30 minutos. Isso ajuda a minimizar a perda acidental de dados de shuffle, evitando a necessidade de repetir trabalhos e recalcular dados intermediários. No entanto, a prevenção da perda de dados de shuffle não é garantida. Para melhorar a proteção do Spark shuffle, recomendamos o reconhecimento aleatório em clusters com a etiqueta de versão 7.4 ou superior. Adicione os seguintes sinalizadores à configuração do cluster para ativar a proteção aprimorada do Spark shuffle. + Se o `yarn.nodemanager.shuffledata-monitor.interval-ms` sinalizador (padrão 30000 ms) ou o `spark.dynamicAllocation.executorIdleTimeout` (padrão 60 segundos) tiver sido alterado dos valores padrão, certifique-se de que a condição `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` permaneça `true` atualizando o sinalizador necessário. ``` [ { "Classification": "yarn-site", "Properties": { "yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true" } }, { "Classification": "spark-defaults", "Properties": { "spark.dynamicAllocation.enabled": "true", "spark.shuffle.service.removeShuffle": "true" } } ] ``` + O ajuste de escala gerenciado primeiro remove os nós de tarefa e depois os nós centrais até alcançar a capacidade desejada de redução da escala verticalmente. O cluster jamais escala abaixo das restrições mínimas especificadas na política de ajuste de escala gerenciado. + Para clusters que são lançados com o Amazon EMR 5.x versões 5.34.0 e superiores e 6.x versões 6.4.0 e superiores, o Amazon EMR Managed Scaling não reduz a escala dos nós que existem `ApplicationMaster` para o Apache Spark, se houver estágios ativos nos aplicativos em execução neles. Isso minimiza falhas e novas tentativas de trabalho, o que ajuda a melhorar a performance do trabalho e reduzir custos. Para confirmar quais nós do cluster estão executando `ApplicationMaster`, acesse o Spark History Server e filtre o driver na guia **Executores** do ID da aplicação Spark. + Embora o ajuste de escala inteligente com o Ajuste de escala gerenciado do EMR minimize a perda de dados de shuffle para o Spark, pode haver casos em que dados de shuffle transitórios podem não ser protegidos durante tal redução. Para fornecer maior resiliência dos dados de shuffle durante a redução da escala vertical, recomendamos habilitar a opção de **Desativação gradual para dados de shuffle** no YARN. Quando a opção **Desativação gradual para dados de shuffle** estiver habilitada no YARN, os nós selecionados para redução de escala vertical que tenham dados de shuffle entrarão no estado de **desativação** e continuarão a fornecer arquivos de shuffle. O YARN ResourceManager espera até que os nós relatem a presença de arquivos aleatórios antes de remover os nós do cluster. + A versão 6.11.0 e superior do Amazon EMR oferece suporte ao descomissionamento elegante baseado em Yarn para dados do **Hive** shuffle para os manipuladores Tez e Shuffle. MapReduce + Habilite a Desativação gradual para dados de shuffle definindo `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` como `true`. + O Amazon EMR versão 7.4.0 e superior oferece suporte à desativação gradual com base no Yarn para dados de shuffle do Spark quando o serviço de shuffle externo está habilitado (habilitado por padrão no EMR no EC2). + O comportamento padrão do serviço de reprodução aleatória externa do Spark, ao executar o Spark no Yarn, é que o Yarn remova os arquivos aleatórios do aplicativo no NodeManager momento do encerramento do aplicativo. Isso pode ter um impacto na velocidade de descomissionamento dos nós e na utilização da computação. Para aplicações de longa execução, considere configurar `spark.shuffle.service.removeShuffle` como `true` para remover arquivos de shuffle que não estão mais em uso para permitir a desativação mais rápida de nós sem dados de shuffle ativos. + Para minimizar a perda de dados do Spark shuffle no Amazon EMR versão 7.4.0 e superior, considere definir as seguintes sinalizações. + Se o `yarn.nodemanager.shuffledata-monitor.interval-ms` sinalizador (padrão 30000 ms) ou o `spark.dynamicAllocation.executorIdleTimeout` (padrão 60 segundos) tiver sido alterado dos valores padrão, certifique-se de que a condição `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` permaneça `true` atualizando o sinalizador necessário. ``` [ { "Classification": "yarn-site", "Properties": { "yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true" } }, { "Classification": "spark-defaults", "Properties": { "spark.dynamicAllocation.enabled": "true", "spark.shuffle.service.removeShuffle": "true" } } ] ``` Se o cluster não tiver nenhuma carga, o Amazon EMR cancelará a adição de novas instâncias de uma avaliação anterior e executará operações de redução da escala verticalmente. Se o cluster tiver uma carga pesada, o Amazon EMR cancelará a remoção de instâncias e executará operações de aumento da escala verticalmente. ## Considerações sobre alocação de nós É recomendável usar a opção de compra sob demanda para os nós centrais para evitar a perda de dados do HDFS em caso de recuperação spot. Você pode usar a opção de compra spot para nós de tarefa para reduzir custos e obter uma execução mais rápida do trabalho quando mais instâncias spot são adicionadas aos nós de tarefa. ## Cenários de alocação de nós É possível criar vários cenários de ajuste de escala com base em suas necessidades configurando os parâmetros máximo, mínimo, limite sob demanda e nó central máximo em combinações diferentes. **Cenário 1: escalar somente os nós centrais** Para escalar somente os nós centrais, os parâmetros do ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda é igual ao limite máximo. + O nó central máximo é igual ao limite máximo. Quando o limite sob demanda e os parâmetros máximos do nó central não estão especificados, ambos os parâmetros assumem o limite máximo como padrão. Esse cenário não é aplicável se você usa ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `CORE`, porque o ajuste de escala gerenciado dimensiona os nós de tarefas para acomodar a demanda do executor. Os exemplos a seguir demonstram o cenário de ajuste de escala somente para os nós centrais. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 2: escalar somente nós de tarefa** Para escalar somente os nós de tarefa, os parâmetros do ajuste de escala gerenciado devem atender ao seguinte requisito: + O nó central máximo deve ser igual ao limite mínimo. Os exemplos a seguir demonstram o cenário de ajuste de escala somente para os nós de tarefa. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 3: somente instâncias sob demanda no cluster** Para ter somente instâncias sob demanda, o cluster e os parâmetros de ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda é igual ao limite máximo. Quando o limite sob demanda não é especificado, o valor do parâmetro assume o limite máximo como padrão. O valor padrão indica que o Amazon EMR escalará somente instâncias sob demanda. Se o nó central máximo for menor que o limite máximo, o parâmetro do nó central máximo poderá ser usado para dividir a alocação de capacidade entre os nós centrais e os nós de tarefa. Para habilitar esse cenário em um cluster composto por grupos de instâncias, todos os grupos de nós do cluster devem usar o tipo de mercado sob demanda durante a configuração inicial. Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND`, porque o ajuste de escala gerenciado dimensiona os nós `Spot` para acomodar a demanda do executor. Os exemplos a seguir demonstram o cenário de ter instâncias sob demanda em todo o cluster. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 4: somente instâncias spot no cluster** Para ter somente instâncias spot, os parâmetros de ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda está definido como 0. Se o nó central máximo for menor que o limite máximo, o parâmetro do nó central máximo poderá ser usado para dividir a alocação de capacidade entre os nós centrais e os nós de tarefa. Para habilitar esse cenário em um cluster composto por grupos de instâncias, o grupo de instâncias central deve usar a opção de compra spot durante a configuração inicial. Se não houver nenhuma instância spot no grupo de instâncias de tarefa, o Ajuste de Escala Gerenciado do Amazon EMR criará um grupo de tarefas usando instâncias spot quando necessário. Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND`, porque o ajuste de escala gerenciado dimensiona os nós `ON_DEMAND` para acomodar a demanda do processo da aplicação. Os exemplos a seguir demonstram o cenário de ter instâncias spot em todo o cluster. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 5: escalar instâncias sob demanda nos nós centrais e instâncias spot nos nós de tarefa** Para escalar instâncias sob demanda em nós centrais e instâncias spot em nós de tarefa, os parâmetros de ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda deve ser igual ao nó central máximo. + Tanto o limite sob demanda como o nó central máximo devem ser menores que o limite máximo. Para habilitar esse cenário em um cluster composto por grupos de instâncias, o grupo de nós centrais deve usar a opção de compra sob demanda. Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND` ou `CORE`. Os exemplos a seguir demonstram o cenário de ajuste de escala de instâncias sob demanda nos nós centrais e instâncias spot nos nós de tarefa. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 6: escale as instâncias `CORE` para a demanda do processo da aplicação e as instâncias `TASK` para a demanda do executor.** Esse cenário só é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `CORE`. Para escalar os nós `CORE` com base na demanda do processo da aplicação e os nós `TASK` com base na demanda do executor, você deve definir as seguintes configurações na inicialização do cluster: + `yarn.node-labels.enabled:true` + `yarn.node-labels.am.default-node-label-expression: 'CORE'` Se você não especificar o limite de `ON_DEMAND` e os parâmetros máximos do nó `CORE`, ambos os parâmetros serão padronizados para o limite máximo. Se o nó `ON_DEMAND` máximo for menor que o limite máximo, o ajuste de escala gerenciado usará o parâmetro do nó `ON_DEMAND` máximo para dividir a alocação de capacidade entre os nós `ON_DEMAND` e `SPOT`. Se você definir o parâmetro máximo do nó `CORE` como menor ou igual ao parâmetro de capacidade mínima, os nós `CORE` permanecerão estáticos na capacidade máxima do núcleo. Os exemplos a seguir demonstram o cenário de ajuste de escala de instâncias CENTRAIS com base na demanda do processo da aplicação e de instâncias DE TAREFA com base na demanda do executor. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 7: escale as instâncias `ON_DEMAND` para a demanda do processo da aplicação e as instâncias `SPOT` para a demanda do executor.** Esse cenário só é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND`. Para escalar os nós `ON_DEMAND` com base na demanda do processo da aplicação e os nós `SPOT` com base na demanda do executor, você deve definir as seguintes configurações na inicialização do cluster: + `yarn.node-labels.enabled:true` + `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'` Se você não especificar o limite de `ON_DEMAND` e os parâmetros máximos do nó `CORE`, ambos os parâmetros serão padronizados para o limite máximo. Se o nó `CORE` máximo for menor que o limite máximo, o ajuste de escala gerenciado usará o parâmetro do nó `CORE` máximo para dividir a alocação de capacidade entre os nós `CORE` e `TASK`. Se você definir o parâmetro máximo do nó `CORE` como menor ou igual ao parâmetro de capacidade mínima, os nós `CORE` permanecerão estáticos na capacidade máxima do núcleo. Os exemplos a seguir demonstram o cenário de ajuste de escala de instâncias sob demanda com base na demanda do processo da aplicação e de instâncias spot com base na demanda do executor. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) # Noções básicas sobre métricas de ajuste de escala gerenciado no Amazon EMR O Amazon EMR publica métricas de alta resolução com dados em uma granularidade de um minuto quando o ajuste de escala gerenciado está habilitado em um cluster. Você pode visualizar eventos em cada iniciação e conclusão de redimensionamento controlados pela escalabilidade gerenciada com o console do Amazon EMR ou o console da Amazon. CloudWatch CloudWatch as métricas são essenciais para a operação da escalabilidade gerenciada do Amazon EMR. Recomendamos que você monitore de perto CloudWatch as métricas 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](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Para obter mais informações sobre o uso de CloudWatch eventos com o Amazon EMR, consulte [Monitorar CloudWatch](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html) eventos. As métricas a seguir indicam as capacidades atuais ou de destino de um cluster. Essas métricas só estão disponíveis quando a escalabilidade gerenciada está habilitada. Para clusters compostos por frotas de instâncias, as métricas de capacidade de cluster são medidas em `Units`. Para clusters compostos por grupos de instâncias, as métricas de capacidade de cluster são medidas em `Nodes` ou `vCPU` com base no tipo de unidade usado na política de escalabilidade gerenciada. | Métrica | Description | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número total alvo de units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número total atual de units/nodes/vCPUs disponíveis em um cluster em execução. Quando um redimensionamento de cluster for solicitado, essa métrica será atualizada depois que as novas instâncias forem adicionadas ou removidas do cluster. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número alvo de CORE units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número atual de CORE em units/nodes/vCPUs execução em um cluster. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número alvo de TASK units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número atual de TAREFAS em units/nodes/vCPUs execução em um cluster. Unidades: *Contagem* | As métricas a seguir indicam o status de uso do cluster e dos aplicativos. Essas métricas estão disponíveis para todos os recursos do Amazon EMR mas são publicadas em uma resolução mais alta com dados em uma granularidade de um minuto quando o ajuste de gerenciado é habilitado para um cluster. É possível correlacionar as métricas a seguir com as métricas de capacidade do cluster na tabela anterior para entender as decisões de escalabilidade gerenciada. | Métrica | Description | | --- | --- | | `AppsCompleted` | O número de aplicativos enviados para o YARN que foram concluídos. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `AppsPending` | O número de aplicativos enviados para o YARN em estado pendente. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `AppsRunning` | O número de aplicativos enviados para o YARN que estão em execução. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ContainerAllocated | O número de contêineres de recursos alocados peloResourceManager. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `ContainerPending` | O número de contêineres na fila que ainda não foram alocados. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ContainerPendingRatio | A proporção de contêineres pendentes em relação aos contêineres alocados (ContainerPendingRatio = ContainerPending / ContainerAllocated). Se ContainerAllocated = 0, então ContainerPendingRatio =ContainerPending. O valor de ContainerPendingRatio representa um número, não uma porcentagem. Esse valor é útil para escalonar recursos de cluster com base no comportamento de alocação do contêiner. Unidades: *Contagem* | | `HDFSUtilization` | O percentual de armazenamento do HDFS em uso no momento. Caso de uso: analisar a performance do cluster Unidade: *percentual* | | `IsIdle` | Indica que um cluster não está mais executando nenhum trabalho, mas ainda está ativo e acumulando cobranças. É definido como 1 se nenhuma tarefa ou nenhum trabalho estiver em execução, caso contrário, é definido como 0. Esse valor é verificado em intervalos de 5 minutos, sendo que um valor de 1 indica somente que o cluster estava ocioso no momento da verificação, e não que ele ficou ocioso durante todo o período de 5 minutos. Para evitar falsos positivos, é necessário gerar um alarme quando esse valor for 1 em mais de uma verificação consecutiva de cinco minutos. Por exemplo, você pode gerar um alerta para esse valor se ele for 1 por 30 minutos ou mais. Caso de uso: monitorar a performance do cluster Unidade: *booliano* | | `MemoryAvailableMB` | A quantidade de memória disponível para ser alocada. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `MRActiveNodes` | O número de nós que estão executando MapReduce tarefas ou trabalhos no momento. Equivalente ao `mapred.resourcemanager.NoOfActiveNodes` da métrica YARN. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `YARNMemoryAvailablePercentage` | A porcentagem de memória restante disponível para o YARN (YARNMemoryAvailablePercentage = MemoryAvailable MB/MemoryTotalMB). Esse valor é útil para escalonar recursos de cluster com base no uso da memória YARN. Unidade: *percentual* | As métricas a seguir fornecem informações sobre os recursos usados pelos contêineres e nós YARN. Essas métricas do gerenciador de recursos do YARN oferecem informações sobre os recursos usados pelos contêineres e nós em execução no cluster. A comparação dessas métricas com as métricas de capacidade de cluster da tabela anterior fornece uma imagem mais clara do impacto do ajuste de escala gerenciado: | Métrica | Versões associadas | Description | | --- | --- | --- | | `YarnContainersUsedMemoryGBSeconds` | Disponível para a versão 7.3.0 e posteriores | A memória consumida do contêiner \$1 segundos durante o período de publicação. **Unidades:** GB \$1 segundos | | `YarnContainersTotalMemoryGBSeconds` | Disponível para a versão 7.3.0 e posteriores | O total do contêiner yarn \$1 segundos para o período de publicação. **Unidades:** GB \$1 segundos | | `YarnContainersUsedVCPUSeconds` | Disponível para a versão 7.5.0 e posteriores | A VCPU consumida do contêiner \$1 segundos durante o período de publicação. **Unidades:** VCPU \$1 segundos | | `YarnContainersTotalVCPUSeconds` | Disponível para a versão 7.5.0 e posteriores | O total da VCPU contêiner \$1 segundos para o período de publicação. **Unidades:** VCPU \$1 segundos | | `YarnNodesUsedMemoryGBSeconds` | Disponível para a versão 7.5.0 e posteriores | A memória consumida do nó \$1 segundos durante o período de publicação. **Unidades:** GB \$1 segundos | | `YarnNodesTotalMemoryGBSeconds` | Disponível para a versão 7.5.0 e posteriores | A memória total do nó \$1 segundos durante o período de publicação. **Unidades:** GB \$1 segundos | | `YarnNodesUsedVCPUSeconds` | Disponível para a versão 7.3.0 e posteriores | A VCPU consumida do nó \$1 segundos durante o período de publicação. **Unidades:** VCPU \$1 segundos | | `YarnNodesTotalVCPUSeconds` | Disponível para a versão 7.3.0 e posteriores | A VCPU total do nó \$1 segundos durante o período de publicação. **Unidades:** VCPU \$1 segundos | ## Criar grafos de métricas de ajuste de escala gerenciado É possível criar grafos de métricas para visualizar os padrões de workload do cluster e as decisões de ajuste de escala correspondentes tomadas pelo Ajuste de Escala Gerenciado do Amazon EMR, conforme demonstrado nas etapas a seguir. **Para representar graficamente as métricas de escalabilidade gerenciadas no console CloudWatch** 1. Abra o [console do CloudWatch](https://console.aws.amazon.com/cloudwatch/). 1. No painel de navegação, escolha o **Amazon EMR**. Você pode pesquisar com base no identificador do cluster para monitoramento. 1. Role para baixo até a métrica para exibição em gráfico. Abra uma métrica para exibir o gráfico. 1. Para criar um gráfico de uma ou mais métricas, marque a caixa de seleção ao lado de cada métrica. O exemplo a seguir ilustra a ação de Ajuste de Escala Gerenciado do Amazon EMR de um cluster. O gráfico mostra três períodos de redução automática, que economizam custos quando há uma workload menos ativa. ![\[Criar gráficos de métricas de escalabilidade gerenciada\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/Managed_Scaling_Decision.png) Todas as métricas de capacidade e uso do cluster são publicadas em intervalos de um minuto. As informações estatísticas adicionais também estão associadas a cada dado de um minuto, o que permite representar várias funções como `Percentiles`, `Min`, `Max`, `Sum`, `Average` e `SampleCount`. Por exemplo, o gráfico a seguir representa graficamente a mesma métrica `YARNMemoryAvailablePercentage` em percentis diferentes, P10, P50, P90 e P99, juntamente com `Sum`, `Average`, `Min` e `SampleCount`. ![\[Criar gráficos de métricas de escalabilidade gerenciada com diferentes percentis\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/Managed_Scaling_Metrics.png)