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

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 istanze EC2 in un gruppo con scalabilità automatica configurato per gestire le tipiche percentuali di caricamento. 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 AWS CLI per le attività che devi eseguire. Ad esempio, per ottenere i dati dei parametri che riflettono l'uso attuale della coda, è possibile utilizzare il comando SQS get-queue-attributes. Assicurati che la CLI sia installata e configurata.

Prima di iniziare, dovrai disporre di una coda Amazon SQS da utilizzare. Le seguenti sezioni presuppongono che si disponga già di una coda (standard o FIFO), di un gruppo con scalabilità automatica e di istanze EC2 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).

Configurazione del dimensionamento in base ad Amazon SQS

Passaggio 1: creare una metrica CloudWatch personalizzata

Un parametro personalizzato viene definito utilizzando uno spazio dei nomi e un nome parametro a scelta. Gli spazi dei nomi per i parametri personalizzati non possono iniziare con AWS/. Per ulteriori informazioni sulla pubblicazione di metriche personalizzate, consulta l'argomento Pubblica metriche personalizzate nella Amazon CloudWatch User Guide.

Segui questa procedura per creare la metrica personalizzata leggendo prima le informazioni dal tuo account. AWS Successivamente, calcola il parametro backlog per istanza, come suggerito in una sezione precedente. Infine, pubblica questo numero su con una granularità CloudWatch di 1 minuto. Quando possibile, consigliamo vivamente di dimensionare in base ai parametri con una granularità di 1 minuto, per garantire una risposta più rapida alle modifiche apportate al carico del sistema.

Dopo che l'applicazione ha emesso la metrica desiderata, i dati vengono inviati a. CloudWatch La metrica è visibile nella console. CloudWatch Puoi accedervi accedendo AWS Management Console e accedendo alla pagina. CloudWatch Puoi visualizzare il parametro passando alla pagina dei parametri oppure cercandolo nella casella di ricerca. Per informazioni sulla visualizzazione dei parametri, consulta Visualizza i parametri disponibili nella Amazon CloudWatch User Guide.

Fase 2: creazione una policy di dimensionamento con monitoraggio degli obiettivi

Il parametro creato può ora essere aggiunto a una policy di dimensionamento con monitoraggio degli obiettivi.

Fase 3: test delle policy di dimensionamento

Una volta completata la configurazione, verifica che la policy di dimensionamento funzioni. Puoi testarla incrementando il numero di messaggi nella coda SQS e verificando che il gruppo con scalabilità automatica abbia avviato un'istanza EC2 aggiuntiva. Puoi testarla anche diminuendo il numero di messaggi nella coda SQS e verificando che il gruppo con scalabilità automatica abbia terminato un'istanza EC2.

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 su Dimensionamento automatico Amazon EC2 per gestire senza problemi la terminazione delle istanze.