Ambienti worker Elastic Beanstalk

Se la tua applicazione AWS Elastic Beanstalk esegue operazioni o flussi di lavoro che richiedono molto tempo, è possibile scaricare tali attività in un ambiente lavoratore dedicato. Il disaccoppiamento del front-end della tua applicazione Web da un processo che esegue le operazioni di blocco è un modo comune per assicurare che la tua applicazione rimanga reattiva sotto carico.

Un'attività con esecuzione lunga è tutto ciò che sostanzialmente aumenta il tempo necessario per completare una richiesta, ad esempio l'elaborazione di immagini o video, l'invio di e-mail oppure la generazione di un archivio ZIP. Queste operazioni possono richiedere solo un secondo o due per essere completate, ma alcuni secondi di ritardo è molto per una richiesta Web che altrimenti verrebbe completata in meno di 500 millisecondi.

Un'opzione è generare un processo lavoratore in locale, restituire una risposta positiva ed elaborare le attività in modo asincrono. Questo funziona se la tua istanza è in grado di eseguire tutte le operazioni inviate. In presenza di un carico elevato, tuttavia, un'istanza può essere sovraccaricata da attività in background e non rispondere alle richieste di priorità superiore. Se i singoli utenti sono in grado di generare più attività, l'aumento del carico potrebbe non corrispondere a un aumento degli utenti, rendendo più complesso un ridimensionamento efficiente a livello di server Web.

Per evitare di eseguire localmente le attività con esecuzione a lungo termine puoi usare l'SDK AWS per il tuo linguaggio di programmazione per inviarle a una coda Amazon Simple Queue Service (Amazon SQS) e avviare il processo che le esegue in un set separato di istanze. Le istanze lavoratore vengono quindi progettate per richiedere solo gli elementi dalla coda quando hanno la capacità di eseguirli, evitando così di sovraccaricarle.

Gli ambienti worker Elastic Beanstalk semplificano questo processo gestendo la coda Amazon SQS ed eseguendo un processo daemon su ciascuna istanza che legge dalla coda automaticamente. Quando il daemon preleva un elemento dalla coda, invia una richiesta HTTP POST in locale per http://localhost/ sulla porta 80 con i contenuti del messaggio della coda nel corpo. Tutto quello di cui ha bisogno l'applicazione è eseguire l'attività di lunga esecuzione in risposta al POST. È possibile configurare il daemon per pubblicare su un altro percorso, utilizzare un tipo MIME diverso dall'applicazione/JSON, connettersi a una coda esistente o personalizzare le connessioni (numero massimo di richieste simultanee), il timeout e i tentativi.

Con le attività periodiche, è anche possibile configurare il daemon lavoratore per accodare i messaggi in base a una pianificazione cron Ogni attività periodica può essere resa disponibile su un percorso diverso. Abilita le attività periodiche includendo un file YAML nel tuo codice sorgente che definisce la pianificazione e il percorso per ogni attività.

Daemon SQS dell'ambiente lavoratore

Gli ambienti worker eseguono un processo daemon fornito da Elastic Beanstalk. Questo daemon è aggiornato regolarmente per aggiungere funzionalità e risolvere i bug. Per ottenere la versione più recente del daemon, esegui l'aggiornamento all'ultima versione della piattaforma.

Quando l'applicazione nell'ambiente worker restituisce una risposta 200 OK per dichiarare che ha ricevuto ed elaborato correttamente la richiesta, il daemon invia una chiamata DeleteMessage alla coda Amazon SQS per eliminare il messaggio dalla coda. Se l'applicazione restituisce una risposta diversa da 200 OK, prima di reinserire il messaggio nella coda Elastic Beanstalk attende che termini l'intervallo ErrorVisibilityTimeout configurato. Se non c'è risposta, prima di reinserire il messaggio nella coda Elastic Beanstalk attende che l'intervallo InactivityTimeout termini, in modo che il messaggio sia disponibile per un altro tentativo di elaborazione.

Amazon SQS elimina automaticamente i messaggi che sono stati in una coda per un periodo superiore al RetentionPeriod configurato.

Il daemon imposta le seguenti intestazioni HTTP.

Code DLQ

Gli ambienti worker Elastic Beanstalk supportano le code DLQ di Amazon Simple Queue Service (Amazon SQS). Una coda DLQ è una coda a cui altre code (origini) possono inviare messaggi che, per qualche motivo, non sono stati elaborati correttamente. Uno dei principali vantaggi dell'utilizzo di una coda DLQ è la possibilità di mettere da parte e isolare i messaggi non elaborati in modo corretto. È quindi possibile analizzare i messaggi inviati alla coda DLQ per cercare di stabilire il motivo per cui non sono stati elaborati correttamente.

Per impostazione predefinita, una coda DLQ viene abilitata per un ambiente worker se specifichi una coda Amazon SQS generata automaticamente al momento della creazione di un livello dell'ambiente worker. Se scegli una coda SQS esistente per il tuo ambiente lavoratore, è necessario utilizzare SQS per configurare una coda DLQ in modo indipendente. Per informazioni su come utilizzare SQS per configurare una coda DLQ, consulta Using Amazon SQS Dead Letter Queues.

Non è possibile disabilitare le code DLQ. I messaggi che non possono essere distribuiti vengono infine inviati a una coda DLQ. È possibile, tuttavia, disattivare questa funzione in modo efficiente impostando l'opzione MaxRetries sul massimo valore valido di 100.

Se una coda DLQ non è configurata per la coda Amazon SQS dell'ambiente worker, Amazon SQS mantiene i messaggi nella coda fino alla scadenza del periodo di conservazione. Per informazioni dettagliate sulla configurazione del periodo di conservazione, consulta Configurazione degli ambienti lavoratore.

Per ulteriori informazioni sul ciclo di vita di un messaggio SQS, consulta l'argomento relativo al ciclo di vita dei messaggi.

Attività periodiche

È possibile definire le attività periodiche in un file denominato cron.yaml nel tuo bundle di origine per aggiungere automaticamente processi alla coda dell'ambiente lavoratore a intervalli regolari.

Ad esempio, il file cron.yaml seguente crea due attività periodiche. La prima viene eseguita ogni 12 ore, mentre la seconda tutti i giorni alle 23.00.

version: 1
cron:
 - name: "backup-job"
   url: "/backup"
   schedule: "0 */12 * * *"
 - name: "audit"
   url: "/audit"
   schedule: "0 23 * * *"

Il name deve essere univoco per ogni attività. L'URL è il percorso su cui viene inviata la richiesta POST per attivare l'attività. La pianificazione è un'espressione CRON che stabilisce quando viene eseguita l'operazione.

Quando viene eseguita un'attività, il daemon pubblica un messaggio nella coda SQS dell'ambiente con un'intestazione che indica l'attività che deve essere eseguita. Ogni istanza dell'ambiente può prendere il messaggio ed elaborare l'attività.

Elastic Beanstalk impiega l'elezione dei leader per stabilire quale istanza nell'ambiente worker sposta in coda l'attività periodica. Ogni istanza tenta di diventare leader scrivendo su una tabella Amazon DynamoDB. La prima istanza che va a buon fine è quella leader che deve continuare a scrivere sulla tabella per mantenere lo stato di leader. Se l'istanza leader è inutilizzabile, un'altra istanza prende rapidamente il suo posto.

Per le attività periodiche, il daemon lavoratore imposta le seguenti intestazioni aggiuntive.

Utilizzo di Amazon CloudWatch per la scalabilità automatica nei livelli dell'ambiente worker

Insieme, Amazon EC2 Auto Scaling e CloudWatch monitorano l'utilizzo della CPU delle istanze in esecuzione nell'ambiente worker. Il modo in cui configuri il limite della scalabilità automatica per capacità di CPU determina il numero di istanze che il gruppo Auto Scaling esegue per gestire correttamente il throughput di messaggi nella coda Amazon SQS. Ogni istanza EC2 pubblica i parametri di utilizzo della CPU su CloudWatch. Amazon EC2 Auto Scaling recupera da CloudWatch l'utilizzo medio della CPU in tutte le istanze dell'ambiente worker. È possibile configurare il limite superiore e inferiore e il numero di istanze da aggiungere o terminare in base alla capacità della CPU. Quando Amazon EC2 Auto Scaling rileva che è stato raggiunto il limite massimo specificato per la capacità della CPU, Elastic Beanstalk crea nuove istanze nell'ambiente worker. Le istanze vengono eliminate quando il carico della CPU scende al di sotto della soglia.

Puoi anche impostare altri allarmi CloudWatch, in base alle esigenze, utilizzando la console Elastic Beanstalk, l'interfaccia a riga di comando o il file delle opzioni. Per ulteriori informazioni, consulta Utilizzo di Elastic Beanstalk con Amazon CloudWatch e l'argomento relativo alla creazione di un gruppo Auto Scaling con policy di dimensionamento di fasi.

Configurazione degli ambienti lavoratore

È possibile gestire la configurazione di un ambiente worker modificando la categoria Worker nella pagina Configuration (Configurazione) della console di gestione dell'ambiente.

La pagina di configurazione Modify worker (Modifica worker) presenta le opzioni seguenti.

Nella sezione Queue (Coda):

Nella sezione Messages (Messaggi):

Nella sezione Advanced options (Opzioni avanzate):

Se utilizzi una coda Amazon SQS esistente, le impostazioni configurate al momento della creazione di un ambiente worker possono entrare in conflitto con le impostazioni configurate direttamente in Amazon SQS. Ad esempio, se configuri un ambiente worker con un valore RetentionPeriod superiore al valore MessageRetentionPeriod impostato in Amazon SQS, Amazon SQS elimina il messaggio quando supera il MessageRetentionPeriod.

Al contrario, se il valore RetentionPeriod configurato nelle impostazioni dell'ambiente worker è inferiore al valore MessageRetentionPeriod impostato in Amazon SQS, il daemon elimina il messaggio prima di Amazon SQS. Per VisibilityTimeout, il valore che viene configurato per il daemon nelle impostazioni dell'ambiente worker ignora l'impostazione VisibilityTimeout di Amazon SQS. Assicurati che i messaggi vengano eliminati correttamente confrontando le impostazioni di Elastic Beanstalk con le impostazioni di Amazon SQS.