Use Case / Manufacturing
Upgrade PostgreSQL su AWS RDS e ingegnerizzazione di test di carico
RISULTATI
Riduzione del 20% dei tempi di ETL, senza cambiare query e codice applicativo.
Riduzione del 30% dei costi cloud RDS.
Ottimizzazione delle risorse, con una riduzione dell'uso della CPU dall'80% al 58% e da 25000 iops a 15000 iops
Downtime inferiore ai 30 minuti per l'upgrade dell'istanza RDS da PostgreSQL 10 a PosgreSQL 14.
Nessun impatto applicativo nell'ottimizzazione delle query (es. una query ridotta da 2 minuti e 29 secondi a 36 secondi, senza riscrittura né creazione indici).
Ingegnerizzazione test di carico replicabili in successivi upgrade.
RISULTATI
Riduzione del TCO del 37%, unico fornitore ed infrastruttura scalabile per eventuali nuovi sviluppi.
Riduzione del 62% delle attività di manutenzione ordinaria e straordinaria, infrastruttura sicura e resiliente.
Meno 15% delle interruzioni di servizio legate a malfunzionamento dei sistemi IT e performance migliori.
Il contesto
Il cliente è un importante produttore di soluzioni per condizionamento, refrigerazione e riscaldamento che ha da sempre sviluppato le proprie soluzioni su AWS.
Dopo un'iniziale installazione del database su AWS con il supporto di Miriade, il cliente aveva proseguito in autonomia e, per innumerevoli problematiche applicative, di tempistiche e di priorità, non aveva più aggiornato la versione del database, giungendo presto alla situazione di end of life della versione di PostgreSQL.
A meno di 6 mesi dalla scadenza del supporto di PostgreSQL, il cliente ci ha contattato chiedendoci di fornire supporto con una migrazione database che fosse il più possibile trasparente per l’applicativo.
Dopo un'iniziale installazione del database su AWS con il supporto di Miriade, il cliente aveva proseguito in autonomia e, per innumerevoli problematiche applicative, di tempistiche e di priorità, non aveva più aggiornato la versione del database, giungendo presto alla situazione di end of life della versione di PostgreSQL.
A meno di 6 mesi dalla scadenza del supporto di PostgreSQL, il cliente ci ha contattato chiedendoci di fornire supporto con una migrazione database che fosse il più possibile trasparente per l’applicativo.
L'impatto e le problematiche
Se non fossimo riusciti a migrare in tempo il database, il cliente avrebbe dovuto affrontare un possibile degrado applicativo molto pesante, in conseguenza del fatto che AWS avrebbe provveduto ad eseguire l'upgrade automatico delle istanze.
A complicare la situazione c'era poi il fatto che la migrazione doveva essere effettuata con un downtime molto basso, inferiore alla giornata, nonostante le dimensioni del database fossero considerevoli (circa 10 Tb di dato, 32 vcpu e 128 Gb di ram).
A complicare la situazione c'era poi il fatto che la migrazione doveva essere effettuata con un downtime molto basso, inferiore alla giornata, nonostante le dimensioni del database fossero considerevoli (circa 10 Tb di dato, 32 vcpu e 128 Gb di ram).
La soluzione
La soluzione adottata è stata quella di creare un ambiente ad hoc con Jmeter, per replicare il carico del sistema di produzione, a cui accedevano centinaia di terminali IoT in lettura massiva e scrittura puntuale su un nuovo database upgradato.
Tutto questo per poter testare in ambiente protetto l’upgrade ed essere preparati per lo switch. Grazie a ciò è stato possibile, quindi, replicare una serie di sessioni salvate dall’ambiente di produzione su cui raccogliere il benchmark e i nuovi tempi di esecuzione.
Si è poi provveduto a ottimizzare l’esecuzione delle query passando ad esempio da 20 a 2 secondi, e un’altra da 10 secondi a qualche centesimo di secondo.
Questo ha portato a un carico molto più lineare dell'applicazione, all'abbattimento dei tempi di ETL e, soprattutto, a una riduzione degli iops e dei costi, perché senza ottimizzazioni era necessario continuare ad aumentare la taglia dell'istanza.
Tutto si è svolto in modo trasparente e senza modifiche del codice applicativo.
Tutto questo per poter testare in ambiente protetto l’upgrade ed essere preparati per lo switch. Grazie a ciò è stato possibile, quindi, replicare una serie di sessioni salvate dall’ambiente di produzione su cui raccogliere il benchmark e i nuovi tempi di esecuzione.
Si è poi provveduto a ottimizzare l’esecuzione delle query passando ad esempio da 20 a 2 secondi, e un’altra da 10 secondi a qualche centesimo di secondo.
Questo ha portato a un carico molto più lineare dell'applicazione, all'abbattimento dei tempi di ETL e, soprattutto, a una riduzione degli iops e dei costi, perché senza ottimizzazioni era necessario continuare ad aumentare la taglia dell'istanza.
Tutto si è svolto in modo trasparente e senza modifiche del codice applicativo.
La tecnologia
Per implementare questo progetto sono stati utilizzati:
-
Amazon RDS per PostgreSQL. Il cliente utilizzava PostgreSQL, il database relazionale open source più usato e alla base delle applicazioni aziendali e per dispositivi mobili leader di settore. Di fatto era collegato a migliaia di dispositivi IoT connessi alla rete da tutto il mondo.
La tecnologia
- La soluzione di replica del carico è stata sviluppata a container con Apache Jmeter, quindi è replicabile anche on premise permettendo di replicare chiamate jdbc,http e di altro tipo.
La tecnologia
Per implementare questo progetto sono stati utilizzati:
-
Amazon VPC per creazione rete isolata.
-
AWS VPN per connessione ad infrastruttura on prem.
-
AWS IAM per gestire in sicurezza l'accesso ai servizi e alle risorse AWS.
-
Amazon EC2 per istanze virtuali.
-
AWS Elastic Load Balancing per bilanciamento servizi in HA.
-
AmazonS3 per storage dati e backup applicativi.
-
AWS Directory Service per integrare l’autenticazione dell’Active Directory on-prem su AWS.
-
AWS Lambda per esecuzione codice.
-
Amazon CloudWatch per monitoraggio risorse.
-
Amazon Cloud Endure per replicare in real time gli application server ed automatizzare la generazione dei cloni degli ambienti di test e produzione.
-
AWS Launch Wizard per effettuare il deploy di SAP Hana in modalità single node e HA seguendo le best practice di AWS Well-Architected Framework e rispettando i requisiti richiesti da SAP.
-
AWS Backup per gestire in modalità centralizzata i backup di EC2 e volumi EBS.
-
AWS Systems Manager per Inventory, Compliance e Continuous Configuration Management delle EC2.
-
AWS CodeDeploy per deploy automatizzato script di configurazione e di backup nelle EC2.
-
Amazon Route 53 per gestione risoluzione DNS.
-
Sap Hana HSR Replication per replicare il dato di Sap Hana realtime.
-
PostgreSQL Streaming per replicare il dato di PostgreSQL realtime.
-
Terraform per creare e configurare tutte le risorse in modalità Infrastructure As Code.
-
Atlassian Jira Core per gestire le varie attività del progetto.
-
Atlassian Bitbucket per ospitare il codice Terraform e script custom su repository GIT.
-
Atlassian Bitbucket Pipelines per automatizzare il deploy dell’infrastruttura tramite Terraform ed il deploy degli script custom integrandosi con AWS CodeDeploy.
Vuoi saperne di più sul cloud e su come aggiornare la tua infrastruttura IT
Mettiti in contatto con noi | Miriade è AWS Advanced Consulting Partner