Questa pagina fa parte di una serie in più parti che illustra l'hosting di Looker, le metodologie di deployment e le best practice per i componenti coinvolti. Questa pagina esplora i pattern di architettura più comuni per un deployment ospitato dal cliente e descrive le best practice per la loro implementazione. Per utilizzare questa pagina in modo efficace, dovresti conoscere i concetti e le pratiche dell'architettura di sistema.
Questa serie si compone di tre parti:
- Panoramica dell'infrastruttura ospitata dal cliente
- Pattern di architettura dell'infrastruttura ospitata dal cliente (questa pagina)
- Procedura dettagliata per i componenti dell'infrastruttura ospitata dal cliente
Strategia del flusso di lavoro
Dopo aver identificato l'hosting autonomo come opzione attuabile per l'implementazione di Looker, il passaggio successivo consiste nell'elaborare la strategia da gestire con il deployment.
- Effettua una valutazione. Identificare un elenco candidato di flussi di lavoro pianificati ed esistenti.
- Elenca i pattern di architettura applicabili. Partendo dai flussi di lavoro dei candidati identificati, identifica i pattern architetturali applicabili.
- Dai priorità e seleziona il pattern di architettura ottimale. Allinea il pattern dell'architettura alle attività e ai risultati più importanti.
- 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, l'overhead di elaborazione associato alla gestione di un grande heap Java sottopone la scalabilità verticale alla legge dei rendimenti decrescenti. Generalmente è accettabile per carichi di lavoro di piccole e medie dimensioni. Il seguente diagramma mostra 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 distribuire e gestire.
- Il database interno è ospitato nell'applicazione Looker.
- I componenti di modelli Looker, repository Git, server SMTP e database di backend possono essere configurati in locale 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 senza limiti per un progetto. Ti consigliamo di configurare un repository Git remoto per la ridondanza.
-
Per impostazione predefinita, Looker viene avviato con un database HyperSQL in memoria. Questo database è pratico e leggero, ma può riscontrare problemi di prestazioni con un uso intensivo. Ti consigliamo di utilizzare un database MySQL per deployment più grandi. Ti consigliamo di eseguire la migrazione a un database MySQL remoto quando il file
~/looker/.db/looker.scriptraggiunge i 600 MB. - Il deployment di Looker dovrà essere convalidato in base al servizio di licenze di Looker; il traffico in uscita sulla porta 443 è obbligatorio.
- Il deployment di una VM dedicata può essere scalata verticalmente aumentando le risorse disponibili e i pool di thread di Looker. Tuttavia, l'aumento della RAM è soggetto alla legge della diminuzione dei rendimenti quando raggiunge i 64 GB, poiché gli eventi di garbage collection sono a thread singoli e interrompono l'esecuzione di tutti gli altri thread. 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 abbia uno spazio di archiviazione con due operazioni al secondo (IOPS) per GB.
Cluster di VM
L'esecuzione di Looker come cluster di istanze su più VM è un pattern flessibile che trae vantaggio dal failover e dalla ridondanza del servizio. La scalabilità orizzontale consente una maggiore velocità effettiva senza incorrere in eccessi e costi eccessivi per la garbage collection. I nodi hanno la possibilità di dedicare il carico di lavoro, il che consente di personalizzare più opzioni di deployment in base ai diversi requisiti aziendali. I deployment dei cluster richiedono almeno un amministratore di sistema che abbia familiarità con i sistemi Linux e sia in grado di gestire i componenti.
Cluster standard
Per la maggior parte dei deployment standard, è sufficiente un cluster di nodi di servizio identici. Tutti i nodi nel cluster sono configurati allo stesso modo e si trovano tutti nello stesso pool del bilanciatore del carico. Nessuno dei nodi in questa configurazione ha maggiori o minori probabilità di gestire le richieste degli utenti 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 Looker che esegue query e interagisce con Looker. Inizia ad arrestarsi quando proviene un numero elevato di richieste da uno scheduler, da un renderer o da un'altra origine. In questo caso, è utile designare determinati nodi di servizio per gestire attività come pianificazioni e rendering.
Ad esempio, gli utenti solitamente pianificano l'esecuzione dei report di lunedì mattina. Un utente che prova a eseguire query di Looker lunedì mattina potrebbe riscontrare problemi di prestazioni mentre Looker utilizza il backlog delle richieste pianificate. Aumentando il numero di nodi di servizio, il cluster fornisce un incremento proporzionale della velocità effettiva per 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 l'ambito 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 scalabilità orizzontale ha ritorni maggiori rispetto alla scalabilità verticale.
- La configurazione di un cluster garantisce la ridondanza e il failover dei servizi.
best practice
- Ogni nodo Looker deve essere ospitato in una propria VM dedicata.
- Il bilanciatore del carico, ovvero il punto in entrata 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 in modo da eseguire il port forwarding da 443 (https) a 9999 (il server Looker della porta è in ascolto).
- Ti consigliamo di fare in modo che il deployment abbia uno spazio di archiviazione con 2 IOPS per GB.
Sviluppo/gestione temporanea/prod.
Per i casi d'uso che danno priorità al tempo di attività massimo dei contenuti per gli utenti finali, consigliamo di separare gli ambienti Looker per compartimentare il lavoro di sviluppo e il lavoro analitico. Controllando i cambiamenti dell'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 degli ambienti interconnessi e l'adozione di un solido ciclo di rilascio. Un deployment Dev/Staging/Prod richiede anche un team di sviluppatori che conoscono l'API Looker e Git per l'amministrazione del flusso di lavoro.
Il seguente diagramma illustra il flusso di contenuti tra gli sviluppatori LookML che sviluppano contenuti sull'istanza Dev, i tester del controllo qualità (QA) che testano i contenuti nell'istanza di QA e gli utenti, le app e gli script che utilizzano i contenuti nell'istanza di produzione.
Vantaggi
- LookML e convalida dei contenuti avvengono 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, come le funzionalità di Labs o i protocolli di autenticazione, possono essere testate in modo isolato prima di essere abilitate nell'ambiente di produzione.
- I criteri del gruppo di dati e della 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, lasciando ampio tempo per testare nuove funzionalità, modifiche ai flussi 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 bug e commettere errori in modo sicuro.
- Istanza QA: detta anche ambiente di test o di gestione temporanea, 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 altamente visibile e dovrebbe essere privo di errori.
- Mantieni un flusso di lavoro del ciclo di rilascio documentato e ripetibile.
- Se è necessario gestire volumi elevati di sviluppatori e tester del QA, le istanze Dev e/o QA possono essere raggruppate in cluster. Sia che vengano lasciate come VM indipendenti o cluster di VM, le istanze Dev e QA sono soggette alle stesse considerazioni sull'architettura illustrate nelle rispettive sezioni precedenti.
Velocità effettiva di pianificazione elevata
Per i casi d'uso che richiedono un'elevata velocità effettiva pianificata dei report e consegne tempestive e affidabili, consigliamo di includere nella configurazione un cluster con un pool di nodi dedicati esclusivamente alla pianificazione. Questa configurazione consentirà di mantenere veloci e reattive le applicazioni web e incorporate. Questi vantaggi richiedono la configurazione di nodi con opzioni di avvio personalizzate e regole di bilanciamento del carico appropriate, come illustrato nel diagramma seguente e nelle sezioni Vantaggi e Best practice per questa opzione.
Vantaggi
- L'utilizzo di nodi per una funzione specifica consente di suddividere le risorse per la pianificazione dalle funzioni di sviluppo e analisi ad hoc.
- Gli utenti possono sviluppare LookML ed esplorare i contenuti senza seguire cicli dai nodi responsabili della gestione delle pubblicazioni dei report pianificate.
- Un traffico elevato di utenti incanalato verso i nodi normali non impedisce i carichi di lavoro pianificati gestiti dai nodi di pianificazione.
best practice
- Ogni nodo Looker deve essere ospitato in una propria VM dedicata.
- Il bilanciatore del carico, ovvero il punto in entrata 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 in modo da eseguire il port forwarding da 443 (https) a 9999 (il server Looker della porta è 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 fare in modo che il deployment abbia uno spazio di archiviazione con 2 IOPS per GB.
Velocità effettiva di rendering elevata
Per casi d'uso che richiedono una velocità effettiva dei report di rendering elevata, consigliamo di configurare un cluster con un pool di nodi dedicati esclusivamente al rendering. Il rendering di un file PDF o di un'immagine PNG/JPEG è un'operazione relativamente costosa in Looker. Il rendering può richiedere molto spazio in termini di memoria e CPU e, quando Linux è sotto pressione, potrebbe terminare un processo in esecuzione. Poiché l'utilizzo della memoria di un job di rendering non può essere determinato in anticipo, l'avvio di un job di rendering potrebbe causare l'interruzione del processo Looker. La configurazione di nodi di rendering dedicati consentirà un'ottimizzazione ottimale dei job di rendering, preservando al contempo 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 appropriate, come illustrato nel diagramma seguente e spiegato nelle sezioni Vantaggi e Best practice per questa opzione. Inoltre, i nodi di rendering potrebbero richiedere più risorse host rispetto ai nodi standard, poiché il servizio di rendering di Looker dipende da processi di terze parti di Chromium che condividono il tempo di CPU e la memoria.
Vantaggi
- L'utilizzo di nodi per una funzione specifica consente di suddividere le risorse per il rendering delle funzioni di sviluppo e analisi ad hoc.
- Gli utenti possono sviluppare LookML ed esplorare i contenuti senza seguire cicli dai nodi responsabili del rendering di PNG e PDF.
- Un traffico elevato di utenti incanalato verso i nodi normali non impedisce i carichi di lavoro di rendering serviti dai nodi di rendering.
best practice
- Ogni nodo Looker deve essere ospitato in una propria VM dedicata.
- Il bilanciatore del carico, ovvero il punto in entrata 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 in modo da eseguire il port forwarding da 443 (https) a 9999 (il server Looker della porta è in ascolto).
- Ometti i nodi di rendering dalle regole di bilanciamento del carico, in modo da non gestire 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 pressione della memoria è stato ridotto sui nodi non di rendering, quindi la quantità di memoria dedicata a Looker può essere aumentata. Invece del 60% predefinito, prendi in considerazione un numero più alto, ad esempio l'80%.
- Ti consigliamo di fare in modo che il deployment abbia uno spazio di archiviazione con 2 IOPS per GB.