Tech Talk Series: Progettare per la scalabilità nel tuo cloud multi-tenant

In Jitterbit la nostra missione è semplificare anche le sfide di connettività più complesse e consentire a chiunque di connettersi nel mondo digitale di oggi. Pur sottolineando che non è necessario essere uno sviluppatore per utilizzare i prodotti Jitterbit, dietro ogni grande soluzione software c’è un team di sviluppatori eccezionali.   Nella serie Jitterbit Tech Talk blog, i membri del team di sviluppo di Jitterbit ci offrono una panoramica sulla creazione di una piattaforma cloud di livello enterprise e sulle sfide che hanno dovuto affrontare in materia di multi-tenancy, scalabilità e sicurezza.

Questa settimana, Pankaj Arora, il nostro Direttore Senior della Tecnologia, esamina come progettare e strutturare una piattaforma cloud di livello aziendale altamente scalabile.

Il Cloud offre alle aziende un modo potente per offrire i propri prodotti e servizi, facilmente accessibili da qualsiasi luogo e su qualsiasi dispositivo. Offre inoltre enormi vantaggi al fornitore, tra cui la visibilità sull'utilizzo della propria offerta, un rapido sviluppo e rilascio e una riduzione complessiva dei costi di IT e manutenzione. Di conseguenza, quasi tutte le aziende oggi cercano di rendere le proprie soluzioni disponibili nel Cloud.

Ma diventare una vera azienda cloud richiede molto di più che installare software su un server ospitato e aggiungere la scritta “Cloud” al proprio materiale di marketing.

Di recente stavo parlando con uno stratega tecnologico, il quale ha osservato che circa 75% delle aziende vorrebbero migrare le proprie soluzioni aziendali legacy sul cloud. Sorprendentemente, il 90% di queste aziende elabora un piano iniziale basato su un’architettura in cui le proprie applicazioni legacy verrebbero semplicemente distribuite su un server cloud accessibile pubblicamente. Questo approccio vanifica tutti i vantaggi offerti dal cloud.

La costruzione di una vera piattaforma cloud multi-tenant richiede la risoluzione di una serie di sfide di diversa natura, come la sicurezza, l'affidabilità, la scalabilità, l'alta disponibilità, la tolleranza agli errori, la registrazione (logging), il monitoraggio, il sistema di notifiche, la capacità di deployment continuo e altro ancora.

Nel post di oggi, esamineremo più da vicino come abbiamo affrontato la sfida della ‘scalabilità’ durante lo sviluppo della nostra piattaforma di integrazione cloud multi-tenant.

Il livello di scalabilità di un'applicazione è legato alla sua capacità di scalare verticalmente e orizzontalmente. In un ambiente Cloud, questo significa progettare servizi che gestiscono richieste esterne e che scalano in modo da poter sfruttare sistemi di backend interni come database, cache, livelli di mediazione, processi batch (motore analitico, motore di raccomandazione) ecc., per gestire un numero praticamente infinito di richieste in un tempo ragionevolmente breve. Non è sempre possibile prevedere il numero di utenti che accederanno alla vostra piattaforma. Progettare un'architettura che tenga conto di ciò nel modello multi-tenant aiuta a trasformare questa incertezza in un problema di scalabilità generico.

Scalabilità verticale

La scalabilità verticale comporta l'aggiunta di risorse, come CPU o memoria aggiuntive, a un singolo nodo in un sistema, e questa dovrebbe essere la prima cosa a cui pensare quando si scalano i propri servizi. È molto importante progettare le applicazioni in modo che utilizzino in modo ottimale queste risorse. Prendi il comune caso d'uso per la nostra piattaforma cloud di integrazione ibrida, in cui le operazioni di integrazione sono gestite da un nodo server locale o cloud. Qui i servizi dovrebbero prendere una richiesta per eseguire integrazioni, passare la richiesta ai nodi del server e continuare a servire altre richieste. Il livello dei servizi non dovrebbe dipendere o essere bloccato dai processi che si verificano ai vari livelli del sistema. Pertanto, è molto importante avere un'architettura asincrona e guidata dagli eventi.

Un modo semplice per comprendere l'architettura asincrona è pensare alla propria architettura come a un ristorante. Un cameriere prende le ordinazioni da un tavolo e le passa allo chef. Mentre lo chef, il portapiatti e il rammentatore si occupano di attività come cucinare, servire e pulire, il cameriere continua a servire nuovi clienti ed effettua i conti alla fine del servizio.

Mantenere l'asincronicità mentre il sistema lavora con tutti i componenti come database, cache e livello mediatore è molto importante. Trasferire il carico a nodi di server clusterizzati e ad alta disponibilità che eseguono le integrazioni libera risorse per il livello di servizio, consentendogli di gestire un numero maggiore di richieste e di rispondere al completamento dei processi.

Scalabilità orizzontale

La successiva considerazione chiave dovrebbe essere che i servizi siano scritti in modo tale che non debba importare quante istanze di tali servizi siano in esecuzione e quale sistema condiviso stia eseguendo transazioni in un dato momento. Ciò conferisce alla nostra piattaforma cloud la flessibilità di scalare automaticamente il livello dei servizi. Ogni parte del backend è altamente disponibile e scalabile automaticamente per stare al passo con la domanda di container di servizi in crescita.

Tuttavia, non possiamo avere contenitori infiniti che eseguono livelli di servizio che utilizzano componenti condivisi. Non è il design ottimale. Torniamo al nostro esempio del ristorante. Con lo scaling verticale, un singolo ristorante potrebbe diventare altamente scalabile aggiungendo altro personale, ma a un certo punto il numero di risorse (cuochi, camerieri, addetti ai tavoli) raggiungerà un punto di saturazione. Per scalare ulteriormente, questa attività dovrebbe aprire ulteriori sedi che aiuterebbero a distribuire i clienti e a bilanciare il carico.

È meglio suddividere l'intera piattaforma in più zone, in cui ciascuna zona si comporta come una replica della zona iniziale. Ciò ci consente di utilizzare più zone per bilanciare il carico delle esigenze future.

Questo modello presenta molteplici vantaggi:

1. Possibile scalabilità orizzontale infinita, poiché possiamo aggiungere un numero qualsiasi di zone

2. Tolleranza agli errori, nel caso in cui l'intera zona subisca un guasto a causa di una catastrofe naturale

3. Separazione dei dati, nel caso di una piattaforma SaaS che richiede anche la segregazione dei metadati basata sulla posizione, come per le zone USA, EMEA, ecc.

Il risultato desiderato qui è che l'esperienza di un utente sia la stessa indipendentemente da dove si trovi e da quale zona raggiunga. Non deve essere richiesto alcun intervento manuale da parte dell'utente per svolgere il proprio lavoro.

Nel nostro cloud di integrazione ibrida blog, abbiamo discusso di come ci siamo scontrati con la sfida di utilizzare un livello mediatore in modo tale che supportasse una scalabilità verticale limitata. Scrivendo un nostro livello di connessione non bloccante personalizzato basato sul trasporto HTTPS sicuro, siamo riusciti a estendere l'architettura ottenendo una scalabilità verticale 50 volte superiore. Naturalmente, è scalabile anche orizzontalmente. Questa combinazione di scalabilità verticale e orizzontale ci ha fornito un livello meno costoso e facilmente estensibile per soddisfare le nostre esigenze in crescita.

Ottimizzazione dell'uso dei componenti condivisi:

I componenti condivisi dovrebbero a loro volta essere scalabili e altamente disponibili per supportare la piattaforma cloud. Tuttavia, essendo condivisi, non sono scalabili quanto il livello dei servizi. È molto importante prestare attenzione ad alcuni componenti che possono essere sensibili a un carico elevato, ad esempio i database. Un modello possibile consiste nel dare priorità e mettere in coda l’usage dei componenti condivisi laddove un carico elevato, multiplo e simultaneo possa causare problemi. L’assegnazione delle priorità può ridurre il carico e mitigare gli errori su qualsiasi richiesta mission-critical.   Tornando al nostro ristorante, la cucina è un componente condiviso e, mentre il cameriere può prendere l’ordine di un ospite per un antipasto, un piatto principale e un dessert, la cucina stabilirà le priorità nella preparazione di queste pietanze e bilancerà il carico di lavoro.

Un altro modo per gestire il carico consiste nel memorizzare nella cache i dati che cambiano raramente, in modo da evitare un valore elevato di usage per tali componenti. Se le patatine fritte sono un piatto molto richiesto nel menu, il ristorante potrebbe decidere di “memorizzare nella cache” una quantità continua di patatine piuttosto che friggerle al momento dell’ordine.

Monitoraggio dei componenti:

Infine, è molto importante monitorare ciascun componente e conoscerne i limiti. Il sistema dovrebbe essere in grado di aumentare la larghezza di banda automaticamente e al momento giusto per mantenere i sistemi operativi secondo le esigenze della piattaforma Cloud. Il monitoraggio può essere esterno o avviato dall'applicazione, ma in entrambi i casi l'obiettivo finale è consentire al sistema di ridimensionarsi automaticamente in base al carico.

Nel prossimo articolo dedicato al blog parleremo del monitoraggio, della registrazione dei log e di altri elementi dell'architettura.