Vom Kunden gehostete Infrastrukturarchitekturmuster

Diese Seite ist Teil einer mehrteiligen Reihe, in der das Hosting von Looker, die Bereitstellungsmethoden und Best Practices für die beteiligten Komponenten erläutert werden. Auf dieser Seite werden die gängigsten Architekturmuster für eine vom Kunden gehostete Bereitstellung sowie die Best Practices für deren Implementierung erläutert. Um diese Seite effektiv verwenden zu können, sollten Sie mit den Konzepten und Praktiken der Systemarchitektur vertraut sein.

Diese Reihe besteht aus drei Teilen:

Workflowstrategie

Nachdem Sie Selbsthosting als praktikable Option für Ihre Implementierung von Looker identifiziert haben, besteht der nächste Schritt darin, die Strategie für die Bereitstellung auszuarbeiten.

  1. Führen Sie eine Bewertung durch. Identifizieren Sie eine Kandidatenliste mit geplanten und vorhandenen Workflows.
  2. Anwendbare Architekturmuster auflisten. Identifizieren Sie anhand der identifizierten Kandidaten-Workflows geeignete Architekturmuster.
  3. Priorisieren und wählen Sie das optimale Architekturmuster aus. Richten Sie das Architekturmuster auf die wichtigsten Aufgaben und Ergebnisse aus.
  4. Konfigurieren Sie die Architekturkomponenten und stellen Sie die Looker-Anwendung bereit. Implementieren Sie den Host, die Abhängigkeiten von Drittanbietern und die Netzwerktopologie, die zum Herstellen sicherer Clientverbindungen erforderlich sind.

Architekturoptionen

Dedizierte virtuelle Maschine

Eine Möglichkeit besteht darin, Looker als einzelne Instanz in einer dedizierten virtuellen Maschine (VM) auszuführen. Eine einzelne Instanz kann anspruchsvolle Arbeitslasten bedienen, indem sie den Host vertikal skaliert und die Standard-Thread-Pools erhöht. Der Verarbeitungsaufwand bei der Verwaltung eines großen Java-Heaps unterliegt jedoch der vertikalen Skalierung dem Gesetz der sinkenden Ergebnisse. Sie ist im Allgemeinen für kleine bis mittlere Arbeitslasten akzeptabel. Das folgende Diagramm zeigt die standardmäßige und optionale Einrichtung zwischen einer Looker-Instanz, die auf einer dedizierten VM ausgeführt wird, den lokalen und Remote-Repositories, den SMTP-Servern und den Datenquellen, die in den Abschnitten Vorteile und Best Practices für diese Option hervorgehoben sind.

Diagramm, das die standardmäßigen und optionalen Konfigurationen zwischen Looker zeigt, das auf einer dedizierten VM mit lokalen und Remote-Repositories, SMTP-Servern und Datenquellen ausgeführt wird.

Vorteile

  • Eine dedizierte VM ist einfach bereitzustellen und zu warten.
  • Die interne Datenbank wird in der Looker-Anwendung gehostet.
  • Die Komponenten der Looker-Modelle, des Git-Repositorys, des SMTP-Servers und der Back-End-Datenbank können lokal oder remote konfiguriert werden.
  • Sie können den Standard-SMTP-Server von Looker für E-Mail-Benachrichtigungen und geplante Aufgaben durch Ihren eigenen ersetzen.

Best Practices

  • Standardmäßig kann Looker Git-Repositories für ein Projekt generieren. Wir empfehlen, ein Remote-Git-Repository zu Redundanzzwecken einzurichten.
  • Standardmäßig startet Looker mit einer speicherinternen HyperSQL-Datenbank. Diese Datenbank ist praktisch und ressourcenintensiv, kann jedoch bei starker Nutzung zu Leistungsproblemen führen. Bei größeren Bereitstellungen empfehlen wir die Verwendung einer MySQL-Datenbank. Wir empfehlen die Migration zu einer MySQL-Remote-Datenbank, sobald die Datei ~/looker/.db/looker.script 600 MB erreicht hat.
  • Ihre Looker-Bereitstellung muss mit dem Looker-Lizenzierungsservice validiert werden. Ausgehender Traffic über Port 443 ist erforderlich.
  • Ein dediziertes VM-Deployment kann vertikal skaliert werden, indem die verfügbaren Ressourcen und Looker-Thread-Pools erhöht werden. Die Erhöhung des RAM-Speichers unterliegt jedoch dem Gesetz der abnehmenden Rückgaben, sobald 64 GB erreicht sind, da Speicherbereinigungsereignisse Single-Threaded sind und die Ausführung aller anderen Threads anhalten. Knoten mit 16 CPUs und 64 GB RAM bieten ein gutes Gleichgewicht zwischen Preis und Leistung.
  • Wir empfehlen, dass Ihre Bereitstellung über einen Speicher mit zwei Vorgängen pro Sekunde (IOPS) pro GB verfügt.

Cluster von VMs

Die Ausführung von Looker als Cluster von Instanzen über mehrere VMs hinweg ist ein flexibles Muster, das von Dienst-Failover und Redundanz profitiert. Horizontale Skalierbarkeit ermöglicht einen höheren Durchsatz, ohne dass Heap-Bloat und übermäßige Kosten für die automatische Speicherbereinigung verursacht werden. Knoten haben die Möglichkeit, Arbeitslasten zuzuweisen. Dadurch können mehrere Bereitstellungsoptionen an unterschiedliche Geschäftsanforderungen angepasst werden. Clusterbereitstellungen erfordern mindestens einen Systemadministrator, der mit Linux-Systemen vertraut ist und in der Lage ist, die Komponenten zu verwalten.

Standard-Cluster

Für die meisten Standardbereitstellungen ist ein Cluster identischer Dienstknoten ausreichend. Alle Knoten im Cluster werden auf die gleiche Weise konfiguriert und befinden sich alle im selben Load-Balancer-Pool. Keiner der Knoten in dieser Konfiguration würde mit größerer oder geringerer Wahrscheinlichkeit Looker-Nutzeranfragen, eine Rendering-Aufgabe, eine geplante Aufgabe, eine API-Anfrage usw. bedienen.

Diese Art der Konfiguration eignet sich, wenn die meisten Anfragen direkt von einem Looker-Benutzer stammen, der Abfragen ausführt und mit Looker interagiert. Die Aufschlüsselung beginnt, wenn eine große Anzahl von Anfragen von einem Planer, einem Renderer oder einer anderen Quelle kommt. In diesem Fall ist es von Vorteil, bestimmte Dienstknoten für Aufgaben wie Zeitpläne und Rendering festzulegen.

Beispielsweise planen Nutzer in der Regel, Berichte so zu planen, dass sie am Montagmorgen erstellt werden. Bei einem Benutzer, der am Montagmorgen versucht, Looker-Abfragen auszuführen, kann es zu Leistungsproblemen kommen, während Looker mit dem Rückstand geplanter Anfragen arbeitet. Durch die Erhöhung der Anzahl der Dienstknoten sorgt der Cluster für einen proportionalen Anstieg des Durchsatzes über alle Funktionen von Looker hinweg.

Das folgende Diagramm zeigt, wie Anfragen an Looker, die vom Benutzer, von Anwendungen und Skripts gesendet werden, in einer Looker-Clusterinstanz verteilt werden.

Anfragen an Looker, die vom Benutzer, von Anwendungen und Skripts stammen, werden auf einen Load-Balancer verteilt, der sich auf drei Looker-Knoten in einer Looker-Cluster-Instanz befindet.

Vorteile

  • Ein Standardcluster maximiert die Allgemeinheit mit minimaler Konfiguration der Clustertopologie.
  • Die Java-VM verzeichnet bei dem zugewiesenen Speichergrenzwert von 64 GB Leistungseinbußen. Deshalb erzielt die horizontale Skalierung größere Ergebnisse als die vertikale Skalierung.
  • Eine Clusterkonfiguration gewährleistet Dienstredundanz und Failover.

Best Practices

  • Jeder Looker-Knoten sollte in einer eigenen dedizierten VM gehostet werden.
  • Der Load-Balancer, der Eingangspunkt des Clusters, sollte ein Layer-4-Load-Balancer sein. Er sollte ein langes Zeitlimit (3.600 Sekunden) haben,mit einem signierten SSL-Zertifikat ausgestattet und so konfiguriert sein, dass eine Portweiterleitung von 443 (https) bis 9999 (Port, der Looker-Server überwacht) konfiguriert ist.
  • Wir empfehlen, dass Ihre Bereitstellung einen Speicher mit 2 IOPS pro GB hat.

Entwicklung/Staging/Produktion

Für Anwendungsfälle, bei denen die maximale Verfügbarkeit von Inhalten für Endnutzer priorisiert wird, empfehlen wir separate Looker-Umgebungen, um Entwicklungs- und Analysearbeit aufzuteilen. Durch das Sperren von Änderungen der Produktionsumgebung hinter isolierten Entwicklungs- und Testumgebungen sorgt diese Architektur für eine möglichst stabile Produktionsumgebung.

Diese Vorteile erfordern die Einrichtung von miteinander verbundenen Umgebungen und die Einführung eines robusten Releasezyklus. Eine Dev/Staging/Prod-Bereitstellung erfordert auch ein Team von Entwicklern, die mit der Looker API und Git vertraut sind, um die Workflow-Verwaltung zu ermöglichen.

Das folgende Diagramm zeigt den Inhaltsfluss zwischen LookML-Entwicklern, die Inhalte auf der Dev-Instanz entwickeln, Qualitätssicherungstestern (QA-Testern), die den Inhalt auf der QA-Instanz testen, und Nutzern, Apps und Skripts, die den Inhalt in der Produktionsinstanz verarbeiten.

Die Inhalte werden auf der Entwicklungsinstanz entwickelt, auf der QA-Instanz getestet und von Nutzern, Apps und Skripts in der Produktionsinstanz verwendet.

Vorteile

  • LookML und Inhaltsvalidierung erfolgt in einer Nicht-Produktionsumgebung. Dadurch wird sichergestellt, dass alle Änderungen an der Modelllogik gründlich überprüft werden können, bevor sie die Produktionsnutzer erreichen.
  • Instanzweite Features wie Labs-Features oder Authentifizierungsprotokolle können isoliert getestet werden, bevor sie in der Produktionsumgebung aktiviert werden.
  • Richtlinien für Datengruppen und Caching können in einer Nicht-Produktionsumgebung getestet werden.
  • Die Tests des Looker-Produktionsmodus sind von Produktionsumgebungen entkoppelt, die für die Bereitstellung von Endnutzern verantwortlich sind.
  • Looker-Releases können in einer Nicht-Produktionsumgebung getestet werden, sodass ausreichend Zeit zum Testen neuer Funktionen, Workflow-Änderungen und Probleme bleibt, bevor die Produktionsumgebung aktualisiert wird.

Best Practices

  • Isolieren Sie die verschiedenen Aktivitäten, die gleichzeitig in mindestens drei separaten Instanzen ausgeführt werden:
    • Entwicklungsinstanz: Entwickler verwenden die Entwicklungsumgebung, um Code zu übergeben, Tests durchzuführen, Fehler zu beheben und auf sichere Weise Fehler zu machen.
    • QA-Instanz: Auch als Testumgebung oder Staging-Umgebung bezeichnet. In dieser Umgebung führen Entwickler manuelle und automatisierte Tests durch. Die QA-Umgebung ist komplex und kann viele Ressourcen verbrauchen.
    • Produktionsinstanz: Hier wird ein Mehrwert für die Kundschaft und/oder das Unternehmen geschaffen. Die Produktion ist eine gut sichtbare Umgebung und sollte frei von Fehlern sein.
  • Pflegen Sie einen dokumentierten, wiederholbaren Releasezyklus-Workflow.
  • Wenn eine große Anzahl von Entwicklern und QA-Testern bereitgestellt werden muss, können die Entwicklungs- und/oder QA-Instanzen geclustert werden. Unabhängig davon, ob sie als eigenständige VM oder Cluster von VMs verwendet werden, unterliegen die Entwicklungs- und QA-Instanzen denselben Architekturüberlegungen, die in den jeweiligen Abschnitten oben erläutert wurden.

Hoher Planungsdurchsatz

Für Anwendungsfälle, die einen hohen Zeitplan für Berichte und zeitnahe, zuverlässige Übermittlungen erfordern, empfehlen wir, dass die Konfiguration einen Cluster mit einem Pool von Knoten enthält, der ausschließlich für die Planung vorgesehen ist. Diese Konfiguration trägt dazu bei, dass das Web und eingebettete Anwendungen schnell und reaktionsschnell sind. Diese Vorteile erfordern die Einrichtung von Knoten mit benutzerdefinierten Startoptionen und geeigneten Load-Balancing-Regeln, wie im Diagramm unten dargestellt und in den Abschnitten Vorteile und Best Practices für diese Option beschrieben.

Looker-Clusterkonfiguration mit einem Pool von Knoten, die ausschließlich für die Planung reserviert sind.

Vorteile

  • Durch die Zuweisung von Knoten für eine bestimmte Funktion werden Ressourcen für die Planung von Entwicklungs- und Ad-hoc-Analysefunktionen aufgeteilt.
  • Benutzer können LookML entwickeln und Inhalte untersuchen, ohne Zyklen von Knoten zu übernehmen, die für die Ausführung geplanter Berichtsübermittlungen verantwortlich sind.
  • Hoher Nutzertraffic, der an die regulären Knoten weitergeleitet wird, behindert geplante Arbeitslasten, die durch die Planung von Knoten ausgeführt werden, nicht.

Best Practices

  • Jeder Looker-Knoten sollte in einer eigenen dedizierten VM gehostet werden.
  • Der Load-Balancer, der Eingangspunkt des Clusters, sollte ein Layer-4-Load-Balancer sein. Er sollte ein langes Zeitlimit (3.600 Sekunden) haben,mit einem signierten SSL-Zertifikat ausgestattet und so konfiguriert sein, dass eine Portweiterleitung von 443 (https) bis 9999 (Port, der Looker-Server überwacht) konfiguriert ist.
  • Lassen Sie Planerknoten aus den Load-Balancing-Regeln aus, damit sie keinen Endnutzer-Traffic und keine internen API-Anfragen bereitstellen.
  • Wir empfehlen, dass Ihre Bereitstellung einen Speicher mit 2 IOPS pro GB hat.

Hoher Renderingdurchsatz

Für Anwendungsfälle, die einen hohen Durchsatz von Renderingberichten erfordern, empfehlen wir die Konfiguration eines Clusters mit einem Pool von Knoten, die ausschließlich für das Rendering vorgesehen sind. Das Rendern einer PDF-Datei oder eines PNG/JPEG-Bildes ist in Looker ein relativ ressourcenintensiver Vorgang. Das Rendern kann speicher- und CPU-lastig sein. Unter Linux hohe Speicherauslastung kann einen laufenden Prozess zum Absturz bringen. Da die Arbeitsspeichernutzung eines Renderingjobs nicht im Voraus bestimmt werden kann, kann das Starten eines Renderingjobs dazu führen, dass der Looker-Prozess abgebrochen wird. Die Konfiguration dedizierter Rendering-Knoten ermöglicht eine optimale Feinabstimmung von Rendering-Jobs, während gleichzeitig die Reaktionsfähigkeit der interaktiven und eingebetteten Anwendung erhalten bleibt.

Diese Vorteile erfordern die Einrichtung von Knoten mit benutzerdefinierten Startoptionen und geeigneten Load-Balancing-Regeln, wie im Diagramm unten dargestellt und in den Abschnitten Vorteile und Best Practices für diese Option erläutert. Darüber hinaus benötigen Rendering-Knoten möglicherweise mehr Host-Ressourcen als Standard-Knoten, da der Rendering-Dienst von Looker davon abhängt, dass Chromium-Prozesse von Drittanbietern die CPU-Zeit und den Arbeitsspeicher gemeinsam nutzen.

Looker-Clusterkonfiguration mit einem Pool von Knoten, die für das Rendering vorgesehen sind.

Vorteile

  • Durch die Zuweisung von Knoten für eine bestimmte Funktion werden Ressourcen für das Rendering aus Entwicklungs- und Ad-hoc-Analysefunktionen aufgeteilt.
  • Benutzer können LookML entwickeln und Inhalte untersuchen, ohne Zyklen von den Knoten zu nehmen, die für das Rendern von PNGs und PDFs verantwortlich sind.
  • Hoher Nutzer-Traffic, der an die regulären Knoten weitergeleitet wird, behindert Rendering-Arbeitslasten, die von Rendering-Knoten bedient werden, nicht.

Best Practices

  • Jeder Looker-Knoten sollte in einer eigenen dedizierten VM gehostet werden.
  • Der Load-Balancer, der Eingangspunkt des Clusters, sollte ein Layer-4-Load-Balancer sein. Er sollte ein langes Zeitlimit (3.600 Sekunden) haben,mit einem signierten SSL-Zertifikat ausgestattet und so konfiguriert sein, dass eine Portweiterleitung von 443 (https) bis 9999 (Port, der Looker-Server überwacht) konfiguriert ist.
  • Lassen Sie Rendering-Knoten aus Load-Balancing-Regeln aus, damit sie keinen Endnutzer-Traffic und keine internen API-Anfragen bereitstellen.
  • Weisen Sie Java in den Rendering-Knoten relativ weniger Arbeitsspeicher zu, um den Prozessen von Chromium einen größeren Zwischenspeicher zu geben. Anstatt 60% des Arbeitsspeichers für Java zuzuweisen, können Sie stattdessen 40–50 % des Arbeitsspeichers zuweisen.
  • Das Risiko einer Arbeitsspeicherauslastung auf den Nicht-Rendering-Knoten wurde reduziert, sodass der für Looker zugewiesene Arbeitsspeicher erhöht werden kann. Anstelle der Standardeinstellung von 60 % sollten Sie eine höhere Zahl wie 80 % verwenden.
  • Wir empfehlen, dass Ihre Bereitstellung einen Speicher mit 2 IOPS pro GB hat.