Architekturmuster für vom Kunden gehostete Infrastrukturen

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

Workflowstrategie

Nachdem Sie das Self-Hosting als praktikable Option für die Implementierung von Looker identifiziert haben, müssen Sie als Nächstes die Strategie ausarbeiten, die von der Bereitstellung unterstützt werden soll.

  1. Bewertung durchführen. Erstellen Sie eine Liste mit geplanten und vorhandenen Workflows.
  2. Anwendbare Architekturmuster auflisten. Identifizieren Sie anhand der ermittelten Kandidaten-Workflows anwendbare Architekturmuster.
  3. Optimales Architekturmuster priorisieren und auswählen. Richten Sie das Architekturmuster an den wichtigsten Aufgaben und Ergebnissen aus.
  4. Architekturkomponenten konfigurieren und die Looker-Anwendung bereitstellen. Implementieren Sie den Host, Drittanbieterabhängigkeiten und die Netzwerktopologie, die zum Herstellen sicherer Clientverbindungen erforderlich sind.

Architekturoptionen

Dedizierte virtuelle Maschine

Eine Option besteht darin, Looker als einzelne Instanz auf einer dedizierten virtuellen Maschine (VM) auszuführen. Eine einzelne Instanz kann anspruchsvolle Arbeitslasten verarbeiten, indem der Host vertikal skaliert und die Standard-Threadpools erhöht werden. Der Verarbeitungsaufwand für die Verwaltung eines großen Java-Heaps unterliegt jedoch dem Gesetz des abnehmenden Grenzertrags. Im Allgemeinen ist dies für kleine bis mittelgroße Arbeitslasten akzeptabel. Das folgende Diagramm zeigt die Standard- und optionalen Setups 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 Setups zwischen Looker, das auf einer dedizierten VM mit lokalen und Remote-Repositories, SMTP-Servern und Datenquellen ausgeführt wird, darstellt.

Vorteile

  • Eine dedizierte VM lässt sich einfach bereitstellen und 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 für E-Mail-Benachrichtigungen und geplante Aufgaben ersetzen.

Best Practices

  • Standardmäßig kann Looker Bare-Git-Repositories für ein Projekt generieren. Wir empfehlen, ein Remote-Git-Repository für die Redundanz einzurichten.
  • Standardmäßig startet Looker mit einer speicherresidenten HyperSQL-Datenbank. Diese Datenbank ist praktisch und ressourcenschonend, kann aber bei starker Nutzung Leistungsprobleme verursachen. Für größere Bereitstellungen empfehlen wir die Verwendung einer MySQL-Datenbank. Wir empfehlen die Migration zu einer Remote-MySQL-Datenbank, sobald die Datei ~/looker/.db/looker.script 600 MB erreicht.
  • Ihre Looker-Bereitstellung muss mit dem Looker-Lizenzierungsdienst validiert werden. Ausgehender Traffic an Port 443 ist erforderlich.
  • Eine dedizierte VM-Bereitstellung kann vertikal skaliert werden, indem die verfügbaren Ressourcen und Looker-Threadpools erhöht werden. Das Erhöhen des RAM unterliegt jedoch dem Gesetz des abnehmenden Grenzertrags, sobald es 64 GB erreicht, da automatische Speicherbereinigungsereignisse Single-Threaded sind und alle anderen Threads anhalten, um ausgeführt zu werden. Knoten mit 16 CPUs und 64 GB RAM bieten ein gutes Preis-Leistungs-Verhältnis.
  • Wir empfehlen, dass Ihre Bereitstellung Speicher mit 2 Vorgängen pro Sekunde (IOPS) pro GB hat.

Cluster von VMs

Looker als Cluster von Instanzen auf mehreren VMs auszuführen ist ein flexibles Muster, das von Service-Failover und Redundanz profitiert. Die horizontale Skalierbarkeit ermöglicht einen höheren Durchsatz, ohne dass es zu Heap-Bloat und übermäßigen Kosten für die automatische Speicherbereinigung kommt. Knoten können für Arbeitslasten dediziert werden, wodurch mehrere Bereitstellungsoptionen an unterschiedliche geschäftliche Anforderungen 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 reicht ein Cluster identischer Dienstknoten aus. Alle Knoten im Cluster sind gleich konfiguriert und befinden sich im selben Load-Balancer-Pool. Keiner der Knoten in dieser Konfiguration ist mehr oder weniger wahrscheinlich, Looker-Nutzeranfragen, Rendering-Aufgaben, geplante Aufgaben, API-Anfragen usw. zu verarbeiten.

Diese Art der Konfiguration ist geeignet, wenn die meisten Anfragen direkt von einem Looker-Nutzer stammen, der Abfragen ausführt und mit Looker interagiert. Sie funktioniert nicht mehr, wenn eine große Anzahl von Anfragen von einem Planer, einem Renderer oder einer anderen Quelle stammt. In diesem Fall ist es von Vorteil, bestimmte Dienstknoten für Aufgaben wie Zeitpläne und Rendering zu verwenden.

Nutzer planen beispielsweise häufig Datenlieferungen für Montagmorgen. Ein Nutzer, der am Montagmorgen Looker-Abfragen ausführen möchte, kann Leistungsprobleme haben, während Looker den Rückstand an geplanten Anfragen verarbeitet. Durch Erhöhen der Anzahl der Dienstknoten bietet der Cluster eine proportionale Steigerung des Durchsatzes für alle Looker-Funktionen.

Das folgende Diagramm zeigt, wie Anfragen an Looker, die von Nutzern, Apps und Skripts gestellt werden, auf eine Cluster-Looker-Instanz verteilt werden.

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

Vorteile

  • Ein Standard-Cluster maximiert den allgemeinen Durchsatz bei minimaler Konfiguration der Clustertopologie.
  • Die Java-VM weist eine Leistungsverschlechterung bei der zugewiesenen Arbeitsspeichergrenze von 64 GB auf. 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 dedizierten VM gehostet werden.
  • Der Load-Balancer, der der Eingangspunkt des Clusters ist, sollte ein Layer-4-Load-Balancer sein. Er sollte ein langes Zeitlimit (3.600 Sekunden) haben,mit einem signierten SSL-Zertifikat ausgestattet sein und so konfiguriert sein, dass er Port 443 (https) zu Port 9999 (Port, auf dem der Looker-Server lauscht) weiterleitet.
  • Wir empfehlen, dass Ihre Bereitstellung 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 Priorität hat, empfehlen wir separate Looker-Umgebungen, um die Entwicklungs- und Analysearbeit zu trennen. Durch das Beschränken von Änderungen an der Produktionsumgebung auf isolierte Entwicklungs- und Testumgebungen wird mit dieser Architektur eine möglichst stabile Produktionsumgebung aufrechterhalten.

Diese Vorteile erfordern die Einrichtung der miteinander verbundenen Umgebungen und die Einführung eines robusten Release-Zyklus. Für eine Bereitstellung mit Entwicklung/Staging/Produktion ist außerdem ein Team von Entwicklern erforderlich, die mit der Looker API und Git für die Workflowverwaltung vertraut sind.

Das folgende Diagramm zeigt den Fluss von Inhalten zwischen LookML-Entwicklern, die Inhalte in der Entwicklungsumgebung erstellen, Qualitätssicherungstestern, die die Inhalte in der Qualitätssicherungsumgebung testen, und Nutzern, Apps und Skripts, die die Inhalte in der Produktionsumgebung verwenden.

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. So können alle Änderungen an der Modelllogik gründlich geprüft werden, bevor sie Produktionsnutzer erreichen.
  • Instanzweite Funktionen wie Preview-Funktionen oder Authentifizierungsprotokolle können isoliert getestet werden, bevor sie in der Produktionsumgebung aktiviert werden.
  • Datengruppen- und Caching-Richtlinien können in einer Nicht-Produktionsumgebung getestet werden.
  • Das Testen des Looker-Produktionsmodus ist von Produktionsumgebungen entkoppelt, die für die Bereitstellung für Endnutzer verantwortlich sind.
  • Looker-Releases können in einer Nicht-Produktionsumgebung getestet werden. So haben Sie ausreichend Zeit, neue Funktionen, Workflowänderungen und Probleme zu testen, bevor Sie die Produktionsumgebung aktualisieren.

Best Practices

  • Isolieren Sie die verschiedenen Aktivitäten, die gleichzeitig stattfinden, in mindestens drei separaten Instanzen:
    • Entwicklungsinstanz: Entwickler verwenden die Entwicklungsumgebung, um Code zu committen, Experimente durchzuführen, Fehler zu beheben und gefahrlos Fehler zu machen.
    • Qualitätssicherungsinstanz: Diese wird auch als Test- oder Staging-Umgebung bezeichnet. Hier führen Entwickler manuelle und automatisierte Tests durch. Die Qualitätssicherungsumgebung ist komplex und kann viele Ressourcen verbrauchen.
    • Produktionsinstanz: Hier wird Wert für Kunden und/oder das Unternehmen geschaffen. Die Produktion ist eine gut sichtbare Umgebung und sollte fehlerfrei sein.
  • Pflegen Sie einen dokumentierten, wiederholbaren Workflow für den Release-Zyklus.
  • Wenn eine große Anzahl von Entwicklern und Qualitätssicherungstestern bedient werden muss, können die Entwicklungs- und/oder Qualitätssicherungsinstanzen gruppiert werden. Unabhängig davon, ob es sich um eine eigenständige VM oder einen Cluster von VMs handelt, unterliegen die Entwicklungs- und Qualitätssicherungsinstanzen denselben architektonischen Überlegungen, die zuvor in den jeweiligen Abschnitten beschrieben wurden.

Hoher Durchsatz bei der Planung

Für Anwendungsfälle, die einen hohen Durchsatz bei der geplanten Datenlieferung und zeitnahe, zuverlässige Lieferungen erfordern, empfehlen wir, dass die Konfiguration einen Cluster mit einem Pool von Knoten enthält, die ausschließlich für die Planung vorgesehen sind. Diese Konfiguration trägt dazu bei, dass die Web- und eingebetteten Anwendungen schnell und reaktionsschnell bleiben. Diese Vorteile erfordern die Einrichtung von Knoten mit benutzerdefinierten Startoptionen und geeigneten Load-Balancing-Regeln, 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 Dedizierung von Knoten für eine bestimmte Funktion 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 verwenden, die für die Bereitstellung geplanter Datenlieferungen zuständig sind.
  • Hoher Nutzertraffic, der an die regulären Knoten weitergeleitet wird, beeinträchtigt nicht die geplanten Arbeitslasten, die von den Planungsknoten verarbeitet werden.

Best Practices

  • Jeder Looker-Knoten sollte auf einer eigenen dedizierten VM gehostet werden.
  • Der Load-Balancer, der der Eingangspunkt des Clusters ist, sollte ein Layer-4-Load-Balancer sein. Er sollte ein langes Zeitlimit (3.600 Sekunden) haben,mit einem signierten SSL-Zertifikat ausgestattet sein und so konfiguriert sein, dass er Port 443 (https) zu Port 9999 (Port, auf dem der Looker-Server lauscht) weiterleitet.
  • Schließen Sie Planungsknoten aus Load-Balancing-Regeln aus, damit sie keinen Endnutzertraffic und keine internen API-Anfragen verarbeiten.
  • Wir empfehlen, dass Ihre Bereitstellung Speicher mit 2 IOPS pro GB hat.

Hoher Durchsatz beim Rendering

Für Anwendungsfälle, die einen hohen Durchsatz beim Rendering von Berichten erfordern, empfehlen wir, einen Cluster mit einem Pool von Knoten zu konfigurieren, 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 Rendering kann speicher- und CPU-intensiv sein. Wenn Linux unter Speicherdruck steht, kann es einen laufenden Prozess beenden. Da die Arbeitsspeichernutzung eines Rendering-Jobs nicht im Voraus bestimmt werden kann, kann das Starten eines Rendering-Jobs dazu führen, dass der Looker-Prozess beendet wird. Durch die Konfiguration dedizierter Rendering-Knoten können Rendering-Jobs optimal abgestimmt werden, während 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 folgenden Diagramm dargestellt und in den Abschnitten Vorteile und Best Practices für diese Option beschrieben. Außerdem benötigen Rendering-Knoten möglicherweise mehr Hostressourcen als Standardknoten, da der Rendering-Dienst von Looker von Chromium-Prozessen von Drittanbietern abhängt, die sich CPU-Zeit und Arbeitsspeicher teilen.

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

Vorteile

  • Durch die Dedizierung von Knoten für eine bestimmte Funktion werden Ressourcen für das Rendering von Entwicklungs- und Ad-hoc-Analysefunktionen getrennt.
  • Nutzer können LookML entwickeln und Inhalte untersuchen, ohne Zyklen von Knoten zu verwenden, die für das Rendern von PNGs und PDFs zuständig sind.
  • Hoher Nutzertraffic, der an die regulären Knoten weitergeleitet wird, beeinträchtigt nicht die Rendering-Arbeitslasten, die von den Rendering-Knoten verarbeitet werden.

Best Practices

  • Jeder Looker-Knoten sollte auf einer eigenen dedizierten VM gehostet werden.
  • Der Load-Balancer, der der Eingangspunkt des Clusters ist, sollte ein Layer-4-Load-Balancer sein. Er sollte ein langes Zeitlimit (3.600 Sekunden) haben,mit einem signierten SSL-Zertifikat ausgestattet sein und so konfiguriert sein, dass er Port 443 (https) zu Port 9999 (Port, auf dem der Looker-Server lauscht) weiterleitet.
  • Schließen Sie Rendering-Knoten aus Load-Balancing-Regeln aus, damit sie keinen Endnutzertraffic und keine internen API-Anfragen verarbeiten.
  • Weisen Sie Java auf den Rendering-Knoten relativ weniger Arbeitsspeicher zu, um den Prozessen von Chromium einen größeren Arbeitsspeicherpuffer zu geben. Weisen Sie Java nicht 60 %, sondern 40–50 % des Arbeitsspeichers zu.
  • Das Risiko von Speicherdruck wurde auf den Nicht-Rendering-Knoten verringert, sodass die Menge des für Looker reservierten Arbeitsspeichers erhöht werden kann. Erwägen Sie anstelle der Standardeinstellung von 60 % einen höheren Wert wie 80%.
  • Wir empfehlen, dass Ihre Bereitstellung Speicher mit 2 IOPS pro GB hat.