Tipps und Tricks
In diesem Dokument werden Best Practices für das Erstellen, Implementieren, Testen und Bereitstellen von Cloud Run Functions beschrieben.
Richtigkeit
In diesem Abschnitt werden allgemeine Best Practices für das Erstellen und Implementieren von Cloud Run Functions beschrieben.
Idempotente Funktionen schreiben
Die Funktionen sollten das gleiche Ergebnis liefern, auch wenn sie mehrmals aufgerufen werden. Dadurch können Sie einen Aufruf wiederholen, wenn der vorherige Aufruf nach der Hälfte des Codes fehlschlägt. Weitere Informationen finden Sie unter Ereignisgesteuerte Funktionen wiederholen.
Sicherstellen, dass HTTP-Funktionen eine HTTP-Antwort senden
Wenn Ihre Funktion durch HTTP ausgelöst wird, denken Sie daran, wie unten gezeigt eine HTTP-Antwort zu senden. Andernfalls wird die Funktion möglicherweise ausgeführt, bis eine Zeitüberschreitung erfolgt. In diesem Fall wird Ihnen die gesamte Zeit bis zur Zeitüberschreitung in Rechnung gestellt. Zeitüberschreitungen können außerdem unvorhersehbares Verhalten zur Folge haben oder zu Kaltstarts bei nachfolgenden Aufrufen führen, was ebenfalls unvorhersehbares Verhalten nach sich ziehen oder die Latenz erhöhen kann.
Keine Hintergrundaktivitäten starten
Als Hintergrundaktivität werden alle Aktivitäten bezeichnet, die nach Beendigung der Funktion stattfinden.
Ein Funktionsaufruf wird beendet, wenn die Funktion ein Ergebnis zurückgibt oder anderweitig ihren Abschluss signalisiert, z. B. durch Aufrufen des callback
-Arguments in ereignisgesteuerten Node.js-Funktionen. Nach einer ordnungsgemäßen Beendigung ausgeführter Code kann nicht auf die CPU zugreifen und erzielt keine Fortschritte.
Wenn ein nachfolgender Aufruf in derselben Umgebung ausgeführt wird, wird außerdem die Hintergrundaktivität fortgesetzt und beeinträchtigt den neuen Aufruf. Das kann unerwartetes Verhalten und schwer zu analysierende Fehler hervorrufen. Wenn Sie nach Beendigung einer Funktion auf das Netzwerk zugreifen, werden Verbindungen in der Regelzurückgesetzt (Fehlercode ECONNRESET
).
Hintergrundaktivitäten können häufig in Logs von individuellen Aufrufen erkannt werden. Dazu müssen Sie in den Logs danach suchen, was unterhalb der Zeile erfasst wurde, in der die Beendigung des Aufrufs aufgeführt ist. Hintergrundaktivitäten sind manchmal tiefer im Code verborgen, insbesondere wenn asynchrone Vorgänge wie Callbacks oder Timer vorliegen. Prüfen Sie den Code, um sicherzustellen, dass alle asynchronen Vorgänge abgeschlossen sind, bevor Sie die Funktion beenden.
Temporäre Dateien immer löschen
Der lokale Laufwerkspeicher im temporären Verzeichnis ist ein speicherinternes Dateisystem. Dateien, die Sie schreiben, belegen Arbeitsspeicher, der für die Funktion verfügbar ist, und bleiben manchmal zwischen Aufrufen bestehen. Wenn diese Dateien nicht explizit gelöscht werden, kann es zu einem Fehler aufgrund fehlenden Speichers und zu einem anschließenden Kaltstart kommen.
Wenn Sie nachsehen möchten, wie viel Arbeitsspeicher eine bestimmte Funktion belegt, können Sie sie in der Liste der Funktionen in der Google Cloud Console auswählen und das Diagramm Arbeitsspeichernutzung auswählen.
Wenn Sie Zugriff auf langfristigen Speicher benötigen, können Sie Cloud Run-Volume-Bereitstellungen mit Cloud Storage oder NFS-Volumes verwenden.
Wenn Sie größere Dateien mit Pipelining verarbeiten, können Sie den Arbeitsspeicherbedarf reduzieren. Zum Verarbeiten einer Datei in Cloud Storage können Sie beispielsweise einen Lesestream erstellen, diesen durch einen streambasierten Prozess leiten und den Ausgabestream direkt in Cloud Storage schreiben.
Functions Framework
Um sicherzustellen, dass dieselben Abhängigkeiten konsistent in verschiedenen Umgebungen installiert werden, können Sie die Functions Framework-Bibliothek in Ihren Paketmanager aufnehmen und die Abhängigkeit an eine bestimmte Functions Framework-Version anpinnen.
Nehmen Sie dazu Ihre bevorzugte Version in die entsprechende Sperrdatei auf (z. B. package-lock.json
für Node.js oder requirements.txt
für Python).
Wenn das Functions Framework nicht explizit als Abhängigkeit aufgeführt ist, wird es während des Build-Prozesses automatisch mit der neuesten verfügbaren Version hinzugefügt.
Tools
Dieser Abschnitt enthält Richtlinien zur Verwendung von Tools zum Implementieren, Testen und Anwenden von Cloud Run Functions.
Lokale Entwicklung
Da die Funktionsbereitstellung zeitaufwendig ist, geht es oft schneller, den Code einer Funktion lokal zu testen.
Fehlerberichte
Lösen Sie bei Sprachen, in denen eine Ausnahmenbehandlung erfolgt, keine nicht erfassten Ausnahmen aus, da diese bei zukünftigen Aufrufen Kaltstarts erzwingen. Informationen zur ordnungsgemäßen Erstellung von Fehlerberichten finden Sie im Error Reporting-Leitfaden.
Nicht manuell beenden
Das manuelle Beenden kann zu unerwartetem Verhalten führen. Bitte verwenden Sie stattdessen die folgenden sprachspezifischen Programmiersprachen:
Nicht process.exit()
verwenden. HTTP-Funktionen sollten eine Antwort mit res.status(200).send(message)
senden. Ereignisgesteuerte Funktionen werden beendet, wenn sie zurückgegeben werden (entweder implizit oder explizit).
Nicht sys.exit()
verwenden. HTTP-Funktionen sollten eine Antwort explizit als String zurückgeben. Ereignisgesteuerte Funktionen werden beendet, sobald sie einen Wert zurückgeben (entweder implizit oder explizit).
Nicht os.Exit()
verwenden. HTTP-Funktionen sollten eine Antwort explizit als String zurückgeben. Ereignisgesteuerte Funktionen werden beendet, sobald sie einen Wert zurückgeben (entweder implizit oder explizit).
Nicht System.exit()
verwenden. HTTP-Funktionen sollten eine Antwort mit response.getWriter().write(message)
senden. Ereignisgesteuerte Funktionen werden beendet, wenn sie zurückgegeben werden (entweder implizit oder explizit).
Nicht System.Environment.Exit()
verwenden. HTTP-Funktionen sollten eine Antwort mit context.Response.WriteAsync(message)
senden. Ereignisgesteuerte Funktionen werden beendet, wenn sie zurückgegeben werden (entweder implizit oder explizit).
Verwenden Sie nicht exit()
oder abort()
. HTTP-Funktionen sollten eine Antwort explizit als String zurückgeben. Ereignisgesteuerte Funktionen werden beendet, sobald sie einen Wert zurückgeben (entweder implizit oder explizit).
Verwenden Sie nicht exit()
oder die()
. HTTP-Funktionen sollten eine Antwort explizit als String zurückgeben. Ereignisgesteuerte Funktionen werden beendet, sobald sie einen Wert zurückgeben (entweder implizit oder explizit).
E-Mails mit SendGrid senden
Cloud Run Functions lässt keine ausgehenden Verbindungen über Port 25 zu, sodass Sie keine nicht gesicherten Verbindungen zu einem SMTP-Server herstellen können. Die empfohlene Methode zum Senden von E-Mails ist die Verwendung eines Drittanbieterdienstes wie SendGrid. Weitere Optionen zum Senden von E-Mails finden Sie in der Anleitung E-Mails von einer Instanz senden für Google Compute Engine.
Leistung
In diesem Abschnitt erfahren Sie mehr über die Best Practices zur Optimierung der Leistung.
Niedrige Parallelität vermeiden
Da Kaltstarts teuer sind, ist es eine gute Optimierung für die Lastverarbeitung, wenn Sie kürzlich gestartete Instanzen bei einem Anstieg wiederverwenden können. Wenn Sie die Gleichzeitigkeit begrenzen, können vorhandene Instanzen nicht optimal genutzt werden, was zu mehr Kaltstarts führt.
Durch die Erhöhung der Gleichzeitigkeit können mehrere Anfragen pro Instanz verschoben werden, was die Verarbeitung von Lastspitzen erleichtert. Hinweis: Bei Funktionen der 1. Generation ist die Gleichzeitigkeit auf 1 begrenzt. Wir empfehlen Ihnen, zu Cloud Run-Funktionen zu migrieren.Abhängigkeiten mit Bedacht verwenden
Da Funktionen zustandslos sind, wird die Ausführungsumgebung in einem sogenannten Kaltstart oft komplett neu initialisiert. Wenn ein Kaltstart erfolgt, wird der globale Kontext der Funktion ausgewertet.
Wenn für Funktionen Module importiert werden, kann die Ladezeit dieser Module die Aufruflatenz während eines Kaltstarts erhöhen. Sie können diese Latenz und die für die Bereitstellung der Funktion erforderliche Zeit reduzieren, indem Sie Abhängigkeiten ordnungsgemäß laden und keine nicht benötigten Abhängigkeiten verwenden.
Globale Variablen verwenden, um Objekte in zukünftigen Aufrufen wiederzuverwenden
Es gibt keine Garantie dafür, dass der Status einer Cloud Run-Funktion für zukünftige Aufrufe erhalten bleibt. Die Ausführungsumgebung eines vorherigen Aufrufs wird in Cloud Run-Funktionen jedoch oft wiederverwendet. Wenn Sie eine Variable im globalen Gültigkeitsbereich deklarieren, kann ihr Wert in nachfolgenden Aufrufen wiederverwendet werden, ohne dass eine Neuberechnung erforderlich ist.
Dadurch können Sie Objekte, deren Neuerstellung bei jedem Funktionsaufruf teuer sein kann, im Cache speichern. Das Verschieben solcher Objekte aus dem Funktionsrumpf in den globalen Gültigkeitsbereich kann zu erheblichen Leistungsverbesserungen führen. Im folgenden Beispiel wird ein schweres Objekt nur einmal pro Funktionsinstanz erstellt und für alle Funktionsaufrufe freigegeben, die die angegebene Instanz erreichen:
Insbesondere globale Netzwerkverbindungen, Bibliotheksreferenzen und API-Clientobjekte sollten im Cache gespeichert werden. Entsprechende Beispiele finden Sie unter Netzwerk optimieren.
Kaltstarts durch Festlegen einer Mindestanzahl an Instanzen reduzieren
Standardmäßig skaliert Cloud Run Functions die Anzahl der Instanzen basierend auf der Anzahl der eingehenden Anfragen. Sie können dieses Standardverhalten ändern, indem Sie eine Mindestanzahl von Instanzen festlegen, die Cloud Run Functions bereithalten muss, um Anfragen zu verarbeiten. Wenn Sie eine Mindestanzahl von Instanzen festlegen, werden Kaltstarts der Anwendung reduziert. Wir empfehlen, eine Mindestanzahl von Instanzen festzulegen und die Initialisierung bei der Ladezeit abzuschließen, wenn Ihre Anwendung latenzempfindlich ist.
Informationen zum Festlegen einer Mindestanzahl von Instanzen finden Sie unter Mindestinstanzzahl verwenden.
Hinweise zum Kaltstart und zur Initialisierung
Die globale Initialisierung erfolgt beim Laden. Ohne sie müsste bei der ersten Anfrage die Initialisierung abgeschlossen und die Module geladen werden, was zu einer höheren Latenz führt.
Die globale Initialisierung hat jedoch auch Auswirkungen auf Kaltstarts. Um diese Auswirkungen zu minimieren, sollten Sie nur das initialisieren, was für die erste Anfrage erforderlich ist, damit die Latenz der ersten Anfrage so niedrig wie möglich bleibt.
Das ist besonders wichtig, wenn Sie die Mindestanzahl von Instanzen wie oben beschrieben für eine latenzempfindliche Funktion konfiguriert haben. In diesem Fall wird die Initialisierung bei der Ladezeit abgeschlossen und nützliche Daten werden im Cache gespeichert, damit die erste Anfrage nicht ausgeführt werden muss und mit geringer Latenz bereitgestellt wird.
Wenn Sie Variablen im globalen Gültigkeitsbereich initialisieren, können lange Initialisierungszeiten je nach Sprache zu zwei Verhaltensweisen führen: – Bei einigen Kombinationen von Sprachen und asynchronen Bibliotheken kann das Funktions-Framework asynchron ausgeführt werden und sofort zurückkehren, wodurch der Code im Hintergrund weiter ausgeführt wird. Dies kann zu Problemen wie einem fehlenden Zugriff auf die CPU führen. Um dies zu vermeiden, sollten Sie die Modulinitialisierung wie unten beschrieben blockieren. Außerdem wird dadurch sichergestellt, dass Anfragen erst nach Abschluss der Initialisierung gesendet werden. – Wenn die Initialisierung dagegen synchron erfolgt, führt die lange Initialisierungszeit zu längeren Kaltstarts, was insbesondere bei Funktionen mit geringer Parallelität bei Lastspitzen ein Problem sein kann.
Beispiel für das Vorwärmen einer asynchronen Node.js-Bibliothek
Node.js mit Firestore ist ein Beispiel für eine asynchrone Node.js-Bibliothek. Um von „min_instances“ zu profitieren, wird mit dem folgenden Code das Laden und die Initialisierung zum Zeitpunkt des Ladens abgeschlossen. Das Laden des Moduls wird blockiert.
Es wird TLA verwendet, was bedeutet, dass ES6 erforderlich ist. Verwenden Sie dazu eine .mjs
-Erweiterung für den Node.js-Code oder fügen Sie der Datei „package.json“ type: module
hinzu.
{ "main": "main.js", "type": "module", "dependencies": { "@google-cloud/firestore": "^7.10.0", "@google-cloud/functions-framework": "^3.4.5" } }
import Firestore from '@google-cloud/firestore'; import * as functions from '@google-cloud/functions-framework'; const firestore = new Firestore({preferRest: true}); // Pre-warm firestore connection pool, and preload our global config // document in cache. In order to ensure no other request comes in, // block the module loading with a synchronous global request: const config = await firestore.collection('collection').doc('config').get(); functions.http('fetch', (req, res) => { // Do something with config and firestore client, which are now preloaded // and will execute at lower latency. });
Beispiele für die globale Initialisierung
PHP-Funktionen können Variablen zwischen Anfragen nicht beibehalten. Im Bereichsbeispiel oben wird Lazy Loading verwendet, um globale Variablenwerte aus einer Datei im Cache zu speichern.
Das ist besonders wichtig, wenn Sie mehrere Funktionen in einer einzigen Datei definieren und wenn verschiedene Funktionen unterschiedliche Variablen verwenden. Wenn Sie auf die verzögerte Initialisierung verzichten, verschwenden Sie möglicherweise Ressourcen für Variablen, die zwar initialisiert, aber nie verwendet werden.
Zusätzliche Ressourcen
Das Video „Cloud Performance Atlas“ von Google mit dem Titel Cloud Run Functions Cold Boot Time (Kaltstartzeit von Cloud Run Functions) enthält weitere Informationen.