Diese Seite wurde von der Cloud Translation API übersetzt.

Erste Schritte mit Cloud Functions (2. Generation)

1. Einführung

In den folgenden Codelabs können Sie erste Schritte mit dem Schreiben von Cloud Run-Funktionen machen:

Andernfalls wird in diesem Codelab beschrieben, wie Sie Cloud Functions (2. Generation) erstellen.

Übersicht

Cloud Functions (2. Generation) ist die nächste Version von Google Cloud Functions, dem Functions-as-a-Service-Angebot von Google Cloud. Diese neue Version bietet erweiterte Funktionen und basiert jetzt auf Cloud Run und Eventarc. Sie erhalten damit eine erweiterte Kontrolle über Leistung und Skalierbarkeit sowie über die Laufzeit der Funktionen und Trigger aus über 90 Ereignisquellen.

In diesem Codelab erfahren Sie, wie Sie Cloud Functions erstellen, die auf HTTP-Aufrufe reagieren und durch Pub/Sub-Nachrichten und Cloud-Audit-Logs ausgelöst werden.

Das ist neu

Diese neue Version von Cloud Functions bietet eine verbesserte FaaS-Funktion, die auf Cloud Run, Cloud Build, Artifact Registry und Eventarc basiert.

Erweiterte Infrastruktur

Längere Anfrageverarbeitung:Sie können Ihre Cloud Functions-Funktionen länger als die Standardeinstellung von 5 Minuten ausführen. Dadurch ist es einfacher, längere Anfragearbeitslasten wie die Verarbeitung großer Datenstreams aus Cloud Storage oder BigQuery auszuführen. Bei HTTP-Funktionen sind das bis zu 60 Minuten. Bei ereignisgesteuerten Funktionen dauert es derzeit bis zu 10 Minuten.
Größere Instanzen: Nutzen Sie bis zu 16 GB RAM und 4 vCPUs mit Cloud Functions, wodurch größere speicherinterne, rechenintensive und parallele Arbeitslasten möglich sind.
Gleichzeitigkeit: Verarbeiten Sie bis zu 1.000 gleichzeitige Anfragen mit einer einzelnen Funktionsinstanz, wodurch Kaltstarts minimiert und die Latenz beim Skalieren verbessert wird.
Mindestinstanzen: Stellen Sie vorbereitete Instanzen bereit, um Kaltstarts zu minimieren und zu gewährleisten, dass die Bootstrap-Zeit Ihrer Anwendung nicht die Anwendungsleistung beeinträchtigt.
Trafficaufteilung: Sie können mehrere Versionen Ihrer Funktionen unterstützen, Traffic auf verschiedene Versionen aufteilen und Ihre Funktion auf eine frühere Version zurücksetzen.

Umfassendere Ereignisabdeckung und CloudEvents-Unterstützung

Eventarc-Integration:Cloud Functions bietet jetzt native Unterstützung für Eventarc. Damit stehen über 90 Ereignisquellen mit Cloud-Audit-Logs (BigQuery, Cloud SQL, Cloud Storage usw.) zur Verfügung. Natürlich werden auch weiterhin Ereignisse aus benutzerdefinierten Quellen unterstützt, indem sie direkt in Cloud Pub/Sub veröffentlicht werden.
CloudEvent-Format: Alle ereignisgesteuerten Funktionen entsprechen unabhängig von der Quelle dem CloudEvents-Industriestandard ( cloudevents.io), um eine einheitliche Entwicklungsumgebung zu gewährleisten. Die Nutzlasten werden über ein strukturiertes CloudEvent mit einer cloudevent.data-Nutzlast gesendet und implementieren den CloudEvent-Standard.

Lerninhalte

Cloud Functions (2. Generation) – Übersicht
So schreiben Sie eine Funktion, die auf HTTP-Aufrufe reagiert.
Eine Funktion schreiben, die auf Pub/Sub-Nachrichten reagiert
So schreiben Sie eine Funktion, die auf Cloud Storage-Ereignisse reagiert.
Eine Funktion schreiben, die auf Cloud-Audit-Logs reagiert
Traffic zwischen zwei Versionen aufteilen.
Kaltstarts mit einer Mindestanzahl von Instanzen vermeiden
So legen Sie die Gleichzeitigkeit fest.

2. Einrichtung und Anforderungen

Einrichtung der Umgebung im eigenen Tempo

Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Gerät testen, um zu sehen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.

Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Dieses Codelab sollte möglichst wenig kosten. Wenn Sie die Ressourcen deaktivieren möchten, damit keine Kosten über diese Anleitung hinaus anfallen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neuen Nutzern der Google Cloud Platform steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

Cloud Shell starten

Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der Google Cloud Console rechts oben in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung dauert nur einen Moment. Wenn der Vorgang abgeschlossen ist, sollte in etwa Folgendes angezeigt werden:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Dadurch werden Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.

gcloud einrichten

Achten Sie darauf, dass in Cloud Shell Ihre Projekt-ID festgelegt und in einer PROJECT_ID-Variablen gespeichert ist und REGION auf us-west1 gesetzt ist:

gcloud config set project [YOUR-PROJECT-ID]
PROJECT_ID=$(gcloud config get-value project)
REGION=us-west1

APIs aktivieren

Aktivieren Sie alle erforderlichen Dienste:

gcloud services enable \
  artifactregistry.googleapis.com \
  cloudfunctions.googleapis.com \
  cloudbuild.googleapis.com \
  eventarc.googleapis.com \
  run.googleapis.com \
  logging.googleapis.com \
  pubsub.googleapis.com

3. HTTP-Funktion

Als Erstes erstellen wir eine authentifizierte Node.js-Funktion, die auf HTTP-Anfragen reagiert. Verwenden wir außerdem eine Zeitüberschreitung von 10 Minuten, um zu zeigen, wie eine Funktion mehr Zeit für die Beantwortung von HTTP-Anfragen haben kann.

Erstellen

Erstellen Sie einen Ordner für die Anwendung und rufen Sie den Ordner auf:

mkdir ~/hello-http && cd $_

Erstellen Sie eine index.js-Datei, die einfach auf HTTP-Anfragen reagiert:

const functions = require('@google-cloud/functions-framework');

functions.http('helloWorld', (req, res) => {
  res.status(200).send('HTTP with Node.js in GCF 2nd gen!');
});

Erstellen Sie eine package.json-Datei, um die Abhängigkeiten anzugeben:

{
  "name": "nodejs-functions-gen2-codelab",
  "version": "0.0.1",
  "main": "index.js",
  "dependencies": {
    "@google-cloud/functions-framework": "^2.0.0"
  }
}

Bereitstellen

Die Funktion bereitstellen:

gcloud functions deploy nodejs-http-function \
  --gen2 \
  --runtime nodejs16 \
  --entry-point helloWorld \
  --source . \
  --region $REGION \
  --trigger-http \
  --timeout 600s

Beachte das Zeitlimit von 600 Sekunden, das für diesen Schritt zwar nicht unbedingt erforderlich ist, aber trotzdem gilt. So kann die Funktion ein längeres Zeitlimit für die Beantwortung von HTTP-Anfragen haben.

Sobald die Funktion bereitgestellt ist, wird sie in der Cloud Console im Bereich „Cloud Functions“ angezeigt:

Testen

Testen Sie die Funktion mit dem folgenden Befehl:

gcloud functions call nodejs-http-function \
  --gen2 --region $REGION

Als Antwort sollte die Meldung HTTP with Node.js in GCF 2nd gen! angezeigt werden.

4. Pub/Sub-Funktion

Als zweite Funktion erstellen wir eine Python-Funktion, die durch eine Pub/Sub-Nachricht ausgelöst wird, die in einem bestimmten Thema veröffentlicht wird.

Pub/Sub-Authentifizierungstokens einrichten

Wenn Sie das Pub/Sub-Dienstkonto am oder vor dem 8. April 2021 aktiviert haben, weisen Sie dem Pub/Sub-Dienstkonto die Rolle iam.serviceAccountTokenCreator zu:

PROJECT_NUMBER=$(gcloud projects list --filter="project_id:$PROJECT_ID" --format='value(project_number)')

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member  serviceAccount:service-$PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com \
  --role roles/iam.serviceAccountTokenCreator

Erstellen

Erstellen Sie ein Pub/Sub-Thema für das Beispiel:

TOPIC=cloud-functions-gen2-topic
gcloud pubsub topics create $TOPIC

Erstellen Sie einen Ordner für die App und rufen Sie ihn auf:

mkdir ~/hello-pubsub && cd $_

Erstellen Sie eine main.py-Datei, in der einfach eine Nachricht mit der CloudEvent-ID protokolliert wird:

import functions_framework

@functions_framework.cloud_event
def hello_pubsub(cloud_event):
   print('Pub/Sub with Python in GCF 2nd gen! Id: ' + cloud_event['id'])

Erstellen Sie eine requirements.txt-Datei mit folgendem Inhalt, um die Abhängigkeiten anzugeben:

functions-framework==3.*

Bereitstellen

Die Funktion bereitstellen:

gcloud functions deploy python-pubsub-function \
  --gen2 \
  --runtime python39 \
  --entry-point hello_pubsub \
  --source . \
  --region $REGION \
  --trigger-topic $TOPIC

Nach der Bereitstellung wird die Funktion in der Cloud Console im Bereich „Cloud Functions“ angezeigt:

Testen

Testen Sie die Funktion, indem Sie eine Nachricht an das Thema senden:

gcloud pubsub topics publish $TOPIC --message="Hello World"

Das empfangene CloudEvent sollte in den Logs angezeigt werden:

gcloud functions logs read python-pubsub-function \
  --region $REGION --gen2 --format "value(log)"

5. Cloud Storage-Funktion

Als Nächstes erstellen wir eine Node.js-Funktion, die auf Ereignisse aus einem Cloud Storage-Bucket reagiert.

Einrichten

Wenn Sie Cloud Storage-Funktionen verwenden möchten, weisen Sie dem Cloud Storage-Dienstkonto die IAM-Rolle pubsub.publisher zu:

SERVICE_ACCOUNT=$(gsutil kms serviceaccount -p $PROJECT_NUMBER)

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:$SERVICE_ACCOUNT \
  --role roles/pubsub.publisher

Erstellen

Erstellen Sie einen Ordner für die App und rufen Sie ihn auf:

mkdir ~/hello-storage && cd $_

Erstellen Sie eine index.js-Datei, die einfach auf Cloud Storage-Ereignisse reagiert:

const functions = require('@google-cloud/functions-framework');

functions.cloudEvent('helloStorage', (cloudevent) => {
  console.log('Cloud Storage event with Node.js in GCF 2nd gen!');
  console.log(cloudevent);
});

Erstellen Sie eine package.json-Datei, um die Abhängigkeiten anzugeben:

{
  "name": "nodejs-functions-gen2-codelab",
  "version": "0.0.1",
  "main": "index.js",
  "dependencies": {
    "@google-cloud/functions-framework": "^2.0.0"
  }
}

Bereitstellen

Erstellen Sie zuerst einen Cloud Storage-Bucket (oder verwenden Sie einen vorhandenen Bucket):

export BUCKET="gs://gcf-gen2-storage-$PROJECT_ID"
gsutil mb -l $REGION $BUCKET

Die Funktion bereitstellen:

gcloud functions deploy nodejs-storage-function \
  --gen2 \
  --runtime nodejs16 \
  --entry-point helloStorage \
  --source . \
  --region $REGION \
  --trigger-bucket $BUCKET \
  --trigger-location $REGION

Nach der Bereitstellung wird die Funktion in der Cloud Console im Bereich „Cloud Functions“ angezeigt.

Testen

Testen Sie die Funktion. Laden Sie dazu eine Datei in den Bucket hoch:

echo "Hello World" > random.txt
gsutil cp random.txt $BUCKET/random.txt

Das empfangene CloudEvent sollte in den Logs angezeigt werden:

gcloud functions logs read nodejs-storage-function \
  --region $REGION --gen2 --limit=100 --format "value(log)"

6. Funktion „Cloud-Audit-Logs“

Als Nächstes erstellen wir eine Node.js-Funktion, die ein Cloud-Audit-Log-Ereignis empfängt, wenn eine Compute Engine-VM-Instanz erstellt wird. Daraufhin wird der neu erstellten VM ein Label hinzugefügt, in dem der Ersteller der VM angegeben ist.

Neu erstellte Compute Engine-VMs ermitteln

Die Compute Engine gibt beim Erstellen einer VM zwei Audit-Logs aus.

Die erste wird zu Beginn der VM-Erstellung ausgegeben und sieht so aus:

Die zweite wird nach der VM-Erstellung ausgegeben und sieht so aus:

Beachten Sie das Vorgangsfeld mit den Werten first: true und last: true. Das zweite Audit-Log enthält alle Informationen, die wir zum Labeln einer Instanz benötigen. Daher verwenden wir das Flag last: true, um es in Cloud Functions zu erkennen.

Einrichten

Wenn Sie Cloud-Audit-Log-Funktionen verwenden möchten, müssen Sie Audit-Logs für Eventarc aktivieren. Außerdem müssen Sie ein Dienstkonto mit der Rolle eventarc.eventReceiver verwenden.

Aktivieren Sie die Cloud-Audit-Logs Lesen durch Administrator, Daten lesen und Daten schreiben für die Compute Engine API:

Weisen Sie dem Standard-Compute Engine-Dienstkonto die IAM-Rolle eventarc.eventReceiver zu:

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --role roles/eventarc.eventReceiver

Code abrufen

Klonen Sie das Repository, das die Anwendung enthält:

git clone https://github.com/GoogleCloudPlatform/eventarc-samples.git

Rufen Sie das App-Verzeichnis auf:

cd eventarc-samples/gce-vm-labeler/gcf/nodejs

Die Datei index.js enthält den Anwendungscode, der das Audit-Log in einem CloudEvent empfängt. Anschließend werden die Details der Compute Engine-VM-Instanz extrahiert und ein Label für die VM-Instanz festgelegt. Sie können sich gerne selbstständig mit index.js vertraut machen.

Bereitstellen

Sie können die Funktion wie gewohnt mit gcloud bereitstellen. Beachten Sie, wie die Funktion nach Audit-Logs für Compute Engine-Einfügungen mit dem Flag --trigger-event-filters filtert:

gcloud functions deploy gce-vm-labeler \
  --gen2 \
  --runtime nodejs16 \
  --entry-point labelVmCreation \
  --source . \
  --region $REGION \
  --trigger-event-filters="type=google.cloud.audit.log.v1.written,serviceName=compute.googleapis.com,methodName=beta.compute.instances.insert" \
  --trigger-location us-central1

Sie können die Funktion auch über die Google Cloud Console bereitstellen und einen Eventarc-Trigger hinzufügen.

Rufen Sie zuerst den Bereich „Cloud Functions“ auf und erstellen Sie eine Funktion mit einer Umgebung der 2. Generation:

Klicke auf die Schaltfläche Add Eventarc Trigger:

Daraufhin wird auf der rechten Seite eine Seitenleiste geöffnet, in der Sie verschiedene Ereignisanbieter und Ereignisse für den Eventarc-Trigger auswählen können.

Wählen Sie den richtigen Ereignisanbieter und das richtige Ereignis aus und klicken Sie dann auf Save Trigger:

Auf der nächsten Seite können Sie die index.js- und package.json-Dateien mit den index.js- und package.json-Dateien auf GitHub aktualisieren und auf die Schaltfläche Deploy klicken:

Testen

Um die Funktion für Audit-Logs zu testen, müssen Sie in der Cloud Console eine Compute Engine-VM erstellen. Sie können auch VMs mit gcloud erstellen, aber es werden anscheinend keine Audit-Logs generiert.

Gehen Sie in der Cloud Console zu Compute Engine > VM-Instanzen und erstellen Sie eine neue VM. Sobald die VM-Erstellung abgeschlossen ist, sollten Sie in der Cloud Console im Abschnitt Allgemeine Informationen oder mit dem folgenden Befehl das hinzugefügte Label creator auf der VM sehen:

gcloud compute instances describe YOUR_VM_NAME

Das Label sollte in der Ausgabe wie im folgenden Beispiel angezeigt werden:

...
labelFingerprint: ULU6pAy2C7s=
labels:
  creator: atameldev
...

7. Traffic-Aufteilung

Cloud Functions (2. Generation) unterstützt mehrere Überarbeitungen Ihrer Funktionen. Sie können den Traffic auf verschiedene Überarbeitungen aufteilen und Ihre Funktion auf eine frühere Version zurücksetzen. Das ist möglich, weil Funktionen der 2. Generation Cloud Run-Dienste sind.

In diesem Schritt stellen Sie zwei Versionen einer Funktion bereit und teilen den Traffic dann im Verhältnis 50:50 auf.

Erstellen

Erstellen Sie einen Ordner für die App und rufen Sie ihn auf:

mkdir ~/traffic-splitting && cd $_

Erstellen Sie eine main.py-Datei mit einer Python-Funktion, die eine Farbumgebungsvariable liest und mit Hello World in dieser Hintergrundfarbe antwortet:

import os

color = os.environ.get('COLOR')

def hello_world(request):
    return f'<body style="background-color:{color}"><h1>Hello World!</h1></body>'

Bereitstellen

Stellen Sie die erste Version der Funktion mit einem orangefarbenen Hintergrund bereit:

COLOR=orange
gcloud functions deploy hello-world-colored \
  --gen2 \
  --runtime python39 \
  --entry-point hello_world \
  --source . \
  --region $REGION \
  --trigger-http \
  --allow-unauthenticated \
  --update-env-vars COLOR=$COLOR

Wenn Sie die Funktion jetzt testen, indem Sie den HTTP-Trigger (die URI-Ausgabe des obigen Bereitstellungsbefehls) in Ihrem Browser aufrufen, sollte Hello World mit einem orangefarbenen Hintergrund angezeigt werden:

Stellen Sie die zweite Version mit einem gelben Hintergrund bereit:

COLOR=yellow
gcloud functions deploy hello-world-colored \
  --gen2 \
  --runtime python39 \
  --entry-point hello_world \
  --source . \
  --region $REGION \
  --trigger-http \
  --allow-unauthenticated \
  --update-env-vars COLOR=$COLOR

Da dies die neueste Version ist, sollte beim Testen der Funktion Hello World mit einem gelben Hintergrund angezeigt werden:

Traffic auf 50–50 aufteilen

Wenn Sie den Traffic auf die orange und die gelbe Version aufteilen möchten, müssen Sie die Überarbeitungs-IDs der zugrunde liegenden Cloud Run-Dienste ermitteln. Mit diesem Befehl rufen Sie die Überarbeitungs-IDs auf:

gcloud run revisions list --service hello-world-colored \
  --region $REGION --format 'value(REVISION)'

Die Ausgabe sollte in etwa so aussehen:

hello-world-colored-00001-man
hello-world-colored-00002-wok

Teilen Sie den Traffic jetzt so auf diese beiden Versionen auf: Aktualisieren Sie X-XXX entsprechend den Namen Ihrer Versionen:

gcloud run services update-traffic hello-world-colored \
  --region $REGION \
  --to-revisions hello-world-colored-0000X-XXX=50,hello-world-colored-0000X-XXX=50

Testen

Testen Sie die Funktion, indem Sie ihre öffentliche URL aufrufen. In der Hälfte der Fälle sollten Sie die orangefarbene und die andere Hälfte sehen:

Weitere Informationen finden Sie unter Rollbacks, graduelle Einführungen und Trafficmigration.

8. Mindestanzahl von Instanzen

In Cloud Functions (2. Generation) kann eine Mindestanzahl von Funktionsinstanzen angegeben werden, die einsatzbereit gehalten werden und zum Verarbeiten von Anfragen bereit sein sollen. Dies ist nützlich, um die Anzahl der Kaltstarts zu begrenzen.

In diesem Schritt stellen Sie eine Funktion mit langsamer Initialisierung bereit. Sie stellen das Kaltstartproblem fest. Anschließend stellen Sie die Funktion mit einer Mindestanzahl von Instanzen von 1 bereit, um den Kaltstart zu vermeiden.

Erstellen

Erstellen Sie einen Ordner für die App und rufen Sie ihn auf:

mkdir ~/min-instances && cd $_

Erstellen Sie eine main.go-Datei. Dieser Go-Dienst hat eine init-Funktion, die 10 Sekunden lang in den Ruhemodus wechselt, um eine lange Initialisierung zu simulieren. Außerdem gibt es eine HelloWorld-Funktion, die auf HTTP-Aufrufe reagiert:

package p

import (
        "fmt"
        "net/http"
        "time"
)

func init() {
        time.Sleep(10 * time.Second)
}

func HelloWorld(w http.ResponseWriter, r *http.Request) {
        fmt.Fprint(w, "Slow HTTP Go in GCF 2nd gen!")
}

Bereitstellen

Binden Sie die erste Version der Funktion mit dem Standardmindestwert „0“ ein:

gcloud functions deploy slow-function \
  --gen2 \
  --runtime go116 \
  --entry-point HelloWorld \
  --source . \
  --region $REGION \
  --trigger-http \
  --allow-unauthenticated

Testen Sie die Funktion mit diesem Befehl:

gcloud functions call slow-function \
  --gen2 --region $REGION

Beim ersten Aufruf ist eine Verzögerung von 10 Sekunden (Kaltstart) zu beobachten. Danach wird die Meldung angezeigt. Nachfolgende Aufrufe sollten sofort zurückgegeben werden.

Mindestanzahl von Instanzen festlegen

Um den Kaltstart bei der ersten Anfrage zu vermeiden, stellen Sie die Funktion wie unten beschrieben noch einmal bereit, wobei das Flag --min-instances auf „1“ gesetzt ist:

gcloud functions deploy slow-function \
  --gen2 \
  --runtime go116 \
  --entry-point HelloWorld \
  --source . \
  --region $REGION \
  --trigger-http \
  --allow-unauthenticated \
  --min-instances 1

Testen

Testen Sie die Funktion noch einmal:

gcloud functions call slow-function \
  --gen2 --region $REGION

Die 10-Sekunden-Verzögerung sollte bei der ersten Anfrage nicht mehr auftreten. Das Problem mit dem Kaltstart bei der ersten Aufrufung (nach langer Zeit ohne) ist dank der Mindestanzahl von Instanzen nicht mehr aufgetreten.

Weitere Informationen finden Sie unter Mindestinstanzen verwenden.

9. Gleichzeitigkeit

In Cloud Functions (2nd gen) verarbeitet eine Funktionsinstanz standardmäßig eine gleichzeitige Anfrage. Sie können jedoch die Anzahl der gleichzeitigen Anfragen angeben, die gleichzeitig von einer Instanz verarbeitet werden können. Dies kann auch nützlich sein, um Kaltstarts zu verhindern, da für jede parallele Anfrage keine neue Funktionsinstanz erstellt werden muss.

In diesem Schritt verwenden Sie die Funktion mit langsamer Initialisierung aus dem vorherigen Schritt. Sie senden 10 Anfragen und stellen das Problem mit dem Kaltstart wieder fest, da neue Funktionsinstanzen zum Ausführen der Anfragen erstellt werden müssen.

Um das Problem beim Kaltstart zu beheben, stellen Sie eine weitere Funktion mit einem Wert von 100 für die Parallelität bereit. Sie werden feststellen, dass die 10 Anfragen jetzt nicht das Kaltstartproblem verursachen und dass eine einzelne Funktionsinstanz alle Anfragen verarbeiten kann.

Ohne Nebenläufigkeit testen

Rufen Sie die URL der Funktion ab:

SLOW_URL=$(gcloud functions describe slow-function --region $REGION --gen2 --format="value(serviceConfig.uri)")

Verwenden Sie das Open-Source-Benchmarking-Tool hey, um zehn gleichzeitige Anfragen an die langsame Funktion zu senden. hey ist bereits in Cloud Shell installiert:

hey -n 10 -c 10 $SLOW_URL

In der Ausgabe von hey sollten Sie sehen, dass einige Anfragen lange dauern:

Summary:
  Total:        10.9053 secs
  Slowest:      10.9048 secs
  Fastest:      0.4439 secs
  Average:      9.7930 secs
  Requests/sec: 0.9170

  Total data:   310 bytes
  Size/request: 31 bytes

Response time histogram:
  0.444 [1]     |■■■■
  1.490 [0]     |
  2.536 [0]     |
  3.582 [0]     |
  4.628 [0]     |
  5.674 [0]     |
  6.720 [0]     |
  7.767 [0]     |
  8.813 [0]     |
  9.859 [0]     |
  10.905 [9]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

Das liegt daran, dass mehr Funktionsinstanzen erstellt werden, um die Anfragen zu verarbeiten. Wenn Sie die Anzahl der aktiven Instanzen für die Funktion prüfen, sollten Sie auch sehen, dass irgendwann mehr als eine Instanz erstellt wurde und diese das Kaltstartproblem verursachen:

Bereitstellen

Eine neue Funktion bereitstellen, die mit der vorherigen identisch ist. Nach der Bereitstellung können Sie die Parallelität erhöhen:

gcloud functions deploy slow-concurrent-function \
  --gen2 \
  --runtime go116 \
  --entry-point HelloWorld \
  --source . \
  --region $REGION \
  --trigger-http \
  --allow-unauthenticated \
  --min-instances 1

Gleichzeitigkeit festlegen

Legen Sie die Nebenläufigkeit des zugrunde liegenden Cloud Run-Dienstes für die Funktion auf 100 fest (maximal 1.000). Dadurch wird sichergestellt, dass mindestens 100 Anfragen von einer einzelnen Funktionsinstanz verarbeitet werden können:

gcloud run services update slow-concurrent-function \
  --concurrency 100 \
  --cpu 1 \
  --region $REGION

Mit Parallelität testen

Rufen Sie die URL der Funktion ab:

SLOW_CONCURRENT_URL=$(gcloud functions describe slow-concurrent-function --region $REGION --gen2 --format="value(serviceConfig.uri)")

Verwenden Sie dann hey, um 10 gleichzeitige Anfragen zu senden:

hey -n 10 -c 10 $SLOW_CONCURRENT_URL

In der Ausgabe von hey sollte angezeigt werden, dass alle Anfragen schnell verarbeitet werden:

Summary:
  Total:        0.2164 secs
  Slowest:      0.2163 secs
  Fastest:      0.0921 secs
  Average:      0.2033 secs
  Requests/sec: 46.2028

  Total data:   310 bytes
  Size/request: 31 bytes

Response time histogram:
  0.092 [1]     |■■■■
  0.105 [0]     |
  0.117 [0]     |
  0.129 [0]     |
  0.142 [0]     |
  0.154 [0]     |
  0.167 [0]     |
  0.179 [0]     |
  0.191 [0]     |
  0.204 [0]     |
  0.216 [9]     |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

Eine einzelne Funktionsinstanz konnte alle Anfragen verarbeiten und das Kaltstartproblem ist dank der erhöhten Nebenläufigkeit behoben.

Weitere Informationen finden Sie unter Gleichzeitigkeit.

10. Glückwunsch!

Herzlichen Glückwunsch zum Abschluss des Codelabs!

Behandelte Themen

Cloud Functions (2. Generation) – Übersicht
So schreiben Sie eine Funktion, die auf HTTP-Aufrufe reagiert.
Eine Funktion schreiben, die auf Pub/Sub-Nachrichten reagiert
So schreiben Sie eine Funktion, die auf Cloud Storage-Ereignisse reagiert.
Eine Funktion schreiben, die auf Cloud-Audit-Logs reagiert
Traffic zwischen zwei Versionen aufteilen.
Kaltstarts mit einer Mindestanzahl von Instanzen vermeiden
So legen Sie die Gleichzeitigkeit fest.