Come prevenire l'abbraccio della morte sull'istanza EC2?


9

Ho un'app iOS sull'app store e recentemente ho ricevuto un'enorme ondata di traffico sulla mia landing page ospitata su EC2 e ho fatto sì che la pagina non rispondesse, fortunatamente sono riuscita a recuperarla riavviando e aggiornando l'istanza a un t2.medium.

Ora sto cercando di assumere qualcuno per implementare una tecnologia per prevenire di nuovo la stessa morte. La mia esperienza si estende solo fino a questo punto permettendomi di comprendere le cose di base di Devops ma non abbastanza per il bilanciamento del carico su AWS, voglio sapere quale sia un'implementazione conveniente per la mia istanza.

La mia pagina di destinazione e il back-end dell'app iOS sono ospitati nella stessa istanza.


1
La tua landing page è statica?
Michael - sqlbot,

Risposte:


8

Se vuoi qualcosa di veloce per risolverlo senza molta più conoscenza, consiglierei il beanstalk elastico. È un'altra applicazione AWS che gestirà la configurazione del bilanciamento del carico e il ridimensionamento delle istanze.

Non ci sono costi aggiuntivi oltre al bilanciamento del carico e alle istanze, quindi puoi continuare a utilizzare istanze di tipo t2 ma lasciare che il beanstalk elastico si ridimensioni tanto quanto vuoi aiutare.

Il ridimensionamento automatico non è istantaneo e in periodi di traffico intenso ci vorrà un breve lasso di tempo, minuti normalmente, per essere in grado di gestire un picco ma sarà molto meglio che ridimensionare manualmente le dimensioni dell'istanza ed è davvero facile arrivare ai grip con.


1

Consiglierei il ridimensionamento automatico come menzionato sopra con l'aggiunta di alcuni allarmi CloudWatch per avviare il processo di ridimensionamento automatico quando soglie specifiche iniziano ad aumentare, non quando è già andato molto lontano.

Per esempio; configura CloudWatch per monitorare il tuo server, quando la CPU è al 50% o superiore per un periodo di almeno 30 secondi, avvia il processo di ridimensionamento automatico.

Questo potrebbe non essere completamente impeccabile, ma è facile da fare tramite alcune guide online e tutte configurabili tramite la GUI.

Inoltre, se la tua pagina di destinazione è statica, perché non ospitarla su un t2.micro di livello gratuito e utilizzare un altro livello libero di t2.micro per la tua app?


Il ridimensionamento automatico non è la risposta olistica durante gli aumenti improvvisi del traffico. La finestra di rilevamento del ridimensionamento automatico si trova tra 1-5 minuti, a seconda del provisioning anche questo può richiedere del tempo. Generalmente la risposta corretta è far funzionare le istanze a caldo, vale a dire: al di sopra del livello di traffico percepito e consentire il ridimensionamento automatico per mantenere quel margine.
Matt O.

1

Mi piacerebbe aiutarti se stai cercando aiuto. A seconda della tua pagina potresti non aver bisogno di ec2. Ad esempio, se stai offrendo qualcosa di statico o JavaScript, può essere offerto da s3 con una distribuzione cloudfront. Oppure potremmo eventualmente utilizzare un gruppo di ridimensionamento automatico se assolutamente necessario.


1

Esistono due strategie generali per gestire le ondate di traffico: aumentare la capacità e ridurre i costi.

L'aumento della capacità significa il ridimensionamento automatico, di cui tutti erano molto entusiasti quando i cloud pubblici sono diventati disponibili per la prima volta. Nel suo senso più elementare, questo avvierà più webserver per te in base al carico e li aggiungerà a un bilanciamento del carico, ma poiché può essere una seccatura da gestire, ci sono anche più soluzioni automagiche, come Elastic Beanstalk.

Il problema con l'espansione automatica della capacità è che anche l'espansione automatica delle bollette - 10 volte il traffico normale significa 10 volte i server significa 10 volte il denaro che devi pagare. Ecco perché, sebbene sia una strategia utile da tenere a mente, penso che dovresti sempre iniziare a vedere quanto puoi imbrogliare.

Per truffa, intendo cache, che si basa sull'idea che la maggior parte delle volte è possibile fornire agli utenti dati leggermente obsoleti e non se ne accorgeranno, e ciò può farti risparmiare enormi quantità di tempo. Immagina di avere una pagina che decidi che va bene se è scaduta da cinque secondi e ottiene 20 req / s. Senza memorizzazione nella cache, esegui quel calcolo 1200 volte al minuto, mentre con la memorizzazione nella cache sono solo 12. Puoi vedere come questo può fare una differenza enorme.

Esistono ovviamente molti tipi di cache e un sito Web di successo ne utilizzerà diversi. Ma per il tuo caso d'uso, ci sono due opzioni abbastanza buone e facili.

Il primo è rendere il sito completamente statico. Questo presuppone che tu possa farlo, ma se puoi, allora hai solo Nginx che serve direttamente l'html e che può servire tonnellate di richieste senza sudore.

Se hai bisogno di un certo livello di dinamicità, fare un po 'di cache a tutta pagina è una buona opzione. Nginx ha alcune capacità per farlo, ma mi piace davvero Varnish per la sua flessibilità.

Qualunque opzione o opzioni segua, assicurati di eseguire i test di carico per confermare che l'hai impostato correttamente; a volte, riparare un punto espone un nuovo collo di bottiglia.


0

Vorrei condividere la nostra esperienza con AWS. Abbiamo distribuito la nostra applicazione su EC2 e abbiamo riscontrato lo stesso problema e costi elevati. Abbiamo distribuito la nostra applicazione Amazon EC2 Container Service sebbene la nostra applicazione fosse monolitica, ma ci siamo riusciti

  • Disponibilità
  • Conveniente
  • scalabilità

Il bilanciamento del carico dell'applicazione gestirà il traffico e indirizzerà il traffico all'istanza integra e sarà possibile eseguire più attività degli stessi servizi senza preoccuparsi del ridimensionamento e del bilanciamento del carico.

Questa architettura semplifica l'implementazione dell'isolamento degli errori. Tecniche come il controllo dello stato, la memorizzazione nella cache, le paratie o gli interruttori di circuito consentono di ridurre il raggio di esplosione di un componente guasto e di migliorare la disponibilità complessiva di una determinata applicazione.


Non esiste un prezzo separato per ECS , ma solo le risorse EC2 sottostanti, quindi come è stato l'utilizzo dell'ECS più conveniente? Dovrebbe consumare la stessa quantità di risorse sia che tu gestisca i container da solo o che consenta ad Amazon di farlo.
Boicottaggio SE per Monica Cellio,

nel container se stai usando alpine che è 5mb ed ec2 stai usando ubuntu che è 2 GB? quale è la cosa migliore? in T2 micro puoi eseguire un contenitore a 5 php con scala in entrata e in uscita sulla base del traffico .. puoi eseguire in ec2 con scala in entrata e in scala?
Adiii,

Non è necessario utilizzare Ubuntu per le istanze ec2; puoi caricare un'immagine alpina e utilizzarla se lo desideri. Se hai fatto funzionare tutto con ECS, è fantastico, ed è improbabile che tu voglia tornare indietro, ma il mio punto è che il semplice passaggio a ECS non rende un'app più scalabile o economica; sono state apportate altre modifiche all'app, all'infrastruttura e all'architettura contemporaneamente.
Boicottaggio SE per Monica Cellio,

0

Questo dipende molto dall'architettura specifica, ma ad esempio:

  • Carica frontalmente il tuo sito Web con CloudFront per ridurre il carico sull'host
  • Usa il servizio di hosting lato client in qualcosa come S3 per la scala
  • Bilanciamento del carico elastico con un gruppo con scalabilità automatica
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.