{"id":6425,"date":"2023-10-27T09:00:00","date_gmt":"2023-10-27T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6425"},"modified":"2023-10-27T09:48:36","modified_gmt":"2023-10-27T07:48:36","slug":"infrastrutture-da-incubo-speciale-halloween-episodio-2","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/infrastrutture-da-incubo-speciale-halloween-episodio-2\/","title":{"rendered":"Infrastrutture da incubo speciale halloween : episodio 2"},"content":{"rendered":"\n
Bimbi e bimbe di ogni et\u00e0,<\/em> <\/p>\n\n\n\n L\u2019anno scorso, abbiamo visto alcune infrastrutture spaventose<\/a>. Siete pronti per il nuovo episodio?<\/p>\n\n\n\n In questo articolo, vedremo storie su alcuni strani design e pratiche che abbiamo incontrato in questo ultimo anno. Sono anti-pattern del Cloud che diventeranno un incubo assoluto nel lungo termine.<\/p>\n\n\n\n Trattenete il respiro; stiamo per iniziare! <\/p>\n\n\n\n <\/p>\n\n\n\n Il concetto moderno di zombi \u00e8 influenzato dalla religione vod\u00f9 haitiana, dove alcune persone credono che un dottore stregone possa far rivivere una persona morta come suo schiavo usando magia o una pozione segreta.<\/p>\n\n\n\n A volte, i task di ECS vengono resuscitati da un servizio, anche se dovrebbero essere sepolti (e fermati). L\u2019abbiamo visto succedere in un ambiente di sviluppo quando un piccolo e grazioso container php aveva un problema a causa di un errore in una pipeline fallita. Il task lottava per restare vivo, ma il brutale healtcheck dell\u2019Application Load Balancer gli sparava in testa; il servizio ECS faceva del suo meglio per far rivivere il task, riprendendolo dal repository ECR.<\/p>\n\n\n\n Nessuno si accorse del problema fino alla fine del mese quando la bolletta fatturato aument\u00f2 a oltre 800$ a causa di 16 Terabyte di traffico attraverso il NAT Gateway.<\/p>\n\n\n\n In questo caso, il circuit breaker di ECS (Deployment circuit breaker – Amazon ECS) era pronto ad aiutare, ma nessuno glielo chiese. Per evitare di creare zombi di ECS, coinvolgetelo la prossima volta che distribuite un container!<\/p>\n\n\n\n <\/p>\n\n\n\n I’m lying when I say, “Trust me”<\/em> Un antico proverbio italiano dice: \u201cDagli amici mi guardi Dio, che dai nemici mi guardo io\u201d.<\/p>\n\n\n\n Questo \u00e8 un episodio breve ma ancora pi\u00f9 spaventoso. Mentre indagavamo su una pipeline fallita, abbiamo visto questa trust relationship in un ruolo con permessi di amministratore su ogni risorsa:<\/p>\n\n\n\n Abbiamo prima staccato la policy e, come dimostrazione del problema, durante una chiamata con il cliente, abbiamo usato il nostro account AWS personale per assumere quel ruolo. Piuttosto spaventoso, eh?<\/p>\n\n\n\n <\/p>\n\n\n\n Esattamente come nel Sesto Senso.. <\/p>\n\n\n\n Era una fredda notte d\u2019inverno, e, durante una tempesta, il nostro cellulare di reperibilit\u00e0 inizi\u00f2 a squillare disperatamente. Un\u2019applicazione serverless lottava per la sopravvivenza, e il nostro API gateway restituiva errori 5xx. Il nostro collega si mise a indagare, e stranamente, tutto era tranquillo. Troppo tranquillo. Nessun log per la lambda associata alla rotta di API Gatewaty era presente in CloudWatch. Quando si facevano richieste con Postman o curl, tutto funzionava alla perfezione. Poich\u00e9 tutto era tornato a funzionare, l\u2019indagine fu rimandata al mattino seguente, ma\u2026 Dopo un\u2019ora, il telefono ricominci\u00f2 a squillare. E, ancora, nessuna traccia di problemi, nemmeno nei log.<\/p>\n\n\n\n Determinato a risolvere il mistero, un altro collega si un\u00ec all\u2019indagine e, mentre revisionava la configurazione\u2026 Apparve improvvisamente! Il nostro cliente, in passato, aveva avuto qualche problema perch\u00e9 la lambda andava in timeout, cos\u00ec aveva \u201criservato un po\u2019 di capacit\u00e0\u201d. Si scopr\u00ec che la reserved concurrency era impostata a 1.<\/p>\n\n\n\n Secondo la documentazione di AWS: \u201cLa reserved concurrency \u00e8 il numero massimo di istanze concorrenti che allocabili alla funzione. Quando una lambda ha impostato la reserved concurrency, nessun\u2019altra funzione pu\u00f2 utilizzare la concorrenza\u201d<\/em>.<\/p>\n\n\n\n Ma c\u2019\u00e8 un trucco: la reserved concurrency \u00e8 anche il numero massimo di istanze lambda concorrenti che possono essere eseguite, quindi impostando questo valore a uno si limita e strozza effettivamente la lambda. In questo modo, se due utenti simultanei chiamano la rotta API, API Gateway restituir\u00e0 un errore 5xx.<\/p>\n\n\n\n Dopo aver rimosso la concorrenza, tutto ha funzionato bene. Per avere delle lambda pronte a servire le richieste occorre considerare la reserved concurrency.<\/p>\n\n\n\n
ecco qualcosa che vi stupir\u00e0!<\/em>
Su, venite \u00e8 propro qui!<\/em>
\u00c8 il paese di Halloween!<\/em> – The nightmare before christmas<\/p>\n\n\n<\/figure><\/div>\n\n\n
Gli zombie<\/h1>\n\n\n
<\/figure><\/div>\n\n\n
\u00c8 questione di fiducia.<\/h1>\n\n\n
<\/figure><\/div>\n\n\n
I can’t believe this is true…<\/em>
Trust hurts, why does trust equal suffering?\u201d<\/em>
Megadeth, Trust<\/p>\n\n\n\n{\n\n \"Version\": \"2012-10-17\",\n\n \"Statement\": [\n\n {\n\n \"Effect\": \"Allow\",\n\n \"Principal\": {\n\n \"AWS\": \"*\"\n\n },\n\n \"Action\": \"sts:AssumeRole\"\n\n }\n\n ]\n\n}<\/code><\/pre>\n\n\n\n
Vedo le lambda morte<\/h1>\n\n\n
<\/figure><\/div>\n\n\n