Pattern di architettura dell'infrastruttura ospitata dal cliente

Questa pagina esplora i pattern di architettura più comuni per un deployment ospitato dal cliente e descrive le best practice per implementarli. Per utilizzare questa pagina in modo efficace, dovresti avere familiarità con i concetti e le pratiche dell'architettura di sistema.

Strategia per il flusso di lavoro

Dopo aver identificato il self-hosting come opzione attuabile. per l'implementazione di Looker, il passaggio successivo è elaborare la strategia che deve essere gestita dal deployment.

1. Esegui una valutazione. Identifica un elenco di candidati di flussi di lavoro pianificati ed esistenti.
2. Elenca i pattern di architettura applicabili. A partire dai flussi di lavoro candidati identificati, identifica i pattern di architettura applicabili.
3. Assegna le priorità e seleziona il pattern di architettura ottimale. Allinea il pattern di architettura alle attività e ai risultati più importanti.
4. Configura i componenti dell'architettura ed esegui il deployment dell'applicazione Looker. Implementa l'host, le dipendenze di terze parti e la topologia di rete necessari per stabilire connessioni client sicure.

Opzioni di architettura

Macchina virtuale dedicata

Un'opzione è eseguire Looker come singola istanza in una macchina virtuale (VM) dedicata. Una singola istanza può gestire carichi di lavoro impegnativi scalando verticalmente l'host e aumentando i pool di thread predefiniti. Tuttavia, il sovraccarico di elaborazione della gestione di un heap Java di grandi dimensioni sottopone la scalabilità verticale alla legge del rendimento decrescente. È generalmente accettabile per carichi di lavoro di piccole e medie dimensioni. Il seguente diagramma illustra le configurazioni predefinite e facoltative tra un'istanza di Looker in esecuzione su una VM dedicata, i repository locali e remoti, i server SMTP e le origini dati evidenziate nelle sezioni Vantaggi e Best practice per questa opzione.

Vantaggi

• Una VM dedicata è facile da implementare e gestire.
• Il database interno è ospitato all'interno dell'applicazione Looker.
• I modelli di Looker, il repository Git, il server SMTP e i componenti del database di backend possono essere configurati localmente o da remoto.
• Puoi sostituire il server SMTP predefinito di Looker con il tuo per le notifiche via email e le attività pianificate.

Best practice

• Per impostazione predefinita, Looker può generare repository Git semplici per un progetto. Ti consigliamo di configurare un repository Git remoto per la ridondanza.
• Per impostazione predefinita, Looker si avvia con un database HyperSQL in memoria. Questo database è pratico e leggero, ma può presentare problemi di prestazioni con un uso intensivo. Consigliamo di utilizzare un database MySQL per deployment più grandi. Consigliamo di eseguire la migrazione a un database MySQL remoto una volta che il file ~/looker/.db/looker.script raggiunge i 600 MB.
• Il deployment di Looker deve essere convalidato in base al servizio di licenze di Looker. il traffico in uscita sulla porta 443 è obbligatorio.
• Un deployment di VM dedicato può essere scalato verticalmente aumentando le risorse disponibili e i pool di thread di Looker. Tuttavia, l'aumento della RAM è soggetto alla legge di diminuzione dei ritorni una volta raggiunta la dimensione di 64 GB, poiché gli eventi di garbage collection sono in thread e interrompono tutti gli altri thread da eseguire. I nodi con 16 CPU e 64 GB di RAM sono un buon equilibrio tra prezzo e prestazioni.
• Consigliamo di fare in modo che il deployment disponga di spazio di archiviazione con 2 operazioni al secondo (IOPS) per GB.

Cluster di VM

L'esecuzione di Looker come cluster di istanze su più VM è un pattern flessibile che sfrutta il failover e la ridondanza del servizio. La scalabilità orizzontale consente di aumentare il throughput senza incorrere in un aumento eccessivo dell'heap e dei costi di raccolta dei rifiuti. I nodi hanno la possibilità di dedicare il carico di lavoro, il che consente di personalizzare più opzioni di deployment a seconda dei diversi requisiti aziendali. I deployment dei cluster richiedono almeno un amministratore di sistema che abbia familiarità con i sistemi Linux e in grado di gestire le parti dei componenti.

Cluster standard

Per la maggior parte dei deployment standard, è sufficiente un cluster di nodi di servizio identici. Tutti i nodi del cluster sono configurati nello stesso modo e si trovano nello stesso pool del bilanciatore del carico. Nessuno dei nodi in questa configurazione potrebbe soddisfare le richieste utente di Looker, un'attività di rendering, un'attività pianificata, una richiesta API e così via.

Questo tipo di configurazione è adatto quando la maggior parte delle richieste proviene direttamente da un utente di Looker che esegue query e interagisce con Looker. Inizia a non funzionare quando un numero elevato di richieste proviene da un programmatore, un visualizzatore o un'altra origine. In questo caso, è consigliabile designare determinati nodi di servizio per gestire attività come pianificazioni e rendering.

Ad esempio, gli utenti di solito pianificano l'invio dei dati per il lunedì mattina. Un utente che tenta di eseguire query di Looker lunedì mattina potrebbe riscontrare problemi di prestazioni mentre Looker lavora sulla coda delle richieste pianificate. Aumentando il numero di nodi di servizio, il cluster fornisce un incremento proporzionale della velocità effettiva in tutte le funzionalità di Looker.

Il seguente diagramma mostra come le richieste a Looker effettuate dall'utente, dalle app e dagli script vengono bilanciate in un'istanza Looker in cluster.

Vantaggi

• Un cluster standard massimizza il livello generale con una configurazione minima della topologia del cluster.
• La Java VM subisce un peggioramento delle prestazioni alla soglia di memoria allocata di 64 GB; questo è il motivo per cui la scala orizzontale ha maggiori ritorni rispetto alla scala verticale.
• La configurazione di un cluster garantisce la ridondanza e il failover del servizio.

Best practice

• Ogni nodo Looker deve essere ospitato nella propria VM dedicata.
• Il bilanciatore del carico, ovvero il punto di ingresso del cluster, deve essere un bilanciatore del carico di livello 4. Deve avere un timeout lungo (3600 secondi), essere dotato di un certificato SSL firmato ed essere configurato per il trasferimento della porta dalla 443 (https) alla 9999 (porta su cui il server Looker è in ascolto).
• Consigliamo di fare in modo che il deployment disponga di uno spazio di archiviazione con 2 IOPS per GB.

Dev/Staging/Prod

Per i casi d'uso che danno priorità al massimo tempo di attività dei contenuti per gli utenti finali, consigliamo ambienti Looker separati in modo da compartimentare le attività di sviluppo e quelle analitiche. Inibendo le modifiche all'ambiente di produzione dietro ambienti di sviluppo e test isolati, questa architettura mantiene un ambiente di produzione il più stabile possibile.

Questi vantaggi richiedono la configurazione di ambienti interconnessi e l'adozione di un ciclo di rilascio affidabile. Un deployment Dev/Staging/Prod richiede anche un team di sviluppatori che conoscono l'API Looker e il Git per l'amministrazione del flusso di lavoro.

Il seguente diagramma illustra il flusso di contenuti tra gli sviluppatori LookML che sviluppano contenuti nell'istanza Dev, i tester del controllo qualità (QA) che testano i contenuti sull'istanza di QA e gli utenti, le app e gli script che utilizzano i contenuti nell'istanza di produzione.

Vantaggi

• La convalida di LookML e dei contenuti avviene in un ambiente non di produzione, garantendo che eventuali modifiche alla logica del modello possano essere esaminate attentamente prima di raggiungere gli utenti di produzione.
• Le funzionalità a livello di istanza, ad esempio le funzionalità di Labs o i protocolli di autenticazione, possono essere testate singolarmente prima di essere attivate nell'ambiente di produzione.
• I criteri relativi ai gruppi di dati e alla memorizzazione nella cache possono essere testati in un ambiente non di produzione.
• I test della modalità di produzione di Looker sono disaccoppiati dagli ambienti di produzione responsabili della gestione degli utenti finali.
• Le release di Looker possono essere testate in un ambiente non di produzione, consentendo di testare in modo approfondito nuove funzionalità, modifiche al flusso di lavoro e problemi prima di aggiornare l'ambiente di produzione.

Best practice

• Isola le varie attività che si verificano contemporaneamente in almeno tre istanze separate:
• Istanza di sviluppo: gli sviluppatori utilizzano l'ambiente di sviluppo per eseguire il commit del codice, condurre esperimenti, correggere i bug e commettere errori in sicurezza.
• Istanza di QA: chiamato anche ambiente di test o di gestione temporanea, in cui gli sviluppatori eseguono test manuali e automatici. L'ambiente di QA è complesso e può richiedere molte risorse.
• Istanza di produzione: è qui che viene creato il valore per i clienti e/o l'attività. La produzione è un ambiente ad alta visibilità e deve essere privo di errori.

• Mantieni uno standard documentato e ripetibile flusso di lavoro del ciclo di rilascio.
• Se è necessario gestire volumi elevati di sviluppatori e tester del QA, le istanze di sviluppo e/o QA possono essere raggruppate in cluster. Che siano lasciate come VM autonome o come cluster di VM, le istanze di sviluppo e QA sono soggette alle stesse considerazioni di architettura mostrate in precedenza nelle rispettive sezioni.

Velocità effettiva di pianificazione elevata

Per i casi d'uso che richiedono un elevato throughput di caricamento dei dati pianificati e caricamenti tempestivi e affidabili, consigliamo di includere nella configurazione un cluster con un pool di nodi dedicati esclusivamente alla pianificazione. Questa configurazione contribuirà a mantenere le applicazioni web e incorporate rapide e reattive. Questi vantaggi richiedono la configurazione di nodi con opzioni di avvio personalizzate e regole di bilanciamento del carico adeguate, come mostrato nel diagramma seguente e descritto nelle sezioni Vantaggi e Best practice per questa opzione.

Vantaggi

• L'assegnazione di nodi per una funzione specifica distingue le risorse per la pianificazione dalle funzioni di sviluppo e analisi ad hoc.
• Gli utenti possono sviluppare LookML ed esplorare i contenuti senza occupare cicli dei nodi responsabili della gestione delle importazioni di dati pianificate.
• Il traffico utente elevato indirizzato ai nodi normali non impedisce i carichi di lavoro pianificati gestiti dai nodi di pianificazione.

Best practice

• Ogni nodo Looker deve essere ospitato nella propria VM dedicata.
• Il bilanciatore del carico, ovvero il punto di ingresso del cluster, deve essere un bilanciatore del carico di livello 4. Deve avere un timeout lungo (3600 secondi), essere dotato di un certificato SSL firmato ed essere configurato per il trasferimento della porta dalla 443 (https) alla 9999 (porta su cui il server Looker è in ascolto).
• Ometti i nodi dello scheduler dalle regole di bilanciamento del carico in modo che non gestiscano il traffico degli utenti finali e le richieste API interne.
• Ti consigliamo di avere uno spazio di archiviazione con 2 IOPS per GB.

Velocità effettiva di rendering elevata

Per i casi d'uso che richiedono un'elevata velocità effettiva del report di rendering, consigliamo di configurare un cluster con un pool di nodi esclusivamente dedicati al rendering. Il rendering di un file PDF o di un'immagine PNG/JPEG è un'operazione relativamente dispendiosa in termini di risorse in Looker. Il rendering può richiedere molta memoria e un uso intensivo della CPU; inoltre, quando la memoria è sotto pressione, Linux potrebbe interrompere un processo in esecuzione. Poiché non è possibile determinare in anticipo l'utilizzo della memoria di un job di rendering, l'avvio di un job di rendering potrebbe causare l'interruzione del processo di Looker. La configurazione di nodi di rendering dedicati consentirà di ottimizzare i job di rendering senza compromettere la reattività dell'applicazione interattiva e incorporata.

Questi vantaggi richiedono la configurazione di nodi con opzioni di avvio personalizzate e regole di bilanciamento del carico adeguate, come mostrato nel diagramma seguente e spiegato nelle sezioni Vantaggi e Best practice per questa opzione. Inoltre, i nodi di rendering potrebbero richiedere più risorse dell'host rispetto ai nodi standard, poiché il servizio di rendering di Looker dipende da processi Chromium di terze parti che condividono tempo della CPU e memoria.

Vantaggi

• Dedicare nodi a una funzione specifica separa le risorse per il rendering delle funzioni di sviluppo e di analisi ad hoc.
• Gli utenti possono sviluppare LookML ed esplorare i contenuti senza occupare cicli dai nodi responsabili del rendering di file PNG e PDF.
• Il traffico utente elevato indirizzato ai nodi normali non impedisce i carichi di lavoro di rendering gestiti dai nodi di rendering.

Best practice

• Ogni nodo Looker deve essere ospitato nella propria VM dedicata.
• Il bilanciatore del carico, che è il punto di ingresso del cluster, deve essere un bilanciatore del carico di livello 4. Deve avere un timeout lungo (3600 secondi), essere dotato di un certificato SSL firmato ed essere configurato per il trasferimento della porta dalla 443 (https) alla 9999 (porta su cui il server Looker è in ascolto).
• Ometti i nodi di rendering dalle regole di bilanciamento del carico, in modo che non gestiscano il traffico degli utenti finali e le richieste API interne.
• Alloca relativamente meno memoria a Java nei nodi di rendering per dare ai processi di Chromium un buffer di memoria più grande. Invece di allocare il 60% della memoria a Java, alloca il 40-50%.
• Il rischio di utilizzare memoria è stato ridotto sui nodi non di rendering, quindi è possibile aumentare la quantità di memoria dedicata a Looker. Anziché il 60% predefinito, valuta la possibilità di utilizzare un numero più alto, ad esempio l'80%.
• Consigliamo di fare in modo che il deployment disponga di uno spazio di archiviazione con 2 IOPS per GB.

Risorsa correlata

• Soluzioni di architettura ospitate dal cliente: procedure dettagliate dei componenti