Tipps und Tricks

In diesem Dokument werden Best Practices für das Erstellen, Implementieren, Testen, und Bereitstellen von Cloud Functions beschrieben.

Richtigkeit

In diesem Abschnitt werden allgemeine Best Practices für das Erstellen und Implementieren Cloud 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.

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 Volumebereitstellungen 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, empfehlen wir, die Functions Framework-Bibliothek in Ihren Paketmanager aufzunehmen und die Abhängigkeit an eine bestimmte Version von Functions Framework anzuheften.

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 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 Functions.

Lokale Entwicklung

Da die Funktionsbereitstellung zeitaufwendig ist, geht es oft schneller, den Code einer Funktion lokal zu testen.

Firebase-Entwickler können den Firebase CLI Cloud Functions Emulator verwenden.

Bereitstellungszeitüberschreitungen während der Initialisierung vermeiden

Wenn die Funktionsbereitstellung mit einem Zeitüberschreitungsfehler fehlschlägt, dauert die Ausführung des globalen Bereichscodes der Funktion während des Bereitstellungsprozesses wahrscheinlich zu lange.

Die Firebase CLI hat eine Standardzeitüberschreitung für die Suche nach Funktionen während der Bereitstellung. Wenn die Initialisierungslogik im Quellcode der Funktionen (Module laden, Netzwerkaufrufe ausführen usw.) diese Zeitüberschreitung überschreitet, kann die Bereitstellung fehlschlagen.

Verwenden Sie eine der folgenden Strategien, um die Zeitüberschreitung zu vermeiden:

Verwenden Sie den onInit()-Hook, um zu verhindern, dass der Initialisierungscode während der Bereitstellung ausgeführt wird. Code im onInit()-Hook wird nur ausgeführt, wenn die Funktion in Cloud Run Functions bereitgestellt wird, nicht während des Bereitstellungsprozesses selbst.

Node.js

const { onInit } = require('firebase-functions/v2/core');
const { onRequest } = require('firebase-functions/v2/https');

// Example of a slow initialization task
function slowInitialization() {
  // Simulate a long-running operation (e.g., loading a large model, network request).
  return new Promise(resolve => {
      setTimeout(() => {
          console.log("Slow initialization complete");
          resolve("Initialized Value");
      }, 20000); // Simulate a 20-second delay
  });
}
let initializedValue;

onInit(async () => {
  initializedValue = await slowInitialization();
});

exports.myFunction = onRequest((req, res) => {
  // Access the initialized value. It will be ready after the first invocation.
  res.send(`Value: ${initializedValue}`);
});

Python

from firebase_functions.core import init
from firebase_functions import https_fn
import time

# Example of a slow initialization task
def _slow_initialization():
  time.sleep(20)  # Simulate a 20-second delay
  print("Slow initialization complete")
  return "Initialized Value"

_initialized_value = None

@init
def initialize():
  global _initialized_value
  _initialized_value = _slow_initialization()

@https_fn.on_request()
def my_function(req: https_fn.Request) -> https_fn.Response:
  # Access the initialized value. It will be ready after the first invocation.
  return https_fn.Response(f"Value: {_initialized_value}")

(Alternative) Zeitüberschreitung für die Suche erhöhen

Wenn Sie Ihren Code nicht umgestalten können, um onInit() zu verwenden, können Sie die Zeitüberschreitung für die Bereitstellung der CLI mit der Umgebungsvariable FUNCTIONS_DISCOVERY_TIMEOUT erhöhen:

$ export FUNCTIONS_DISCOVERY_TIMEOUT=30
$ firebase deploy --only functions

E-Mails mit SendGrid senden

Cloud 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 Drittanbieters 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.

Geringe Nebenläufigkeit vermeiden

Da Kaltstarts teuer sind, ist die Wiederverwendung kürzlich gestarteter Instanzen während eines Lastanstiegs eine gute Optimierung zur Bewältigung der Last. Wenn Sie die Parallelität begrenzen, wird die Nutzung vorhandener Instanzen eingeschränkt, was zu mehr Kaltstarts führt.

Durch Erhöhen der Parallelität hilft, mehrere Anfragen pro Instanz zu verzögern, wodurch Lastspitzen leichter zu bewältigen sind.

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 Funktion für zukünftige Aufrufe erhalten bleibt. Die Cloud Functions Ausführungsumgebung eines vorherigen Aufrufs wird jedoch oft wiederverwendet. Wenn Sie eine globale Variable 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:

Node.js

console.log('Global scope');
const perInstance = heavyComputation();
const functions = require('firebase-functions');

exports.function = functions.https.onRequest((req, res) => {
  console.log('Function invocation');
  const perFunction = lightweightComputation();

  res.send(`Per instance: ${perInstance}, per function: ${perFunction}`);
});

Python

import time

from firebase_functions import https_fn

# Placeholder
def heavy_computation():
  return time.time()

# Placeholder
def light_computation():
  return time.time()

# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()

@https_fn.on_request()
def scope_demo(request):

  # Per-function scope
  # This computation runs every time this function is called
  function_var = light_computation()
  return https_fn.Response(f"Instance: {instance_var}; function: {function_var}")
  

Diese HTTP-Funktion verwendet ein Anfrageobjekt (flask.Request) und gibt den Antworttext oder eine beliebige Menge von Werten zurück, die mit make_response in ein Response Objekt umgewandelt werden können.

Insbesondere globale Netzwerkverbindungen, Bibliotheksreferenzen und API-Clientobjekte sollten im Cache gespeichert werden. Entsprechende Beispiele finden Sie unter Netzwerke optimieren.

Kaltstarts durch Festlegen einer Mindestanzahl an Instanzen reduzieren

Standardmäßig skaliert Cloud 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 Functions bereithalten muss, 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 zur Ladezeit abzuschließen, wenn Ihre Anwendung latenzempfindlich ist.

Weitere Informationen zu diesen Laufzeitoptionen finden Sie unter Skalierungsverhalten steuern.

Hinweise zu Kaltstart und Initialisierung

Die globale Initialisierung erfolgt zur Ladezeit. Ohne sie müsste die erste Anfrage die Initialisierung abschließen und Module laden, was zu einer höheren Latenz führen würde.

Die globale Initialisierung hat jedoch auch Auswirkungen auf Kaltstarts. Um diese Auswirkungen zu minimieren, initialisieren Sie nur das, was für die erste Anfrage erforderlich ist, damit die Latenz der ersten Anfrage so gering wie möglich bleibt.

Das ist besonders wichtig, wenn Sie Mindestanzahlen von Instanzen wie oben beschrieben für eine latenzempfindliche Funktion konfiguriert haben. In diesem Fall wird durch das Abschließen der Initialisierung zur Ladezeit und das Speichern nützlicher Daten im Cache sichergestellt, dass die erste Anfrage dies nicht tun muss und mit geringer Latenz verarbeitet wird.

Wenn Sie Variablen im globalen Bereich 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. Dadurch wird der Code im Hintergrund weiter ausgeführt, was zu Problemen führen kann, z. B. kein Zugriff auf die CPU. Um dies zu vermeiden, sollten Sie die Modulinitialisierung wie unten beschrieben blockieren. Dadurch wird auch sichergestellt, dass Anfragen erst verarbeitet werden, wenn die Initialisierung abgeschlossen ist. Wenn die Initialisierung hingegen synchron ist, führt die lange Initialisierungszeit zu längeren Kaltstarts, was insbesondere bei Funktionen mit geringer Nebenläufigkeit während 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 die Vorteile von `min_instances` zu nutzen, wird mit dem folgenden Code das Laden und die Initialisierung zur Ladezeit abgeschlossen und das Laden des Moduls blockiert.

Es wird TLA verwendet, was bedeutet, dass ES6 erforderlich ist. Verwenden Sie dazu die .mjs Erweiterung für den Node.js-Code oder fügen Sie type: module zur Datei „package.json“ hinzu.

{
  "main": "main.js",
  "type": "module",
  "dependencies": {
    "@google-cloud/firestore": "^7.10.0",
    "@google-cloud/functions-framework": "^3.4.5"
  }
}

Node.js

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

Node.js

const functions = require('firebase-functions');
let myCostlyVariable;

exports.function = functions.https.onRequest((req, res) => {
  doUsualWork();
  if(unlikelyCondition()){
      myCostlyVariable = myCostlyVariable || buildCostlyVariable();
  }
  res.status(200).send('OK');
});

Python

from firebase_functions import https_fn

# Always initialized (at cold-start)
non_lazy_global = file_wide_computation()

# Declared at cold-start, but only initialized if/when the function executes
lazy_global = None

@https_fn.on_request()
def lazy_globals(request):

  global lazy_global, non_lazy_global

  # This value is initialized only if (and when) the function is called
  if not lazy_global:
      lazy_global = function_specific_computation()

  return https_fn.Response(f"Lazy: {lazy_global}, non-lazy: {non_lazy_global}.")
  

Diese HTTP-Funktion verwendet verzögert initialisierte globale Variablen. Sie verwendet ein Anfrageobjekt (flask.Request) und gibt den Antworttext oder eine beliebige Menge von Werten zurück, die mit make_responsein ein Response Objekt umgewandelt werden können.

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 „Google Cloud Atlas“ enthält weitere Informationen zur Leistungsoptimierung Cloud Functions Cold Boot Time.