Premiers pas avec Cloud Functions (2e génération)

1. Introduction

Pour commencer à écrire des fonctions Cloud Run, vous pouvez utiliser les ateliers de programmation suivants:

Dans le cas contraire, cet atelier de programmation vous explique comment créer des fonctions Cloud Functions (2e génération).

Présentation

Cloud Functions (2e génération) est la prochaine version de Google Cloud Functions, l'offre Functions as a Service de Google Cloud. Cette nouvelle version intègre un ensemble de fonctionnalités avancées et est désormais optimisée par Cloud Run et Eventarc. Elle vous offre un contrôle plus avancé des performances et de l'évolutivité, ainsi qu'un contrôle accru sur l'environnement d'exécution des fonctions et les déclencheurs de plus de 90 sources d'événements.

Cet atelier de programmation vous explique comment créer des fonctions Cloud qui répondent aux appels HTTP et sont déclenchées par les messages Pub/Sub et les journaux Cloud Audit Logs.

Nouveautés

Cette nouvelle version de Cloud Functions améliore l'expérience FaaS fournie par Cloud Run, Cloud Build, Artifact Registry et Eventarc.

Infrastructure améliorée

  • Traitement des requêtes plus long:exécutez vos fonctions Cloud Functions plus longtemps que la valeur par défaut de cinq minutes, ce qui facilite l'exécution de charges de travail de requête plus longues, telles que le traitement de grands flux de données depuis Cloud Storage ou BigQuery. Pour les fonctions HTTP, cette durée peut atteindre 60 minutes. Pour les fonctions basées sur des événements, ce délai est actuellement de 10 minutes maximum.
  • Instances plus volumineuses:profitez de 16 Go de RAM et de quatre processeurs virtuels sur Cloud Functions, ce qui permet d'utiliser des charges de travail en mémoire exigeantes en ressources de calcul et plus parallèles.
  • Simultanéité:traitez jusqu'à 1 000 requêtes simultanées avec une seule instance de fonction, ce qui minimise les démarrages à froid et améliore la latence lors du scaling.
  • Nombre minimal d'instances:fournissez des instances préalablement démarrées pour réduire les démarrages à froid et assurez-vous que le temps d'amorçage de votre application n'affecte pas ses performances.
  • Répartition du trafic:acceptez plusieurs versions de vos fonctions, répartissez le trafic entre différentes versions et restaurez une version antérieure de la fonction.

Couverture étendue des événements et compatibilité avec CloudEvents

  • Intégration d'Eventarc:Cloud Functions est désormais compatible en natif avec Eventarc. Celui-ci fournit plus de 90 sources d'événements à l'aide de Cloud Audit Logs (BigQuery, Cloud SQL, Cloud Storage, etc.). Cloud Functions continue bien sûr à accepter les événements provenant de sources personnalisées en publiant directement sur Cloud Pub/Sub.
  • Format CloudEvent:toutes les fonctions basées sur des événements respectent les CloudEvents standards dans l'industrie ( cloudevents.io), quelle que soit la source, afin de garantir une expérience cohérente pour les développeurs. Les charges utiles sont envoyées via un CloudEvent structuré avec une charge utile cloudevent.data et implémentent la norme CloudEvent.

Points abordés

  • Présentation de Cloud Functions (2e génération)
  • Écrire une fonction qui répond aux appels HTTP
  • Écrire une fonction qui répond aux messages Pub/Sub
  • Écrire une fonction qui répond aux événements Cloud Storage
  • Écrire une fonction qui répond aux journaux Cloud Audit Logs
  • Répartir le trafic entre deux révisions
  • Comment se débarrasser des démarrages à froid avec un nombre minimal d'instances
  • Définir la simultanéité

2. Préparation

Configuration de l'environnement au rythme de chacun

  1. Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pouvez le mettre à jour à tout moment.
  • L'ID du projet doit être unique sur l'ensemble des projets Google Cloud et doit être immuable (vous ne pouvez pas le modifier une fois que vous l'avez défini). La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Il ne peut pas être modifié après cette étape et restera actif pendant toute la durée du projet.
  • Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.
  1. Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai gratuit pour bénéficier d'un crédit de 300 $.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Dans la console Google Cloud, cliquez sur l'icône Cloud Shell dans la barre d'outils supérieure :

55efc1aaa7a4d3ad.png

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

7ffe5cbb04455448.png

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez effectuer toutes les tâches de cet atelier de programmation dans un navigateur. Vous n'avez rien à installer.

Configurer gcloud

Dans Cloud Shell, assurez-vous que l'ID de votre projet est défini et enregistré dans une variable PROJECT_ID, et que REGION est défini sur us-west1:

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

Activer les API

Activez tous les services nécessaires :

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. Fonction HTTP

Pour la première fonction, créons une fonction Node.js authentifiée qui répond aux requêtes HTTP. Utilisons également un délai avant expiration de 10 minutes pour montrer comment une fonction peut avoir plus de temps pour répondre aux requêtes HTTP.

Créer

Créez un dossier pour l'application et accédez-y:

mkdir ~/hello-http && cd $_

Créez un fichier index.js qui répond simplement aux requêtes HTTP:

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

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

Créez un fichier package.json pour spécifier les dépendances:

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

Déployer

Déployez la fonction :

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

Bien que cela ne soit pas strictement nécessaire pour cette étape, notez le délai avant expiration de 600 secondes. Cela permet à la fonction de disposer d'un délai d'expiration plus long pour répondre aux requêtes HTTP.

Une fois la fonction déployée, vous pouvez la voir dans la section "Cloud Functions" de la console Cloud:

7541800e1e3f299f.png

Tester

Testez la fonction à l'aide de la commande suivante:

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

Le message HTTP with Node.js in GCF 2nd gen! doit s'afficher en réponse.

4. Fonction Pub/Sub

Pour la deuxième fonction, créons une fonction Python déclenchée par un message Pub/Sub publié sur un sujet spécifique.

Configurer des jetons d'autorisation Pub/Sub

Si vous avez activé le compte de service Pub/Sub le 8 avril 2021 ou avant cette date, attribuez le rôle iam.serviceAccountTokenCreator au compte de service Pub/Sub:

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

Créer

Créez un sujet Pub/Sub à utiliser pour cet exemple:

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

Créez un dossier pour l'application et accédez-y:

mkdir ~/hello-pubsub && cd $_

Créez un fichier main.py qui consigne simplement un message contenant l'ID CloudEvent:

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'])

Créez un fichier requirements.txt avec le contenu suivant pour spécifier les dépendances:

functions-framework==3.*

Déployer

Déployez la fonction :

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

Une fois la fonction déployée, vous pouvez la voir dans la section "Cloud Functions" de la console Cloud:

107029714c32baff.png

Tester

Testez la fonction en envoyant un message au sujet:

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

L'événement CloudEvent reçu doit apparaître dans les journaux :

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

5. Fonction Cloud Storage

Pour la fonction suivante, nous allons créer une fonction Node.js qui répond aux événements provenant d'un bucket Cloud Storage.

Configurer

Pour utiliser les fonctions Cloud Storage, accordez le rôle IAM pubsub.publisher au compte de service Cloud Storage:

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

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

Créer

Créez un dossier pour l'application et accédez-y:

mkdir ~/hello-storage && cd $_

Créez un fichier index.js qui répond simplement aux événements Cloud Storage:

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);
});

Créez un fichier package.json pour spécifier les dépendances:

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

Déployer

Commencez par créer un bucket Cloud Storage (ou utilisez un bucket existant):

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

Déployez la fonction :

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

Une fois la fonction déployée, vous pouvez la voir dans la section "Fonctions Cloud" de Cloud Console.

Tester

Testez la fonction en important un fichier dans le bucket:

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

L'événement CloudEvent reçu doit apparaître dans les journaux :

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

6. Fonction Cloud Audit Logs

Pour la fonction suivante, créons une fonction Node.js qui reçoit un événement Cloud Audit Log lorsqu'une instance de VM Compute Engine est créée. En réponse, il ajoute un libellé à la VM nouvellement créée, en spécifiant son créateur.

Déterminer les VM Compute Engine nouvellement créées

Compute Engine émet deux journaux d'audit lorsqu'une VM est créée.

La première est émise au début de la création de la VM et ressemble à ceci:

8d394a481644c4b6.png

Le second est émis après la création de la VM et ressemble à ceci:

ee0e221d82887cd1.png

Notez le champ d'opération avec les valeurs first: true et last: true. Le deuxième journal d'audit contient toutes les informations dont nous avons besoin pour ajouter un libellé à une instance. Nous utiliserons donc l'indicateur last: true pour la détecter dans Cloud Functions.

Configurer

Pour utiliser les fonctions des journaux d'audit Cloud, vous devez activer les journaux d'audit pour Eventarc. Vous devez également utiliser un compte de service disposant du rôle eventarc.eventReceiver.

  1. Activez les types de journaux Cloud Audit Logs Lecture administrateur, Lecture de données et Écriture de données pour l'API Compute Engine:

76b7417ea4071241.png

  1. Attribuez au compte de service Compute Engine par défaut le rôle IAM eventarc.eventReceiver:
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --role roles/eventarc.eventReceiver

Obtenir le code

Clonez le dépôt contenant l'application:

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

Accédez au répertoire de l'application:

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

Le fichier index.js contient le code de l'application qui reçoit le journal d'audit encapsulé dans un CloudEvent. Il extrait ensuite les détails de l'instance de VM Compute Engine et lui attribue une étiquette. N'hésitez pas à étudier index.js plus en détail par vous-même.

Déployer

Vous pouvez déployer la fonction avec gcloud comme auparavant. Notez que la fonction filtre dans les journaux d'audit pour les insertions de Compute Engine avec l'option --trigger-event-filters:

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

Vous pouvez également déployer la fonction et ajouter un déclencheur Eventarc depuis la console Google Cloud.

Commencez par accéder à la section "Cloud Functions" et créez une fonction avec un environnement de 2e génération:

8ba79a12ee152d8.png

Cliquez sur le bouton Add Eventarc Trigger:

655346320a5e3631.png

Un panneau latéral s'ouvre sur la droite, dans lequel vous pouvez choisir différents fournisseurs d'événements et événements pour le déclencheur Eventarc.

Sélectionnez le bon fournisseur d'événements et l'événement, puis cliquez sur Save Trigger:

7d24325ff06c9b05.png

Enfin, sur la page suivante, vous pouvez mettre à jour les fichiers index.js et package.json avec les fichiers index.js et package.json sur GitHub, puis cliquer sur le bouton Deploy:

f2e338eed2ccf5a2.png

Tester

Pour tester votre fonction de journal des audits, vous devez créer une VM Compute Engine dans Cloud Console (vous pouvez également créer des VM avec gcloud, mais cela ne semble pas générer de journaux des audits).

Accédez à la section Compute Engine > Instances de VM de la console Cloud, puis créez une VM. Une fois la VM créée, l'étiquette creator doit s'afficher sur la VM dans la console Cloud, dans la section Informations générales ou à l'aide de la commande suivante:

gcloud compute instances describe YOUR_VM_NAME

Le libellé doit s'afficher dans la sortie, comme dans l'exemple suivant:

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

7. Répartition du trafic

Cloud Functions (2nd gen) est compatible avec plusieurs révisions de vos fonctions, ce qui vous permet de répartir le trafic entre différentes révisions et d'effectuer un rollback de votre fonction vers une version précédente. Cela est possible, car les fonctions de 2e génération sont des services Cloud Run en sous-couche.

À cette étape, vous allez déployer deux révisions d'une fonction, puis répartir le trafic entre elles à 50/50.

Créer

Créez un dossier pour l'application et accédez-y:

mkdir ~/traffic-splitting && cd $_

Créez un fichier main.py avec une fonction Python qui lit une variable d'environnement de couleur et renvoie Hello World dans cette couleur d'arrière-plan:

import os

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

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

Déployer

Déployez la première révision de la fonction avec un arrière-plan orange:

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

À ce stade, si vous testez la fonction en affichant le déclencheur HTTP (la sortie URI de la commande de déploiement ci-dessus) dans votre navigateur, vous devriez voir Hello World avec un arrière-plan orange:

36ca0c5f39cc89cf.png

Déployez la deuxième révision avec un arrière-plan jaune:

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

Comme il s'agit de la dernière révision, si vous testez la fonction, Hello World devrait s'afficher avec un arrière-plan jaune:

391286a08ad3cdde.png

Répartir le trafic en 50/50

Pour répartir le trafic entre les révisions orange et jaune, vous devez trouver les ID de révision des services Cloud Run sous-jacents. Voici la commande à exécuter pour afficher les ID de révision:

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

La sortie devrait ressembler à ce qui suit :

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

Répartissez maintenant le trafic entre ces deux révisions comme suit (modifiez X-XXX en fonction des noms de vos révisions):

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

Tester

Testez la fonction en accédant à son URL publique. La moitié du temps, la version orange doit s'afficher, et l'autre moitié, la version jaune:

36ca0c5f39cc89cf.png 391286a08ad3cdde.png

Pour en savoir plus, consultez la section Rollbacks, déploiements progressifs et migration du trafic.

8. Nombre minimal d'instances

Dans Cloud Functions (2e génération), vous pouvez spécifier un nombre minimal d'instances de fonction à garder en attente et prêtes à traiter des requêtes. Cela permet de limiter le nombre de démarrages à froid.

À cette étape, vous allez déployer une fonction avec une initialisation lente. Vous constaterez le problème de démarrage à froid. Vous allez ensuite déployer la fonction avec la valeur d'instance minimale définie sur 1 pour supprimer le démarrage à froid.

Créer

Créez un dossier pour l'application et accédez-y:

mkdir ~/min-instances && cd $_

Créez un fichier main.go. Ce service Go comporte une fonction init qui passe en veille pendant 10 secondes pour simuler une longue initialisation. Il comporte également une fonction HelloWorld qui répond aux appels HTTP:

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!")
}

Déployer

Déployez la première révision de la fonction avec une valeur d'instance minimale par défaut de zéro:

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

Testez la fonction à l'aide de la commande suivante:

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

Vous observerez un délai de 10 secondes (démarrage à froid) au premier appel, puis le message s'affichera. Les appels suivants doivent être renvoyés immédiatement.

Définir le nombre minimal d'instances

Pour supprimer le démarrage à froid lors de la première requête, redéployez la fonction avec l'indicateur --min-instances défini sur 1 comme suit:

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

Tester

Testez à nouveau la fonction:

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

Le délai de 10 secondes ne devrait plus s'afficher dans la première requête. Le problème de démarrage à froid pour la première invocation (après une longue période sans) a disparu, grâce aux instances minimales.

Pour en savoir plus, consultez la section Utiliser un nombre minimal d'instances.

9. Simultanéité

Dans Cloud Functions (2e génération), une instance de fonction gère une requête simultanée par défaut, mais vous pouvez spécifier le nombre de requêtes simultanées pouvant être traitées simultanément par une instance. Cela peut également être utile pour éviter les démarrages à froid, car il n'est pas nécessaire de créer une nouvelle instance de fonction pour chaque requête parallèle.

Dans cette étape, vous allez utiliser la fonction avec l'initialisation lente de l'étape précédente. Vous lui enverrez 10 requêtes et observerez à nouveau le problème de démarrage à froid, car de nouvelles instances de fonction doivent être créées pour gérer les requêtes.

Pour résoudre le problème de démarrage à froid, vous allez déployer une autre fonction avec une valeur de simultanéité de 100. Vous constaterez que les 10 requêtes ne provoquent plus le problème de démarrage à froid et qu'une seule instance de fonction peut gérer toutes les requêtes.

Test sans simultanéité

Obtenez l'URL de la fonction:

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

Utilisez un outil d'analyse comparative Open Source appelé hey pour envoyer 10 requêtes simultanées à la fonction lente. hey est déjà installé dans Cloud Shell:

hey -n 10 -c 10 $SLOW_URL

Dans la sortie de hey, vous devriez voir que certaines requêtes prennent du temps:

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]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

En effet, davantage d'instances de fonction sont créées pour gérer les requêtes. Si vous vérifiez le nombre d'instances actives pour la fonction, vous devriez également constater que plusieurs instances ont été créées à un moment donné, ce qui est à l'origine du problème de démarrage à froid:

9f5c6877836d62fb.png

Déployer

Déployez une nouvelle fonction identique à la précédente. Une fois le déploiement déployé, vous allez augmenter sa simultanéité:

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

Définir la simultanéité

Définissez la simultanéité du service Cloud Run sous-jacent de la fonction sur 100 (elle peut être de 1 000 au maximum). Cela garantit qu'au moins 100 requêtes peuvent être traitées par une seule instance de fonction:

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

Tester en simultanéité

Obtenez l'URL de la fonction:

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

Utilisez ensuite hey pour envoyer 10 requêtes simultanées:

hey -n 10 -c 10 $SLOW_CONCURRENT_URL

Dans la sortie de hey, vous devriez voir que toutes les requêtes sont traitées rapidement:

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]     |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

Une seule instance de fonction a pu gérer toutes les requêtes, et le problème de démarrage à froid a disparu grâce à l'augmentation de la simultanéité.

Pour en savoir plus, consultez la section Cohérence.

10. Félicitations !

Félicitations, vous avez terminé l'atelier de programmation.

Points abordés

  • Présentation de Cloud Functions (2e génération)
  • Écrire une fonction qui répond aux appels HTTP
  • Écrire une fonction qui répond aux messages Pub/Sub
  • Écrire une fonction qui répond aux événements Cloud Storage
  • Écrire une fonction qui répond aux journaux Cloud Audit Logs
  • Répartir le trafic entre deux révisions
  • Comment se débarrasser des démarrages à froid avec un nombre minimal d'instances
  • Définir la simultanéité