Riduci la latenza per le applicazioni con tempi di avvio lunghi utilizzando pool caldi - Amazon EC2 Auto Scaling

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

Riduci la latenza per le applicazioni con tempi di avvio lunghi utilizzando pool caldi

Un warm pool offre la possibilità di ridurre la latenza per le applicazioni che hanno tempi di avvio eccezionalmente lunghi, ad esempio, perché le istanze devono scrivere enormi quantità di dati su disco. Con i warm pool, è possibile gestire la latenza per migliorare le prestazioni delle applicazioni evitando di eseguire un provisioning dei gruppi di Auto Scaling oltre il necessario. Per ulteriori informazioni, consulta il seguente post sul blog Ridimensionamento più rapido delle applicazioni con EC2 Auto Scaling Warm Pools.

Importante

Creare un warm pool quando non è necessario può generare costi inutili. Se il primo avvio non causa problemi di latenza evidenti per l'applicazione, probabilmente non è necessario utilizzare un warm pool.

Concetti principali

Prima di iniziare, acquisisci familiarità con i concetti principali riportati di seguito:

Warm pool

Un pool caldo è un pool di EC2 istanze preinizializzate che si trova accanto a un gruppo di Auto Scaling. Ogni volta che l'applicazione deve essere dimensionata, il gruppo con scalabilità automatica può sviluppare sul warm pool per soddisfare la nuova capacità desiderata. L'obiettivo è garantire che le istanze siano pronte per iniziare rapidamente a servire il traffico delle applicazioni, accelerando la risposta a un evento di aumento orizzontale. Man mano che le istanze lasciano il warm pool, contano per la capacità desiderata del gruppo. Si tratta del cosiddetto avvio a caldo.

Mentre le istanze sono nel periodo di riscaldamento, le policy di scalabilità vengono dimensionate orizzontalmente solo se il valore del parametro delle istanze che si trovano nello stato InService è maggiore della soglia massima di allarme della policy di dimensionamento (che è uguale all'utilizzo di destinazione di una policy di dimensionamento con monitoraggio degli obiettivi).

Dimensione di un warm pool

Per impostazione predefinita, la dimensione del warm pool viene calcolata come la differenza tra la capacità massima del gruppo con scalabilità automatica e la capacità desiderata. Ad esempio, se la capacità desiderata del gruppo con scalabilità automatica è 6 e la capacità massima è 10, la dimensione del warm pool sarà 4 quando imposti il warm pool e questo viene inizializzato.

Per specificare separatamente la capacità massima del pool caldo, utilizzate l'opzione custom specifications (MaxGroupPreparedCapacity) e impostate un valore personalizzato maggiore della capacità corrente del gruppo. Se fornite un valore personalizzato, la dimensione del pool caldo viene calcolata come la differenza tra il valore personalizzato e la capacità corrente desiderata del gruppo. Ad esempio, se la capacità desiderata del gruppo Auto Scaling è 6, se la capacità massima è 20 e se il valore personalizzato è 8, la dimensione della piscina calda sarà 2 quando si configura per la prima volta la piscina calda e il pool si sta inizializzando.

Potrebbe essere necessario utilizzare l'opzione custom specifications (MaxGroupPreparedCapacity) solo quando si lavora con gruppi di Auto Scaling di grandi dimensioni per gestire i vantaggi in termini di costi derivanti da una piscina calda. Ad esempio, un gruppo con scalabilità automatica con 1000 istanze, una capacità massima di 1500 (per fornire capacità extra per picchi di traffico di emergenza) e un warm pool di 100 istanze potrebbero aiutarti a raggiungere gli obiettivi meglio che mantenere 500 istanze riservate per un uso futuro all'interno del warm pool.

Dimensione minima del warm pool

Valuta la possibilità di utilizzare l'impostazione della dimensione minima per impostare staticamente il numero minimo di istanze da conservare nel warm pool. Per impostazione predefinita, non è impostata alcuna dimensione minima.

Stato delle istanze del warm pool

È possibile mantenere istanze nel warm pool in uno dei tre stati: Stopped, Running o Hibernated. Mantenere le istanze nello stato Stopped è un modo efficace per ridurre al minimo i costi. Con le istanze arrestate, paghi solo per i volumi utilizzati e gli indirizzi IP elastici assegnati alle istanze.

In alternativa, potete mantenere le istanze in uno Hibernated stato tale da interromperle senza eliminarne il contenuto della memoria (). RAM Quando un'istanza viene ibernata, questo segnala al sistema operativo di salvare il contenuto della tua istanza nel tuo RAM volume EBS root Amazon. Quando l'istanza viene riavviata, il volume root viene ripristinato allo stato precedente e il RAM contenuto viene ricaricato. Mentre le istanze sono in ibernazione, paghi solo per i EBS volumi, incluso lo spazio di archiviazione per RAM i contenuti e gli indirizzi IP elastici collegati alle istanze.

Inoltre, è possibile mantenere delle istanze nello stato Running all'interno del warm pool, ma è vivamente sconsigliato, per evitare di incorrere in spese inutili. Quando le istanze vengono interrotte o ibernate, si risparmia il costo delle istanze stesse. Paghi per le istanze solo quando sono in esecuzione.

Hook del ciclo di vita

Gli hook del ciclo di vita consentono di mettere le istanze in uno stato di attesa in modo da poter eseguire operazioni personalizzate sulle istanze. Le operazioni personalizzate vengono eseguite all'avvio o prima della fine delle istanze.

In una configurazione di pool caldo, gli hook del ciclo di vita ritardano l'arresto o l'ibernazione delle istanze ed evitano che vengano messe in esecuzione durante un evento di aumento orizzontale fino a quando non hanno terminato l'inizializzazione. Se si aggiunge un warm pool al gruppo con scalabilità automatica senza un hook del ciclo di vita, le istanze che richiedono molto tempo per terminare l'inizializzazione potrebbero essere arrestate o ibernate e quindi messe in esecuzione durante un evento di aumento orizzontale prima che siano pronte.

Policy per il riutilizzo delle istanze

Per impostazione predefinita, Amazon EC2 Auto Scaling interrompe le istanze quando il gruppo Auto Scaling aumenta. Quindi, avvia nuove istanze nel warm pool per sostituire quelle che sono state terminate.

Se invece si desidera restituire le istanze al warm pool, è possibile specificare una policy per il riutilizzo delle istanze. Ciò consente di riutilizzare le istanze già configurate per servire il traffico delle applicazioni. Per assicurarsi che il pool caldo non venga fornito eccessivamente, Amazon EC2 Auto Scaling può terminare le istanze nel pool caldo per ridurne le dimensioni quando è più grande del necessario in base alle sue impostazioni. Quando vengono terminate le istanze nel warm pool, si utilizza la policy di terminazione di default per scegliere quali istanze terminare per prime.

Importante

Se si desidera ibernare le istanze durante la riduzione orizzontale e ci sono istanze esistenti nel gruppo con scalabilità automatica, devono soddisfare i requisiti, ad esempio l'ibernazione. In caso contrario, quando le istanze ritornano nel warm pool, vengono nuovamente arrestate e non ibernate.

Nota

Attualmente, puoi specificare una politica di riutilizzo delle istanze solo utilizzando o un. AWS CLI SDK Questa funzionalità non è disponibile dalla console.

Prerequisiti

Prima di creare un pool caldo per il gruppo con dimensionamento automatico, decidi come utilizzare gli hook del ciclo di vita per inizializzare nuove istanze con uno stato iniziale appropriato.

Per eseguire azioni personalizzate sulle istanze mentre sono in stato di attesa a causa di un hook del ciclo di vita, hai due opzioni:

  • Per scenari semplici in cui si desidera eseguire comandi sulle istanze all'avvio, è possibile includere uno script di dati utente quando si crea un modello di avvio o una configurazione di avvio per il gruppo con scalabilità automatica. Gli script di dati utente sono solo normali script della shell o direttive cloud-init gestiti da cloud-init all'avvio delle istanze. Lo script può controllare anche quando le istanze passano allo stato successivo utilizzando l'ID dell'istanza su cui viene eseguito. Se non lo stai già facendo, aggiorna lo script per recuperare l'ID istanza dai metadati dell'istanza. Per ulteriori informazioni, consulta Recupera i metadati dell'istanza nella Amazon EC2 User Guide.

    Suggerimento

    Per eseguire gli script dei dati utente al riavvio di un'istanza, i dati utente devono essere in formato MIME multiparte e specificare quanto segue nella #cloud-config sezione dei dati utente:

    #cloud-config cloud_final_modules: - [scripts-user, always]
  • Per scenari avanzati in cui è necessario un servizio, ad esempio per eseguire operazioni mentre le istanze entrano o escono dal pool caldo, è possibile creare un lifecycle hook per il gruppo Auto Scaling e configurare il servizio di destinazione per eseguire azioni personalizzate basate sulle notifiche del ciclo di vita. AWS Lambda Per ulteriori informazioni, consulta Destinazioni di notifica supportate.

Preparazione delle istanze all'ibernazione

Per preparare le istanze di Auto Scaling all'utilizzo dello stato del Hibernated pool, crea un nuovo modello di avvio o una configurazione di avvio configurata correttamente per supportare l'ibernazione dell'istanza, come descritto nell'argomento Prerequisiti di ibernazione nella Amazon User Guide. EC2 Quindi, associa il nuovo modello di avvio o la configurazione di avvio al gruppo con scalabilità automatica e avvia un aggiornamento delle istanze per sostituire quelle associate a un modello di avvio o alla configurazione di avvio precedenti. Per ulteriori informazioni, consulta Usa un aggiornamento dell'istanza per aggiornare le istanze in un gruppo di Auto Scaling.

Aggiornamento di istanze in un pool caldo

Per aggiornare le istanze in un pool caldo, devi creare un nuovo modello o una nuova configurazione di avvio e associarla al gruppo con dimensionamento automatico. Tutte le nuove istanze vengono lanciate utilizzando i nuovi AMI e altri aggiornamenti specificati nel modello di avvio o nella configurazione di avvio, ma le istanze esistenti non ne risentono.

Per forzare l'avvio di istanze del pool caldo sostitutive che utilizzano il nuovo modello o la nuova configurazione di avvio puoi avviare un aggiornamento in sequenza del tuo gruppo. Un aggiornamento delle istanze sostituisce le istanze InService per prime. Quindi sostituisce le istanze nel warm pool. Per ulteriori informazioni, consulta Usa un aggiornamento dell'istanza per aggiornare le istanze in un gruppo di Auto Scaling.

Puoi visitare il nostro GitHubrepository per esempi di ganci per il ciclo di vita per piscine calde.

Limitazioni

  • Non è possibile aggiungere un pool caldo a un gruppo di Auto Scaling con una politica di istanze miste. Inoltre, non è possibile aggiungere un pool caldo a un gruppo di Auto Scaling che dispone di un modello di avvio o di una configurazione di avvio che richiede istanze Spot.

  • Amazon EC2 Auto Scaling può mettere un'istanza in uno Hibernated stato Stopped or solo se ha un EBS volume Amazon come dispositivo root. Le istanze che utilizzano archivi di istanze per il dispositivo root non possono essere arrestate o ibernate.

  • Amazon EC2 Auto Scaling può mettere un'istanza in uno Hibernated stato solo se soddisfa tutti i requisiti elencati nell'argomento Prerequisiti di ibernazione nella Amazon User Guide. EC2

  • Se il warm pool è esaurito quando c'è un evento di aumento orizzontale, le istanze verranno avviate direttamente nel gruppo con scalabilità automatica (avvio a freddo). Gli avvii a freddo possono verificarsi anche nel caso di inaccessibilità di una zona di disponibilità.

  • Se un'istanza all'interno del pool caldo riscontra un problema durante il processo di avvio che le impedisce di raggiungere lo InService stato, l'istanza verrà considerata un avvio non riuscito e terminata. Ciò vale indipendentemente dalla causa sottostante, ad esempio un errore di capacità insufficiente o qualsiasi altro fattore.

  • Se provi a utilizzare un pool caldo con un gruppo di nodi gestiti di Amazon Elastic Kubernetes Service (EKSAmazon), le istanze ancora in fase di inizializzazione potrebbero registrarsi nel tuo cluster Amazon. EKS Di conseguenza, il cluster potrebbe pianificare i lavori su un'istanza che si sta preparando per essere arrestata o ibernata.

  • Allo stesso modo, se provi a utilizzare un pool caldo con un ECS cluster Amazon, le istanze potrebbero registrarsi nel cluster prima del completamento dell'inizializzazione. Per risolvere il problema, devi configurare un modello di avvio o una configurazione di avvio che includa una variabile di configurazione di agente speciale nei dati utente. Per ulteriori informazioni, consulta la sezione Utilizzo di un warm pool per un gruppo con scalabilità automatica nella Guida per gli sviluppatori di Amazon Elastic Container Service.

  • Il supporto per l'ibernazione per le piscine calde è disponibile in tutte le pubblicità in cui sono disponibili Regioni AWS Amazon Auto EC2 Scaling e ibernazione, ad eccezione di quanto segue:

    • Asia Pacific (Hyderabad)

    • Asia Pacifico (Melbourne)

    • Canada occidentale (Calgary)

    • Regione Cina (Pechino)

    • Regione Cina (Ningxia)

    • Europa (Spagna)

    • Israele (Tel Aviv)