Pattern di architettura dell'infrastruttura ospitata dal cliente

Questa pagina illustra 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, devi conoscere i concetti e le pratiche di architettura di sistema.

Strategia di flusso di lavoro

Dopo aver identificato l'hosting autonomo come opzione praticabile per l'implementazione di Looker, il passaggio successivo consiste nell'elaborare la strategia da applicare al 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 necessarie 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 da piccoli a medi. Il seguente diagramma mostra le configurazioni predefinite e facoltative tra un'istanza di Looker in esecuzione in 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.

Diagramma che mostra le configurazioni predefinite e facoltative tra Looker in esecuzione in una VM dedicata con repository locali e remoti, server SMTP e origini dati.

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 bare 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 l'utilizzo di un database MySQL per implementazioni di dimensioni maggiori. 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; è necessario 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 del rendimento decrescente una volta raggiunti i 64 GB, poiché gli eventi di raccolta dei rifiuti sono a thread singolo e interrompono l'esecuzione di tutti gli altri thread. I nodi con 16 CPU e 64 GB di RAM offrono un buon equilibrio tra prezzo e prestazioni.
  • Ti consigliamo di utilizzare uno 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 del volume dell'heap e dei costi di raccolta dei rifiuti. I nodi hanno la possibilità di dedicarsi ai carichi di lavoro, il che consente di personalizzare più opzioni di implementazione in base a diversi requisiti aziendali. I deployment in 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 del cluster sono configurati allo stesso modo e si trovano nello stesso pool del bilanciatore del carico. Nessuno dei nodi in questa configurazione ha maggiori o minori probabilità di soddisfare 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 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 in genere 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 offre un aumento proporzionale del throughput 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.

Le richieste a Looker effettuate dall'utente, dalle app e dagli script vengono distribuite su un bilanciatore del carico su tre nodi Looker in un'istanza di Looker in cluster.

Vantaggi

  • Un cluster standard massimizza la produttività generale con una configurazione minima della topologia del cluster.
  • La VM Java subisce un degrado delle prestazioni alla soglia di memoria allocata di 64 GB; ecco perché la scalabilità orizzontale ha rendimenti maggiori rispetto alla scalabilità verticale.
  • Una configurazione del 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, 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 l'inoltro di porte dalla 443 (https) alla 9999 (porta su cui il server Looker è in ascolto).
  • Ti consigliamo di avere uno spazio di archiviazione con 2 IOPS per GB.

Dev/Staging/Prod

Per i casi d'uso che danno la priorità al tempo di attività massimo dei contenuti per gli utenti finali, consigliamo ambienti Looker separati per suddividere il lavoro di sviluppo e quello di analisi. In quanto le modifiche all'ambiente di produzione vengono applicate in 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 solido. Un deployment di Dev/Staging/Prod richiede anche un team di sviluppatori che abbiano familiarità con l'API Looker e Git per l'amministrazione del flusso di lavoro.

Il seguente diagramma mostra il flusso dei contenuti tra gli sviluppatori LookML che sviluppano i contenuti nell'istanza di sviluppo, i tester di 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.

I contenuti vengono sviluppati nell'istanza di sviluppo, testati nell'istanza di QA e utilizzati da utenti, app e script 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 gruppi di dati e i criteri di 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 pubblicazione per gli 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 distinte:
    • Istanza di sviluppo: gli sviluppatori utilizzano l'ambiente di sviluppo per eseguire commit del codice, condurre esperimenti, correggere bug e commettere errori in sicurezza.
    • Istanza QA: nota anche come ambiente di test o gestione temporanea, è qui che gli sviluppatori eseguono test manuali e automatici. L'ambiente QA è complesso e può consumare 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 deve essere privo di errori.
  • Mantieni un flusso di lavoro del ciclo di rilascio documentato e ripetibile.
  • Se è necessario gestire elevati volumi di sviluppatori e tester QA, le istanze di sviluppo e/o QA possono essere raggruppate. 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 elevata della pianificazione

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.

Configurazione del cluster di Looker con un pool di nodi dedicati esclusivamente alla pianificazione.

Vantaggi

  • La dedica dei nodi a una funzione specifica consente di suddividere le risorse per la pianificazione dalle funzioni di analisi ad hoc e di sviluppo.
  • 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 regolari non impedisce i workload pianificati gestiti dai nodi di pianificazione.

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 l'inoltro di porte dalla 443 (https) alla 9999 (porta su cui il server Looker è in ascolto).
  • Ometti i nodi di pianificazione 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 elevato throughput dei report di rendering, 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 dispendiosa in termini di risorse in Looker. Il rendering può richiedere molta memoria e CPU e, quando Linux è sotto pressione di memoria, potrebbe interrompere 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 comportare l'interruzione del processo di Looker. La configurazione di nodi di rendering dedicati consente di ottimizzare i 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 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.

Configurazione del cluster di Looker con un pool di nodi dedicati al rendering.

Vantaggi

  • La dedica dei nodi a una funzione specifica consente di suddividere le risorse per il rendering dalle funzioni di sviluppo e di analisi ad hoc.
  • Gli utenti possono sviluppare LookML ed esplorare i contenuti senza sottrarre cicli ai 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 l'inoltro di porte 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 fornire 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 utilizzo intensivo della memoria è stato ridotto sui nodi di non rendering, pertanto la quantità di memoria dedicata a Looker può essere aumentata. Anziché il 60% predefinito, valuta la possibilità di utilizzare un numero più alto, ad esempio l'80%.
  • Ti consigliamo di avere uno spazio di archiviazione con 2 IOPS per GB.