Le patch di Amazon Redshift possono introdurre behavior changes che, pur migliorando performance e funzionalità, rischiano di rompere workload di produzione o infrangere gli SLA. La pratica consigliata da AWS è tenere i cluster Dev/QA sul Current track e la produzione sul Trailing track, sfruttando la finestra di 1-6 settimane tra l’arrivo di una patch e il deployment in produzione per testare gli effetti del cambiamento.
In un articolo sul suo Big Data Blog, AWS mostra una test suite che automatizza proprio questa validazione: si attiva a ogni patch, reboot o modifica del cluster e usa i driver standard contro pattern di workload reali, funzionando come un gate verificato tra il momento in cui la patch atterra e quello in cui arriva in produzione.
Come funziona la pipeline
La soluzione è interamente serverless e basata su servizi nativi AWS. Le notifiche di evento del cluster Redshift vengono intercettate da regole Amazon EventBridge, che invocano una funzione AWS Lambda leggera. Questa lancia un task AWS Fargate nella stessa VPC del cluster, così da avere connettività di rete diretta con l’endpoint.
Il task esegue un container Docker con una test suite in quattro fasi: test del driver JDBC ufficiale (chiamate DatabaseMetaData, gestione connessioni), test del driver ODBC PostgreSQL (SQLTables, SQLColumns), circa 35 query di catalogo su pg_catalog, information_schema e viste svv_* organizzate per client, e benchmark di performance sulle query più sensibili del proprio workload.
Compatibilità dei client e regressioni
La suite replica il comportamento di connessione di client SQL diffusi (SQL Workbench/J, DBeaver, RStudio via DBI/odbc, API JDBC di metadata) emettendo le stesse chiamate che questi tool eseguono al collegamento. Sul fronte performance, alla prima esecuzione la suite cattura i tempi di esecuzione come baseline “known good”; nelle esecuzioni successive confronta i tempi correnti e segnala le regressioni. Se una query che prima girava in 2 secondi ora ne impiega 15, il report lo evidenzia subito.
I risultati dettagliati in JSON finiscono su Amazon S3 per l’analisi storica, mentre una notifica Amazon SNS invia via email un riepilogo pass/fail. In caso di fallimento si dispone di evidenze concrete (quali query si sono rotte, quali driver o benchmark hanno ceduto) per aprire un support case e chiedere un rollback, differendo la manutenzione fino alla risoluzione.
Per chi lavora con data stack, l’approccio è interessante non solo per Redshift: è un esempio di validazione event-driven a basso costo operativo, che gira solo quando serve e paga solo la compute effettivamente consumata. La soluzione completa (template CloudFormation, script di build Docker, test suite) è disponibile su GitHub e va personalizzata con le proprie query critiche.
- Separare Dev/QA (Current track) e produzione (Trailing track) crea la finestra utile per intercettare le regressioni prima che colpiscano gli utenti.
- Testare con i driver reali (JDBC e ODBC) valida gli stessi code path che i tool usano in produzione, cosa che le query simulate non garantiscono.
- L’automazione event-driven e serverless evita che qualche patch resti non testata, con overhead operativo e costi minimi.
Fonte: Patch perfect: Automating Amazon Redshift patch testing — https://aws.amazon.com/blogs/big-data/patch-perfect-automating-amazon-redshift-patch-testing/
Hai qualcosa da aggiungere? Unisciti alla discussione.