Architekturmuster für vom Kunden gehostete Infrastrukturen

Auf dieser Seite werden die gängigsten Architekturmuster für eine vom Kunden gehostete Bereitstellung erläutert und die Best Practices für ihre Implementierung beschrieben. Damit Sie diese Seite effektiv nutzen können, sollten Sie mit den Konzepten und Praktiken der Systemarchitektur vertraut sein.

Workflowstrategie

Nachdem Sie das Self-Hosting als praktikable Option für die Implementierung von Looker identifiziert haben, besteht der nächste Schritt darin, die Strategie zu entwickeln, die durch die Bereitstellung umgesetzt werden soll.

  1. Führen Sie eine Bewertung durch. Erstellen Sie eine Liste der geplanten und vorhandenen Workflows.
  2. Geben Sie anwendbare Architekturmuster an. Bestimmen Sie anhand der identifizierten potenziellen 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 auf einer dedizierten virtuellen Maschine (VM) auszuführen. Eine einzelne Instanz kann anspruchsvolle Arbeitslasten bedienen, indem der Host vertikal skaliert und die Standard-Threadpools erhöht werden. Aufgrund des Verarbeitungsaufwands für die Verwaltung eines großen Java-Heaps unterliegt die vertikale Skalierung jedoch dem Gesetz des abnehmenden Grenznutzens. Sie ist in der Regel für kleine bis mittelgroße Arbeitslasten akzeptabel. Das folgende Diagramm zeigt die Standard- und optionalen Konfigurationen 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 werden.

Diagramm, das die Standard- und optionalen Konfigurationen zwischen Looker in einer dedizierten VM mit lokalen und Remote-Repositories, SMTP-Servern und Datenquellen darstellt

Vorteile

  • Eine dedizierte VM ist einfach bereitzustellen und zu verwalten.
  • Die interne Datenbank wird in der Looker-Anwendung gehostet.
  • Die Looker-Modelle, das Git-Repository, der SMTP-Server und die Komponenten der Backend-Datenbank können lokal oder remote konfiguriert werden.
  • Sie können den Standard-SMTP-Server von Looker durch Ihren eigenen ersetzen, um E-Mail-Benachrichtigungen und geplante Aufgaben zu senden.

Best Practices

  • Standardmäßig kann Looker Bare-Git-Repositories für ein Projekt generieren. Wir empfehlen, ein Remote-Git-Repository zur Redundanz einzurichten.
  • Standardmäßig startet Looker mit einer speicherresidenten HyperSQL-Datenbank. Diese Datenbank ist praktisch und effizient, kann aber bei intensiver Nutzung zu Leistungsproblemen führen. Für größere Bereitstellungen empfehlen wir die Verwendung einer MySQL-Datenbank. Wir empfehlen, die Datei ~/looker/.db/looker.script zu einer Remote-MySQL-Datenbank zu migrieren, sobald sie 600 MB erreicht.
  • Ihre Looker-Bereitstellung muss mit dem Looker-Lizenzierungsservice abgeglichen werden. Dazu ist ausgehender Traffic über Port 443 erforderlich.
  • Eine dedizierte VM-Bereitstellung kann vertikal skaliert werden, indem die verfügbaren Ressourcen und Looker-Threadpools erhöht werden. Die Erhöhung des RAM ist jedoch nach Erreichen von 64 GB nicht mehr sinnvoll, da Garbage-Collection-Ereignisse nur einen Thread haben und alle anderen Threads anhalten. Knoten mit 16 CPUs und 64 GB RAM bieten ein gutes Preis-Leistungs-Verhältnis.
  • Wir empfehlen für Ihre Bereitstellung einen Speicher mit 2 E/A-Vorgängen pro Sekunde (IOPS) pro GB.

Cluster von VMs

Wenn Sie Looker als Cluster von Instanzen auf mehreren VMs ausführen, ist das ein flexibles Muster, das von Dienst-Failover und Redundanz profitiert. Die horizontale Skalierbarkeit ermöglicht einen höheren Durchsatz, ohne dass es zu einem Haufen-Bloat und übermäßigen Kosten für die Garbage Collection kommt. Knoten können für bestimmte Arbeitslasten reserviert werden, sodass mehrere Bereitstellungsoptionen an unterschiedliche Geschäftsanforderungen angepasst werden können. Für Clusterbereitstellungen ist mindestens ein Systemadministrator erforderlich, der mit Linux-Systemen vertraut ist und die Komponenten verwalten kann.

Standard-Cluster

Für die meisten Standardimplementierungen reicht ein Cluster mit identischen Dienstknoten aus. Alle Knoten im Cluster sind gleich konfiguriert und befinden sich im selben Load Balancer-Pool. Bei keiner der Knoten in dieser Konfiguration ist die Wahrscheinlichkeit höher oder niedriger, dass Looker-Nutzeranfragen, Rendering-Aufgaben, geplante Aufgaben, API-Anfragen usw. verarbeitet werden.

Diese Art der Konfiguration eignet sich, wenn die meisten Anfragen direkt von einem Looker-Nutzer stammen, der Abfragen ausführt und mit Looker interagiert. Es kommt zu Problemen, wenn eine große Anzahl von Anfragen von einem Scheduler, einem Renderer oder einer anderen Quelle kommt. In diesem Fall ist es sinnvoll, bestimmte Dienstknoten für Aufgaben wie Zeitpläne und Rendering zuzuweisen.

Nutzer planen Datenübermittlungen beispielsweise häufig für Montagmorgen. Wenn ein Nutzer am Montagmorgen Looker-Abfragen ausführen möchte, kann es zu Leistungsproblemen kommen, während Looker den Rückstand an geplanten Anfragen abarbeitet. Durch die Erhöhung der Anzahl der Dienstknoten erhöht der Cluster den Durchsatz proportional für alle Looker-Funktionen.

Das folgende Diagramm zeigt, wie Anfragen an Looker, die von Nutzern, Apps und Scripts gesendet werden, auf eine clusterbasierte Looker-Instanz verteilt werden.

Anfragen an Looker, die vom Nutzer, von Apps und von Scripts stammen, werden über einen Load Balancer auf drei Looker-Knoten in einer clusterbasierten Looker-Instanz verteilt.

Vorteile

  • Ein Standardcluster maximiert die allgemeine Durchsatzleistung bei minimaler Konfiguration der Clustertopologie.
  • Die Leistung der Java-VM verschlechtert sich bei einem zugewiesenen Arbeitsspeichergrenzwert von 64 GB. Daher ist die horizontale Skalierung effektiver als die vertikale Skalierung.
  • Eine Clusterkonfiguration sorgt für Dienstredundanz und Failover.

Best Practices

  • Jeder Looker-Knoten sollte auf einer eigenen VM gehostet werden.
  • Der Load Balancer, der der Ingress-Punkt des Clusters ist, sollte ein Layer 4-Load Balancer sein. Sie sollte eine lange Zeitüberschreitung (3.600 Sekunden) haben, mit einem signierten SSL-Zertifikat ausgestattet sein und für die Portweiterleitung von 443 (https) zu 9999 konfiguriert sein (Port, auf dem der Looker-Server wartet).
  • Wir empfehlen für Ihre Bereitstellung einen Speicher mit 2 IOPS pro GB.

Dev/Staging/Prod

Für Anwendungsfälle, bei denen die maximale Verfügbarkeit von Inhalten für Endnutzer im Vordergrund steht, empfehlen wir separate Looker-Umgebungen, um Entwicklungs- und Analyseaufgaben voneinander zu trennen. Da Änderungen an der Produktionsumgebung erst nach einer Prüfung in isolierten Entwicklungs- und Testumgebungen vorgenommen werden, ist diese Produktionsumgebung so stabil wie möglich.

Diese Vorteile erfordern die Einrichtung der miteinander verbundenen Umgebungen und die Einführung eines robusten Release-Zyklus. Für eine Dev-/Staging-/Prod-Bereitstellung ist außerdem ein Entwicklerteam erforderlich, das mit der Looker API und Git für die Workflowverwaltung vertraut ist.

Das folgende Diagramm zeigt den Inhaltsfluss zwischen LookML-Entwicklern, die Inhalte in der Entwicklungsinstanz entwickeln, QA-Testern, die die Inhalte in der QA-Instanz testen, sowie Nutzern, Apps und Scripts, die die Inhalte in der Produktionsinstanz nutzen.

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

Vorteile

  • Die LookML- und Inhaltsvalidierung erfolgt in einer Nicht-Produktionsumgebung, damit alle Änderungen an der Modelllogik gründlich geprüft werden können, bevor sie Produktionsnutzer erreichen.
  • Instanzweite Funktionen wie Labs-Funktionen oder Authentifizierungsprotokolle können einzeln getestet werden, bevor sie in der Produktionsumgebung aktiviert werden.
  • Datengruppen- und Caching-Richtlinien können in einer Nicht-Produktionsumgebung getestet werden.
  • Tests im Looker-Produktionsmodus sind von Produktionsumgebungen getrennt, die für die Bereitstellung von Daten für Endnutzer verantwortlich sind.
  • Looker-Releases können in einer Nicht-Produktionsumgebung getestet werden. So haben Sie genügend Zeit, neue Funktionen, Workflowänderungen und Probleme zu testen, bevor Sie die Produktionsumgebung aktualisieren.

Best Practices

  • Isolieren Sie die verschiedenen Aktivitäten, die gleichzeitig in mindestens drei separaten Instanzen stattfinden:
    • Entwicklungsinstanz: Entwickler verwenden die Entwicklungsumgebung, um Code zu committen, Tests durchzuführen, Fehler zu beheben und Fehler sicher zu machen.
    • QA-Instanz: Auch als Testumgebung oder Staging-Umgebung bezeichnet. Hier führen Entwickler manuelle und automatisierte Tests durch. Die QA-Umgebung ist komplex und kann viele Ressourcen verbrauchen.
    • Produktionsinstanz: Hier wird Mehrwert für Kunden und/oder das Unternehmen geschaffen. Die Produktionsumgebung ist sehr sichtbar und sollte fehlerfrei sein.
  • Einen dokumentierten, wiederholbaren Release-Zyklus-Workflow pflegen
  • Wenn viele Entwickler und QA-Tester bedient werden müssen, können die Dev- und/oder QA-Instanzen geclustert werden. Unabhängig davon, ob die Entwicklungs- und QA-Instanzen als eigenständige VM oder als VM-Cluster ausgeführt werden, unterliegen sie denselben architektonischen Überlegungen, die in den jeweiligen Abschnitten bereits erläutert wurden.

Hoher Planungsdurchsatz

Für Anwendungsfälle, bei denen ein hoher Durchsatz für die geplante Datenübermittlung und zeitnahe, zuverlässige Übermittlungen erforderlich sind, empfehlen wir, die Konfiguration um einen Cluster mit einem Pool von Knoten zu ergänzen, die ausschließlich für die Planung vorgesehen sind. Diese Konfiguration trägt dazu bei, dass Web- und eingebettete Anwendungen schnell und reaktionsschnell bleiben. Um diese Vorteile zu nutzen, müssen Knoten mit benutzerdefinierten Startoptionen und geeigneten Load Balancing-Regeln eingerichtet werden, wie im folgenden Diagramm 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 vorgesehen sind.

Vorteile

  • Wenn Sie bestimmte Knoten für eine bestimmte Funktion festlegen, werden Ressourcen für die Planung von Entwicklungs- und Ad-hoc-Analysefunktionen getrennt.
  • Nutzer können LookML entwickeln und Inhalte untersuchen, ohne Zyklen von Knoten zu belegen, die für die Bereitstellung geplanter Datenablieferungen verantwortlich sind.
  • Ein hoher Nutzertraffic, der an die regulären Knoten weitergeleitet wird, beeinträchtigt nicht die geplanten Arbeitslasten, die von Planungsknoten ausgeführt werden.

Best Practices

  • Jeder Looker-Knoten sollte auf einer eigenen VM gehostet werden.
  • Der Load Balancer, der der Ingress-Punkt des Clusters ist, sollte ein Layer 4-Load Balancer sein. Sie sollte eine lange Zeitüberschreitung (3.600 Sekunden) haben, mit einem signierten SSL-Zertifikat ausgestattet sein und für die Portweiterleitung von 443 (https) zu 9999 konfiguriert sein (Port, auf dem der Looker-Server wartet).
  • Schließen Sie Scheduler-Knoten von Load Balancing-Regeln aus, damit sie keinen Endnutzer-Traffic und keine internen API-Anfragen bedienen.
  • Wir empfehlen für Ihre Bereitstellung einen Speicher mit 2 IOPS pro GB.

Hoher Renderingdurchsatz

Für Anwendungsfälle, bei denen ein hoher Berichtsdurchsatz beim Rendern erforderlich ist, empfehlen wir die Konfiguration eines Clusters mit einem Pool von Knoten, die ausschließlich dem Rendern dienen. Das Rendern einer PDF-Datei oder eines PNG-/JPEG-Bilds ist in Looker relativ ressourcenintensiv. Das Rendering kann speicher- und CPU-intensiv sein. Wenn Linux unter Speicherdruck steht, kann ein laufender Prozess beendet werden. Da die Arbeitsspeichernutzung eines Renderjobs nicht im Voraus bestimmt werden kann, kann das Starten eines Renderjobs dazu führen, dass der Looker-Prozess beendet wird. Wenn Sie spezielle Rendering-Knoten konfigurieren, können Sie Renderjobs optimal optimieren und gleichzeitig die Reaktionsfähigkeit der interaktiven und eingebetteten Anwendung beibehalten.

Um diese Vorteile zu nutzen, müssen Knoten mit benutzerdefinierten Startoptionen und geeigneten Load Balancing-Regeln eingerichtet werden, wie im folgenden Diagramm dargestellt und in den Abschnitten Vorteile und Best Practices für diese Option erläutert. Außerdem benötigen Rendering-Knoten möglicherweise mehr Hostressourcen als Standardknoten, da der Rendering-Dienst von Looker auf Chromium-Prozessen von Drittanbietern basiert, die sich CPU-Zeit und Arbeitsspeicher teilen.

Looker-Clusterkonfiguration mit einem Pool von Knoten, die dem Rendering gewidmet sind.

Vorteile

  • Wenn Sie bestimmte Knoten für eine bestimmte Funktion festlegen, werden Ressourcen für das Rendering von Entwicklungs- und Ad-hoc-Analysefunktionen getrennt.
  • Nutzer können LookML entwickeln und Inhalte analysieren, ohne Zyklen von den Knoten zu übernehmen, die für das Rendern von PNGs und PDFs verantwortlich sind.
  • Ein hoher Nutzertraffic, der an die regulären Knoten weitergeleitet wird, beeinträchtigt nicht die Rendering-Arbeitslasten, die von Rendering-Knoten ausgeführt werden.

Best Practices

  • Jeder Looker-Knoten sollte auf einer eigenen VM gehostet werden.
  • Der Load Balancer, der der Ingress-Punkt des Clusters ist, sollte ein Layer 4-Load Balancer sein. Sie sollte eine lange Zeitüberschreitung (3.600 Sekunden) haben, mit einem signierten SSL-Zertifikat ausgestattet sein und für die Portweiterleitung von 443 (https) zu 9999 konfiguriert sein (Port, auf dem der Looker-Server wartet).
  • Lasse Rendering-Knoten aus den Load Balancing-Regeln aus, damit sie keinen Endnutzer-Traffic und keine internen API-Anfragen bedienen.
  • Java in den Rendering-Knoten relativ weniger Arbeitsspeicher zuweisen, um den Prozessen von Chromium einen größeren Arbeitsspeicher-Puffer zu geben. Weisen Sie Java nicht 60% des Arbeitsspeichers zu, sondern 40–50%.
  • Das Risiko einer Speicherauslastung wurde auf den Knoten ohne Rendering reduziert, sodass die für Looker verfügbare Arbeitsspeichermenge erhöht werden kann. Anstatt den Standardwert von 60 % sollten Sie einen höheren Wert wie 80 % wählen.
  • Wir empfehlen für Ihre Bereitstellung einen Speicher mit 2 IOPS pro GB.