Zuverlässige Aufgabenplanung in Compute Engine mit Cloud Scheduler

In verteilten Systemen, beispielsweise einem Netzwerk von Compute Engine-Instanzen, ist es schwierig, Aufgaben zuverlässig zu planen, da es jederzeit passieren kann, dass Instanzen aufgrund von Autoscaling oder einer Netzwerkpartitionierung nicht mehr verfügbar sind.

Wenn Sie Cloud Scheduler für die Planung und Pub/Sub für verteilte Nachrichten nutzen, können Sie eine entsprechende Anwendung für die zuverlässige Zeitplanung von Aufgaben auf einer Reihe von Compute Engine-Instanzen erstellen. Wenn Sie komplexe Workflows für andere Produkte oder Clouds planen und orchestrieren müssen, sollten Sie es in Betracht ziehen, stattdessen Cloud Composer zu verwenden.

Dieser dreiteilige Artikel umfasst:

Aufgaben zuverlässig in Compute Engine planen

Bei Cron handelt es sich um ein Standard-Tool für das Planen wiederkehrender Aufgaben auf Unix-Systemen. Wenn die von Ihnen erstellten Systeme an Komplexität zunehmen und verteilt werden, kann ein einzelner Cron ausführender Computer zu einem kritischen Ausfallpunkt werden. Die Instanz wird möglicherweise aufgrund einer automatischen Skalierung gestoppt oder deren Netzwerksegment wird von den Systemen, mit denen es kommunizieren muss, partitioniert.

Cloud Scheduler bietet einen vollständig verwalteten Dienst für Unternehmen, mit dem Sie Ereignisse planen können. Nachdem Sie einen Job geplant haben, ruft Cloud Scheduler die konfigurierten Event-Handler auf, bei denen es sich um App Engine-Dienste, HTTP-Endpunkte oder Pub/Sub-Abos handeln kann.

Wenn auf Ihrer Compute Engine-Instanz Aufgaben als Reaktion auf Cloud Scheduler-Ereignisse ausgeführt werden sollen, müssen Sie die Ereignisse an diese Instanzen weiterleiten. Dies ist beispielsweise durch das Aufrufen eines HTTP-Endpunkts möglich, der auf den Compute Engine-Instanzen ausgeführt wird. Oder Sie können mit Pub/Sub Nachrichten von Cloud Scheduler an die Compute Engine-Instanzen weiterleiten. Letzteres wird in diesem Beispiel erläutert.

Hier sehen Sie eine allgemeine Übersicht der entsprechenden Architektur:

Architektur-Übersichtsdiagramm

Bei dieser Implementierung planen Sie Ereignisse in Cloud Scheduler und übertragen sie dann mithilfe von Pub/Sub an Compute Engine-Instanzen.

Ein Dienstprogramm auf Ihren Compute Engine-Instanzen abonniert Pub/Sub-Themen und führt als Reaktion auf Ereignisse, die es aus diesen Themen zieht, Cronjobs aus. Das Dienstprogramm führt Standardskripte aus; Sie müssen Ihre aktuellen Cron-Skripte nicht verändern, um sie in diesem Beispiel zu verwenden.

Wenn Sie mit Pub/Sub die Aufgabenplanungslogik von der Logik entkoppeln, die die Befehle in Compute Engine ausführt, können Sie Ihre Cron-Skripts nach Bedarf aktualisieren, ohne die Cloud Scheduler-Konfiguration zu aktualisieren. Außerdem können Sie Ihre Aufgabenplanung ändern, ohne das Dienstprogramm auf den Compute Engine-Instanzen zu aktualisieren.

Kontingente

Da es in der Regel nur wenige Cronjobs gibt und diese nach einem stündlichen, wöchentlichen oder täglichen Zeitplan ausgeführt werden, sollten bei diesem Designmuster die Cloud Scheduler-Kontingente nicht überschritten werden, die zehn Anfragen pro Minute und Tausende pro Tag zulassen. Wenn dies der Fall ist, sollten Sie andere Anwendungsmuster in Betracht ziehen, wie etwa die Verwaltung der Zeitplanung für die Aufgaben direkt im Anwendungscode.

Kosten

Sie können die Beispielimplementierung dieses Designmusters mit der kostenlosen Google Cloud-Stufe ausprobieren, wenn Sie die darin enthaltenen Ressourcen nicht für andere Anwendungen verwenden. Wenn Ihre kostenlosen Kontingente bereits von anderen Anwendungen in Ihrem Projekt aufgebraucht wurden, leiten sich die Kosten aus der Gesamtnutzung von Compute Engine-, Cloud Scheduler- und Pub/Sub-Ressourcen ab.

Die Preise für Cloud Scheduler basieren auf der Anzahl der geplanten Jobs. Die Preise für Compute Engine basieren auf dem Typ der verwendeten Instanzen und deren Nutzungsdauer. Die Preise für Pub/Sub errechnen sich aus dem gesendeten Datenvolumen.

Beispiel: Wenn Sie eine Beispielimplementierung im folgenden Abschnitt eine Stunde lang ausführen und dann die Google Cloud-Ressourcen löschen, betragen die Kosten etwa 1 Cent. Eine Aufschlüsselung der Kosten in dieser Schätzung finden Sie im Preisrechner. Dieser ermöglicht auch eine Berechnung der Kosten für Ihren persönlichen Fall.

Beispielimplementierung des Designmusters

Eine Beispielimplementierung dieses Designmusters, Beispiel: Zuverlässige Aufgabenplanung in Compute Engine, ist auf GitHub verfügbar.

Das Beispiel besteht aus zwei Teilen:

  • einer Anleitung zum Konfigurieren von Cloud Scheduler und Pub/Sub sowie

  • einem Dienstprogramm, das auf Compute Engine ausgeführt wird. Dieses Dienstprogramm überwacht ein Pub/Sub-Thema. Wenn es eine neue Nachricht erkennt, wird der entsprechende Befehl lokal auf dem Server ausgeführt.

In der enthaltenen Readme-Datei wird das Beispiel ausführlicher beschrieben und auch erläutert, wie Sie den Beispielcode auf Google Cloud ausführen.

Erweiterungen des Designmusters und Beispiels

Das Beispiel zeigt eine Möglichkeit, mithilfe von Cloud Scheduler eine zuverlässige Planungslösung für Compute Engine zu implementieren. Dies ist ein nützliches Designmuster, da es die Planungslogik von der Logik trennt, die Befehle auf der Compute Engine-Instanz ausführt und so das Ändern des Speicherortes und die Ausführung Ihrer Aufgaben ohne notwendige Aktualisierung der Planungslogik ermöglicht.

Die folgende Grafik zeigt den Fluss von Nachrichten in diesem Beispiel. Durch Angabe, welche Instanzen ein bestimmtes Thema abonnieren, können Sie kontrollieren, ob ein Cronjob auf einer einzelnen Instanz oder auf mehreren Instanzen ausgeführt wird.

Detailliertes Architekturdiagramm

Ein weiterer Vorteil dieser Architektur besteht in der Kontrolle, die Sie darüber erhalten, wie Cronjobs zu Ihren Instanzen geführt werden.

Sie können verschiedene Cron-Nachrichten an verschiedene Servergruppen senden, wie anhand der Pub/Sub-Themen A und C dargestellt. Die Aufgaben im Thema A werden an einen einzelnen Abonnenten geschickt, wohingegen mehrere Server das Thema C abonnieren. Mit dieser Strategie können Sie einen Satz Befehle auf Ihrem Webserver und einen anderen auf Ihren anderen Servern ausführen.

Eine weitere Option ist, einen Befehl auf einem von mehreren Servern auszuführen. Dies wird durch Thema B veranschaulicht. In diesem Fall teilen sich mehrere Server ein einzelnes Abo. In Thema B veröffentlichte Nachrichten werden vom ersten Server verarbeitet, um sicherzustellen, dass diese Nachricht und der entsprechende Befehl nur auf diesem Server ausgeführt werden. Sie können mit diesem Ansatz eine nächtliche Datenanalyse vornehmen, die nur auf einem einzigen Server ausgeführt werden muss.

Weitere Informationen

Sie haben die Möglichkeit das Beispiel zu verändern und es als Modell für Ihre eigene Anwendung zu verwenden. Hier finden Sie einige Ideen für den Anfang:

  • Aktualisieren Sie die Cloud Scheduler-Konfiguration, um Ihre eigenen Cron-Nachrichten anzugeben. Sie können den Cronjob direkt aktualisieren, wie unter Cronjobs erstellen und konfigurieren beschrieben.

  • Ändern Sie test_executor.py, damit anstelle von logger_sample_task.py ein echtes Skript ausgeführt wird, oder schreiben Sie Ihr eigenes Executor-Dienstprogramm.

  • Statt das Dienstprogramm manuell in Compute Engine zu starten und als Vordergrundprozess auszuführen, können Sie es mit einem System- oder Drittanbietertool wie systemd oder Supervisor automatisch als Daemon starten.

  • Weder für Cloud Scheduler noch für Pub/Sub kann garantiert werden, dass es zu "genau einer" Zustellung kommt. In unwahrscheinlichen Fällen können Nachrichten zweimal zugestellt werden. Wenn das Ausführen einer bestimmten Aufgabe mehr als einmal zu einem unerwünschten Ergebnis führt, sollten Sie ein verteiltes, konsistentes Sperrtool wie Zookeeper verwenden, um sicherzustellen, dass die Aufgabe nur einmal und nur von einer Instanz ausgeführt wird.

  • Befolgen Sie bei der Planung von Aufgaben die Best Practices von Cron und prüfen Sie, ob Aufgaben weit genug auseinander geplant werden, damit die Verarbeitung vor der nächsten Ausführung abgeschlossen wird.

  • Überlegen Sie, ob für alle Aufgaben die Ausführung von Compute Engine-Instanzen erforderlich ist. Eine Alternative besteht darin, als Antwort auf Pub/Sub-Nachrichten Cloud Functions-Funktionen auszulösen. Cloud Functions-Funktionen können Cloud APIs aufrufen, aber keine Shell-Skripts direkt ausführen. Wenn Sie Shell-Skripts ausführen müssen, können Sie die Compute Engine API aufrufen, um temporäre Compute Engine-Instanzen zum Ausführen von Skripts zu erstellen. Diese Instanzen können sich selbst herunterfahren, wenn die Aufgaben abgeschlossen sind. Dies gibt Ihnen die Flexibilität, Aufgaben schon bald nach der Ereigniszeit zu minimalen Kosten abzuschließen.

Weitere Google Cloud Platform-Funktionen mit unseren Anleitungen testen