Il funzionamento affidabile del sistema è un requisito per qualsiasi piattaforma di integrazione come servizio (iPaaS) seria. Spesso l'affidabilità o la tolleranza ai guasti sono elencate come caratteristiche, ma è difficile capire cosa significhi in termini pratici. Per un progetto di integrazione dei dati, l'affidabilità può essere una sfida perché deve collegare servizi esterni disparati, che si guastano da soli. In un precedente post del blog, abbiamo discusso di come le pipeline di SnapLogic Integration Cloud possano essere costruite per gestire i guasti dei punti finali con il nostro meccanismo di consegna garantita. In questo post, esamineremo alcune delle tecniche che utilizziamo per garantire l'esecuzione affidabile dei servizi che controlliamo.
L'architettura di SnapLogic è suddivisa in due categorie: il piano dati e il piano di controllo. Il piano dati è incapsulato all'interno di uno Snaplex, mentre il piano di controllo è un insieme di server distribuiti replicati. Questa separazione progettuale è utile sia per l'isolamento dei dati che per l'affidabilità, perché possiamo facilmente impiegare approcci diversi alla tolleranza ai guasti nei due piani.
Piano dati: Snaplex e ridondanza della pipeline
Lo Snaplex è un cluster di uno o più nodi di esecuzione della pipeline. Uno Snaplex può risiedere sia in SnapLogic Integration Cloud sia in sede. Lo Snaplex è progettato per supportare l'autoscaling in caso di aumento del carico della pipeline. Inoltre, il cruscotto di monitoraggio controlla lo stato di salute di tutti i nodi Snaplex. In questo modo, il guasto di un nodo Snaplex può essere rilevato tempestivamente, in modo che le pipeline future non vengano programmate sul nodo guasto. Per gli Snaplex basati su cloud, noti anche come Cloudplex, i guasti dei nodi vengono rilevati automaticamente e i nodi sostitutivi vengono resi disponibili senza problemi. Per gli Snaplex on-premise, noti anche come Groundplex, gli utenti dell'amministrazione ricevono una notifica del nodo guasto in modo da poterlo sostituire.
Se un nodo Snaplex si guasta durante l'esecuzione di una pipeline, la pipeline viene contrassegnata come fallita. Gli sviluppatori possono scegliere di riprovare le pipeline fallite o in alcuni casi, come le pipeline pianificate in modo ricorrente, l'esecuzione fallita può essere ignorata. La suddivisione di pipeline di lunga durata in diverse pipeline più brevi può limitare l'esposizione al guasto del nodo. Per le integrazioni altamente critiche è possibile costruire ed eseguire pipeline replicate in modo simultaneo. In questo modo, una singola replica non interrompe l'integrazione. In alternativa, è possibile costruire una pipeline per lo stage dei dati nel File System SnapLogic (SLFS) o in un archivio dati alternativo come AWS S3. Lo staging dei dati può ridurre la necessità di acquisire nuovamente i dati da un'origine dati, ad esempio se l'origine dati è lenta, come AWS Glacier. Inoltre, alcune fonti di dati hanno costi di trasferimento più elevati o limiti di trasferimento che renderebbero proibitivo richiedere i dati più volte in presenza di guasti sul punto finale a monte di una pipeline.
Piano di controllo: Affidabilità del servizio
Il "piano di controllo" di SnapLogic risiede in SnapLogic Integration Cloud, ospitato in AWS. Disaccoppiando il controllo dall'elaborazione dei dati, forniamo approcci differenziati all'affidabilità. Tutti i servizi del piano di controllo sono replicati sia per la scalabilità che per l'affidabilità. Tutti i server front-end basati su REST si trovano dietro il servizio AWS ELB (Elastic Load Balancing). Se un servizio del piano di controllo si guasta, sarà sempre disponibile un pool di servizi replicati in grado di soddisfare le richieste dei clienti e degli utenti interni. Ecco un esempio in cui la ridondanza aiuta sia l'affidabilità che la scalabilità.
Utilizziamo ZooKeeper per implementare il nostro affidabile servizio di pianificazione. Un aspetto importante di SnapLogic iPaaS è la possibilità di creare integrazioni programmate. È importante che queste attività pianificate vengano avviate a un'ora specifica o agli intervalli richiesti. Il servizio di pianificazione è implementato come un insieme di server. Tutti i server possono accettare richieste CRUD in entrata sui task, ma solo un server viene eletto come leader. A tale scopo utilizziamo un algoritmo di elezione del leader basato su ZooKeeper. In questo modo, se il leader fallisce, un nuovo leader viene eletto immediatamente e riprende a programmare le attività in tempo. In questo modo ci assicuriamo che nessuna attività programmata venga persa. Oltre a utilizzare ZooKeeper per l'elezione del leader, lo usiamo anche per consentire agli schedulatori follower di notificare al leader gli aggiornamenti delle attività.
Utilizziamo inoltre una serie di tecnologie di archiviazione dei dati replicati per garantire il controllo e l'esistenza dei metadati in modo affidabile. Attualmente utilizziamo cluster MongoDB per i metadati e bucket AWS S3 criptati per implementare SLFS. Non esponiamo direttamente S3, ma forniamo una vista gerarchica virtuale dei dati. Questo ci permette di tracciare e autorizzare correttamente l'accesso ai dati SLFS.
Per MongoDB abbiamo sviluppato una strategia affidabile di lettura-modifica-scrittura per gestire gli aggiornamenti dei metadati in modo non bloccante utilizzando findAndModfy. Il nostro approccio consente di ottenere aggiornamenti non conflittuali altamente efficienti, ma sicuri in presenza di un conflitto di scrittura. In un prossimo post forniremo una descrizione tecnica del funzionamento.
I vantaggi dell'integrazione definita dal software
Dividendo l'architettura iPaaS elastica di SnapLogic in piano dati e piano di controllo, possiamo impiegare strategie di affidabilità efficaci ma diverse tra queste due classi. Nel piano dati aiutiamo a identificare e correggere i guasti del server Snaplex, ma consentiamo anche agli utenti di implementare pipeline altamente affidabili, a seconda delle necessità. Nel piano di controllo utilizziamo una combinazione di replicazione dei server, bilanciamento del carico e ZooKeeper per garantire un'esecuzione affidabile del sistema. Il nostro approccio "one size does not fit all" ci permette di modulare l'affidabilità e di utilizzare strategie di test mirate. L'affidabilità non è una caratteristica del prodotto, ma una caratteristica di progettazione intrinseca in ogni aspetto di SnapLogic Integration Cloud.
