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á. # Configuração de uma aplicação ao trabalhar com o EMR Sem Servidor Com o EMR Sem Servidor, configure as aplicações que você usa. Por exemplo, defina a capacidade máxima para a qual uma aplicação pode aumentar a escala verticalmente, configurar a capacidade pré-inicializada para manter o driver e os trabalhadores prontos para responder e especificar um conjunto comum de configurações de runtime e monitoramento no nível da aplicação. As páginas a seguir descrevem como configurar aplicações ao usar o EMR Sem Servidor. **Topics** + [Noções básicas do comportamento da aplicação no EMR Sem Servidor](app-behavior.md) + [Capacidade pré-inicializada para trabalhar com uma aplicação no EMR Sem Servidor](pre-init-capacity.md) + [Configuração padrão de aplicações do EMR Sem Servidor](default-configs.md) # Noções básicas do comportamento da aplicação no EMR Sem Servidor Esta seção descreve o comportamento de envio de trabalhos, a configuração da capacidade para ajuste de escala e as definições de configuração do trabalhador do EMR Sem Servidor. ## Comportamento padrão da aplicação **Início automático**: por padrão, uma aplicação é configurada para iniciar automaticamente no envio do trabalho. Você pode desativar esse recurso. **Parada automática**: por padrão, uma aplicação é configurada para ser interrompida automaticamente quando ociosa por 15 minutos. Quando uma aplicação muda para o estado `STOPPED`, ela libera qualquer capacidade pré-inicializada configurada. Você pode modificar a quantidade de tempo ocioso antes que uma aplicação pare automaticamente ou desativar esse recurso. ## Capacidade máxima Você pode configurar a capacidade máxima para a qual uma aplicação pode aumentar a escala verticalmente. Você pode especificar sua capacidade máxima em termos de CPU, memória (GB) e disco (GB). **nota** As práticas recomendadas são configurar sua capacidade máxima de forma proporcional aos tamanhos dos seus operadores com suporte, multiplicando o número de operadores pelos seus tamanhos. Por exemplo, se você quiser limitar seu aplicativo a 50 trabalhadores com 2 vCPUs, 16 GB para memória e 20 GB para disco, defina sua capacidade máxima para 100 vCPUs, 800 GB para memória e 1000 GB para disco. ## Configuração de trabalhador compatíveis A tabela a seguir mostra as configurações e tamanhos de trabalhadores compatíveis que você pode especificar para o EMR Sem Servidor. Configure tamanhos diferentes para drivers e executores com base na necessidade da workload. **Configurações e tamanhos de operadores** | CPU | Memória | Armazenamento temporário padrão | | --- | --- | --- | | 1 vCPU | Mínimo de 2 GB, máximo de 8 GB, em incrementos de 1 GB | De 20 GB a 200 GB | | 2 vCPU | Mínimo de 4 GB, máximo de 16 GB, em incrementos de 1 GB | De 20 GB a 200 GB | | 4 vCPU | Mínimo de 8 GB, máximo de 30 GB, em incrementos de 1 GB | De 20 GB a 200 GB | | 8 vCPU | Mínimo de 16 GB, máximo de 60 GB, em incrementos de 4 GB | De 20 GB a 200 GB | | 16 vCPU | Mínimo de 32 GB, máximo de 120 GB, em incrementos de 8 GB | De 20 GB a 200 GB | **CPU** — Cada trabalhador pode ter 1, 2, 4, 8 ou 16 CPUs v. **Memória**: cada trabalhador tem memória, especificada em GB, dentro dos limites listados na tabela anterior. Os trabalhos do Spark têm uma sobrecarga de memória, o que significa que a memória que eles usam é maior do que os tamanhos de contêineres especificados. Essa sobrecarga é especificada com as propriedades `spark.driver.memoryOverhead` e `spark.executor.memoryOverhead`. A sobrecarga tem um valor padrão de 10% da memória do contêiner, com um mínimo de 384 MB. Você deve considerar essa sobrecarga ao escolher o tamanho dos trabalhadores. Por exemplo, se você escolher 4 v CPUs para sua instância de trabalho e uma capacidade de armazenamento pré-inicializada de 30 GB, defina um valor de aproximadamente 27 GB como memória executora para sua tarefa do Spark. Isso maximiza a utilização da capacidade pré-inicializada. A memória utilizável é 27 GB, mais 10% de 27 GB (2,7 GB), totalizando 29,7 GB. **Disco**: você pode configurar cada trabalhador com discos de armazenamento temporário com tamanho mínimo de 20 GB e máximo de 200 GB. Você paga apenas pelo armazenamento adicional além de 20 GB configurado por trabalhador. # Capacidade pré-inicializada para trabalhar com uma aplicação no EMR Sem Servidor O EMR Sem Servidor fornece um recurso opcional que mantém o driver e os trabalhadores pré-inicializados e prontos para responder em segundos. Isso cria efetivamente um grupo de aquecimento de trabalhadores para uma aplicação. Esse recurso é chamado de *capacidade pré-inicializada*. Para configurar esse recurso, defina o parâmetro `initialCapacity` de uma aplicação para o número de trabalhadores que você deseja pré-inicializar. Com a capacidade de trabalhadores pré-inicializada, os trabalhos começam imediatamente. Isso é ideal quando você deseja implementar aplicações iterativas e trabalhos urgentes. A capacidade pré-inicializada mantém um grupo de aquecimento de trabalhadores prontos para a inicialização de trabalhos e sessões em segundos. Você pagará por trabalhadores pré-inicializados provisionados mesmo quando a aplicação estiver ociosa. Portanto, sugerimos habilitá-los para casos de uso que se beneficiem do rápido tempo de inicialização e dimensioná-los para a utilização ideal dos recursos. As aplicações do EMR Sem Servidor são desligadas automaticamente quando ociosas. Sugerimos manter esse recurso ativado ao usar trabalhadores pré-inicializados para evitar cobranças inesperadas. Quando você envia um trabalho, se houver trabalhadores da `initialCapacity` disponíveis, o trabalho usa esses recursos para iniciar sua execução. Se esses trabalhadores já estiverem sendo usados por outros trabalhos, ou se o trabalho precisar de mais recursos do que os disponíveis da `initialCapacity`, a aplicação solicitará e obterá trabalhadores adicionais, até os limites máximos de recursos definidos para a aplicação. Quando um trabalho termina a execução, ele libera os trabalhadores que usou e o número de recursos disponíveis para a aplicação retorna para `initialCapacity`. Uma aplicação mantém a `initialCapacity` dos recursos mesmo após o término da execução dos trabalhos. A aplicação libera recursos em excesso além da `initialCapacity` quando os trabalhos não precisam mais deles para serem executados. A capacidade pré-inicializada está disponível e pronta para uso quando a aplicação é iniciada. A capacidade pré-inicializada fica inativa quando a aplicação é interrompida. Uma aplicação passa para o estado `STARTED` somente se a capacidade pré-inicializada solicitada tiver sido criada e estiver pronta para uso. Durante todo o tempo em que a aplicação está no estado `STARTED`, o EMR Sem Servidor mantém a capacidade pré-inicializada disponível para utilização ou em uso por trabalhos ou workloads interativas. O recurso restaura a capacidade de contêineres liberados ou com falha. Isso mantém o número de trabalhadores que o parâmetro `InitialCapacity` especifica. O estado de uma aplicação sem capacidade pré-inicializada pode mudar imediatamente de `CREATED` para `STARTED`. Você pode configurar a aplicação para liberar a capacidade pré-inicializada se ela não for usada por um determinado período, com um padrão de 15 minutos. Uma aplicação interrompida é iniciada automaticamente quando você envia um novo trabalho. Você pode definir essas configurações automáticas de início e parada ao criar a aplicação ou alterá-las quando a aplicação estiver em um estado `CREATED` ou `STOPPED`. Você pode alterar as contagens da `InitialCapacity` e especificar configurações de computação, como CPU, memória e disco, para cada trabalhador. Como você não pode fazer modificações parciais, especifique todas as configurações de computação ao alterar os valores. Você só pode alterar as configurações quando a aplicação está no estado `CREATED` ou `STOPPED`. **nota** Para otimizar o uso de recursos da aplicação, sugerimos alinhar os tamanhos dos contêineres com os tamanhos dos trabalhadores da capacidade pré-inicializada. Por exemplo, se você configurar o tamanho do executor do Spark para 2 CPUs e sua memória para 8 GB, mas o tamanho do operador de capacidade pré-inicializada for 4 CPUs com 16 GB de memória, os executores do Spark usarão apenas metade dos recursos dos trabalhadores quando forem designados para esse trabalho. ## Personalização da capacidade pré-inicializada para Spark e Hive Você pode personalizar ainda mais a capacidade pré-inicializada de workloads executadas em estruturas específicas de big data. Por exemplo, quando uma workload é executada no Apache Spark, especifique quantos trabalhadores começam como drivers e quantos começam como executores. Da mesma forma, ao usar o Apache Hive, especifique quantos trabalhadores começam como drivers do Hive e quantos devem executar tarefas do Tez. **Configuração de aplicações executando o Apache Hive com capacidade pré-inicializada** A solicitação de API a seguir cria uma aplicação executando o Apache Hive com base na versão emr-6.6.0 do Amazon EMR. A aplicação começa com 5 drivers pré-inicializados do Hive, cada um com 2 vCPUs e 4 GB de memória, e 50 trabalhadores pré-inicializados de tarefas do Tez, cada um com 4 vCPUs e 8 GB de memória. Quando as consultas do Hive são executadas nessa aplicação, elas primeiro usam os trabalhadores pré-inicializados e começam a ser executadas imediatamente. Se todos os trabalhadores pré-inicializados estiverem ocupados e mais trabalhos do Hive forem enviados, a aplicação pode escalar para um total de 400 vCPU e 1.024 GB de memória. Opcionalmente, você pode omitir a capacidade do trabalhador do `DRIVER` ou da `TEZ_TASK`. ``` aws emr-serverless create-application \ --type "HIVE" \ --name my-application-name \ --release-label emr-6.6.0 \ --initial-capacity '{ "DRIVER": { "workerCount": 5, "workerConfiguration": { "cpu": "2vCPU", "memory": "4GB" } }, "TEZ_TASK": { "workerCount": 50, "workerConfiguration": { "cpu": "4vCPU", "memory": "8GB" } } }' \ --maximum-capacity '{ "cpu": "400vCPU", "memory": "1024GB" }' ``` **Configuração de aplicações executando o Apache Spark com capacidade pré-inicializada** A solicitação de API a seguir cria uma aplicação que executa o Apache Spark 3.2.0 com base na versão 6.6.0 do Amazon EMR. A aplicação começa com 5 drivers pré-inicializados do Spark, cada um com 2 vCPUs e 4 GB de memória, e 50 executores pré-inicializados, cada um com 4 vCPUs e 8 GB de memória. Quando os trabalhos do Spark são executados nessa aplicação, eles primeiro usam os trabalhadores pré-inicializados e começam a ser executados imediatamente. Se todos os trabalhadores pré-inicializados estiverem ocupados e mais trabalhos do Spark forem enviados, a aplicação pode escalar para um total de 400 vCPU e 1.024 GB de memória. Opcionalmente, você pode omitir a capacidade do `DRIVER` ou do `EXECUTOR`. **nota** O Spark adiciona uma sobrecarga de memória configurável, com um valor padrão de 10%, à memória solicitada pelo driver e pelos executores. Para que os trabalhos usem trabalhadores pré-inicializados, a configuração inicial da memória de capacidade deve ser maior do que a memória solicitada pelo trabalho e pela sobrecarga. ``` aws emr-serverless create-application \ --type "SPARK" \ --name my-application-name \ --release-label emr-6.6.0 \ --initial-capacity '{ "DRIVER": { "workerCount": 5, "workerConfiguration": { "cpu": "2vCPU", "memory": "4GB" } }, "EXECUTOR": { "workerCount": 50, "workerConfiguration": { "cpu": "4vCPU", "memory": "8GB" } } }' \ --maximum-capacity '{ "cpu": "400vCPU", "memory": "1024GB" }' ``` # Configuração padrão de aplicações do EMR Sem Servidor Você pode especificar um conjunto comum de configurações de runtime e monitoramento no nível da aplicação para todos os trabalhos enviados na mesma aplicação. Isso reduz a sobrecarga adicional associada à necessidade de enviar as mesmas configurações para cada trabalho. Você pode modificar as configurações nos seguintes momentos: + [Declare as configurações em nível de aplicação no envio do trabalho.](#default-configs-declare) + [Substitua as configurações padrão durante a execução do trabalho.](#default-configs-override) As seções a seguir fornecem mais detalhes e um exemplo para contexto adicional. ## Declaração de configurações no nível da aplicação É possível especificar propriedades de configuração de registro em log e de runtime no nível da aplicação para os trabalhos enviados na aplicação. **`monitoringConfiguration`** Para especificar as configurações de log de trabalhos enviados com a aplicação, use o campo [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_MonitoringConfiguration.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_MonitoringConfiguration.html). Para obter mais informações sobre o registro em log do EMR Sem Servidor, consulte [Armazenamento de logs](logging.md). **`runtimeConfiguration`** Para especificar propriedades de configuração de runtime, como `spark-defaults`, forneça um objeto de configuração no campo `runtimeConfiguration`. Isso afeta as configurações padrão de todos os trabalhos enviados com a aplicação. Para obter mais informações, consulte [Parâmetro de substituição da configuração do Hive](jobs-hive.md#hive-defaults-configurationOverrides) e [Parâmetro de substituição de configuração do Spark](jobs-spark.md#spark-defaults-configurationOverrides). As classificações de configuração disponíveis variam de acordo com a versão específica do EMR Sem Servidor. Por exemplo, classificações para Log4j personalizado `spark-driver-log4j2` e `spark-executor-log4j2` estão disponíveis somente nas versões 6.8.0 e superiores. Para obter uma lista de propriedades específicas da aplicação, consulte [Propriedades do trabalho do spark](jobs-spark.md#spark-defaults) e [Propriedades do trabalho do Hive](jobs-hive.md#hive-defaults). Você também pode configurar [propriedades do Apache Log4j2](log4j2.md), o [AWS Secrets Manager para proteção de dados](secrets-manager.md) e o [runtime do Java 17](using-java-runtime.md) no nível da aplicação. Para transmitir segredos do Secrets Manager no nível da aplicação, anexe a política a seguir aos usuários e perfis que precisam criar ou atualizar aplicações do EMR Sem Servidor com segredos. **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SecretsManagerPolicy", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret-name-123abc" ] }, { "Sid": "KMSDecryptPolicy", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012" ] } ] } ``` Para obter mais informações sobre a criação de políticas personalizadas para segredos, consulte [Exemplos de políticas de permissões para AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html) no *Guia do usuário do AWS Secrets Manager *. **nota** A `runtimeConfiguration` que você especifica no nível da aplicação é mapeada para `applicationConfiguration` na API [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html). ### Exemplo de declaração O exemplo a seguir mostra como declarar configurações padrão com `create-application`. ``` aws emr-serverless create-application \ --release-label release-version \ --type SPARK \ --name my-application-name \ --runtime-configuration '[ { "classification": "spark-defaults", "properties": { "spark.driver.cores": "4", "spark.executor.cores": "2", "spark.driver.memory": "8G", "spark.executor.memory": "8G", "spark.executor.instances": "2", "spark.hadoop.javax.jdo.option.ConnectionDriverName":"org.mariadb.jdbc.Driver", "spark.hadoop.javax.jdo.option.ConnectionURL":"jdbc:mysql://db-host:db-port/db-name", "spark.hadoop.javax.jdo.option.ConnectionUserName":"connection-user-name", "spark.hadoop.javax.jdo.option.ConnectionPassword": "EMR.secret@SecretID" } }, { "classification": "spark-driver-log4j2", "properties": { "rootLogger.level":"error", "logger.IdentifierForClass.name": "classpathForSettingLogger", "logger.IdentifierForClass.level": "info" } } ]' \ --monitoring-configuration '{ "s3MonitoringConfiguration": { "logUri": "s3://amzn-s3-demo-logging-bucket/logs/app-level" }, "managedPersistenceMonitoringConfiguration": { "enabled": false } }' ``` ## Substituição de configurações durante a execução de um trabalho Você pode especificar substituições de configuração para a configuração da aplicação e a configuração de monitoramento com a API [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html). Em seguida, o EMR Sem Servidor mescla as configurações que você especifica no nível da aplicação e no nível do trabalho para determinar as configurações da execução do trabalho. O nível de granularidade quando a mesclagem ocorre é o seguinte: + **[https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration)**: tipo de classificação, por exemplo, `spark-defaults`. + **[https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-monitoringConfiguration](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-monitoringConfiguration)**: tipo de configuração, por exemplo, `s3MonitoringConfiguration`. **nota** A prioridade das configurações fornecidas em [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html) substitui as configurações que você fornece no nível da aplicação. Para obter mais informações sobre classificações de prioridade, consulte [Parâmetro de substituição da configuração do Hive](jobs-hive.md#hive-defaults-configurationOverrides) e [Parâmetro de substituição de configuração do Spark](jobs-spark.md#spark-defaults-configurationOverrides). Quando você inicia um trabalho, caso não especifique uma configuração específica, ela será herdada da aplicação. Se você declarar as configurações no nível do trabalho, poderá executar as seguintes operações: + **Substituir uma configuração existente**: forneça o mesmo parâmetro de configuração na solicitação de `StartJobRun` com seus valores de substituição. + **Adicionar mais uma configuração**: adicione o novo parâmetro de configuração na solicitação de `StartJobRun` com os valores que deseja especificar. + **Remover uma configuração existente**: para remover a *configuração de runtime* de uma aplicação, forneça a chave da configuração que deseja remover e passe uma declaração vazia `{}` para a configuração. Não recomendamos remover nenhuma classificação que contenha parâmetros necessários para a execução de um trabalho. Por exemplo, se você tentar remover as [propriedades necessárias de um trabalho do Hive](https://docs.aws.amazon.com/), o trabalho falhará. Para remover a *configuração de monitoramento* de uma aplicação, use o método apropriado para o tipo de configuração relevante: + **`cloudWatchLoggingConfiguration`**: para remover `cloudWatchLogging`, passe o sinalizador habilitado como `false`. + **`managedPersistenceMonitoringConfiguration`**: para remover as configurações de persistência gerenciada e voltar ao estado habilitado padrão, passe uma declaração vazia `{}` para a configuração. + **`s3MonitoringConfiguration`**: para remover `s3MonitoringConfiguration`, passe uma declaração vazia `{}` para a configuração. ### Exemplo de substituição O exemplo a seguir mostra diferentes operações que você pode realizar durante o envio do trabalho em `start-job-run`. ``` aws emr-serverless start-job-run \ --application-id your-application-id \ --execution-role-arn your-job-role-arn \ --job-driver '{ "sparkSubmit": { "entryPoint": "s3://us-east-1.elasticmapreduce/emr-containers/samples/wordcount/scripts/wordcount.py", "entryPointArguments": ["s3://amzn-s3-demo-destination-bucket1/wordcount_output"] } }' \ --configuration-overrides '{ "applicationConfiguration": [ { // Override existing configuration for spark-defaults in the application "classification": "spark-defaults", "properties": { "spark.driver.cores": "2", "spark.executor.cores": "1", "spark.driver.memory": "4G", "spark.executor.memory": "4G" } }, { // Add configuration for spark-executor-log4j2 "classification": "spark-executor-log4j2", "properties": { "rootLogger.level": "error", "logger.IdentifierForClass.name": "classpathForSettingLogger", "logger.IdentifierForClass.level": "info" } }, { // Remove existing configuration for spark-driver-log4j2 from the application "classification": "spark-driver-log4j2", "properties": {} } ], "monitoringConfiguration": { "managedPersistenceMonitoringConfiguration": { // Override existing configuration for managed persistence "enabled": true }, "s3MonitoringConfiguration": { // Remove configuration of S3 monitoring }, "cloudWatchLoggingConfiguration": { // Add configuration for CloudWatch logging "enabled": true } } }' ``` No momento da execução do trabalho, as classificações e configurações a seguir serão aplicadas com base na classificação de substituição de prioridade descrita em [Parâmetro de substituição da configuração do Hive](jobs-hive.md#hive-defaults-configurationOverrides) e [Parâmetro de substituição de configuração do Spark](jobs-spark.md#spark-defaults-configurationOverrides). + A classificação `spark-defaults` será atualizada com as propriedades especificadas no nível do trabalho. Somente as propriedades incluídas em `StartJobRun` são consideradas para essa classificação. + A classificação `spark-executor-log4j2` será adicionada à lista existente de classificações. + A classificação `spark-driver-log4j2` será removida. + As configurações de `managedPersistenceMonitoringConfiguration` serão atualizadas com as configurações no nível do trabalho. + As configurações de `s3MonitoringConfiguration` serão removidas. + As configurações de `cloudWatchLoggingConfiguration` serão adicionadas às configurações de monitoramento existentes.