Environnement d'exécution Cloud Functions

Remarque : Les informations de ce document s'appliquent généralement à Cloud Functions (1st gen) et à Cloud Functions (2nd gen), sauf indication contraire. Pour découvrir les fonctionnalités supplémentaires compatibles avec la 2e génération, consultez la section Comparaison des versions de Cloud Functions.

Cloud Functions s'exécute dans un environnement sans serveur entièrement géré, dans lequel Google s'occupe de l'infrastructure, des systèmes d'exploitation et des environnements d'exécution à votre place. Chaque fonction Cloud Functions s'exécute dans son propre contexte sécurisé et isolé, évolue automatiquement et dispose d'un cycle de vie indépendant des autres fonctions.

Environnements d'exécution

Cloud Functions accepte plusieurs environnements d'exécution de langage. Vous aurez besoin de la valeur de l'ID d'exécution si vous déployez des fonctions à partir de la ligne de commande ou via Terraform.

Node.js

Runtime	Système d'exploitation	ID d'exécution	Obsolescence	Hors service
Node.js 18 (recommandé)	Ubuntu 22.04	nodejs18
Node.js 16	Ubuntu 18.04	Node.js 16	2024-01-30
Node.js 14	Ubuntu 18.04	nodejs14	2024-01-30
Node.js 12	Ubuntu 18.04	nodejs12	2024-01-30
Node.js 10	Ubuntu 18.04	nodejs10	2024-01-30
Node.js 8	Ubuntu 18.04	nodejs8	2020-06-05
Node.js 6	Ubuntu 18.04	nodejs8	2019-04-17	2020-04-04

Python

Runtime	Système d'exploitation	ID d'exécution	Obsolescence	Hors service
Python 3.11 (recommandé)	Ubuntu 22.04	python311	2027-10-01
Python 3.10	Ubuntu 22.04	python310	2026-10-01
Python 3.9	Ubuntu 18.04	python39	2025-10-01
Python 3.8	Ubuntu 18.04	python38	2024-10-01
Python 3.7	Ubuntu 18.04	python37	2024-01-30

Go

Runtime	Système d'exploitation	ID d'exécution	Obsolescence	Hors service
Go 1.19 (recommandé)	Ubuntu 22.04	go119
Go 1.20 (preview)	Ubuntu 22.04	go120
Go 1.18	Ubuntu 22.04	go118
Go 1.16	Ubuntu 18.04	go116	2024-01-30
Go 1.13	Ubuntu 18.04	go113	2024-10-01
Go 1.12	Ubuntu 18.04	go112	2024-01-30
Go 1.11	Ubuntu 18.04	go111	2020-08-05

Java

Runtime	Système d'exploitation	ID d'exécution	Obsolescence	Hors service
Java 17 (recommandé)	Ubuntu 22.04	java17
Java 11	Ubuntu 18.04	java11

Ruby

Runtime	Système d'exploitation	ID d'exécution	Obsolescence	Hors service
Ruby 3.0 (recommandé)	Ubuntu 18.04	ruby30
Ruby 3.2 (preview)	Ubuntu 18.04	ruby32
Ruby 2.7	Ubuntu 18.04	ruby27	2024-01-30
Ruby 2.6	Ubuntu 18.04	ruby26	2024-01-30

PHP

Runtime	Système d'exploitation	ID d'exécution	Obsolescence	Hors service
PHP 8.1 (recommandé)	Ubuntu 18.04	php81
PHP 7.4	Ubuntu 18.04	php74	2024-01-30

.NET Core

Environnement d'exécution	Système d'exploitation	ID d'exécution	Obsolescence	Hors service
.NET Core 6 (recommandé)	Ubuntu 22.04	dotnet6
.NET Core 3	Ubuntu 18.04	dotnet3	2024-01-30

Sauf indication contraire, lorsque vous déployez une fonction, les mises à jour et les correctifs de sécurité sont appliqués aux environnements d'exécution et à leurs dépendances. Cela inclut les mises à jour et les correctifs développés par une communauté de programmeurs, qui sont disponibles après une période de tests de stabilité. De même, Cloud Functions peut appliquer des mises à jour à d'autres aspects de l'environnement d'exécution, tels que le système d'exploitation ou les packages inclus. Ces mises à jour assurent la sécurité de votre fonction.

Remarque : Tous les environnements d'exécution contiennent un ensemble de packages système.

Comportement d'autoscaling

Cloud Functions met en œuvre le paradigme sans serveur, dans lequel vous exécutez simplement votre code sans vous soucier de l'infrastructure sous-jacente, telle que les serveurs ou les machines virtuelles. Une fois déployées, vos fonctions sont automatiquement gérées et adaptées.

Cloud Functions gère les requêtes entrantes en les attribuant à des instances de votre fonction. En fonction du volume de requêtes et du nombre d'instances de fonction existantes, Cloud Functions peut attribuer une requête à une instance existante ou en créer une.

Lorsque le volume de requêtes entrantes dépasse le nombre d'instances existantes, Cloud Functions peut démarrer plusieurs nouvelles instances pour gérer les requêtes. Ce comportement de scaling automatique permet à Cloud Functions de gérer de nombreuses requêtes en parallèle, chacune utilisant une instance différente de votre fonction.

Remarque : Une augmentation extrêmement rapide du trafic entrant peut entraîner l'échec de certaines requêtes avec un code HTTP 500. Cela est dû au fait que les requêtes expirent dans la file d'attente en attendant la création d'instances. Pour résoudre ce problème, vous devez configurer votre charge de travail pour qu'elle augmente progressivement le trafic au cours d'une minute. Pour en savoir plus, consultez la page Résoudre les problèmes liés à Cloud Functions.

Dans certains cas, un scaling illimité peut être souhaitable. Pour résoudre ce problème, Cloud Functions vous permet de configurer un nombre maximal d'instances pouvant coexister à un moment donné pour une fonction particulière.

Caractéristique "sans état"

Pour activer la gestion et le scaling automatiques de vos fonctions, celles-ci doivent être sans état : un appel de fonction ne doit pas dépendre de l'état en mémoire défini par un appel précédent. Les appels peuvent être gérés par différentes instances de fonctions qui ne partagent pas de variables globales, de mémoire, de systèmes de fichiers ou d'autres états.

Remarque : Bien qu'il ne faille pas s'y fier, il est souvent possible de réutiliser l'état en mémoire pour optimiser les performances. Pour en savoir plus, consultez la recommandation dans Conseils et astuces.

Si vous avez besoin de partager un état sur l'ensemble des appels de fonctions, votre fonction doit utiliser un service tel que Memorystore, Datastore, Firestore ou Cloud Storage pour conserver ces données. Consultez les pages Bases de données Google Cloud et Produits de stockage Google Cloud pour en savoir plus sur les options de base de données et de stockage proposées par Google Cloud.

Simultanéité

Cloud Functions (2nd gen)

Cloud Functions (2nd gen) permet de gérer plusieurs requêtes simultanées sur une seule instance de fonction. Cela peut être utile pour éviter les démarrages à froid, car une instance déjà préchauffée peut traiter plusieurs requêtes simultanément, ce qui réduit la latence globale. Pour en savoir plus, consultez la section Simultanéité

Cloud Functions (1st gen)

Dans Cloud Functions (1st gen), chaque instance d'une fonction ne gère qu'une seule requête simultanée à la fois. Cela signifie que lorsque votre code traite une requête, il est impossible qu'une deuxième requête soit acheminée vers la même instance. Ainsi, la requête d'origine peut utiliser la totalité des ressources (mémoire et processeur) que vous allouez.

Dans la mesure où les requêtes simultanées dans Cloud Functions (1st gen) sont traitées par différentes instances de fonctions, elles ne partagent pas les mêmes variables ni la même mémoire locale. Pour en savoir plus, consultez les sections Sans état et Durée de vie de l'instance de fonction.

Démarrages à froid

Une nouvelle instance de fonction est créée dans deux cas :

• Lorsque vous déployez une fonction.

• Lorsqu'une nouvelle instance de fonction est automatiquement créée pour s'adapter à la charge actuelle ou, plus rarement, pour remplacer une instance existante.

Le lancement d'une nouvelle instance de fonction implique le chargement de l'environnement d'exécution et de votre code. Les requêtes qui impliquent le démarrage d'une instance de fonction, appelées démarrages à froid, peuvent être plus lentes que les requêtes acheminées vers des instances de fonction existantes. Si votre fonction reçoit une charge constante, le nombre de démarrages à froid est généralement négligeable, à moins que votre fonction connaisse de nombreux plantages et nécessite un redémarrage de tout son environnement.

Si votre code de fonction génère une exception non détectée ou bloque le processus en cours, l'instance de fonction peut être redémarrée. Cela peut entraîner des démarrages à froid plus élevés et une latence plus élevée. Nous vous recommandons donc de capturer les exceptions et d'éviter l'arrêt du processus en cours. Consultez la page Signaler des erreurs pour savoir comment gérer et signaler les erreurs dans Cloud Functions.

Remarque : Dans la première génération, la quantité de mémoire attribuée à une fonction affecte l'allocation du processeur, ce qui peut avoir un impact sur le démarrage à froid (voir la section Tarifs). Bien que cela s'applique également à la 2e génération par défaut, vous avez la possibilité de configurer l'allocation du processeur en dehors de la mémoire.

Si votre fonction est sensible à la latence, envisagez de définir un nombre minimal d'instances pour éviter les démarrages à froid.

Durée de vie de l'instance de fonction

Les instances de fonction sont généralement résilientes et réutilisées par des appels de fonctions ultérieurs, à moins que le nombre d'instances soit réduit en raison d'un manque de trafic continu ou de plantage de votre fonction. Cela signifie que lorsque l'exécution d'une fonction se termine, un autre appel de fonction peut être géré par cette même instance de fonction.

Remarque : Vous pouvez mettre en cache l'état des appels dans le champ d'application global à des fins d'optimisation. Cependant, votre fonction ne doit pas se fier à cet état mis en cache, car rien ne garantit que l'appel suivant sera transmis à la même instance de fonction. Consultez la section Sans état.

Champ d'application de la fonction et champ d'application global

Un appel de fonction unique entraîne seulement l'exécution du corps de la fonction déclarée comme point d'entrée. Le champ d'application global de votre code source de fonction n'est exécuté que lors de démarrages à froid, et non sur des instances déjà initialisées.

Node.js

functions/tips/scopeDemo/index.js

Afficher sur GitHub Commentaires

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

// TODO(developer): Define your own computations
const {lightComputation, heavyComputation} = require('./computations');

// Global (instance-wide) scope
// This computation runs once (at instance cold-start)
const instanceVar = heavyComputation();

/**
 * HTTP function that declares a variable.
 *
 * @param {Object} req request context.
 * @param {Object} res response context.
 */
functions.http('scopeDemo', (req, res) => {
  // Per-function scope
  // This computation runs every time this function is called
  const functionVar = lightComputation();

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

Python

functions/tips-scopes/main.py

Afficher sur GitHub Commentaires

import time

import functions_framework

# 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()

@functions_framework.http
def scope_demo(request):
    """
    HTTP Cloud Function that declares a variable.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """

    # Per-function scope
    # This computation runs every time this function is called
    function_var = light_computation()
    return 'Instance: {}; function: {}'.format(instance_var, function_var)

Go

functions/tips/scope.go

Afficher sur GitHub Commentaires

// h is in the global (instance-wide) scope.
var h string

// init runs during package initialization. So, this will only run during an
// an instance's cold start.
func init() {
	h = heavyComputation()
	functions.HTTP("ScopeDemo", ScopeDemo)
}

// ScopeDemo is an example of using globally and locally
// scoped variables in a function.
func ScopeDemo(w http.ResponseWriter, r *http.Request) {
	l := lightComputation()
	fmt.Fprintf(w, "Global: %q, Local: %q", h, l)
}

Java

functions/concepts/scopes/src/main/java/functions/Scopes.java

Afficher sur GitHub Commentaires

import com.google.cloud.functions.HttpFunction;
import com.google.cloud.functions.HttpRequest;
import com.google.cloud.functions.HttpResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;

public class Scopes implements HttpFunction {
  // Global (instance-wide) scope
  // This computation runs at instance cold-start.
  // Warning: Class variables used in functions code must be thread-safe.
  private static final int INSTANCE_VAR = heavyComputation();

  @Override
  public void service(HttpRequest request, HttpResponse response)
      throws IOException {
    // Per-function scope
    // This computation runs every time this function is called
    int functionVar = lightComputation();

    var writer = new PrintWriter(response.getWriter());
    writer.printf("Instance: %s; function: %s", INSTANCE_VAR, functionVar);
  }

  private static int lightComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).sum();
  }

  private static int heavyComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).reduce((t, x) -> t * x).getAsInt();
  }
}

Ruby

functions/tips/scopes/app.rb

Afficher sur GitHub Commentaires

# Global (instance-wide) scope.
# This block runs on cold start, before any function is invoked.
#
# Note: It is usually best to run global initialization in an on_startup block
# instead at the top level of the Ruby file. This is because top-level code
# could be executed to verify the function during deployment, whereas an
# on_startup block is run only when an actual function instance is starting up.
FunctionsFramework.on_startup do
  instance_data = perform_heavy_computation

  # To pass data into function invocations, the best practice is to set a
  # key-value pair using the Ruby Function Framework's built-in "set_global"
  # method. Functions can call the "global" method to retrieve the data by key.
  # (You can also use Ruby global variables or "toplevel" local variables, but
  # they can make it difficult to isolate global data for testing.)
  set_global :my_instance_data, instance_data
end

FunctionsFramework.http "tips_scopes" do |_request|
  # Per-function scope.
  # This method is called every time this function is called.
  invocation_data = perform_light_computation

  # Retrieve the data computed by the on_startup block.
  instance_data = global :my_instance_data

  "instance: #{instance_data}; function: #{invocation_data}"
end

Vous pouvez utiliser des variables globales à des fins d'optimisation, mais vous ne devez pas vous fier à l'état défini dans le champ d'application global par les appels de fonctions précédents. Pour plus d'informations, consultez la page Sans état.

Vous pouvez considérer que pour chaque instance de fonction, le champ d'application global aura été exécuté une fois avant que votre code de fonction ne soit appelé. Toutefois, vous ne devez pas dépendre du nombre total d'exécutions de champ d'application global, ni de leur planification, car elles peuvent varier en fonction de l'activité de l'autoscaling.

Chronologie d'exécution des fonctions

Une fonction n'a accès à ses ressources allouées (mémoire et processeur) que pendant sa durée d'exécution. L'exécution du code en dehors de la période d'exécution n'est pas garantie et peut être interrompue à tout moment. Par conséquent, vous devez toujours signaler la fin de l'exécution de votre fonction et éviter d'exécuter du code au-delà. Pour obtenir des conseils, consultez les pages Fonctions HTTP, Fonctions d'arrière-plan et Fonctions CloudEvent.

L'exécution d'une fonction est également soumise à un délai d'inactivité. Pour en savoir plus, consultez la section Délai d'inactivité d'une fonction.

Tenez compte de la chronologie d'exécution lors de l'initialisation de votre application. Les tâches en arrière-plan ne doivent pas être créées dans le champ d'application global lors de l'initialisation, car elles s'exécutent en dehors de la durée d'une requête.

Garanties d'exécution

Vos fonctions sont généralement appelées une seule fois pour chaque événement entrant. Cependant, Cloud Functions ne garantit pas un appel unique dans tous les cas, en raison de différences dans les scénarios d'erreur.

Le nombre maximum ou minimum d'appels de fonctions pour un seul événement dépend du type de fonction :

• Les fonctions HTTP sont appelées au maximum une fois. Cela est dû à la nature synchrone des appels HTTP. Ainsi, toute erreur survenant lors de l'appel de la fonction sera affichée sans nouvelle tentative. L'appelant d'une fonction HTTP doit assumer la gestion des erreurs, ainsi que des nouvelles tentatives, le cas échéant.

• Les fonctions basées sur des événements sont appelées au moins une fois. Cela est dû à la nature asynchrone de la gestion de ces événements, dans lesquels aucun appelant n'attend de réponse. Dans de rares cas, le système peut appeler plusieurs fois une fonction basée sur des événements, afin d'assurer la diffusion de l'événement. Si un appel de fonction basée sur des événements échoue et renvoie une erreur, cet appel ne sera pas renouvelé, sauf si des tentatives en cas d'échec sont activées pour cette fonction.

Pour vous assurer que votre fonction se comporte correctement lors de nouvelles tentatives d’exécution, vous devez la rendre idempotente en la mettant en œuvre de sorte qu'un événement produise les résultats souhaités (et les effets secondaires), même s’il est transmis plusieurs fois. Dans le cas des fonctions HTTP, cela signifie également renvoyer la valeur souhaitée, même si l'appelant réessaie d'appeler le point de terminaison de la fonction HTTP. Consultez la page Effectuer de nouvelles tentatives d'exécution des fonctions basées sur des événements pour plus d'informations sur la manière de rendre votre fonction idempotente.

Mémoire et système de fichiers

Chaque fonction dispose d'une certaine quantité de mémoire allouée à son utilisation. Vous pouvez configurer la quantité de mémoire au déploiement. Pour en savoir plus, consultez la section Limites de mémoire.

L'environnement d'exécution de fonction inclut un système de fichiers en mémoire contenant les fichiers sources et les répertoires déployés avec votre fonction (voir Structurer le code source). Le répertoire contenant vos fichiers source est en lecture seule, mais le reste du système de fichiers est accessible en écriture (à l'exception des fichiers utilisés par le système d'exploitation). L'utilisation du système de fichiers est comptabilisée dans l'utilisation de la mémoire d'une fonction.

Votre fonction peut interagir avec le système de fichiers à l'aide de méthodes standards dans chaque langage de programmation.

Remarque : Dans l'environnement d'exécution Cloud Functions, le répertoire racine du code source de votre fonction est le répertoire de travail actuel (.), à l'exception des environnements d'exécution Go, où le répertoire racine du code source de votre fonction se trouve sous le répertoire de travail actuel à l'emplacement ./serverless_function_source_code.

Réseau

Votre fonction peut accéder à l'Internet public en utilisant des méthodes standards dans chaque langage de programmation, que ce soit via des bibliothèques intégrées proposées par l'environnement d'exécution ou des bibliothèques tierces que vous incluez en tant que dépendances.

Essayez de réutiliser les connexions réseau pour vos appels de fonctions, comme décrit dans la section Optimisation des réseaux. Notez toutefois qu'une connexion inutilisée pendant 10 minutes peut être fermée par le système et que toute nouvelle tentative d'utilisation d'une connexion fermée entraîne une erreur de type "Connexion réinitialisée". Votre code doit utiliser une bibliothèque qui gère les connexions fermées de manière appropriée, ou bien les gérer explicitement si vous utilisez des constructions réseau de bas niveau.

Isolation de fonction

Chaque fonction déployée est isolée de toutes les autres fonctions, même celles déployées à partir du même fichier source. Plus précisément, elles ne partagent pas de mémoire, de variables globales, de systèmes de fichiers ou d'autres états.

Pour partager des données entre des fonctions déployées, vous pouvez utiliser des services tels que Memorystore, Datastore, Firestore ou Cloud Storage. Vous pouvez également appeler une fonction à partir d'une autre en utilisant les déclencheurs appropriés et en transmettant les données nécessaires. Par exemple, envoyez une requête HTTP au point de terminaison d'une fonction HTTP ou publiez un message dans un sujet Pub/Sub pour déclencher une fonction Pub/Sub.