19

Sep

Windows Azure – Poison messages, Workers dinamici e MapReduce

Poison Messages

Nella letteratura riguardante le code, i messaggi avvelenati sono dei messaggi in coda, che hanno la caratteristica di essere intrinsecamente fallimentari, provocando comportamenti inattesi, crash applicativi e/o bug di qualsivoglia natura. Perchè sono male? Perchè per esempio nelle code di Azure avremmo un poison message che continua a ripresentarsi ogni 30 secondi visto che il processo che lo analizza va regolarmente in crash e/o non riesce a elaborarlo. Perciò, oltre che soffrire di starvation, consuma anche risorse e non è escluso che possa portare anche al blocco dell’intero sistema.

Fortunatamente c’è un supporto nativo per i Poison Messages, introducendo nel messaggio-coda il parametro DequeueCount. Così, come nel protocollo TCP esiste il TTL per evitare lo stesso problema di instradamento infinito intra-routers, anche per le code è necessario porre un limite di rielaborazioni successive. A differenze del TTL che imposta un valore massimo per decrementarlo ad ogni hop, nel messaggio-coda il valore del counter viene incrementato ad ogni elaborazione e spetterà al client verificare le condizioni alla sua elaborazione.

image

E’ chiaro che si dovrà procedere al Poison-check PRIMA di qualsiasi altra operazione sul messaggio, pena la eventuale possibilità di blocco relativa appunto, alla elaborazione dello stesso. Inoltre siccome i poison messages possono indicare molto bene alcune anomalie recondite del sistema, è utile loggare i messaggi-coda avvelenati in una coda apposta, per poi andarseli a verificare manualmente e rilevare eventuali errori applicativi (se non “sistemarli” per re-immetterli nella coda sana).

Worker Roles dinamiche

E’ noto che Windows Azure costi abbastanza ed è anche noto che il modello di pricing si applica ad ogni ora di deployment indipendentemente dal carico di lavoro o dall’utilizzo reale della VM. Perciò uno dei problemi dibattuti più spesso è: mi conviene veramente impostare un Worker Role quando esso lavorerà a pieno carico solo raramente? Essendo il ruolo una istanza a sè stante, la considerazione è lecita e sensata, anche se la risposta spetta solo all’architetto. Quello che possiamo aggiungere è un pattern interessante a metà strada tra il codice mobile e un plugin-pattern qualsiasi. L’idea è di usare un worker role per caricare ed eseguire codice dinamicamente reperito da un blob caricato in un qualsiasi momento dall’utente.

Supponiamo il caso in cui volessimo processare dei modelli XML all’interno della worker role, di cui però non sappiamo a priori le regole di validazione. L’idea potrebbe essere quella, a fronte di un “nuovo formato” sconosciuto al worker role, di fornire un messaggio-coda contenente il riferimento all’assembly (dll) e al metodo che possa processare l’operazione, così che il ruolo possa andare a prendersi la DLL, magari dal blob storage, e invocare tramite reflection i metodi corretti per eseguire l’operazione di background (magari in un AppDomain separato). Così facendo avremmo esecuzione di codice dinamicamente scaricato da internet e caricato intra-istanza. Un esempio con il solito scenario dell’elaborazione di immagini è presente sotto:

image

Map/Reduce

Benchè Google abbia preso il nome per un suo popolare framework, oggi si parla di Map/Reduce quando si vuole arguire un algoritmo di computazione distribuita su grandi set di dati/informazioni. L’idea di base è molto semplice: avere un grande set di dati che possa essere splittato opportunamente, passato ai corrispettivi peers della catena di produzione (nodi di un cluster o appunto, istanze di Azure) per poi riorganizzarne il risultato e consolidarlo centralmente. Questo approccio può chiaramente portare ad una elaborazione molto veloce e può superare molti dei problemi che sono praticamente verificati in tutti quei casi in cui si chiede una computazione teorica infinita.

Non ci sono meccanismi all-inclusive per ottenere questa architettura su Azure, anche se esistono progetti open molto validi che, usati in connessione con ciò che abbiamo spiegato finora, possono portare all’implementazione del modello. Sotto un esempio di come una immagine enorme possa essere filtrata con MapReduce:

image

by Roberto Freato on 9/19/2011
Post archive