Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Interazione e configurazione di un'applicazione EMR Serverless Questa sezione spiega come interagire con la tua applicazione Amazon EMR Serverless con. AWS CLI Descrive inoltre la configurazione di un'applicazione, l'esecuzione delle personalizzazioni e le impostazioni predefinite per i motori Spark e Hive. **Topics** + [Stati dell'applicazione](#application-states) + [Creazione di un'applicazione EMR Serverless dalla console EMR Studio](studio.md) + [Interazione con l'applicazione EMR Serverless su AWS CLI](applications-cli.md) + [Configurazione di un'applicazione quando si lavora con EMR Serverless](application-capacity.md) + [Personalizzazione di un'immagine EMR Serverless](application-custom-image.md) + [Configurazione dell'accesso VPC per le applicazioni EMR Serverless per la connessione ai dati](vpc-access.md) + [Opzioni di architettura Serverless Amazon EMR](architecture.md) + [Concorrenza dei job e accodamento per un'applicazione EMR Serverless](applications-concurrency-queuing.md) ## Stati dell'applicazione Quando si crea un'applicazione con EMR Serverless, l'esecuzione dell'applicazione entra nello stato. `CREATING` Dopodiché passa per i seguenti stati fino a quando non ha esito positivo (codice di uscita `0`) o negativo (codice di uscita diverso da zero). Le applicazioni possono avere i seguenti stati: **** | Stato | Description | | --- | --- | | Creazione in corso | L'applicazione è in fase di preparazione e non è ancora pronta per l'uso. | | Creato | L'applicazione è stata creata ma non ha ancora fornito capacità. È possibile modificare l'applicazione per modificare la configurazione iniziale della capacità. | | Avvio di | L'applicazione si sta avviando e sta fornendo capacità. | | Avviato | L'applicazione è pronta per accettare nuovi lavori. L'applicazione accetta offerte di lavoro solo quando si trova in questo stato. | | Stopping (In arresto) | Tutti i lavori sono stati completati e l'applicazione sta esaurendo la sua capacità. | | Arrestate | L'applicazione è arrestata e nessuna risorsa è in esecuzione sull'applicazione. È possibile modificare l'applicazione per cambiarne la configurazione iniziale della capacità. | | Terminata | L'applicazione è stata chiusa e non appare nell'elenco delle applicazioni. | Il diagramma seguente illustra la traiettoria degli stati delle applicazioni EMR Serverless. ![\[Stati delle applicazioni EMR Serverless.\]](http://docs.aws.amazon.com/it_it/emr/latest/EMR-Serverless-UserGuide/images/emr-serverless-application-states.png) # Creazione di un'applicazione EMR Serverless dalla console EMR Studio Dalla console EMR Studio, crea, accedi e gestisci applicazioni EMR Serverless. Per accedere alla console EMR Studio, segui le istruzioni in [Guida introduttiva dalla](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console) console. ## Creazione di un'applicazione Con la pagina **Crea applicazione**, crea un'applicazione EMR Serverless seguendo questi passaggi. 1. Nel campo **Nome**, inserisci il nome con cui vuoi chiamare l'applicazione. 1. Nel campo **Tipo**, scegli Spark o Hive come tipo di applicazione. 1. Nel campo **Versione release**, scegli il numero di release EMR. 1. Nelle opzioni **Architettura**, scegli l'architettura del set di istruzioni da utilizzare. Per ulteriori informazioni, vedi [Opzioni di architettura Serverless Amazon EMR](architecture.md). + **arm64** — Architettura ARM a 64 bit; per usare i processori Graviton + **x86\$164 — architettura x86 a 64** bit; per utilizzare processori basati su x86 1. Esistono due opzioni di configurazione dell'applicazione per i campi rimanenti: impostazioni predefinite e impostazioni personalizzate. Questi campi sono facoltativi. **Impostazioni predefinite**: le impostazioni predefinite consentono di creare rapidamente un'applicazione con capacità preinizializzata. Ciò include un driver e un executor per Spark e un driver e un Tez Task per Hive. Le impostazioni predefinite non abilitano la connettività di rete al tuo. VPCs L'applicazione è configurata per arrestarsi se inattiva per 15 minuti e si avvia automaticamente all'invio del lavoro. **Impostazioni personalizzate: le** impostazioni personalizzate consentono di modificare le seguenti proprietà. + **Capacità preinizializzata**: il numero di driver ed esecutori o di Hive Tez Task worker e le dimensioni di ciascun lavoratore. + **Limiti delle applicazioni**: la capacità massima di un'applicazione. + Comportamento dell'applicazione: il **comportamento** di avvio e arresto automatico dell'applicazione. + **Connessioni** di rete: connettività di rete alle risorse VPC. + **Tag**: tag personalizzati che vengono assegnati all'applicazione. Per ulteriori informazioni sulla capacità preinizializzata, sui limiti delle applicazioni e sul comportamento dell'applicazione, fare riferimento a. [Configurazione di un'applicazione quando si lavora con EMR Serverless](application-capacity.md) Per ulteriori informazioni sulla connettività di rete, fare riferimento a. [Configurazione dell'accesso VPC per le applicazioni EMR Serverless per la connessione ai dati](vpc-access.md) 1. Per creare l'applicazione, scegli **Crea applicazione**. # Elenca le applicazioni dalla console EMR Studio È possibile accedere a tutte le applicazioni EMR Serverless esistenti dalla pagina **Elenco** applicazioni. È possibile scegliere il nome di un'applicazione per accedere alla pagina dei **dettagli** dell'applicazione. # Gestione delle applicazioni dalla console EMR Studio È possibile eseguire le seguenti azioni su un'applicazione dalla pagina **Elenco applicazioni** o dalla pagina **Dettagli** di un'applicazione specifica. ****Avvia l'applicazione**** Scegliete questa opzione per avviare manualmente un'applicazione. ****Interrompi l'applicazione**** Scegliete questa opzione per interrompere manualmente un'applicazione. Un'applicazione non deve avere processi in esecuzione per essere interrotta. Per ulteriori informazioni sulle transizioni di stato delle applicazioni, fare riferimento a[Stati dell'applicazione](applications.md#application-states). ****Configurare l'applicazione**** Modifica le impostazioni opzionali per un'applicazione dalla pagina **Configura applicazione**. È possibile modificare la maggior parte delle impostazioni dell'applicazione. Ad esempio, modifica l'etichetta di rilascio di un'applicazione per aggiornarla a una versione diversa di Amazon EMR o cambia l'architettura da x86\$164 a arm64. **Le altre impostazioni opzionali sono le stesse presenti nella sezione **Impostazioni personalizzate** nella pagina Crea applicazione.** Per ulteriori informazioni sulle impostazioni dell'applicazione, fare riferimento a[Creazione di un'applicazione](studio.md#studio-create-app). ****Eliminare l'applicazione**** Scegliete questa opzione per eliminare manualmente un'applicazione. È necessario interrompere un'applicazione per eliminarla. Per ulteriori informazioni sulle transizioni di stato delle applicazioni, fare riferimento a[Stati dell'applicazione](applications.md#application-states). # Interazione con l'applicazione EMR Serverless su AWS CLI Da AWS CLI, crea, descrivi ed elimina singole applicazioni. Puoi anche elencare tutte le tue applicazioni in modo da accedervi con un colpo d'occhio. Questa sezione descrive come eseguire queste azioni. Per ulteriori operazioni sulle applicazioni, come l'avvio, l'arresto e gli aggiornamenti delle applicazioni, fare riferimento all'[EMR Serverless](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html) API Reference. Per esempi su come utilizzare l'API EMR Serverless utilizzando il AWS SDK per Java, consulta gli [esempi Java](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/java-api) nel nostro repository. GitHub Per esempi su come utilizzare l'API EMR Serverless utilizzando il AWS SDK per Python (Boto), consulta gli esempi di [Python](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/python-api) nel nostro repository. GitHub Per creare un'applicazione, usa. `create-application` È necessario specificare `SPARK` o `HIVE` come applicazione`type`. Questo comando restituisce l'ARN, il nome e l'ID dell'applicazione. ``` aws emr-serverless create-application \ --name my-application-name \ --type 'application-type' \ --release-label release-version ``` Per descrivere un'applicazione, usatela `get-application` e fornitela. `application-id` Questo comando restituisce le configurazioni relative allo stato e alla capacità dell'applicazione. ``` aws emr-serverless get-application \ --application-id application-id ``` Per elencare tutte le tue applicazioni, chiama. `list-applications` Questo comando restituisce le stesse proprietà `get-application` ma include tutte le applicazioni. ``` aws emr-serverless list-applications ``` Per eliminare la tua applicazione, chiama `delete-application` e fornisci il tuo`application-id`. ``` aws emr-serverless delete-application \ --application-id application-id ``` # Configurazione di un'applicazione quando si lavora con EMR Serverless Con EMR Serverless, configura le applicazioni che usi. Ad esempio, imposta la capacità massima fino a cui un'applicazione può scalare, configura la capacità preinizializzata per mantenere il conducente e gli operatori pronti a rispondere e specifica un set comune di configurazioni di runtime e monitoraggio a livello di applicazione. Le pagine seguenti descrivono come configurare le applicazioni quando si utilizza EMR Serverless. **Topics** + [Comprensione del comportamento delle applicazioni in EMR Serverless](app-behavior.md) + [Capacità preinizializzata per lavorare con un'applicazione in EMR Serverless](pre-init-capacity.md) + [Configurazione predefinita dell'applicazione per EMR Serverless](default-configs.md) # Comprensione del comportamento delle applicazioni in EMR Serverless Questa sezione descrive il comportamento di invio dei lavori, la configurazione della capacità per la scalabilità e le impostazioni di configurazione del worker per EMR Serverless. ## Comportamento predefinito dell'applicazione **Avvio automatico**: per impostazione predefinita, un'applicazione è configurata per l'avvio automatico all'invio del lavoro. È possibile disattivare questa funzionalità. **Arresto automatico**: per impostazione predefinita, un'applicazione è configurata per l'arresto automatico quando è inattiva per 15 minuti. Quando un'applicazione passa allo `STOPPED` stato, rilascia qualsiasi capacità preinizializzata configurata. È possibile modificare la quantità di tempo di inattività prima dell'arresto automatico di un'applicazione oppure disattivare questa funzionalità. ## Capacità massima È possibile configurare la capacità massima fino alla quale un'applicazione può scalare. È possibile specificare la capacità massima in termini di CPU, memoria (GB) e disco (GB). **Nota** È consigliabile configurare la capacità massima in modo che sia proporzionale alle dimensioni dei lavoratori supportate moltiplicando il numero di lavoratori per le loro dimensioni. Ad esempio, se desideri limitare l'applicazione a 50 worker con 2 vCPUs, 16 GB per la memoria e 20 GB per il disco, imposta la capacità massima su 100 vCPUs, 800 GB per la memoria e 1000 GB per il disco. ## Configurazioni dei lavoratori supportate La tabella seguente elenca le configurazioni e le dimensioni dei lavoratori supportate che possono essere specificate per EMR Serverless. Configura diverse dimensioni per driver ed esecutori in base alle esigenze del carico di lavoro. **Configurazioni e dimensioni dei lavoratori** | CPU | Memoria | Archiviazione temporanea predefinita | | --- | --- | --- | | 1 vCPU | Minimo 2 GB, massimo 8 GB, con incrementi di 1 GB | 20 GB - 200 GB | | 2 vCPU | Minimo 4 GB, massimo 16 GB, con incrementi di 1 GB | 20 GB - 200 GB | | 4 vCPU | Minimo 8 GB, massimo 30 GB, con incrementi di 1 GB | 20 GB - 200 GB | | 8 vCPU | Minimo 16 GB, massimo 60 GB, con incrementi di 4 GB | 20 GB - 200 GB | | 16 vCPU | Minimo 32 GB, massimo 120 GB, con incrementi di 8 GB | 20 GB - 200 GB | **CPU**: ogni lavoratore può avere 1, 2, 4, 8 o 16 CPUs v. **Memoria**: ogni worker dispone di memoria, specificata in GB, entro i limiti elencati nella tabella precedente. I job Spark hanno un sovraccarico di memoria, il che significa che la memoria che usano è superiore alle dimensioni del contenitore specificate. Questo sovraccarico è specificato con le proprietà e. `spark.driver.memoryOverhead` `spark.executor.memoryOverhead` L'overhead ha un valore predefinito del 10% della memoria del contenitore, con un minimo di 384 MB. È necessario considerare questo sovraccarico quando si scelgono le dimensioni dei lavoratori. Ad esempio, se scegli 4 v CPUs per l'istanza di lavoro e una capacità di storage preinizializzata di 30 GB, imposta un valore di circa 27 GB come memoria esecutrice per il tuo job Spark. Ciò massimizza l'utilizzo della capacità preinizializzata. La memoria utilizzabile è di 27 GB, più il 10% di 27 GB (2,7 GB), per un totale di 29,7 GB. **Disco**: è possibile configurare ogni lavoratore con dischi di archiviazione temporanei con una dimensione minima di 20 GB e un massimo di 200 GB. Paghi solo lo spazio di archiviazione aggiuntivo oltre i 20 GB configurato per lavoratore. # Capacità preinizializzata per lavorare con un'applicazione in EMR Serverless EMR Serverless offre una funzionalità opzionale che mantiene il conducente e il personale preinizializzati e pronti a rispondere in pochi secondi. In questo modo si crea in modo efficace un pool di lavoratori accogliente per un'applicazione. Questa funzionalità è denominata capacità *preinizializzata*. Per configurare questa funzionalità, imposta il `initialCapacity` parametro di un'applicazione sul numero di lavoratori che desideri preinizializzare. Con la capacità dei lavoratori preinizializzata, i lavori iniziano immediatamente. Questa soluzione è ideale quando si desidera implementare applicazioni iterative e lavori urgenti. La capacità preinizializzata consente a un gruppo ristretto di lavoratori di essere pronti all'avvio dei lavori e delle sessioni in pochi secondi. I lavoratori preinizializzati assegnati verranno pagati anche quando l'applicazione è inattiva, pertanto suggeriamo di attivarla per i casi d'uso che traggono vantaggio dai tempi di avvio rapidi e di ridimensionarla per un utilizzo ottimale delle risorse. Le applicazioni EMR Serverless si chiudono automaticamente quando sono inattive. Suggeriamo di mantenere attiva questa funzionalità quando si utilizzano worker preinizializzati per evitare addebiti imprevisti. Quando invii un lavoro, se `initialCapacity` sono disponibili lavoratori di, il lavoro utilizza tali risorse per iniziare la sua esecuzione. Se tali lavoratori sono già utilizzati da altri lavori o se il lavoro richiede più risorse di quelle disponibili`initialCapacity`, l'applicazione richiede e ottiene lavoratori aggiuntivi, fino ai limiti massimi di risorse impostati per l'applicazione. Al termine dell'esecuzione, un processo rilascia i worker utilizzati e il numero di risorse disponibili per l'applicazione torna a essere lo stesso`initialCapacity`. Un'applicazione mantiene le `initialCapacity` risorse anche dopo che i job hanno terminato l'esecuzione. L'applicazione rilascia risorse in eccesso oltre il periodo in `initialCapacity` cui i job non ne hanno più bisogno per l'esecuzione. La capacità preinizializzata è disponibile e pronta all'uso all'avvio dell'applicazione. La capacità preinizializzata diventa inattiva quando l'applicazione viene arrestata. Un'applicazione passa allo `STARTED` stato solo se la capacità preinizializzata richiesta è stata creata ed è pronta per l'uso. Per tutto il tempo in cui l'applicazione è nello `STARTED` stato, EMR Serverless mantiene la capacità preinizializzata disponibile per l'uso o l'uso da parte di lavori o carichi di lavoro interattivi. La funzionalità ripristina la capacità dei contenitori rilasciati o guasti. Ciò mantiene il numero di lavoratori specificato dal `InitialCapacity` parametro. Lo stato di un'applicazione senza capacità preinizializzata può cambiare immediatamente da a. `CREATED` `STARTED` È possibile configurare l'applicazione in modo che rilasci la capacità preinizializzata se non viene utilizzata per un determinato periodo di tempo, con un valore predefinito di 15 minuti. Una candidatura interrotta si avvia automaticamente quando invii un nuovo lavoro. È possibile impostare queste configurazioni di avvio e arresto automatiche quando si crea l'applicazione o modificarle quando l'applicazione è in uno `STOPPED` stato `CREATED` or. È possibile modificare i `InitialCapacity` conteggi e specificare configurazioni di calcolo come CPU, memoria e disco per ogni lavoratore. Poiché non puoi apportare modifiche parziali, specifica tutte le configurazioni di calcolo quando modifichi i valori. È possibile modificare le configurazioni solo quando l'applicazione è nello stato o. `CREATED` `STOPPED` **Nota** Per ottimizzare l'uso delle risorse da parte dell'applicazione, suggeriamo di allineare le dimensioni dei container alle dimensioni dei dipendenti preinizializzate. Ad esempio, se configuri la dimensione dell'esecutore Spark su 2 CPUs e la memoria su 8 GB, ma la capacità preinizializzata del worker è 4 CPUs con 16 GB di memoria, gli esecutori Spark utilizzano solo la metà delle risorse dei lavoratori quando vengono assegnati a questo lavoro. ## Personalizzazione della capacità preinizializzata per Spark e Hive Puoi personalizzare ulteriormente la capacità preinizializzata per i carichi di lavoro eseguiti su specifici framework di big data. Ad esempio, quando un carico di lavoro viene eseguito su Apache Spark, specifica quanti worker iniziano come driver e quanti come esecutori. Allo stesso modo, quando usi Apache Hive, specifica quanti lavoratori si avviano come driver Hive e quanti devono eseguire le attività Tez. **Configurazione di un'applicazione che esegue Apache Hive con capacità preinizializzata** La seguente richiesta API crea un'applicazione che esegue Apache Hive basata sulla release emr-6.6.0 di Amazon EMR. L'applicazione inizia con 5 driver Hive preinizializzati, ciascuno con 2 vCPU e 4 GB di memoria, e 50 task worker Tez preinizializzati, ciascuno con 4 vCPU e 8 GB di memoria. Quando le query Hive vengono eseguite su questa applicazione, utilizzano innanzitutto i worker preinizializzati e iniziano l'esecuzione immediatamente. Se tutti i worker preinizializzati sono occupati e vengono inviati più lavori Hive, l'applicazione può scalare fino a un totale di 400 vCPU e 1024 GB di memoria. Facoltativamente, è possibile omettere la capacità per il lavoratore o per il lavoratore. `DRIVER` `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" }' ``` **Configurazione di un'applicazione che esegue Apache Spark con capacità preinizializzata** La seguente richiesta API crea un'applicazione che esegue Apache Spark 3.2.0 basata sulla versione 6.6.0 di Amazon EMR. L'applicazione inizia con 5 driver Spark preinizializzati, ciascuno con 2 vCPU e 4 GB di memoria, e 50 executor preinizializzati, ciascuno con 4 vCPU e 8 GB di memoria. Quando i job Spark vengono eseguiti su questa applicazione, utilizzano innanzitutto i worker preinizializzati e iniziano a essere eseguiti immediatamente. Se tutti i worker preinizializzati sono occupati e vengono inviati più job Spark, l'applicazione può scalare fino a un totale di 400 vCPU e 1024 GB di memoria. Facoltativamente, puoi omettere la capacità per o per. `DRIVER` `EXECUTOR` **Nota** Spark aggiunge un sovraccarico di memoria configurabile, con un valore predefinito del 10%, alla memoria richiesta per driver ed esecutori. Affinché i job utilizzino worker preinizializzati, la configurazione della memoria con capacità iniziale deve essere maggiore della memoria richiesta dal job e dall'overhead. ``` 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" }' ``` # Configurazione predefinita dell'applicazione per EMR Serverless È possibile specificare un set comune di configurazioni di runtime e monitoraggio a livello di applicazione per tutti i lavori inviati nella stessa applicazione. Ciò riduce il sovraccarico aggiuntivo associato alla necessità di inviare le stesse configurazioni per ogni lavoro. È possibile modificare le configurazioni nei seguenti momenti: + [Dichiarare le configurazioni a livello di applicazione al momento dell'invio del lavoro.](#default-configs-declare) + [Sostituisci le configurazioni predefinite durante l'esecuzione del lavoro.](#default-configs-override) Le sezioni seguenti forniscono maggiori dettagli e un esempio per un ulteriore contesto. ## Dichiarazione delle configurazioni a livello di applicazione È possibile specificare le proprietà di registrazione a livello di applicazione e di configurazione di runtime per i lavori inviati tramite l'applicazione. **`monitoringConfiguration`** Per specificare le configurazioni di registro per i lavori inviati con l'applicazione, utilizza il 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) Per ulteriori informazioni sulla registrazione per EMR Serverless, fare riferimento a. [Archiviazione dei registri](logging.md) **`runtimeConfiguration`** Per specificare proprietà di configurazione in fase di esecuzione`spark-defaults`, ad esempio, fornire un oggetto di configurazione nel campo. `runtimeConfiguration` Ciò influisce sulle configurazioni predefinite per tutti i lavori inviati con l'applicazione. Per ulteriori informazioni, consulta [Parametro di sovrascrittura della configurazione Hive](jobs-hive.md#hive-defaults-configurationOverrides) e [Parametro di override della configurazione Spark](jobs-spark.md#spark-defaults-configurationOverrides). Le classificazioni di configurazione disponibili variano in base alla specifica release EMR Serverless. Ad esempio, le classificazioni per Log4j personalizzate `spark-executor-log4j2` sono disponibili solo con le versioni `spark-driver-log4j2` 6.8.0 e successive. Per un elenco delle proprietà specifiche dell'applicazione, fare riferimento a and. [Proprietà del lavoro Spark](jobs-spark.md#spark-defaults) [Proprietà del lavoro di Hive](jobs-hive.md#hive-defaults) È inoltre possibile configurare le [proprietà di Apache Log4j2](log4j2.md), [Gestione dei segreti AWS per la protezione dei dati](secrets-manager.md), e il runtime di [Java](using-java-runtime.md) 17 a livello di applicazione. Per trasmettere i segreti di Secrets Manager a livello di applicazione, allega la seguente policy agli utenti e ai ruoli che devono creare o aggiornare applicazioni EMR Serverless con segreti. **** ``` { "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" ] } ] } ``` *Per ulteriori informazioni sulla creazione di policy personalizzate per i segreti, consulta gli [esempi di policy di autorizzazione disponibili Gestione dei segreti AWS nella Guida per](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html) l'Gestione dei segreti AWS utente.* **Nota** `runtimeConfiguration`Ciò che specifichi a livello di applicazione viene `applicationConfiguration` mappato all'[https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html)API. ### Dichiarazione di esempio L'esempio seguente mostra come dichiarare le configurazioni predefinite con. `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 } }' ``` ## Sovrascrivere le configurazioni durante l'esecuzione di un lavoro È possibile specificare sostituzioni di configurazione per la configurazione dell'applicazione e la configurazione di monitoraggio con l'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) EMR Serverless unisce quindi le configurazioni specificate a livello di applicazione e a livello di processo per determinare le configurazioni per l'esecuzione del lavoro. Il livello di granularità al momento dell'unione è il seguente: + **[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 di classificazione, ad esempio. `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 di configurazione, ad esempio`s3MonitoringConfiguration`. **Nota** La priorità delle configurazioni fornite in [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html)sostituisce le configurazioni fornite a livello di applicazione. Per ulteriori informazioni sulla classificazione delle priorità, consulta e. [Parametro di sovrascrittura della configurazione Hive](jobs-hive.md#hive-defaults-configurationOverrides) [Parametro di override della configurazione Spark](jobs-spark.md#spark-defaults-configurationOverrides) Quando si avvia un lavoro, se non si specifica una configurazione particolare, questa verrà ereditata dall'applicazione. Se si dichiarano le configurazioni a livello di processo, è possibile eseguire le seguenti operazioni: + **Sostituisci una configurazione esistente**: fornisci lo stesso parametro di configurazione nella `StartJobRun` richiesta con i tuoi valori di override. + **Aggiungi una configurazione aggiuntiva**: aggiungi il nuovo parametro di configurazione nella `StartJobRun` richiesta con i valori che desideri specificare. + **Rimuovere una configurazione esistente**: per rimuovere una *configurazione di runtime* dell'applicazione, fornite la chiave per la configurazione che desiderate rimuovere e passate una dichiarazione vuota `{}` per la configurazione. Non è consigliabile rimuovere le classificazioni che contengono parametri necessari per l'esecuzione di un processo. Ad esempio, se si tenta di rimuovere le [proprietà richieste per un lavoro Hive](https://docs.aws.amazon.com/), il processo avrà esito negativo. Per rimuovere una *configurazione di monitoraggio* dell'applicazione, utilizzate il metodo appropriato per il tipo di configurazione pertinente: + **`cloudWatchLoggingConfiguration`**- Per rimuoverla`cloudWatchLogging`, passate il flag enabled as`false`. + **`managedPersistenceMonitoringConfiguration`**- Per rimuovere le impostazioni di persistenza gestita e tornare allo stato abilitato predefinito, passa una dichiarazione vuota `{}` per la configurazione. + **`s3MonitoringConfiguration`**- Per rimuovere`s3MonitoringConfiguration`, passa una dichiarazione vuota `{}` per la configurazione. ### Esempio: override L'esempio seguente mostra diverse operazioni che è possibile eseguire durante l'invio di un lavoro all'indirizzo. `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 } } }' ``` Al momento dell'esecuzione del lavoro, verranno applicate le seguenti classificazioni e configurazioni in base alla classificazione di priorità prioritaria descritta in and. [Parametro di sovrascrittura della configurazione Hive](jobs-hive.md#hive-defaults-configurationOverrides) [Parametro di override della configurazione Spark](jobs-spark.md#spark-defaults-configurationOverrides) + La classificazione `spark-defaults` verrà aggiornata con le proprietà specificate a livello di mansione. Ai fini di questa classificazione `StartJobRun` vengono prese in considerazione solo le proprietà incluse in. + La classificazione `spark-executor-log4j2` verrà aggiunta all'elenco di classificazioni esistente. + La classificazione `spark-driver-log4j2` verrà rimossa. + Le configurazioni di `managedPersistenceMonitoringConfiguration` verranno aggiornate con le configurazioni a livello di processo. + Le configurazioni di `s3MonitoringConfiguration` verranno rimosse. + Le configurazioni di `cloudWatchLoggingConfiguration` verranno aggiunte alle configurazioni di monitoraggio esistenti. # Personalizzazione di un'immagine EMR Serverless A partire da Amazon EMR 6.9.0, utilizza immagini personalizzate per impacchettare le dipendenze delle applicazioni e gli ambienti di runtime in un unico contenitore con Amazon EMR Serverless. Ciò semplifica la gestione delle dipendenze del carico di lavoro e rende i pacchetti più portabili. La personalizzazione dell'immagine EMR Serverless offre i seguenti vantaggi: + Installa e configura pacchetti ottimizzati per i carichi di lavoro. Questi pacchetti non sono ampiamente disponibili nella distribuzione pubblica degli ambienti di runtime Amazon EMR. + Integra EMR Serverless con gli attuali processi di compilazione, test e implementazione all'interno dell'organizzazione, inclusi sviluppo e test locali. + Applica processi di sicurezza consolidati, come la scansione delle immagini, che soddisfano i requisiti di conformità e governance all'interno dell'organizzazione. + Consente di utilizzare le proprie versioni di JDK e Python per le applicazioni. EMR Serverless fornisce immagini da utilizzare come base per la creazione di immagini personalizzate. L'immagine di base fornisce i jar, la configurazione e le librerie essenziali per l'interazione dell'immagine con EMR Serverless. Puoi trovare l'immagine di base nella [Amazon ECR Public Gallery](https://gallery.ecr.aws/emr-serverless/). Usa l'immagine che corrisponde al tipo di applicazione (Spark o Hive) e alla versione di rilascio. Ad esempio, se crei un'applicazione su Amazon EMR versione 6.9.0, utilizza le seguenti immagini. | Tipo | Immagine | | --- | --- | | Spark | `public.ecr.aws/emr-serverless/spark/emr-6.9.0:latest` | | Hive | `public.ecr.aws/emr-serverless/hive/emr-6.9.0:latest` | ## Prerequisiti Prima di creare un'immagine personalizzata EMR Serverless, completare questi prerequisiti. 1. Crea un repository Amazon ECR nello stesso Regione AWS che usi per avviare le applicazioni EMR Serverless. Per creare un repository privato Amazon ECR, consulta [Creazione di un repository privato](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html). 1. Per concedere agli utenti l'accesso al tuo repository Amazon ECR, aggiungi le seguenti policy agli utenti e ai ruoli che creano o aggiornano applicazioni EMR Serverless con immagini da questo repository. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ECRRepositoryListGetPolicy", "Effect": "Allow", "Action": [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:DescribeImages" ], "Resource": [ "arn:aws:ecr:*:123456789012:repository/my-repo" ] } ] } ``` ------ Per ulteriori esempi di policy basate sull'identità di Amazon ECR, consulta gli esempi di policy basate sull'identità di [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html). ## Fase 1: Creare un'immagine personalizzata da immagini di base EMR Serverless Innanzitutto, crea un [Dockerfile](https://docs.docker.com/engine/reference/builder/) che inizi con un'`FROM`istruzione che utilizza l'immagine di base preferita. Dopo le `FROM` istruzioni, includi tutte le modifiche che desideri apportare all'immagine. L'immagine di base imposta automaticamente `USER` su`hadoop`. Questa impostazione non dispone delle autorizzazioni per tutte le modifiche incluse. Come soluzione alternativa, imposta su`root`, modifica `USER` l'immagine e quindi reimpostala su. `USER` `hadoop:hadoop` Per fare riferimento agli esempi per i casi d'uso più comuni, fare riferimento a[Utilizzo di immagini personalizzate con EMR Serverless](using-custom-images.md). ``` # Dockerfile FROM public.ecr.aws/emr-serverless/spark/emr-6.9.0:latest USER root # MODIFICATIONS GO HERE # EMRS runs the image as hadoop USER hadoop:hadoop ``` Dopo aver creato il Dockerfile, crea l'immagine con il seguente comando. ``` # build the docker image docker build . -t aws-account-id.dkr.ecr.region.amazonaws.com/my-repository[:tag]or[@digest] ``` ## Passaggio 2: convalida l'immagine localmente EMR Serverless fornisce uno strumento offline in grado di controllare staticamente l'immagine personalizzata per convalidare file di base, variabili di ambiente e correggere le configurazioni dell'immagine. Per informazioni su come installare ed eseguire lo strumento, consulta [l'Amazon EMR Serverless Image](https://github.com/awslabs/amazon-emr-serverless-image-cli) CLI. GitHub Dopo aver installato lo strumento, esegui il seguente comando per convalidare un'immagine: ``` amazon-emr-serverless-image \ validate-image -r emr-6.9.0 -t spark \ -i aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest ``` L'output appare simile al seguente. ``` Amazon EMR Serverless - Image CLI Version: 0.0.1 ... Checking if docker cli is installed ... Checking Image Manifest [INFO] Image ID: 9e2f4359cf5beb466a8a2ed047ab61c9d37786c555655fc122272758f761b41a [INFO] Created On: 2022-12-02T07:46:42.586249984Z [INFO] Default User Set to hadoop:hadoop : PASS [INFO] Working Directory Set to : PASS [INFO] Entrypoint Set to /usr/bin/entrypoint.sh : PASS [INFO] HADOOP_HOME is set with value: /usr/lib/hadoop : PASS [INFO] HADOOP_LIBEXEC_DIR is set with value: /usr/lib/hadoop/libexec : PASS [INFO] HADOOP_USER_HOME is set with value: /home/hadoop : PASS [INFO] HADOOP_YARN_HOME is set with value: /usr/lib/hadoop-yarn : PASS [INFO] HIVE_HOME is set with value: /usr/lib/hive : PASS [INFO] JAVA_HOME is set with value: /etc/alternatives/jre : PASS [INFO] TEZ_HOME is set with value: /usr/lib/tez : PASS [INFO] YARN_HOME is set with value: /usr/lib/hadoop-yarn : PASS [INFO] File Structure Test for hadoop-files in /usr/lib/hadoop: PASS [INFO] File Structure Test for hadoop-jars in /usr/lib/hadoop/lib: PASS [INFO] File Structure Test for hadoop-yarn-jars in /usr/lib/hadoop-yarn: PASS [INFO] File Structure Test for hive-bin-files in /usr/bin: PASS [INFO] File Structure Test for hive-jars in /usr/lib/hive/lib: PASS [INFO] File Structure Test for java-bin in /etc/alternatives/jre/bin: PASS [INFO] File Structure Test for tez-jars in /usr/lib/tez: PASS ----------------------------------------------------------------- Overall Custom Image Validation Succeeded. ----------------------------------------------------------------- ``` ## Fase 3: carica l'immagine nel tuo repository Amazon ECR Invia la tua immagine Amazon ECR al tuo repository Amazon ECR con i seguenti comandi. Assicurati di disporre delle autorizzazioni IAM corrette per inviare l'immagine al tuo repository. Per ulteriori informazioni, consulta [Pushing an image](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-push.html) nella *Amazon ECR User* Guide. ``` # login to ECR repo aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws-account-id.dkr.ecr.region.amazonaws.com # push the docker image docker push aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest ``` ## Passaggio 4: creare o aggiornare un'applicazione con immagini personalizzate Scegli la Console di gestione AWS scheda o la AWS CLI scheda in base a come desideri avviare l'applicazione, quindi completa i seguenti passaggi. ------ #### [ Console ] 1. [Accedere alla console EMR Studio all'indirizzo https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) Accedi alla tua applicazione o crea una nuova applicazione seguendo le istruzioni in [Creare](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/studio.html#studio-create-app) un'applicazione. 1. Per specificare immagini personalizzate quando si crea o si aggiorna un'applicazione EMR Serverless, selezionare **Impostazioni personalizzate** nelle opzioni di configurazione dell'applicazione. 1. Nella sezione **Impostazioni personalizzate dell'immagine**, selezionare la casella di controllo **Usa l'immagine personalizzata con questa applicazione**. 1. Incolla l'URI dell'immagine Amazon ECR nel campo **URI dell'immagine**. EMR Serverless utilizza questa immagine per tutti i tipi di worker per l'applicazione. In alternativa, puoi scegliere **Immagini personalizzate diverse e incollare immagini** Amazon ECR diverse URIs per ogni tipo di lavoratore. ------ #### [ CLI ] + Crea un'applicazione con il `image-configuration` parametro. EMR Serverless applica questa impostazione a tutti i tipi di lavoratore. ``` aws emr-serverless create-application \ --release-label emr-6.9.0 \ --type SPARK \ --image-configuration '{ "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" }' ``` Per creare un'applicazione con impostazioni di immagine diverse per ogni tipo di lavoratore, utilizzare il `worker-type-specifications` parametro. ``` aws emr-serverless create-application \ --release-label emr-6.9.0 \ --type SPARK \ --worker-type-specifications '{ "Driver": { "imageConfiguration": { "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" } }, "Executor" : { "imageConfiguration": { "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" } } }' ``` Per aggiornare un'applicazione, utilizzate il `image-configuration` parametro. EMR Serverless applica questa impostazione a tutti i tipi di lavoratore. ``` aws emr-serverless update-application \ --application-id application-id \ --image-configuration '{ "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" }' ``` ------ ## Fase 5: consentire a EMR Serverless di accedere all'archivio di immagini personalizzato Aggiungi la seguente policy sulle risorse al repository Amazon ECR per consentire al responsabile del servizio EMR Serverless di utilizzare e `download` le `get` richieste provenienti da questo repository. `describe` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EmrServerlessCustomImageSupport", "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:DescribeImages", "ecr:GetDownloadUrlForLayer" ], "Resource": "arn:aws:ecr:*:123456789012:repository/my-repo", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:emr-serverless:*:123456789012:/applications/*" } } } ] } ``` ------ Come best practice di sicurezza, aggiungi una chiave di `aws:SourceArn` condizione alla policy del repository. La chiave di condizione globale IAM `aws:SourceArn` garantisce che EMR Serverless utilizzi il repository solo per l'ARN di un'applicazione. Per ulteriori informazioni sulle politiche del repository Amazon ECR, consulta [Creazione di un repository privato](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html). ## Considerazioni e limitazioni Quando lavori con immagini personalizzate, considera quanto segue: + Usa l'immagine di base corretta che corrisponda al tipo (Spark o Hive) e all'etichetta di rilascio (ad esempio`emr-6.9.0`) dell'applicazione. + EMR Serverless ignora le nostre `[ENTRYPOINT]` istruzioni nel `[CMD]` file Docker. Usa istruzioni comuni nel file Docker, come, e. `[COPY]` `[RUN]` `[WORKDIR]` + Non modificate le variabili di ambiente `JAVA_HOME``SPARK_HOME`,`HIVE_HOME`,, `TEZ_HOME` quando create un'immagine personalizzata. + Le immagini personalizzate non possono superare le dimensioni di 10 GB. + Se modifichi file binari o jar nelle immagini di base di Amazon EMR, ciò può causare errori di avvio dell'applicazione o del processo. + Il repository Amazon ECR deve trovarsi nello stesso Regione AWS che usi per avviare le applicazioni EMR Serverless. # Configurazione dell'accesso VPC per le applicazioni EMR Serverless per la connessione ai dati Puoi configurare applicazioni EMR Serverless per connetterti ai tuoi archivi di dati all'interno del tuo VPC, come cluster Amazon Redshift, database Amazon RDS o bucket Amazon S3 con endpoint VPC. La tua applicazione EMR Serverless dispone di connettività in uscita agli archivi dati all'interno del tuo VPC. Per impostazione predefinita, EMR Serverless blocca sia l'accesso in entrata alle applicazioni sia l'accesso a Internet in uscita per migliorare la sicurezza. **Nota** È necessario configurare l'accesso VPC se si desidera utilizzare un database metastore Hive esterno per l'applicazione. [Per informazioni su come configurare un metastore Hive esterno, consulta la sezione Configurazione di Metastore.](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/metastore-config.html) ## Crea applicazione Nella pagina **Crea applicazione**, scegli le impostazioni personalizzate e specifica il VPC, le sottoreti e i gruppi di sicurezza che le applicazioni EMR Serverless possono utilizzare. ### VPCs Scegli il nome del cloud privato virtuale (VPC) che contiene i tuoi archivi dati. La pagina **Crea applicazione** elenca tutti quelli VPCs che hai scelto Regione AWS. ### Sottoreti Scegli le sottoreti all'interno del VPC che contiene il tuo data store. La pagina **Crea applicazione** elenca tutte le sottoreti per gli archivi dati nel tuo VPC. Sono supportate sia le sottoreti pubbliche che quelle private. Puoi passare sottoreti private o pubbliche alle tue applicazioni. La scelta di disporre di una sottorete pubblica o privata comporta alcune considerazioni di cui tenere conto. Per le sottoreti private: + Le tabelle di routing associate non devono avere gateway Internet. + Per la connettività in uscita a Internet, se necessario, configura i percorsi in uscita utilizzando un gateway NAT. [Per configurare un gateway NAT, fai riferimento ai gateway NAT.](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-working-with) + Per la connettività Amazon S3, configura un gateway NAT o un endpoint VPC. Per configurare un endpoint VPC S3, consulta [Creare un endpoint gateway](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3). + Se configuri un endpoint VPC S3 e alleghi una policy endpoint per controllare l'accesso, segui le istruzioni in [Logging for EMR Serverless con storage gestito per fornire le autorizzazioni a EMR Serverless per archiviare](logging.html#jobs-log-storage-managed-storage) e servire i log delle applicazioni. + Per la connettività con altri Servizi AWS dispositivi esterni al VPC, ad esempio Amazon DynamoDB, configura gli endpoint VPC o un gateway NAT. Per configurare gli endpoint VPC per Servizi AWS, consulta Lavora [con gli endpoint VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html#working-with-privatelink). **Nota** Quando configuri un'applicazione Amazon EMR Serverless in una sottorete privata, ti suggeriamo di configurare anche gli endpoint VPC per Amazon S3. Se la tua applicazione EMR Serverless si trova in una sottorete privata senza endpoint VPC per Amazon S3, dovrai sostenere costi aggiuntivi per il gateway NAT associati al traffico S3. Questo perché il traffico tra l'applicazione EMR e Amazon S3 non rimarrà all'interno del VPC quando gli endpoint VPC non sono configurati. Per le sottoreti pubbliche: + Questi hanno un percorso verso un Internet Gateway. + È necessario garantire configurazioni adeguate dei gruppi di sicurezza per controllare il traffico in uscita. I lavoratori possono connettersi agli archivi dati all'interno del tuo VPC tramite il traffico in uscita. Per impostazione predefinita, EMR Serverless blocca l'accesso in entrata ai lavoratori. Questo serve a migliorare la sicurezza. Quando si utilizza AWS Config, EMR Serverless crea un record di elementi dell'interfaccia di rete elastica per ogni lavoratore. Per evitare i costi legati a questa risorsa, prendi in considerazione la possibilità di disattivarla. `AWS::EC2::NetworkInterface` AWS Config **Nota** Ti consigliamo di selezionare più sottoreti in più zone di disponibilità. Questo perché le sottoreti scelte determinano le zone di disponibilità disponibili per l'avvio di un'applicazione EMR Serverless. Ogni lavoratore utilizza un indirizzo IP nella sottorete in cui viene avviato. Assicurati che le sottoreti specificate abbiano indirizzi IP sufficienti per il numero di worker che intendi avviare. Per ulteriori informazioni sulla pianificazione delle sottoreti, fare riferimento a. [Procedure consigliate per la pianificazione delle sottoreti](#subnet-best-practices) #### Considerazioni e limitazioni per le sottoreti + EMR Serverless con sottoreti pubbliche non supporta Lake Formation. AWS + Il traffico in entrata non è supportato per le sottoreti pubbliche. ### Gruppi di sicurezza Scegli uno o più gruppi di sicurezza in grado di comunicare con i tuoi archivi di dati. La pagina **Crea applicazione** elenca tutti i gruppi di sicurezza nel tuo VPC. EMR Serverless associa questi gruppi di sicurezza a interfacce di rete elastiche collegate alle sottoreti VPC. **Nota** Si consiglia di creare un gruppo di sicurezza separato per le applicazioni EMR Serverless. **EMR Serverless non consente di **creare**, **aggiornare**, **avviare un'applicazione** se i gruppi di sicurezza hanno porte aperte alla rete Internet pubblica su **0.0.0.0/0 o nell'intervallo: :/0**.** Ciò offre maggiore sicurezza e isolamento e rende più efficiente la gestione delle regole di rete. Ad esempio, questo blocca il traffico imprevisto verso i lavoratori con indirizzi IP pubblici. Per comunicare con i cluster Amazon Redshift, ad esempio, definisci le regole del traffico tra i gruppi di sicurezza Serverless di Redshift ed EMR, come illustrato nell'esempio riportato nella sezione seguente. **Example Esempio: comunicazione con i cluster Amazon Redshift** 1. Aggiungi una regola per il traffico in entrata al gruppo di sicurezza Amazon Redshift da uno dei gruppi di sicurezza EMR Serverless. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) 1. Aggiungi una regola per il traffico in uscita da uno dei gruppi di sicurezza EMR Serverless. Esegui questa operazione in due modi. Innanzitutto, apri il traffico in uscita verso tutte le porte. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) In alternativa, puoi limitare il traffico in uscita ai cluster Amazon Redshift. Ciò è utile solo quando l'applicazione deve comunicare con i cluster Amazon Redshift e nient'altro. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) ## Configura l'applicazione È possibile modificare la configurazione di rete per un'applicazione EMR Serverless esistente dalla pagina **Configura** applicazione. ### Accedi ai dettagli dell'esecuzione del processo Nella pagina dei **dettagli del Job run**, accedi alla sottorete utilizzata dal job per un'esecuzione specifica. Si noti che un processo viene eseguito solo in una sottorete selezionata dalle sottoreti specificate. ## Procedure consigliate per la pianificazione delle sottoreti AWS le risorse vengono create in una sottorete che è un sottoinsieme di indirizzi IP disponibili in un Amazon VPC. Ad esempio, un VPC con maschera di rete /16 ha fino a 65.536 indirizzi IP disponibili che possono essere suddivisi in più reti più piccole utilizzando maschere di sottorete. Ad esempio, è possibile suddividere questo intervallo in due sottoreti, ognuna delle quali utilizza la maschera /17 e 32.768 indirizzi IP disponibili. Una sottorete si trova all'interno di una zona di disponibilità e non può estendersi su più zone. Le sottoreti devono essere progettate tenendo conto dei limiti di scalabilità delle applicazioni EMR Serverless. Ad esempio, se un'applicazione richiede 4 vCPU worker ed è possibile scalare fino a 4.000 vCPU, l'applicazione richiede al massimo 1.000 worker per un totale di 1.000 interfacce di rete. Ti consigliamo di creare sottoreti su più zone di disponibilità. Ciò consente a EMR Serverless di riprovare il lavoro o di fornire capacità preinizializzata in una zona di disponibilità diversa nell'improbabile eventualità di un guasto in una zona di disponibilità. Pertanto, ogni sottorete in almeno due zone di disponibilità deve avere più di 1.000 indirizzi IP disponibili. Sono necessarie sottoreti con una dimensione della maschera inferiore o uguale a 22 per effettuare il provisioning di 1.000 interfacce di rete. Qualsiasi maschera superiore a 22 non soddisfa il requisito. Ad esempio, una subnet mask di /23 fornisce 512 indirizzi IP, mentre una maschera di /22 fornisce 1024 e una maschera di /21 fornisce 2048 indirizzi IP. Di seguito è riportato un esempio di 4 sottoreti con maschera /22 in un VPC di /16 netmask che possono essere allocate a diverse zone di disponibilità. Esiste una differenza di cinque tra gli indirizzi IP disponibili e quelli utilizzabili perché i primi quattro indirizzi IP e l'ultimo indirizzo IP in ogni sottorete sono riservati da. AWS | ID sottorete | Indirizzo di sottorete | Maschera di sottorete | Intervallo di indirizzi IP | Indirizzi IP disponibili | Indirizzi IP utilizzabili | | --- | --- | --- | --- | --- | --- | | 1 | 10.0.0.0 | 255,255,252,0/22 | 10.0.0.0 - 10.0.3.255 | 1,024 | 1.019 | | 2 | 10,04,0 | 255,255,252,0/22 | 10.0.4.0 - 10.0.7.255 | 1,024 | 1.019 | | 3 | 10,08.0 | 255,255,252,0/22 | 10.0.8.0 - 10.0.11.255 | 1,024 | 1.019 | | 4 | 10,012,0 | 255,255,252,0/22 | 10.0.12.0 - 10.0.15.255 | 1,024 | 1.019 | Dovresti valutare se il tuo carico di lavoro è più adatto per lavoratori di grandi dimensioni. L'utilizzo di lavoratori di dimensioni maggiori richiede un minor numero di interfacce di rete. Ad esempio, l'utilizzo di worker a 16 vCPU con un limite di scalabilità delle applicazioni di 4.000 vCPU richiede al massimo 250 lavoratori per un totale di 250 indirizzi IP disponibili per il provisioning delle interfacce di rete. Per effettuare il provisioning di 250 interfacce di rete sono necessarie sottoreti in più zone di disponibilità con una dimensione della maschera inferiore o uguale a 24. Qualsiasi maschera di dimensioni superiori a 24 offre meno di 250 indirizzi IP. Se condividi sottoreti tra più applicazioni, ogni sottorete deve essere progettata tenendo conto dei limiti di scalabilità collettivi di tutte le applicazioni. Ad esempio, se hai 3 applicazioni che richiedono 4 vCPU worker e ciascuna può scalare fino a 4000 vCPU con una quota di servizio basata su 12.000 vCPU a livello di account, ogni sottorete richiede 3000 indirizzi IP disponibili. In caso contrario, è possibile provare ad aumentare il numero di indirizzi IP disponibili. Tale operazione può essere effettuata associando i blocchi di instradamento interdominio senza classi (CIDR) secondari al VPC. Per ulteriori informazioni, consulta [Associare blocchi IPv4 CIDR aggiuntivi al tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) nella *Amazon VPC* User Guide. Puoi utilizzare uno dei tanti strumenti disponibili online per generare rapidamente definizioni di sottorete e rivedere la gamma di indirizzi IP disponibili. # Opzioni di architettura Serverless Amazon EMR L'architettura del set di istruzioni dell'applicazione Amazon EMR Serverless determina il tipo di processori utilizzati dall'applicazione per eseguire il processo. **Amazon EMR offre due opzioni di architettura per l'applicazione: **x86\$164** e arm64.** EMR Serverless si aggiorna automaticamente alle istanze di ultima generazione non appena sono disponibili, in modo che le applicazioni possano utilizzare le istanze più recenti senza richiedere ulteriori sforzi da parte dell'utente. **Topics** + [Utilizzo dell'architettura x86\$164](#x86) + [Utilizzo dell'architettura arm64 (Graviton)](#arm64) + [Lancio di nuove applicazioni con supporto Graviton](#arm64-new) + [Configurazione delle applicazioni esistenti per l'utilizzo di Graviton](#arm64-existing) + [Considerazioni sull'utilizzo di Graviton](#arm64-considerations) ## Utilizzo dell'architettura x86\$164 L'architettura **x86\$164** è anche nota come x86 64-bit o x64. **x86\$164** è l'opzione predefinita per le applicazioni EMR Serverless. Questa architettura utilizza processori basati su x86 ed è compatibile con la maggior parte degli strumenti e delle librerie di terze parti. **La maggior parte delle applicazioni è compatibile con la piattaforma hardware x86 e può essere eseguita correttamente sull'architettura x86\$164 predefinita.** Tuttavia, se l'applicazione è compatibile con ARM a 64 bit, passa ad **arm64** per utilizzare i processori Graviton per migliorare prestazioni, potenza di calcolo e memoria. L'esecuzione di istanze sull'architettura arm64 costa meno rispetto all'esecuzione di istanze di uguali dimensioni sull'architettura x86. ## Utilizzo dell'architettura arm64 (Graviton) AWS I processori Graviton sono progettati su misura AWS con core ARM Neoverse a 64 bit e sfruttano l'architettura arm64 (nota anche come Arch64 o ARM a 64 bit). La linea di processori AWS Graviton disponibile su EMR Serverless include processori Graviton3 e Graviton2. Questi processori offrono un rapporto prezzo/prestazioni superiore per i carichi di lavoro Spark e Hive rispetto ai carichi di lavoro equivalenti eseguiti sull'architettura x86\$164. EMR Serverless utilizza automaticamente i processori di ultima generazione quando disponibili senza alcuno sforzo da parte dell'utente per l'aggiornamento alla generazione di processori di ultima generazione. ## Lancio di nuove applicazioni con supporto Graviton Utilizzate uno dei seguenti metodi per avviare un'applicazione che utilizza l'architettura **arm64**. ------ #### [ AWS CLI ] Per avviare un'applicazione che utilizza i processori Graviton da AWS CLI, specifica `ARM64` come `architecture` parametro nell'`create-application`API. Fornisci i valori appropriati per la tua applicazione negli altri parametri. ``` aws emr-serverless create-application \ --name my-graviton-app \ --release-label emr-6.8.0 \ --type "SPARK" \ --architecture "ARM64" \ --region us-west-2 ``` ------ #### [ EMR Studio ] Per avviare un'applicazione utilizzando i processori Graviton di EMR Studio, **scegli** arm64 come opzione Architettura quando **crei** o aggiorni un'applicazione. ------ ## Configurazione delle applicazioni esistenti per l'utilizzo di Graviton Puoi configurare le tue applicazioni Amazon EMR Serverless esistenti per utilizzare l'architettura Graviton (arm64) con l'SDK o EMR Studio. AWS CLI **Per convertire un'applicazione esistente da x86 a arm64** 1. Conferma di utilizzare la versione principale più recente di [AWS CLI/SDK che supporta](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/emr-serverless/index.html#cli-aws-emr-serverless) il parametro. `architecture` 1. Verificate che non vi siano lavori in esecuzione, quindi arrestate l'applicazione. ``` aws emr-serverless stop-application \ --application-id application-id \ --region us-west-2 ``` 1. Per aggiornare l'applicazione per utilizzare Graviton, specifica `ARM64` il `architecture` parametro nell'`update-application`API. ``` aws emr-serverless update-application \ --application-id application-id \ --architecture 'ARM64' \ --region us-west-2 ``` 1. Per verificare che l'architettura della CPU dell'applicazione sia aggiornata ARM64, utilizza l'`get-application`API. ``` aws emr-serverless get-application \ --application-id application-id \ --region us-west-2 ``` 1. Quando sei pronto, riavvia l'applicazione. ``` aws emr-serverless start-application \ --application-id application-id \ --region us-west-2 ``` ## Considerazioni sull'utilizzo di Graviton Prima di avviare un'applicazione EMR Serverless utilizzando arm64 per il supporto Graviton, confermare quanto segue. ### Compatibilità con le librerie Quando selezioni Graviton (arm64) come opzione di architettura, assicurati che i pacchetti e le librerie di terze parti siano compatibili con l'architettura ARM a 64 bit. Per informazioni su come impacchettare le librerie Python in un ambiente virtuale Python compatibile con l'architettura selezionata, fare riferimento a. [Utilizzo delle librerie Python con EMR Serverless](using-python-libraries.md) Per saperne di più, consulta il repository [AWS Graviton Getting Started](https://github.com/aws/aws-graviton-getting-started) su. GitHub Questo repository contiene risorse essenziali che possono aiutarti a iniziare con Graviton basato su ARM. # Concorrenza dei job e accodamento per un'applicazione EMR Serverless A partire dalla versione 7.0.0 e successive di Amazon EMR, specifica il timeout della coda di esecuzione del lavoro e la configurazione di concorrenza per la tua applicazione. Quando specifichi questa configurazione, Amazon EMR Serverless inizia mettendo in coda il lavoro e inizia l'esecuzione in base all'utilizzo simultaneo dell'applicazione. Ad esempio, se la contemporanea esecuzione di un processo è pari a 10, sull'applicazione vengono eseguiti solo dieci processi alla volta. I job rimanenti vengono messi in coda fino al termine di uno dei job in esecuzione. Se il timeout della coda viene raggiunto prima, il job scade. Per ulteriori informazioni, fare riferimento a [Job run states](job-states.html). ## Principali vantaggi della concorrenza e dell'accodamento La concorrenza e l'accodamento dei lavori offrono i seguenti vantaggi quando sono necessari molti invii di lavoro: + Aiuta a controllare i processi di esecuzione simultanei per utilizzare in modo efficiente i limiti di capacità a livello di applicazione. + La coda può contenere una serie improvvisa di invii di lavori, con un'impostazione di timeout configurabile. ## Guida introduttiva alla concorrenza e alle code Le procedure seguenti illustrano un paio di modi diversi per implementare la concorrenza e l'accodamento. **Usando il AWS CLI** 1. Crea un'applicazione Amazon EMR Serverless con timeout di coda ed esecuzioni di job simultanee: ``` aws emr-serverless create-application \ --release-label emr-7.0.0 \ --type SPARK \ --scheduler-configuration '{"maxConcurrentRuns": 1, "queueTimeoutMinutes": 30}' ``` 1. Aggiorna un'applicazione per modificare il timeout e la concorrenza della coda dei lavori: ``` aws emr-serverless update-application \ --application-id application-id \ --scheduler-configuration '{"maxConcurrentRuns": 5, "queueTimeoutMinutes": 30}' ``` **Nota** È possibile aggiornare l'applicazione esistente per abilitare la concorrenza e l'accodamento dei lavori. A tale scopo, l'applicazione deve avere un'etichetta di rilascio *emr-7.0.0* o successiva. **Usando il Console di gestione AWS** Nei passaggi seguenti viene illustrato come iniziare a utilizzare la concorrenza e l'accodamento dei lavori, utilizzando: Console di gestione AWS 1. Vai a EMR Studio e scegli di creare un'applicazione con etichetta di rilascio EMR-7.0.0 o superiore. 1. **In **Opzioni di configurazione dell'applicazione**, seleziona l'opzione Usa impostazioni personalizzate.** 1. In **Configurazioni aggiuntive** c'è una sezione per le **impostazioni del Job Run**. Seleziona l'opzione **Abilita la concorrenza dei lavori** per abilitare la funzionalità. 1. Dopo la selezione, seleziona Esecuzioni di **processi simultanee** e Timeout di **coda per configurare rispettivamente il numero di esecuzioni di processi simultanee e il timeout** della coda. Se non si inseriscono valori per queste impostazioni, vengono utilizzati i valori predefiniti. 1. Scegliete **Crea applicazione** e l'applicazione verrà creata con questa funzionalità abilitata. Per verificare, vai alla dashboard, seleziona l'applicazione e controlla nella scheda delle proprietà per determinare se la funzionalità è abilitata. Dopo la configurazione, invia lavori con questa funzionalità abilitata. ## Considerazioni sulla concorrenza e sull'accodamento Quando implementate la concorrenza e l'accodamento, tenete in considerazione quanto segue: + Job concurrency and queuing è supportato dalla release 7.0.0 e successive di Amazon EMR. + La concorrenza e l'accodamento dei job sono abilitati per impostazione predefinita su Amazon EMR versione 7.3.0 e successive. + **Non è possibile aggiornare la concorrenza per un'applicazione nello stato STARTED.** + L'intervallo valido per `maxConcurrentRuns` è compreso tra 1 e 1000 e compreso tra 15 e 720. `queueTimeoutMinutes` + Lo stato IN CODA può essere impostato su un massimo **di** 2000 lavori per account. + La concorrenza e l'accodamento si applicano ai lavori in batch e in streaming. Non può essere utilizzato per lavori interattivi. Per ulteriori informazioni, consulta [Esegui carichi di lavoro interattivi con EMR Serverless tramite EMR Studio](interactive-workloads.html).