Quando configurare gli eventi EMR in CloudWatch - Amazon EMR

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à.

Quando configurare gli eventi EMR in CloudWatch

Per alcune API di polling, ad esempio, and DescribeCluster DescribeStep ListClusters, la configurazione di un CouldWatch 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

Esempio 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 le DescribeStep API o. 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

Esempio 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

Esempio 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.