{"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>
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

\n
\"\"<\/figure><\/div>\n\n\n

<\/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

Gli zombie<\/h1>\n\n\n
\n
\"\"<\/figure><\/div>\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

\u00c8 questione di fiducia.<\/h1>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

I’m lying when I say, “Trust me”<\/em>
I can’t believe this is true…<\/em>
Trust hurts, why does trust equal suffering?\u201d<\/em>
Megadeth, Trust<\/p>\n\n\n\n

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

{\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
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
Vedo le lambda morte<\/h1>\n\n\n
\n
\"\"<\/figure><\/div>\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
Questo articolo spiega come questi due parametri influenzano l\u2019esecuzione e le prestazioni  Lambda function scaling – AWS Lambda (amazon.com)<\/a>..<\/p>\n\n\n\n
Troppi segreti<\/h1>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
\u201cEsistono alcuni segreti che non si possono essere raccontati\u201d<\/em>
Edgar Allan Poe – L\u2019uomo della folla<\/p>\n\n\n\n
A volte, le infrastrutture possono essere perfette, ma possono comunque essere abusate. Questo \u00e8 il caso di un replatform di un\u2019applicazione e-commerce. Dopo una valutazione e una progettazione iniziali, abbiamo suggerito delle modifiche per integrarsi meglio in un ambiente cloud.<\/p>\n\n\n\n
Sono state implementate sessioni stateless usando a Elasticache per Redis, scalabilit\u00e0 del database usando Aurora Serverless per MySQL, e, infine, \u00e8 stata aumentata la sicurezza grazie all\u2019uso di ruoli e SecretsManager per memorizzare le credenziali del database e le chiavi API esterne, invece dei soliti file di configurazione in chiaro.<\/p>\n\n\n\n
Tutto andava bene quando, dopo un deployment, l\u2019applicazione rallentava e fallivano gli health check del load balancer. <\/p>\n\n\n\n
Si scopr\u00ec che, poich\u00e9 SecretsManager era cos\u00ec facile e comodo da usare, veniva usato per tutto, anche per i parametri di configurazione ordinari come ad esempio i nomi dei bucket, gli endpoint e varie configurazioni.<\/p>\n\n\n\n
Ogni richiesta a una pagina accedeva almeno una o due volte a diversi segreti, e, per peggiorare le cose, c\u2019erano picchi di traffico dovuti alle campagne di marketing. Alla fine del mese, la dashboard del billing AWS ha mostrato 25.000.000 di chiamate API, con un costo aggiuntivo di 150$.<\/p>\n\n\n\n
Ma c\u2019\u00e8 dell\u2019altro: a volte, l\u2019applicazione smetteva di rispondere perch\u00e9 il servizio dei metadati (usato per autenticare le chiamate API usando i ruoli IAM) iniziava a fare throttling delle richieste, pensando che l\u2019applicazione stesse cercando di fare un DoS.<\/p>\n\n\n\n
Dopo aver spiegato il problema e proposto una soluzione che utilizzasse parameter store e le variabili d\u2019ambiente, tutto ha funzionato di nuovo alla perfezione, e il porting \u00e8 andato bene.<\/p>\n\n\n\n
Alta inaffidabilt\u00e0<\/h1>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
\u201cCongratulazioni. Sei ancora vivo. La maggior parte delle persone \u00e8 cos\u00ec ingrata di essere viva. Ma non tu. Non pi\u00f9\u201d<\/em> 
– Saw.<\/p>\n\n\n\n
Parlando di rifacimento delle applicazioni orientate al cloud, questo \u00e8 un semplice errore che a volte vediamo accadere: se un\u2019applicazione \u00e8 altamente disponibile, per favore non legate le richieste vitali a un singolo point of failure (come un server FTP che gira su un\u2019istanza EC2 per recuperare i file di configurazione). Questa \u00e8 una storia breve, ma c\u2019\u00e8 molto dolore dietro. <\/p>\n\n\n\n
Backup infernale<\/h1>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
\u201cTutti impazziamo un po\u2019 a volte.\u201d<\/em>
– Psycho (1960)<\/p>\n\n\n\n
Il disaster recovery dei workload on-premise sul Cloud \u00e8 un argomento attualissimo, soprattutto per le grandi imprese e le architetture on-premise.<\/p>\n\n\n\n
Progettare una soluzione resiliente non \u00e8 facile. Il primo passo \u00e8 trovare una strategia di backup che possa adattarsi e garantire il giusto RPO e RTO. Una volta definita la strategia di backup e i requisiti, \u00e8 il momento di trovare il software giusto che soddisfi le nostre esigenze.<\/p>\n\n\n\n
In una grande impresa, la prima scelta \u00e8 di usare la soluzione esistente, ma adattarla per funzionare sul Cloud. Nessun problema, purch\u00e9 ci sia almeno una forma di integrazione, tipicamente con Amazon Glacier o Amazon S3. Questo era il nostro caso, ma\u2026<\/p>\n\n\n\n
Per rendere le cose pi\u00f9 resilienti, qualcuno ha installato il software su un\u2019istanza EC2 in un account AWS dedicato e lo ha configurato per fare il backup delle macchine on-premise usando la connessione Direct Connect esistente e quindi attraverso l\u2019attachment del Transit Gateway.<\/p>\n\n\n\n
Si pu\u00f2 gi\u00e0 intuire che direzione pu\u00f2 prendere il billing di AWS (spoiler: molto in alto)! Per peggiorare le cose, tutti gli endpoint erano centralizzati in un account di rete dedicato per una migliore gestibilit\u00e0 e osservabilit\u00e0.<\/p>\n\n\n\n
Quindi, per riassumere, un singolo gigabyte salvato da on-premise: <\/p>\n\n\n\n