Modelli di architettura dell'infrastruttura ospitata dal cliente

Questa pagina fa parte di una serie in più parti che illustra l'hosting, le metodologie di deployment e le best practice di Looker 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 implementarli. Per utilizzare questa pagina in modo efficace, dovresti avere familiarità con i concetti e le pratiche dell'architettura di sistema.

Questa serie è composta da tre parti:

• Panoramica dell'infrastruttura ospitata dal cliente
• Pattern di architettura dell'infrastruttura ospitata dal cliente (questa pagina)
• Procedure dettagliate per i componenti dell'infrastruttura ospitati dal cliente

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 per il deployment.

1. Esegui una valutazione. Identificare un elenco di candidati di flussi di lavoro pianificati ed esistenti.
2. Elenca i pattern di architettura applicabili. Partendo dai flussi di lavoro dei candidati identificati, identifica i pattern architetturali applicabili.
3. Dai la priorità e seleziona il modello di architettura ottimale. Allinea il modello dell'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, l'overhead di elaborazione associato alla gestione di un heap Java di grandi dimensioni sottopone il ridimensionamento verticale alla legge di rendimenti decrescenti. È generalmente accettabile per carichi di lavoro medio-piccoli. 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 distribuire e gestire.
• Il database interno è ospitato all'interno dell'applicazione Looker.
• I modelli Looker, il repository Git, il server SMTP e i componenti di 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 semplici per un progetto. Consigliamo di configurare un repository Git remoto per la ridondanza.
• Per impostazione predefinita, Looker inizia con un database HyperSQL in memoria. Questo database è pratico e leggero, ma con un uso intensivo può verificarsi problemi di prestazioni. Consigliamo di utilizzare un database MySQL per deployment di grandi dimensioni. Consigliamo di eseguire la migrazione a un database MySQL remoto quando il file ~/looker/.db/looker.script raggiunge i 600 MB.
• Il deployment di Looker dovrà essere convalidato in base al servizio di licenze di Looker. È richiesto il traffico in uscita sulla porta 443.
• 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 trae vantaggio dal failover e la ridondanza dei servizi. La scalabilità orizzontale consente una maggiore velocità effettiva senza sovraccaricare l'heap e costi eccessivi della garbage collection. 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 nel cluster sono configurati allo stesso modo e si trovano tutti 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 ad arrestarsi quando un numero elevato di richieste proviene da uno scheduler, un renderer o un'altra origine. In questo caso, è utile designare determinati nodi di servizio per gestire attività come pianificazioni e rendering.

Ad esempio, gli utenti di solito pianificheranno l'esecuzione dei report il lunedì mattina. Un utente che prova a eseguire query di Looker lunedì mattina potrebbe riscontrare problemi di prestazioni mentre Looker lavora sul backlog 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 da utente, app e script vengono bilanciate in un'istanza di Looker in cluster.

Vantaggi

• Un cluster standard massimizza l'utilizzo generale con una configurazione minima della topologia dei 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 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. Dovrebbe avere un timeout lungo (3600 secondi), essere dotato di un certificato SSL firmato ed essere configurato per il port forwarding da 443 (https) a 9999 (il server Looker della porta rimane 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 la priorità al massimo tempo di attività dei contenuti per gli utenti finali, consigliamo ambienti Looker separati in modo da categorizzare il lavoro di sviluppo e quello analitico. Bloccando le modifiche 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 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 mostra 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

• LookML e convalida dei contenuti avvengono in un ambiente non di produzione, assicurando che tutte le modifiche alla logica del modello possano essere accuratamente verificate 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 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, offrendo un ampio tempo per testare 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 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 per l'attività. La produzione è un ambiente ad alta visibilità e deve 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 di sviluppo e/o QA possono essere raggruppate in cluster. Che siano lasciate come VM autonome o cluster di VM, le istanze Dev e QA sono soggette alle stesse considerazioni sull'architettura precedentemente mostrate nelle rispettive sezioni.

Velocità effettiva di pianificazione elevata

Per i casi d'uso che richiedono un'elevata velocità effettiva dei report pianificata e consegne tempestive e affidabili, consigliamo di includere un cluster con un pool di nodi esclusivamente dedicato alla pianificazione. Questa configurazione ti aiuterà a mantenere il web e le applicazioni incorporate veloci e reattive. Questi vantaggi richiedono la configurazione di nodi con opzioni di avvio personalizzate e regole di bilanciamento del carico appropriate, come illustrato nel diagramma di seguito e 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 utilizzare cicli dai nodi responsabili della gestione delle pubblicazioni pianificate dei report.
• Un elevato traffico di utenti incanalato verso i nodi normali non ostacola 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. Dovrebbe avere un timeout lungo (3600 secondi), essere dotato di un certificato SSL firmato ed essere configurato per il port forwarding da 443 (https) a 9999 (il server Looker della porta rimane 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.
• Consigliamo di fare in modo che il deployment disponga di 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 costosa 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 appropriate, come illustrato nel diagramma di seguito e descritto 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 Chromium di terze parti che condividono il tempo di CPU e la 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 un LookML ed esplorare i contenuti senza utilizzare i cicli dei nodi responsabili del rendering dei file PNG e PDF.
• Un elevato traffico di utenti incanalato verso i 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, ovvero il punto di ingresso del cluster, deve essere un bilanciatore del carico di livello 4. Dovrebbe avere un timeout lungo (3600 secondi), essere dotato di un certificato SSL firmato ed essere configurato per il port forwarding da 443 (https) a 9999 (il server Looker della porta rimane 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, allocare 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, prendi in considerazione un numero più alto, ad esempio 80%.
• Consigliamo di fare in modo che il deployment disponga di uno spazio di archiviazione con 2 IOPS per GB.