Autoscaling-Tool in Cloud Run-Funktionen bereitstellen

Das Autoscaling-Tool ist für Flexibilität ausgelegt und kann die bestehende Trennung der Aufgabenbereiche der Betriebs- und Anwendungsteams berücksichtigen. Die Verantwortung für die Konfiguration des Autoscalings von Spanner-Instanzen kann zentralisiert mit einem einzelnen Betriebsteam sein oder es kann an die Teams weiter verteilt werden, die den Anwendungen zugeordnet sind, die von diesen Spanner-Instanzen bereitgestellt werden.

Dieses Dokument ist Teil einer Reihe, die folgende Themen behandelt:

Diese Reihe richtet sich an IT-, Betriebs- und Site Reliability Engineering-Teams (SRE), die den operativen Aufwand reduzieren und die Kosten der Spanner-Bereitstellungen optimieren möchten.

Auf dieser Seite werden drei Möglichkeiten vorgestellt, wie Sie den Autoscaler je nach Ihren Anforderungen in Cloud Run-Funktionen bereitstellen können:

  • Eine projektspezifische Bereitstellungstopologie. Die Autoscaling-Infrastruktur wird im selben Projekt wie Spanner bereitgestellt, das automatisch skaliert werden muss. Diese Topologie wird für unabhängige Teams empfohlen, die ihre eigene Autoscaling-Konfiguration und -Infrastruktur verwalten möchten. Eine projektspezifische Bereitstellungstopologie ist auch ein guter Ausgangspunkt zum Testen der Funktionen des Autoscalings.
  • Eine zentralisierte Bereitstellungstopologie. Das Autoscaling-Tool wird in einem Projekt bereitgestellt und verwaltet eine oder mehrere Spanner-Instanzen in verschiedenen Projekten. Diese Topologie wird für Teams empfohlen, die die Konfiguration und Infrastruktur einer oder mehrerer Spanner-Instanzen verwalten und gleichzeitig die Komponenten und die Konfiguration für Autoscaling an einem zentralen Ort aufbewahren. In der zentralisierten Topologie richten Sie zusätzlich zu einem Autoscaling-Projekt ein zweites Projekt ein, das in dieser Anleitung als Anwendungsprojekt bezeichnet wird. Das Anwendungsprojekt enthält die Anwendungsressourcen, einschließlich Spanner.
  • Eine verteilte Bereitstellungstopologie Der Großteil der Autoscaling-Infrastruktur wird in einem Projekt bereitgestellt. Bei einigen Infrastrukturkomponenten werden die Spanner-Instanzen jedoch in verschiedenen Projekten automatisch skaliert. Diese Topologie wird für Organisationen mit mehreren Teams empfohlen, bei denen die Teams, die die Spanner-Instanzen verwalten, nur die Autoscaling-Konfigurationsparameter für ihre Instanzen verwalten möchten, die restliche Autoscaling-Infrastruktur jedoch von einem zentralen Team verwaltet wird.

Serverlose Bereitstellung und einfache Verwaltung

In diesem Modell wird das Autoscaling-Tool nur mit serverlosen und verwaltungsarmen Google Cloud Tools wie Cloud Run-Funktionen, Pub/Sub, Cloud Scheduler und Firestore erstellt. Mit diesem Ansatz werden die Kosten und der operative Aufwand für die Ausführung des Autoscaling-Tools minimiert.

Mithilfe der integrierten Google Cloud Tools kann das Autoscaling IAM für die Authentifizierung und Autorisierung in vollem Umfang nutzen.

Konfiguration

Das Autoscaling-Tool verwaltet Spanner-Instanzen über die in Cloud Scheduler definierte Konfiguration. Wenn mehrere Spanner-Instanzen mit demselben Intervall abgefragt werden müssen, empfehlen wir Ihnen, diese im selben Cloud Scheduler-Job zu konfigurieren. Die Konfiguration der einzelnen Instanzen wird als JSON-Objekt dargestellt. Das folgende Beispiel zeigt eine Konfiguration, bei der zwei Spanner-Instanzen mit einem einzigen Cloud Scheduler-Job verwaltet werden:

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

Spanner-Instanzen können mehrere Konfigurationen für verschiedene Cloud Scheduler-Jobs haben. Eine Instanz kann beispielsweise eine Autoscaling-Konfiguration mit der linearen Methode für normale Vorgänge haben, aber auch eine weitere Autoscaling-Konfiguration mit der direkten Methode für geplante Batcharbeitslasten.

Wenn der Cloud Scheduler-Job ausgeführt wird, sendet er eine Pub/Sub-Nachricht an das Abfrage-Pub/Sub-Thema. Die Nutzlast dieser Nachricht ist das JSON-Array der Konfigurationsobjekte für alle Instanzen, die im selben Job konfiguriert wurden. Eine vollständige Liste der Konfigurationsoptionen finden Sie in der Poller-README-Datei.

Projektspezifische Topologie

In einer projektspezifischen Topologiebereitstellung hat jedes Projekt mit einer Spanner-Instanz, die automatisch skaliert werden muss, eine eigene unabhängige Bereitstellung der Autoscaling-Komponenten. Diese Topologie wird für unabhängige Teams empfohlen, die ihre eigene Autoscaling-Konfiguration und -Infrastruktur verwalten möchten. Es ist auch ein guter Ausgangspunkt für das Testen der Funktionen des Autoscaling-Tools.

Das folgende Diagramm zeigt eine allgemeine konzeptionelle Ansicht einer projektspezifischen Bereitstellung.

Konzeptionelle projektspezifische Bereitstellung.

Die im vorherigen Diagramm dargestellten projektspezifischen Bereitstellungen haben folgende Eigenschaften:

  • Zwei Anwendungen (Anwendung 1 und Anwendung 2) verwenden jeweils ihre eigenen Spanner-Instanzen.
  • Spanner-Instanzen (A) befinden sich in den Projekten der Anwendungen 1 und 2.
  • In jedem Projekt wird ein unabhängiges Autoscaling (B) bereitgestellt, um das Autoscaling der Instanzen in einem Projekt zu steuern.

Die projektspezifische Bereitstellung hat folgende Vor- und Nachteile.

Vorteile:

  • Einfachstes Design: Die Topologie pro Projekt ist das einfachste Design der drei Topologien, da alle Autoscaling-Komponenten zusammen mit den Spanner-Instanzen bereitgestellt werden, die automatisch skaliert werden.
  • Konfiguration: Die Kontrolle über Scheduler-Parameter gehört dem Team, das die Spanner-Instanz besitzt. Das Team kann somit mehr Anpassungsmöglichkeiten für das Autoscaling-Tool haben als an einem zentralisierten oder verteilten Topologie.
  • Klare Grenze der Infrastrukturverantwortliche: Das Design einer projektbezogenen Topologie bildet eine klare Verantwortlichkeit und Sicherheit für die Autoscaling-Infrastruktur, da der Teaminhaber der Spanner-Instanzen auch der Besitzer der Autoscaling-Infrastruktur ist.

Nachteile:

  • Mehr Wartung insgesamt: Jedes Team ist für die Konfiguration und Infrastruktur des Autoscalings verantwortlich. Daher kann es schwierig sein, sicherzustellen, dass alle Autoscaling-Tools im gesamten Unternehmen den gleichen Aktualisierungsrichtlinien folgen.
  • Komplexere Prüfung: Da jedes Team eine hohe Kontrolle hat, kann ein zentralisiertes Audit komplexer werden.

Informationen zum Einrichten des Autoscalings mit einer projektspezifischen Topologie finden Sie in der Schritt-für-Schritt-Anleitung zur projektspezifischen Bereitstellung.

Zentralisierte Topologie

Wie bei der projektspezifischen Topologie befinden sich in einer zentralisierten Topologiebereitstellung alle Komponenten des Autoscaling-Tools im selben Projekt. Die Spanner-Instanzen befinden sich jedoch in verschiedenen Projekten. Diese Bereitstellung eignet sich für ein Team, das die Konfiguration und Infrastruktur mehrerer Spanner-Instanzen über eine einzige Bereitstellung des Autoscaling-Tools an einem zentralen Ort verwaltet.

Das folgende Diagramm zeigt eine allgemeine konzeptionelle Ansicht einer Bereitstellung mit zentralisiertem Projekt:

Konzeptionelle Bereitstellung mit zentralisiertem Projekt.

Die im vorherigen Diagramm dargestellte zentralisierte Bereitstellung hat folgende Eigenschaften:

  • Zwei Anwendungen (Anwendung 1 und Anwendung 2) verwenden jeweils ihre eigenen Spanner-Instanzen.
  • Spanner-Instanzen (A) befinden sich in den Projekten der Anwendungen 1 und 2.
  • Autoscaling (B) wird in einem separaten Projekt bereitgestellt, um das Autoscaling der Spanner-Instanzen sowohl in den Projekten der Anwendung 1 als auch der Anwendung 2 zu steuern.

Eine zentralisierte Bereitstellung hat folgende Vor- und Nachteile.

Vorteile:

  • Zentrale Konfiguration und Infrastruktur: Ein einziges Team steuert die Planerparameter und die Autoscaling-Infrastruktur. Dieser Ansatz kann in stark regulierten Branchen nützlich sein.
  • Weniger Wartung insgesamt: Wartungen und Einrichtungsaufwand haben im Vergleich zu einer Pro-Projekt-Bereitstellung meist weniger Aufwand.
  • Zentrale Richtlinien und Audits: Die Best Practices zwischen den Teams können möglicherweise leichter angegeben und umgesetzt werden. Audits können einfacher ausgeführt werden.

Nachteile:

  • Zentrale Konfiguration: Änderungen an den Autoscaling-Parametern müssen über das zentralisierte Team erfolgen, obwohl das Team, das die Änderung anfordert, zu der Spanner-Instanz gehört.
  • Potenzial für zusätzliche Risiken: Das zentralisierte Team selbst kann zu einem Single Point of Failure werden, auch wenn die Autoscaling-Infrastruktur im Hinblick auf Hochverfügbarkeit konzipiert ist.

Informationen zum Einrichten des Autoscalings mit einer zentralen Topologie finden Sie in der Schritt-für-Schritt-Anleitung zur zentralen Bereitstellung.

Verteilte Topologie

Bei einer Bereitstellung mit verteilter Topologie befinden sich die Cloud Scheduler- und Spanner-Instanzen, die automatisch skaliert werden müssen, im selben Projekt. Die verbleibenden Komponenten des Autoscaling-Tools befinden sich in einem zentral verwalteten Projekt. Diese Bereitstellung ist eine Hybridbereitstellung. Teams, die die Spanner-Instanzen besitzen, verwalten nur die Autoscaling-Konfigurationsparameter für ihre Instanzen und ein zentrales Team verwaltet die verbleibende Autoscaling-Infrastruktur.

Das folgende Diagramm zeigt eine allgemeine konzeptionelle Ansicht einer Bereitstellung mit verteiltem Projekt.

Konzeptionelle Bereitstellung mit verteiltem Projekt.

Die im vorherigen Diagramm dargestellte Hybridbereitstellung hat folgende Eigenschaften:

  • Zwei Anwendungen (Anwendung 1 und Anwendung 2) verwenden ihre eigenen Spanner-Instanzen.
  • Die Spanner-Instanzen (A) befinden sich in den Projekten der Anwendungen 1 und 2.
  • In jedem Projekt wird eine unabhängige Cloud Scheduler-Komponente (C) bereitgestellt: Anwendung 1 und Anwendung 2.
  • Die verbleibenden Autoscaling-Komponenten (B) werden in einem separaten Projekt bereitgestellt.
  • Mit dem Autoscaling-Tool werden die Spanner-Instanzen sowohl in Projekten der Anwendung 1 als auch der Anwendung 2 automatisch mithilfe der Konfigurationen skaliert, die von den unabhängigen Cloud Scheduler-Komponenten in jedem Projekt gesendet werden.

Forwarder-Funktion

Cloud Scheduler kann nur Nachrichten zu Themen im selben Projekt veröffentlichen. Für die verteilte Topologie ist daher eine Zwischenkomponente namens Forwarder-Funktion erforderlich.

Die Forwarder-Funktion übernimmt Nachrichten, die von Cloud Scheduler in Pub/Sub veröffentlicht wurden, überprüft ihre JSON-Syntax und leitet sie an das Poller-Pub/Sub-Thema weiter. Das Thema kann zu einem separaten Projekt für Cloud Scheduler gehören.

Das folgende Diagramm zeigt die Komponenten, die für den Weiterleitungsmechanismus verwendet werden:

Weiterleitungsmechanismus

Wie im vorherigen Diagramm gezeigt, befinden sich die Spanner-Instanzen in Projekten mit den Namen Anwendung 1 und Anwendung 2:

  1. Cloud Scheduler ist das gleiche Projekt wie die Spanner-Instanzen.
  2. (2a) Cloud Scheduler veröffentlicht seine Nachrichten im Forwarder-Thema in den Projekten "Anwendung 1" und "Anwendung 2".

    (2b) Die Forwarder-Funktion liest Nachrichten aus dem Forwarder-Thema.

    (2c) Die Forwarder-Funktion leitet Nachrichten an das Abfragethema im Autoscaling-Projekt weiter.

  3. Die Poller-Funktion liest die Nachrichten aus dem Abfragethema und der Prozess wird wie unter Poller beschrieben ausgeführt.

Eine verteilte Bereitstellung hat die folgenden Vorteile und Nachteile.

Vorteile:

  • Anwendungsteams steuern die Konfiguration und die Zeitpläne: Cloud Scheduler wird zusammen mit den Spanner-Instanzen bereitgestellt, die automatisch skaliert werden. Damit erhalten Anwendungsteams mehr Kontrolle über Konfiguration und Planung.
  • Betriebsteam steuert die Infrastruktur: Die Kernkomponenten des Autoscaling-Tools werden zentral bereitgestellt. Dadurch erhalten die Betriebsteams die Kontrolle über die Autoscaling-Infrastruktur.
  • Zentrale Wartung: Die Infrastruktur ist komplex und reduziert den Aufwand.

Nachteile:

  • Komplexere Konfiguration: Anwendungsteams müssen Dienstkonten bereitstellen, um in das Abfragethema schreiben zu können.
  • Potenzial für zusätzliche Risiken: Die gemeinsam genutzte Infrastruktur kann zu einem Single Point of Failure werden, auch wenn die Infrastruktur im Hinblick auf Hochverfügbarkeit konzipiert ist.

Informationen zum Einrichten des Autoscalings mit einer verteilten Topologie finden Sie in der Schritt-für-Schritt-Anleitung zur verteilten Bereitstellung.

Nächste Schritte