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

Politica di scalabilità basata su Amazon SQS

In questa sezione viene illustrato come dimensionare il gruppo con scalabilità automatica in risposta alle modifiche apportate al carico di sistema in una coda Amazon Simple Queue Service (Amazon SQS). Per ulteriori informazioni su come utilizzare Amazon SQS, consulta Guida per sviluppatori Amazon Simple Queue.

Vi sono alcuni scenari in cui si potrebbe pensare al dimensionamento in risposta a un'attività in una coda Amazon SQS. Ad esempio, supponi di avere un'app Web che permette agli utenti di caricare immagini e di utilizzarle online. In questo scenario, ogni immagine richiede il ridimensionamento e la codifica, prima di poter essere pubblicata. L'app viene eseguita su EC2 istanze in un gruppo Auto Scaling ed è configurata per gestire le velocità di caricamento tipiche. Le istanze non integre vengono terminate e sostituite per mantenere i livelli di istanze correnti in qualsiasi momento. L'app colloca i dati bitmap grezzi delle immagini in una coda SQS per l'elaborazione. Le elabora e pubblica le immagini elaborate dove possono essere visualizzate dagli utenti. L'architettura per questo scenario funziona bene se il numero di caricamenti di immagini non varia nel tempo. Tuttavia, se il numero di caricamenti cambia nel tempo, per scalare la capacità del gruppo con scalabilità automatica, potresti prendere in considerazione l'utilizzo del dimensionamento dinamico.

Utilizzare il monitoraggio degli obiettivi con il giusto parametro

Se utilizzi una policy di dimensionamento con monitoraggio degli obiettivi basato su un parametro personalizzato della coda Amazon SQS, il dimensionamento dinamico può adattarsi in modo più efficace alla curva di domanda dell'applicazione. Per ulteriori informazioni sulla scelta dei parametri per il monitoraggio degli obiettivi, consulta Selezionare i parametri..

Il problema legato all'utilizzo di una metrica di CloudWatch Amazon SQS come ApproximateNumberOfMessagesVisible per il tracciamento delle destinazioni è che il numero di messaggi nella coda potrebbe non cambiare proporzionalmente alla dimensione del gruppo Auto Scaling che elabora i messaggi dalla coda. Ciò accade perché il numero di messaggi nella coda SQS non definisce esclusivamente il numero di istanze necessarie. Il numero di istanze nel gruppo con scalabilità automatica può essere determinato da più fattori, tra cui la quantità di tempo necessaria per elaborare un messaggio e la quantità di latenza (ritardo della coda) accettabile.

La soluzione è utilizzare un parametro backlog per instance (backlog per istanza) dove il valore di destinazione è il backlog accettabile per istanza da mantenere. È possibile calcolare questi valori nel modo seguente:

Ad esempio, supponiamo che al momento si disponga di un gruppo con scalabilità automatica con 10 istanze e il numero di messaggi visibili nella coda (ApproximateNumberOfMessages) è 1500. Se il tempo di elaborazione medio è 0,1 secondi per ogni messaggio e la latenza massima accettabile è 10 secondi, il backlog per istanza accettabile è 10/0,1, ovvero 100 messaggi. Questo significa che 100 è il valore di destinazione per la policy con monitoraggio degli obiettivi. Quando il backlog per istanza raggiunge il valore target, si verificherà un evento di aumentazione orizzontale. Poiché il backlog per istanza è già di 150 messaggi (1500 messaggi / 10 istanze), il gruppo si aumenta orizzontalmente e si aumenta orizzontalmente di cinque istanze per mantenere la proporzione con il valore target.

Nelle procedure seguenti viene illustrato come pubblicare il parametro personalizzato e creare una policy di dimensionamento con monitoraggio degli obiettivi che permetta di configurare il gruppo con scalabilità automatica in modo che venga dimensionato in base a questi calcoli.

Sono tre, le parti principali di questa configurazione:

Nel diagramma seguente viene illustrata l'architettura di questa configurazione.

Limitazioni e prerequisiti

Per utilizzare questa configurazione, devi essere consapevole delle seguenti limitazioni:

Le seguenti sezioni ti spiegano come utilizzare i AWS CLI per le attività che devi eseguire. Ad esempio, per ottenere dati metrici che riflettano l'uso attuale della coda, si utilizza il comando get-queue-attributesSQS. Assicurati che la CLI sia installata e configurata.

Prima di iniziare, dovrai disporre di una coda Amazon SQS da utilizzare. Le sezioni seguenti presuppongono che l'utente disponga già di una coda (standard o FIFO), di un gruppo di Auto Scaling EC2 e di istanze che eseguono l'applicazione che utilizza la coda. Per ulteriori informazioni su Amazon SQS, consulta la Guida per gli sviluppatori di Amazon Simple Queue Service).

Amazon SQS e la protezione per la riduzione orizzontale delle istanze

I messaggi che non sono stati elaborati nel momento in cui un'istanza viene terminata vengono restituiti alla coda SQS dove possono essere elaborati da un altro daemon su un'istanza ancora in esecuzione. Per le applicazioni in cui vengono eseguite attività di lunga durata, è possibile utilizzare facoltativamente la protezione per la riduzione orizzontale dell'istanza per avere il controllo su quali dipendenti della coda vengono terminati quando il gruppo con scalabilità automatica viene ridotto.

Lo pseudocodice seguente mostra un modo per proteggere i processi di lavoro a esecuzione prolungata e basati sulla coda dalla terminazione della riduzione orizzontale.

while (true)
{
  SetInstanceProtection(False);
  Work = GetNextWorkUnit();
  SetInstanceProtection(True);
  ProcessWorkUnit(Work);
  SetInstanceProtection(False);
}

Per ulteriori informazioni, consulta Progetta le tue applicazioni per gestire in modo corretto la chiusura delle istanze.