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á. # 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 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 executados 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.
Estado inicial do clusterParâmetros de escalabilidadeComportamento do ajuste de escala
**Grupos de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda e uma spot		`UnitType`: instâncias
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 20		Escale de 1 a 20 instâncias ou unidades da frota de instâncias nos nós centrais usando o tipo sob demanda. Sem ajuste de escala nos nós de tarefa.
Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação ao nós `ON_DEMAND`, o cluster escalará de 1 a 20 instâncias ou unidades da frota de instâncias em nós `CORE` usando o tipo `On-Demand` ou `Spot`, dependendo do tipo de demanda.
**Frotas de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda e uma spot		UnitType: InstanceFleetUnits
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 20
**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.
Estado inicial do clusterParâmetros de escalabilidadeComportamento do ajuste de escala
**Grupos de instâncias**
Central: duas sob demanda
De tarefa: uma spot		`UnitType`: instâncias
`MinimumCapacityUnits`: 2
`MaximumCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 2		Mantenha os nós centrais estáveis em 2 e escale somente os nós de tarefa de 0 a 18 instâncias ou unidades da frota de instâncias. A capacidade entre os limites mínimo e máximo é adicionada somente aos nós de tarefa.
Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação aos nós ON\_DEMAND, o cluster mantém os nós centrais estáveis em 2 e só escala os nós de tarefa entre 0 a 18 instâncias ou unidades da frota de instâncias que usam o tipo `On-demand` ou `Spot`, dependendo do tipo de demanda.
**Frotas de instâncias**
Central: duas sob demanda
De tarefa: uma spot		`UnitType`: InstanceFleetUnits
`MinimumCapacityUnits`: 2
`MaximumCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 2
**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.
Estado inicial do clusterParâmetros de escalabilidadeComportamento do ajuste de escala
**Grupos de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda 		`UnitType`: instâncias
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 12		Escale de 1 a 12 instâncias ou unidades da frota de instâncias nos nós centrais usando o tipo sob demanda. Escale a capacidade restante usando sob demanda em nós de tarefa. Sem ajuste de escala usando instâncias spot.
Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação aos nós `CORE`, o cluster escala entre 1 a 20 instâncias ou unidades da frota de instâncias em nós `CORE` ou `task` usando o tipo `ON_DEMAND`, dependendo do tipo de demanda. O ajuste de escala nos nós centrais não excederá 12 instâncias ou unidades da frota de instâncias.
**Frotas de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda		`UnitType`: InstanceFleetUnits
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 12
**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.
Estado inicial do clusterParâmetros de escalabilidadeComportamento do ajuste de escala
**Grupos de instâncias**
Central: uma spot
De tarefa: uma spot		`UnitType`: instâncias
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 0		Escale de 1 a 20 instâncias ou unidades da frota de instâncias nos nós centrais usando spot. Sem ajuste de escala usando o tipo sob demanda.
Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação aos nós `CORE`, o cluster escala entre 1 a 20 instâncias ou unidades da frota de instâncias em nós `CORE` ou `TASK` usando o spot, dependendo do tipo de demanda. O Amazon EMR não escala usando o tipo `ON_DEMAND`.
**Frotas de instâncias**
Central: uma spot
De tarefa: uma spot		`UnitType`: InstanceFleetUnits
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 0
**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.
Estado inicial do clusterParâmetros de escalabilidadeComportamento do ajuste de escala
**Grupos de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda e uma spot		`UnitType`: instâncias
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 7
`MaximumCoreCapacityUnits`: 7		Escale até 6 unidades sob demanda no nó central, pois já existe 1 unidade sob demanda no nó de tarefa, e o limite máximo para sob demanda é 7. Depois escale até 13 unidades spot nos nós de tarefa.
**Frotas de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda e uma spot		`UnitType`: InstanceFleetUnits
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 7
`MaximumCoreCapacityUnits`: 7
**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.
Estado inicial do clusterParâmetros de escalabilidadeComportamento do ajuste de escala
**Grupos de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda		`UnitType`: instâncias
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 10
`MaximumCoreCapacityUnits`: 20		Escala os nós `CORE` entre 1 e 20 nós com base na demanda do processo da aplicação do cluster usando o tipo de mercado sob demanda ou spot. Escala os nós `TASK` com base na demanda do executor e na capacidade disponível restante após a alocação dos nós `CORE` pelo Amazon EMR.
A soma dos nós solicitados `CORE` e `TASK` não excederá a `maximumCapacity` de 20. A soma dos nós centrais sob demanda solicitados e dos nós de tarefas sob demanda não excederá `maximumOnDemandCapacity` de 10. Os nós centrais ou de tarefas adicionais usam o tipo de mercado spot.
**Frotas de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda		`UnitType`: InstanceFleetUnits
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 10
`MaximumCoreCapacityUnits`: 20
**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.
Estado inicial do clusterParâmetros de escalabilidadeComportamento do ajuste de escala
**Grupos de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda		`UnitType`: instâncias
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 10		Escala os nós `ON_DEMAND` entre 1 e 20 nós com base na demanda do processo da aplicação do cluster usando o tipo de nó `CORE` ou `TASK`. Escala os nós `SPOT` com base na demanda do executor e na capacidade disponível restante após a alocação dos nós `ON_DEMAND` pelo Amazon EMR.
A soma dos nós solicitados `ON_DEMAND` e `SPOT` não excederá a `maximumCapacity` de 20. A soma dos nós centrais sob demanda solicitados e dos nós centrais spot não excederá a `maximumCoreCapacity` de 10. Os nós sob demanda ou spot adicionais usam o tipo de nó `TASK`.
**Frotas de instâncias**
Central: uma sob demanda
De tarefa: uma sob demanda		`UnitType`: InstanceFleetUnits
`MinimumCapacityUnits`: 1
`MaximumCapacityUnits`: 20
`MaximumOnDemandCapacityUnits`: 20
`MaximumCoreCapacityUnits`: 10