Architekturmuster der vom Kunden gehosteten Infrastruktur

Auf dieser Seite werden die gängigsten Architekturmuster für eine vom Kunden gehostete Bereitstellung erläutert und die Best Practices für deren 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. Identifizieren Sie eine Kandidatenliste geplanter und vorhandener Workflows.
  2. Geben Sie anwendbare Architekturmuster an. Identifizieren Sie anhand der identifizierten Workflows, um geeignete Architekturmuster zu identifizieren.
  3. Das optimale Architekturmuster priorisieren und auswählen. 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 verarbeiten, indem sie den Host vertikal skaliert und die Standard-Thread-Pools erhöht. Aufgrund des Verarbeitungsaufwands für die Verwaltung eines großen Java-Heaps unterliegt die vertikale Skalierung jedoch dem Gesetz des abnehmenden Grenznutzens. Sie ist im Allgemeinen für kleine bis mittlere 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, die auf einer dedizierten VM mit lokalen und Remote-Repositories, SMTP-Servern und Datenquellen ausgeführt wird, zeigt.

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 Backend-Datenbankkomponenten 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. Für Redundanz empfehlen wir, ein Remote-Git-Repository einzurichten.
  • Standardmäßig beginnt Looker mit einer In-Memory-HyperSQL-Datenbank. Diese Datenbank ist praktisch und schlank, kann jedoch bei intensiver Nutzung zu Leistungsproblemen führen. Für größere Bereitstellungen empfehlen wir die Verwendung einer MySQL-Datenbank. Wir empfehlen die Migration zu einer MySQL-Remotedatenbank, sobald die Datei ~/looker/.db/looker.script 600 MB erreicht.
  • Ihre Looker-Bereitstellung muss mit dem Looker-Lizenzierungsdienst validiert werden. Ausgehender Traffic auf Port 443 ist erforderlich.
  • Eine dedizierte VM-Bereitstellung kann vertikal skaliert werden, indem die verfügbaren Ressourcen und Looker-Thread-Pools 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 ausgewogenes Verhältnis zwischen Preis und Leistung.
  • Wir empfehlen, in Ihrer Bereitstellung einen Speicher mit 2 Vorgängen pro Sekunde (IOPS) pro GB zu haben.

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 Pufferüberlauf und übermäßigen Kosten für die Garbage Collection kommt. Knoten können Arbeitslasten zuweisen, 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 Standardbereitstellungen ist ein Cluster identischer Dienstknoten ausreichend. Alle Knoten im Cluster sind gleich konfiguriert und befinden sich 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. verarbeiten.

Diese Art der Konfiguration ist geeignet, wenn die meisten Anfragen direkt von einem Looker-Benutzer stammen, der Abfragen ausführt und mit Looker interagiert. Die Daten werden aufgeschlüsselt, wenn eine große Anzahl von Anfragen von einem Planer, 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 sorgt der Cluster für eine proportionale Steigerung des Durchsatzes über alle Funktionen von Looker hinweg.

Das folgende Diagramm zeigt, wie Anfragen an Looker, die von Nutzern, Apps und Skripts gesendet werden, in einer Looker-Instanz geclustert werden.

Anfragen an Looker, die vom Nutzer, von Apps und von Scripts gestellt werden, 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 Java-VM verschlechtert sich ab dem Grenzwert des zugewiesenen Arbeitsspeichers von 64 GB. Deshalb ist die horizontale Skalierung höher 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 ein langes Zeitlimit (3.600 Sekunden) haben, mit einem signierten SSL-Zertifikat ausgestattet sein und für die Portweiterleitung von 443 (https) auf 9999 (Port wird der Looker-Server überwacht) konfiguriert.
  • Wir empfehlen für Ihre Bereitstellung einen Speicher mit 2 IOPS pro GB.

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 Entwicklungsarbeit und analytische Arbeit aufzuteilen. Da Änderungen an der Produktionsumgebung hinter isolierten Entwicklungs- und Testumgebungen gesteuert werden, erhält diese Architektur eine möglichst stabile Produktionsumgebung.

Diese Vorteile erfordern die Einrichtung der miteinander verbundenen Umgebungen und die Einführung eines robusten Release-Zyklus. Eine Dev-, Staging-/Prod-Bereitstellung erfordert außerdem ein Team von Entwicklern, die mit der Looker-API und Git für die Workflow-Verwaltung vertraut sind.

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

  • LookML- und Inhaltsvalidierung erfolgt in einer Nicht-Produktionsumgebung, wodurch sichergestellt wird, dass jegliche Änderungen an der Modelllogik gründlich überprüft werden können, bevor sie Produktionsnutzern erreichen.
  • Instanzenweite 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.
  • Die Tests im Produktionsmodus von Looker sind von den Produktionsumgebungen entkoppelt, die für die Betreuung der 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 nutzen die Entwicklungsumgebung, um Code zu übergeben, Tests durchzuführen, Fehler zu beheben und auf sichere Weise Fehler zu machen.
    • QA-Instanz: Wird auch als Test- oder Staging-Umgebung bezeichnet. Hier führen Entwickler manuelle und automatisierte Tests aus. 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.
  • Halten Sie eine dokumentierte, wiederholbare Workflow für Veröffentlichungszyklus.
  • 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 vorgestellt wurden.

Hoher Planungsdurchsatz

Für Anwendungsfälle, bei denen ein hoher Durchsatz bei der geplanten 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

  • 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 verwenden, die für geplante Datenlieferungen 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 ein langes Zeitlimit (3.600 Sekunden) haben, mit einem signierten SSL-Zertifikat ausgestattet sein und für die Portweiterleitung von 443 (https) auf 9999 (Port wird der Looker-Server überwacht) konfiguriert.
  • 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 Rendering-Durchsatz

Für Anwendungsfälle, die einen hohen Rendering-Berichtdurchsatz erfordern, empfehlen wir die Konfiguration eines Clusters mit einem Pool von Knoten, der ausschließlich für das Rendering vorgesehen ist. 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.

Damit Sie diese Vorteile nutzen können, 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 für das Rendering vorgesehen 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 untersuchen, 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).
  • Lassen Sie Renderingknoten in Load-Balancing-Regeln weg, damit sie Endnutzer-Traffic und interne API-Anfragen nicht verarbeiten.
  • Weisen Sie Java in den Rendering-Knoten relativ weniger Arbeitsspeicher zu, damit die Prozesse von Chromium einen größeren Zwischenspeicher haben. Weisen Sie Java nicht 60% des Arbeitsspeichers zu, sondern 40–50%.
  • Das Risiko einer Speicherauslastung wurde auf den Nicht-Rendering-Knoten reduziert, sodass der für Looker vorgesehene Arbeitsspeicher 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.