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à. # Gestione delle Service Quotas di Amazon EMR **Topics** + [Cosa sono le Service Quotas di Amazon EMR](emr-service-limits-what-are.md) + [Come gestire le Service Quotas di Amazon EMR](emr-service-limits-strategy.md) + [Quando configurare gli eventi EMR in CloudWatch](emr-service-limits-cloudwatch-events.md) Gli argomenti di questa sezione descrivono le quote del servizio EMR (precedentemente denominate limiti di servizio), come gestirle e quando è vantaggioso utilizzare CloudWatch gli eventi anziché le quote di servizio per monitorare i cluster e attivare azioni. Console di gestione AWS # Cosa sono le Service Quotas di Amazon EMR L' AWS account dispone di quote di servizio predefinite, note anche come limiti, per ogni servizio. AWS Il servizio EMR presenta due tipi di limiti: + *Limiti delle risorse*: è possibile utilizzare EMR per creare risorse EC2. Tuttavia, queste risorse CE2 sono soggette a Service Quotas. I limiti delle risorse in questa categoria sono: + Il numero massimo di cluster attivi che possono essere eseguiti nello stesso momento. + Il numero massimo di istanze attive per gruppo di istanze. + *Limiti APIs*: quando si utilizza EMR APIs, i due tipi di limitazioni sono: + *Limite di frammentazione*: questo è il numero massimo di chiamate API che puoi effettuare contemporaneamente. Ad esempio, il numero massimo di richieste AddInstanceFleet API che è possibile effettuare al secondo è impostato su 5 calls/second come impostazione predefinita. Ciò implica che il limite di burst dell' AddInstanceFleet API è di 5 chiamate/secondo o che, in qualsiasi momento, è possibile effettuare al massimo 5 AddInstanceFleet chiamate API. Tuttavia, dopo aver utilizzato il limite di frammentazione, le chiamate successive sono limitate dal limite di frequenza. + *Limite di frequenza*: questa è la velocità di rifornimento della capacità di espansione dell'API. Ad esempio, la frequenza di rifornimento delle AddInstanceFleet chiamate è impostata a 0,5 come impostazione predefinita. calls/second Ciò significa che dopo aver raggiunto il limite di frammentazione, è necessario attendere almeno 2 secondi (0,5 chiamate/secondo x 2 secondi = 1 chiamata) per effettuare la chiamata API. Se si effettua una chiamata prima di questo valore temporale, si è limitati dal servizio Web EMR. In qualsiasi momento, è possibile effettuare solo un numero di chiamate pari alla capacità di espansione senza alcuna limitazione. Per ogni ulteriore secondo di attesa, la capacità di espansione aumenta di 0,5 chiamate fino a raggiungere il limite massimo di 5, ossia il limite di frammentazione. # Come gestire le Service Quotas di Amazon EMR Service Quotas è una AWS funzionalità che puoi utilizzare per visualizzare e gestire le quote o i limiti del servizio Amazon EMR da una posizione centrale, utilizzando l'API o il Console di gestione AWS. AWS CLI Per ulteriori informazioni sulla visualizzazione delle quote e sulla richiesta di un aumento, consulta [Service Quotas di AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in *Riferimenti generali di Amazon Web Services*. **Importante** Le quote di servizio possono essere applicate indipendentemente l'una dall'altra e, a volte, i loro effetti possono sovrapporsi. Alcune hanno un ambito specifico APIs, mentre altre impongono limiti a livello di account. In particolare, a livello di account vengono applicate le seguenti quote: *La velocità massima di rifornimento del bucket per tutte le operazioni EMR* *Il numero massimo di richieste API che puoi effettuare al secondo* Tieni presente che se richiedi con successo un aumento di quota specifico e continui a riscontrare limitazioni, ad esempio per le richieste API, è possibile che una di queste quote a livello di account continui a limitare le frequenze di chiamata API. Per la risoluzione dei problemi, puoi utilizzare la console Service Quotas, disponibile a [https://console.aws.amazon.com/servicequotas/casa](https://console.aws.amazon.com/servicequotas/home), per verificare i limiti di quota e richiedere aumenti. Se effettui richieste di aumento e continui a riscontrare limitazioni, contatta l'assistenza. *È inoltre possibile trovare i limiti e le descrizioni predefiniti per le [quote del servizio](https://docs.aws.amazon.com/general/latest/gr/emr.html#limits_emr) EMR nella guida di **riferimento AWS generale**.* Per alcuni APIs, l'organizzazione di un CloudWatch evento potrebbe essere un'opzione migliore rispetto all'aumento delle quote di servizio. Puoi anche risparmiare tempo impostando allarmi e attivando l' CloudWatch aumento delle richieste in modo proattivo, prima di raggiungere la quota di servizio. Per ulteriori dettagli, consultare [Quando configurare gli eventi EMR in CloudWatch](emr-service-limits-cloudwatch-events.md). # Quando configurare gli eventi EMR in CloudWatch Per alcune API di polling, ad esempio, and DescribeCluster DescribeStep ListClusters, la configurazione di un CloudWatch evento può ridurre i tempi di risposta alle modifiche e liberare quote di servizio. Se hai impostato una funzione Lambda che si attiva al variare dello stato di un cluster, ad esempio quando una fase viene completata o il cluster viene terminato, puoi utilizzare tale attivazione per avviare l'operazione successiva nel flusso di lavoro anziché attendere il polling successivo. In caso contrario, se hai impostato specifiche istanze Amazon EC2 o funzioni Lambda che eseguono costantemente il polling dell'API EMR per le modifiche, oltre a sprecare risorse di calcolo potresti anche raggiungere la tua quota di servizio. Di seguito sono riportati alcuni casi che mostrano come trarre vantaggio dal passaggio a un'architettura basata su eventi. ## Caso 1: sondaggio EMR DescribeCluster utilizzando chiamate API per il completamento delle fasi **Example Sondaggio EMR DescribeCluster tramite chiamate API per il completamento delle fasi** Uno schema comune consiste nell'inviare una fase a un cluster in esecuzione e interrogare Amazon EMR per verificare lo stato della fase, in genere utilizzando DescribeCluster o. DescribeStep APIs Questa attività può anche essere eseguita con un ritardo minimo collegandosi all'evento di modifica dello stato della fase Amazon EMR. Questo evento include le seguenti informazioni nel relativo payload. ``` { "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Step Status Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:53:09Z", "region": "us-east-1", "resources": [], "detail": { "severity": "ERROR", "actionOnFailure": "CONTINUE", "stepId": "s-ZYXWVUTSRQPON", "name": "CustomJAR", "clusterId": "j-123456789ABCD", "state": "FAILED", "message": "Step s-ZYXWVUTSRQPON (CustomJAR) in Amazon EMR cluster j-123456789ABCD (Development Cluster) failed at 2016-12-16 20:53 UTC." } } ``` Nella mappa di dettaglio, una funzione Lambda potrebbe analizzare "state", "stepId" o "clusterId" per trovare informazioni pertinenti. ## Caso 2: Polling di EMR per i cluster disponibili per l'esecuzione di flussi di lavoro **Example Polling di EMR per i cluster disponibili per l'esecuzione di flussi di lavoro** Un modello utile per i clienti che eseguono più cluster consiste nell'eseguire flussi di lavoro su cluster non appena sono disponibili. Se ci sono molti cluster in esecuzione ed è necessario eseguire un flusso di lavoro su un cluster in attesa, uno schema potrebbe essere quello di interrogare EMR utilizzando DescribeCluster o chiamate ListClusters API per i cluster disponibili. Un altro modo per ridurre il ritardo nel sapere quando un cluster è pronto per una fase è elaborare l'evento di modifica dello stato del cluster Amazon EMR. Questo evento include le seguenti informazioni nel relativo payload. ``` { "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:43:05Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "WAITING", "message": "Amazon EMR cluster j-123456789ABCD ..." } } ``` Per questo evento, potresti impostare una funzione Lambda per inviare immediatamente un flusso di lavoro in attesa a un cluster non appena il suo stato cambia in WAITING (IN ATTESA). ## Caso 3: Polling di EMR per la terminazione del cluster **Example Polling di EMR per la terminazione del cluster** Un modello comune tra i clienti che eseguono molti cluster EMR è il polling di Amazon EMR per cluster terminati in modo che il lavoro non venga più inviato a esso. Puoi implementare questo modello con le chiamate DescribeCluster e ListClusters API o utilizzando l'evento Amazon EMR Cluster State Change in. In seguito alla terminazione del cluster, l'evento emesso ha un aspetto simile all'esempio seguente. ``` { "version": "0", "id": "1234abb0-f87e-1234-b7b6-000000123456", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T21:00:23Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"USER_REQUEST\",\"message\":\"Terminated by user request\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "TERMINATED", "message": "Amazon EMR Cluster jj-123456789ABCD (Development Cluster) has terminated at 2016-12-16 21:00 UTC with a reason of USER_REQUEST." } } ``` La sezione "Detail (Dettaglio)" del payload include il clusterId e lo stato su cui è possibile agire.