Application Performance Management

Application Performance Management

Indice 1. Introduzione all’APM - Application Performance 2. Scenario tipico di produzione 3. Le architetture 4. Gli attori coinvolti 5. Sistemi distribuiti 6. Definizioni

Introduzione all’APM - Application Performance Questo articolo introduce i concetti ed i termini fondamentali dell’ Application Performance Management (APM), utilizzando come scenario di esempio un ambiente tipico per le applicazioni on-line basate sull'edizione enterprise di Java (JEE). L'obiettivo dell'APM è la gestione delle performance applicative, intese come l'insieme dei requisiti (impliciti ed espliciti) non funzionali che caratterizzano la qualità del servizio come percepita dall'utente. Per valutare la qualità del sistema preposto all'erogazione del servizio, cioè quanto bene esso assolva lo scopo per cui è stato costruito, si utilizzano degli indicatori quali tempi di risposta, disponibilità, capacità etc etc. L’articolo presenta le metriche più utilizzate per monitorare la qualità del servizio e ne esemplifica l'uso. L'utilizzo di metriche comporta la disponibilità di misure, valori limite, andamenti storici e trend dei dati; essi presentano in modo quantitativo ed oggettivo il quadro completo delle performance applicative. Queste misure sono prese nell'ambiente di produzione dove è necessario considerare aspetti quali la sicurezza e l'impatto del monitoraggio sulle performance applicative (overhead). In genere per l'overhead sono ammessi solo pochi punti percentuali della capacità totale delle CPU di produzione, tipicamente il 2 o il 3%. In pratica più misure si prendono e maggiore è l'impegno di CPU necessario. Per mantenere accettabile l'overhead è necessario l'uso di una tecnologia evoluta e di configurazioni specifiche che limitano il numero delle metriche a quelle strettamente necessarie. E' fondamentale quindi trovar l'equilibrio tra queste due necessità contrapposte: da una parte quella di avere la massima

copertura del monitoraggio, dall'altra quella di avere il minimo overhead. Per ottenere questo è necessario conoscere quanto più dettagliatamente possibile l'architettura e gli utenti del sistema. L’articolo descrive l'architettura tipica, o meglio quella consigliata dalle best practice della JEE, sia dal punto di vista sistemistico che applicativo. Una chiara comprensione dell'architettura è infatti uno dei prerequisiti per la corretta applicazione delle tecniche dell'APM. L'insieme dei profili delle persone coinvolte nella gestione e sviluppo del sistema on-line, assieme alla sua complessità interna, fa intendere come il sistema sia da trattare utilizzando gli strumenti tipici dei sistemi complessi. Vedremo infatti come il monitoraggio separato secondo i diversi layer o ambienti (web, middleware, EIS, rete) sia destinato a fallire per i sistemi distribuiti.

Scenario tipico di produzione

Diagramma 1: Scenario tipico di produzione Come esemplificato dal diagramma 1, lo scenario tipico della produzione di una applicazione web distribuita presenta una intrinseca complessità dovuta, in primo luogo, ai diversi layer presenti. Solitamente lo specialista APM è chiamato ad operare o per attività di troubleshooting oppure all'interno di un progetto di monitoraggio. In entrambi i casi o il sistema è già operativo o comunque in una fase finale di implementazione perciò è molto importante riuscire a riconoscere i pattern architetturali più comuni e separare le soluzioni custom da analizzzare di volta in volta. L'utilizzo di standard rende possibile la scomposizione delle scenario completo in sotto moduli interdipendenti. Inoltre rende superfluo la descrizione dettaglia delle singole implementazioni dei diversi vendor e

permette così di focalizzare l'attenzione sul layer di interesse (applicativo, infrastrutturale, sistemistico..etc.). I diversi attori interagiscono con il sistema ognuno tramite una interfaccia utente che maschera questa complessità, mostrando loro solo la parte di proprio interesse e non tutti i moduli, che però utilizza e di cui necessita nelle sue funzioni.

Diagramma 2: Scenario tipico di produzione con più dettaglio Come si può dedurre dal diagramma 2, è inutile cercare di mostrare il dettaglio mantenendo la visione di insieme. Meglio utilizzare la modularità della soluzione e descrivere sistematicamente ogni singolo modulo, fermandosi alle interfacce con gli altri moduli o con gli altri layer. Esistono quindi diversi strati (i 'layers'), differenti fornitori dei prodotti (i 'vendors') e differenti profili delle persone che interagiscono e utilizzano l'applicazione (i 'profiles'). Il risultato è un agglomerato potenzialmente complesso da controllare ma in definitiva composto da parti che sono semplici da affrontare, a patto di conoscere per ognuna di esse cosa sta facendo e perché è presente nel sistema.

Le architetture L'architettura dell'applicazione deve essere affrontata dal punto di vista applicativo e da quello sistemistico. Entrambi seguono le direttive e le implementazioni dello standard J2EE, che prevede per l'AS un ruolo centrale server side. L’architettura applicativa

Figura 1: esempio di architettura applicativa L'applicazione presenta una architettura interna basata su componenti standard, ognuno con specifici compiti e funzionalità (Servlet, JSP, EJB, connettori). I componenti possono essere sviluppati in modo indipendente ed essere deployati direttamente sull'AS; oppure tramite uno specifico framework applicativo (Struts, Spring, Seam.. ). Poiché l'AS J2EE utilizza la JVM Standard Edition (SE), le applicazioni JEE possono usare anche i Plain Old Java Objects

(POJO).

L’architettura sistemistica

Figura 2: esempio di architettura sistemistica L'architettura distribuita prevede un Hub server side che riceve e smista le richieste applicative (l'AS). Utilizza i dati e le funzioni dei sistemi di backend. A seconda del tipo di applicazione si possono avere orchestrazioni di funzioni già presenti nei back end, o elaborazione nel middleware dei dati presi dai back end, o un mix di entrambi. L'architettura di produzione viene clonata in pre-produzione, e normalmente coesistono ambienti di integrazione e quality assurance.

Gli attori coinvolti Ogni attore è una persona che agisce nel sistema secondo uno scopo predeterminato dal suo profilo. Ogni profilo (utente, responsabili di business, operatore sistemistico, sviluppatore, architetto, tester, operatore Q/A) ha le proprie necessità e desiderata. Spesso utilizza un linguaggio e strumenti specialistici, entrambi validi unicamente per i propri fini. Questi linguaggi però non sono adatti allo scambio di informazioni con gli altri profili e ciò può essere un fattore limitante nella gestione complessiva del sistema sotto esame. Nell’APM si individuano sei attori: 1. 2. 3. 4. 5. 6.

Customer LOB manager Operator Developer Q/A tester Management

Vediamoli nel dettaglio. Il cliente (Customer) utilizza l'applicazione per i suoi scopi di business ed eventualmente chiede assistenza (per esempio ad un operatore di help desk). Il responsabile della linea di business (LOB manager) è interessato al livello di servizio e alla soddisfazione del cliente. I tecnici delle operations hanno il monitoraggio completo, nel caso di avvisi conoscono per primi il problema (prima degli utenti), ne capiscono l'origine e sanno chi contattare di caso in caso. Lo sviluppatore (Developer) implementa le nuove funzionalità, elabora le correzioni all'applicazione. Il Q/A tester controlla e verifica le funzionalità sotto test. Riproduce gli errori utilizzando i dati opportuni. Assicura il corretto funzionamento in produzione. Il Management controlla i costi, verifica che gli accordi sul livello di servizio (SLA) siano rispettati, si assicura che il sistema e le persone lavorino efficacemente.

Solo alcuni attori sono direttamente coinvolti nelle attività di gestione delle performance dell'applicazione: • • • •

LOB manager: Comunica gil SLA, controlla la soddisfazione del cliente, produce report per il business e i manger Operator: Controlla la produzione 24/7, si attiva in modo proattivo alla ricezione degli avvisi per evitare l'impatto sulla produzione Developer: Coinvolto nella ricerca delle cause di problemi applicativi, eventualmente fornisce le patch Q/A - Application support: Raccoglie i dati degli incident, effettua il triage sui diversi problemi

Sistemi distribuiti Per raggiungere questi obiettivi, il sistema di produzione deve essere mantenuto sempre sotto controllo. Le performance di produzione si valutano real-time confrontando i dati di monitoraggio con i valori delle soglie prefissate. Dalla teoria dei sistemi complessi si evince come, per tenere sotto controllo un sistema complesso, non sia sufficiente monitorare e caratterizzare i singoli sottomoduli a se stanti ma è necessario monitorare le modalità di interazione che sussistono tra di essi. Questo è in antitesi con l'approccio cartesiano sulla scomposizione di un sistema nei componenti. In questo modo infatti si fallisce nell'identificazione delle 'Emergenze'. Con 'Emergenza' si intende il principio per cui dalle mutue interazioni delle diverse parti nascono delle caratteristiche del sistema che non si ritrovano tra le caratteristiche di alcuna parte singola.

Definizioni Nella parte finale di questo articolo si propongono le definizioni e il glossario per indicare i concetti chiave dell’APM. Conoscere e condividere questa terminologia è fondamentale per la corretta comprensione e applicazione dell’APM su un progetto web in produzione. I termini che approfondiremo sono: • • • • • • • •

Performance Response time Load Throughput Path length Bottleneck Capacity Scalability

Performance Definizioni: • •

•

•

Capacità dell'applicazione di soddisfare le aspettative dell'utente. Da notare come sia una definizione relativa all'utente e non assoluta. Quindi, in funzione del profilo ci saranno risposte differenti alla domanda: “Cosa sono le performance?' Dal punto di vista pratico si definiscono delle grandezze misurabili e si definiscono valori di soglia per determinare le aree di lavoro con la qualità desiderata. La mancata definizione delle performance come entità oggettiva permette di superare le limitazioni di un approccio allo sviluppo del software dominato dalle performance, mentre la definizione di valori soglia per alcune metriche permette di sviluppare modelli previsionali, cioè prima del completamento dello sviluppo, che valutano le scelte architetturali ed il loro possibile impatto sulle performance.

Response time Definizioni: •

Il tempo trascorso tra l'evento di invio della singola richiesta (click dell'utente) e la presentazione della risposta.

•

•

•

E' una misura ad alta criticità perché, più di tutte le altre, si pone come diretto indicatore della reattività (responsiveness) dell'applicazione agli eventi utente. É composto dal tempo di rete (nei due sensi di andata e ritorno), tempo applicativo (tempo necessario all'applicazione per generare la risposta, comprensivo di attraversamenti di code interne) e tempo di visualizzazione. Statisticamente è espressa in termini di percentile.

Figura 3: rappresentazione del Response-Time:Tempo necessario per ottenere una risposta dopo aver effettuato una richiesta da parte dell'utente Load Definizioni: • • •

E' la misura del numero di richieste in un dato intervallo temporale. E' indicativo della 'pressione' esercitata sul sito dalle richieste degli utenti. E' un valore dato del problema della gestione delle performance, su cui difficilmente si riesce a interagire poiché dipende principalmente dal comportamento degli utenti.

Figura 4: Rappresentazione del Load: carico utente che il sistema è in grado di gestire in un intervallo temporale Throughput Definizioni: • • •

E' definito come il numero di risposte date nell'unità di tempo a fronte di un certo numero di richieste (carico) Può essere uguale o molto diverso al valore del carico a seconda della capacità del sistema di rispondere velocemente alle richieste. Oltre il punto di saturazione all'aumentare del carico , il throughput resta costante al valore massimo, per poi scendere.

Figura 5: Rappresentazione del Throughput: Numero di risposte che il sistema è in grado di erogare in un intervallo temporale Path length Definizioni: • •

Si definisce come il numero di azioni eseguite all'interno del sistema per completare una richiesta. E' indicativo sia della complessità delle azioni sia del numero di risorse da impegnare su server per gestire la richiesta che saranno liberate e rese disponibili solo alla fine.

Figura 6: Rappresentazione del Path length: Passaggi necessari per eseguire una richiesta Bottleneck Definizioni: •

• • •

Letteralmente 'collo di bottiglia', è il termine usato per indicare una strozzatura che limita il flusso concorrente delle azioni che gestiscono le richieste. Tipico problema presente negli ambienti multi-threaded come il server di una applicazione web. La velocità complessiva è dominata dal componente più lento. Una volta evitato un collo di bottiglia se ne può presentare un altro, precedentemente 'nascosto' da quello appena risolto.

Figura 7: Rappresentazione del Bottleneck: Punti del sistema che generano un rallentamento del servizio fornito Capacity Definizioni: • •

La capacità di un sistema è la misura del carico che il sistema riesce a gestire mantenendo i tempi di risposta entro limiti predeterminati. E' un termine più esteso del throughput, e solitamente è espresso in termini di sessioni utente all'ora.

Scalability Definizioni: •

•

La scalabilità indica la qualità intrinseca di un sistema di espandere. L'espansione può avvenire attraverso l'utilizzo di nuove risorse hardware o software. Si dice scalabile un sistema che accetta l'inserimento di nuove risorse per aumentare la sua capacità operativa. Quanto più è scalabile tanto più l'inserimento è semplice.

Figura 8: Rappresentazione della Scalabilità: Capacità del sistema di accedere a risorse hardware e software per rispondere ad aumenti di carico utenti