L’importanza del observability nelle architetture moderne ed i vantaggi dell’offering AWS
L’evoluzione delle architetture sta facendo mutare i landscape applicativi di riferimento sempre più velocemente. Seppur abbiamo raggiunto caratteristiche del servizo impensabili fino a qualche tempo fa in termini di velocità, completezza e facilità di fruizione, attualmente ci troviamo a dover affrontare scenari sempre più complessi da gestire in termini di erogazione di una singola funzionalità.
Come è avvenuto con l’arrivo degli smartphone, quando pian piano ci si è resi conto che bisognava trasformare il modo di realizzare contenuti web utilizzando l’approccio “mobile first”, anche con le nuove architetture applicative si sta realizzando che bisogna cambiare l’approccio ed il mind-set che si ha nell’affrontare il disegno di queste soluzioni.
Da applicazioni monolitiche, a Service Oriented Architecture e fino ad architetture a microservizi, il modo di disegnare una soluzione è cambiato profondamente nella sostanza e nei ragionamenti che si fanno durante il processo di realizzazione. Dopo una fase di entusiasmo generale nell’osservare un’architettura moderna, ci si rende subito conto che lo sviluppo di questo tipo di soluzioni che consentono di migliorare la resilienza e la scalabilità introducono però delle complessità di gestione non indifferenti.
Per governare in maniera efficace un’architettura complessa come quella riportata in esempio, bisogna cambiare l’approccio che si adotta per monitorarla.
Se in passato si pensava che con un buon log si poteva governare il runtime di una applicazione, nelle architetture moderne si sa già che solo un buon log non è sufficiente a garantire la possibilità di effettuare un troubleshooting veloce, preciso e affidabile. Basti pensare che in un’architettura a microservizi moderna il numero di componenti applicative potrebbe raggiungere numeri impensabili ed è già facile percepire che tramite dei semplici log, seppur aggregati in maniera centralizzata, sarebbe estremamente difficile identificare la root cause di una issue in produzione. Di pari passo all’evoluzione delle architetture software infatti, anche i sistemi di monitoring sono stati rivisti per supportare in maniere efficiente ed efficace l’analisi di problemi su un’architettura moderna. Affianco ai tradizionali log, sono stati aggiunti sistemi di collecting delle metriche e sistemi di tracing delle richieste. Un monitoraggio completo è quindi costituito da Log, Metrics e Trace che sono i pillar principali di un monitoring system moderno.
Partendo quindi dalla consapevolezza del dover affrontare il problema del monitoring end2end di una Modern Cloud Application sin dalla sua progettazione, vediamo ora come il cloud viene in aiuto nel facilitare l’integrazione questi temi nella soluzione software sviluppata.
In particolare, visto il mio background, proporrò una serie di soluzioni AWS che si occupano di monitoring affrontando la raccolta e l’aggregazione delle tre fondamentali dimensioni necessarie al monitoring di una applicazione: Log, Trace e Metrics.
1. Log
AWS CloudWatch Logs
CloudWatch Logs è il servizio di AWS che permette di centralizzare la raccolta dei log provenienti da diverse fonti direttamente in un unico punto. Tramite l’interfaccia di CloudWatch Logs sarà inoltre possibile visualizzare, filtrare o archiviare i logs in maniera sicura. Il servizio è fully managed per cui non sarà necessario dimensionare a priori il sizing di questo servizio.
Per un approfondimento su questo servizio, è possibile consultare la guida utente disponibile qui.
AWS OpenSearch Service
OpenSearch Service è il servizio di AWS che consente di effettuare il deploy di un cluster OpenSearch e/o ElasticSearch managed by AWS. Rispetto il servizio di CloudWatch Logs, è necessario effettuare un sizing dell’infrastruttura che ospiterà i logs ed il costo è funzione del dimensionamento oltre che dello spazio occupato. L’esperienza di utilizzo è praticamente la medesima di OpenSearch per cui il servizio è “cloud agnostic”, difatti è possibile effettuare il deploy di questo stack anche su ambienti non cloud oppure in maniera Self-Managed su EC2. Considerando che OpenSearch è una suite completa, il servizio è untilizzabile anche per il collezionamento di metriche e trace tramite dei “tools” che permettono il collezionamento di queste entità.
Per approfondire le caratteristiche di questo servizio, è possibile consultare il seguente link.
Quale scegliere e perchè
La scelta del servizio da utilizzare si porta dietro sempre razioniali complessi e non è facile indicare quale servizio utilizzare senza conoscere il contesto. Per progetti nuovi, in cui l’esigenza è quella di concentrarsi su tematiche diverse rispetto questa, la scelta ricade sicuramente su AWS CloudWatch Logs. Il tempo necessario allo start-up ed integrazione di questo servizio è davvero limitato, inoltre non è necessario dimensionare in maniera preventiva l’infrastruttura di Log Collecting e per nuovi progetti questo è un vantaggio importante. In caso di progetti già esistenti, magari già integrati con ElasticSearch, ovviamente la scelta ricadrebbe su OpenSearch poichè sarà possibile sfruttare già l’integrazione pre-esistente, con pochissimo sforzo.
Ulteriore punto per la scelta è la tipologia dei servizi da integrare:
- Per servizi Cloud-Native AWS, l’integrazione con AWS CloudWatch è nativa, con qualche semplice configurazione sarà possibile collezionare i logs su AWS CloudWatch.
- Per servizi IaaS AWS, l’integrazione con AWS CloudWatch è effettuata attraverso l’installazione di un agent per la raccolta di logs ed è similare all’integrazione con OpenSearch che consiste nell’installazione di un Agent di raccolta di Logs tramite accesso ad i file. In questo caso l’effort di integrazione dei due sistemi di Logs Collecting è medesimo.
2. Metrics
AWS CloudWatch
CloudWatch è il servizio AWS che permette di raccogliere le metriche applicative e di visualizzarle in un unico punto centralizzato. E’ integrato nativamente con i servizi Cloud Native di AWS per cui le metriche di questi servizi saranno disponibili direttamente su CloudWatch. Il servizio è fully managed per cui anche per CloudWatch non è necessario pre-dimensionare l’infrastruttura.
Se si utilizza in combinazione con AWS CloudWatch Logs, è possibile sfruttare le funzionalità di correlazione delle metriche con i logs.
Per un approfondimento su questo servizio, è possibile consultare la guida utente disponibile qui.
AWS Managed Prometheus
Managed Prometheus è il servizio AWS che mette a disposizione una istanza di Prometheus Managed by AWS. Tramite questo servizio è possibile recuperare le metriche dagli applicativi che le espongono tramite formato Prometheus. Il servizio è fully managed e non è necessario dimensionare l’infrastruttura. Il pricing è basato sul numero di metriche su cui viene fatta ingestion e query.
A questo servizio può essere abbinata la AWS OpenTelemetry Distro per il recupero delle metriche delle istanze da integrare.
E’ possibile inoltre utilizzare AWS Managed Grafana agganciato a questo servizio che fornisce una istanza di Grafana fully-managed per la visualizzazione dei dati di Prometheus.
Al seguente link, si possono trovare ulteriori informazioni sull’utilizzo di questo servizio.
AWS OpenSearch Service
Come riportato nel paragrafo precedente, AWS OpenSearch Service è il servizio di AWS che consente di effettuare il deploy di un cluster OpenSearch e/o ElasticSearch managed by AWS. Tramite questo servizio e l’utilizzo di Metricbeat, è possibile effettuare il collecting delle metrice applicative.
Per la configurazione di Metricbeat con OpenSearch è possibile consultare il seguente link.
Quale scegliere e perchè
Anche per il servizio di collecting delle metriche, la scelta dipende da diversi razionali che vanno analizzati prima di decidere. Se l’applicazione che si vuole integrare supporta già l’export di metriche verso Prometheus, sicuramente la soluzione è quella di usare la versione Managed Prometheus di AWS. Oltre a questa considerazione però, il suggerimento è di utilizzare una soluzione coerente con quella di collecting dei log. Se si sta utilizzando già OpenSearch per il collecting dei logs potrebbe essere giusto utilizzare lo stesso sistema per la raccolta delle metriche in modo da poter correlare le informazioni in un unico punto. Per l’utilizzo su soluzioni CloudNative AWS, la prima scelta rimane sempre AWS CloudWatch poichè l’integrazione è disponibile Out-Of-Box.
3. Trace
AWS X-Ray
AWS X-Ray è il servizio fully-managed per il recupero dei trace applicativi. La soluzione è integrata nativamente nei servizi CloudNative AWS (Lambda,ApiGateway, etc.). Per l’integrazione su altri servizi, è necessario installare un Agent locale ed iniettare l’SDK di tracing all’interno del codice applicativo. I linguaggi supportati sono molteplici e vengono spesso aggiornati.
X-Ray fornisce diverse dashboard di visualizzazione ed è integrato con l’ecosistema CloudWatch per la correlazione dei logs e metriche in un unico punto.
Per l’utilizzo di questo servizio, è possibile consultare la developer guide a questo link.
AWS OpenSearch Service
Anche per il collecting delle metriche è utilizzabile AWS OpenSearch. Tramite l’installazione di OpenTelemetry Collector sull’applicazione e il Data Prepper, è possibile effettuare il push dei trace applicativi all’interno di OpenSearch.
Questa soluzione è basata completamente su stack Opensource poichè l’OpenTelemetry collector supporta il formato jaeger e zipkin dei trace applicativi. Ne consegue che è possibile utilizzare qualsiasi libreria di instrumentazione che supporta i formati standard-de-facto per i trace applicativi.
Per questa configurazione, è possibile approfondire su questo blog post di AWS.
Quale scegliere e perchè
Per il monitoraggio dei trace applicativi stanno nascendo sempre più soluzioni, che hanno reso molto complicata la scelta del tool. Se non si ha già a disposizione nessuna infrastruttura per il collecting delle trace, il suggerimento è quello di partire con X-Ray che consente di integrare le applicazioni con poco effort e senza dover predisporre infrastrutture ad-hoc (come necessario per Jager o similari). Se invece esistono già delle soluzioni di pubblicazione metriche nel formato standard e magari si sta già utilizzando OpenSearch per il collecting dei log applicativi, utilizzare anche quest’ultimo per le trace è la scelta vincente. In un unico ambiente sarà possibile avere una vista completa dello stato del servizio avendo trace,logs e metriche correlate in un unico punto.
Conclusione
Lo scopo di questo articolo, ovviamente, non vuole essere quello di fornire in maniera esaustiva le modalità di utilizzo dell’enorme quantità di tool messi a disposizione da AWS per lo scopo ma, quello di aiutare chi si sta approcciando al mondo dell’observability a capire che criterio utilizzare per scegliere tra le soluzioni disponibili.
Ribadisco inoltre come la tematica dell’observability dovrebbe essere affrontata già dalle prime fasi dello sviluppo di una applicazione, per permettere una integrazione semplificata e soprattutto per iniziare da subito a rimediare agli errori di implementazione fatti.
Versione Inglese: https://emanuelrusso93.medium.com/the-importance-of-observability-in-modern-architectures-and-the-advantages-of-aws-offering-db6a3d849e19
