Cloud Functions est régional, ce qui signifie que l'infrastructure qui exécute votre fonction est située dans des régions spécifiques et gérée par Google pour être disponible de manière redondante dans toutes les zones de ces régions.
Au moment de sélectionner les régions dans lesquelles vos fonctions vont s'exécuter, vos principales considérations doivent être la latence et la disponibilité. Vous pouvez généralement sélectionner des régions proches de vos utilisateurs, mais vous devez également tenir compte de l'emplacement des autres produits et services utilisés par votre application. L'utilisation de services dans plusieurs régions peut avoir des répercussions sur la latence de votre application, ainsi que sur les tarifs.
Par défaut, les fonctions s'exécutent dans la région us-central1. Notez que cela peut être
différent de la région d'une source d'événements, comme un Cloud Storage bucket.
Découvrez comment
spécifier la région dans laquelle une fonction s'exécute
plus loin sur cette page.
Régions où le service est disponible
Dans les listes de cette section, l'icône energy_savings_leaf indique que l'électricité de cette région est produite avec de faibles émissions de carbone. Pour en savoir plus, consultez la section Une énergie sans carbone pour les régions Google Cloud.
Tarifs de niveau 1
Cloud Functions est disponible dans les régions suivantes avec des tarifs de niveau 1 :
| Région | Emplacement | Versions de produit compatibles | Émissions de CO2 |
|---|---|---|---|
africa-south1 |
Johannesburg | 2e génération uniquement | |
asia-east1 |
Taïwan | 1st gen, 2nd gen | |
asia-east2 |
Hong Kong | 1re génération uniquement | |
asia-northeast1 |
Tokyo | 1st gen, 2nd gen | |
asia-northeast2 |
Osaka | 1st gen, 2nd gen | |
europe-north1 |
Finlande | 2e génération uniquement | energy_savings_leaf |
europe-southwest1 |
Madrid | 2e génération uniquement | |
europe-west1 |
Belgique | 1st gen, 2nd gen | energy_savings_leaf |
europe-west4 |
Pays-Bas | 2e génération uniquement | |
europe-west8 |
Milan | 2e génération uniquement | |
europe-west9 |
Paris | 2e génération uniquement | energy_savings_leaf |
me-west1 |
Tel Aviv | 2e génération uniquement | |
europe-west2 |
Londres | 1re génération uniquement | |
us-central1 |
Iowa | 1st gen, 2nd gen | energy_savings_leaf |
us-east1 |
Caroline du Sud | 1st gen, 2nd gen | |
us-east4 |
Virginie du Nord | 1st gen, 2nd gen | |
us-east5 |
Columbus | 2e génération uniquement | |
us-south1 |
Dallas | 2e génération uniquement | |
us-west1 |
Oregon | 1st gen, 2nd gen | energy_savings_leaf |
Tarifs de niveau 2
Cloud Functions est disponible dans les régions suivantes avec des tarifs de niveau 2 :
| Région | Emplacement | Versions de produit compatibles | Émissions de CO₂ |
|---|---|---|---|
asia-east2 |
Hong Kong | 2e génération uniquement | |
asia-northeast3 |
Séoul | 1st gen, 2nd gen | |
asia-southeast1 |
Singapour | 1st gen, 2nd gen | |
asia-southeast2 |
Jakarta | 1st gen, 2nd gen | |
asia-south1 |
Mumbai | 2e génération uniquement | |
asia-south2 |
Delhi, Inde | 2e génération uniquement | |
australia-southeast1 |
Sydney | 1st gen, 2nd gen | |
australia-southeast2 |
Melbourne | 2e génération uniquement | |
europe-central2 |
Varsovie | 1st gen, 2nd gen | |
europe-west2 |
Londres | 2e génération uniquement | |
europe-west3 |
Francfort | 1st gen, 2nd gen | energy_savings_leaf |
europe-west6 |
Zurich | 1st gen, 2nd gen | energy_savings_leaf |
europe-west10 |
Berlin | 2e génération uniquement | |
europe-west12 |
Turin | 2e génération uniquement | |
me-central1 |
Doha | 2e génération uniquement | |
me-central2 |
Dammam | 2e génération uniquement | |
northamerica-northeast1 |
Montréal | 1st gen, 2nd gen | energy_savings_leaf |
northamerica-northeast2 |
Toronto | 2e génération uniquement | energy_savings_leaf |
southamerica-east1 |
São Paulo | 1st gen, 2nd gen | energy_savings_leaf |
southamerica-west1 |
Santiago, Chili | 2e génération uniquement | |
us-west2 |
Los Angeles | 1st gen, 2nd gen | |
us-west3 |
Salt Lake City | 1st gen, 2nd gen | |
us-west4 |
Las Vegas | 1st gen, 2nd gen |
Les fonctions dans une région donnée au sein d'un projet donné doivent porter des noms uniques (non sensibles à la casse ). Par contre, les fonctions interrégionales ou sur plusieurs projets peuvent partager le même nom.
Bonnes pratiques pour spécifier une région
Par défaut, les fonctions s'exécutent dans la région us-central1. Notez que cela peut être
différent de la région d'une source d'événements, comme un Cloud Storage bucket. Si
vous devez spécifier la région dans laquelle une fonction s'exécute, suivez les
recommandations de cette section pour chaque type de déclencheur de fonction.
Pour définir la région dans laquelle une fonction s'exécute, définissez le paramètre region dans la
définition de la fonction comme suit :
Node.js
exports.firestoreAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
Python
# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
pass
# After
@firestore_fn.on_document_created("my-collection/{docId}",
region="asia-northeast1")
def firestore_trigger_asia(event):
pass
Vous pouvez spécifier plusieurs régions en transmettant plusieurs chaînes de région séparées par une virgule
dans region. Notez également que, lorsque vous spécifiez une région pour de nombreux
types de déclencheurs en arrière-plan, vous devez spécifier le filtre d'événement approprié
avec la région. Dans l'exemple ci-dessus, il s'agit du Cloud Firestore document
qui émet l'événement. Pour un Cloud Storage déclencheur, le filtre d'événement
peut être bucket, pour un déclencheur Pub/Sub, il s'agit de topic, et ainsi de suite.
Pour en savoir plus sur la modification de la région d'une fonction qui gère le trafic de production, consultez la section Modifier la région d'une fonction.
Fonctions HTTP et fonctions appelables par le client
Pour les fonctions HTTP et les fonctions appelables, nous vous recommandons de commencer par définir votre fonction sur la région de destination ou la plus proche de l'emplacement de la plupart des clients attendus, et puis de modifier votre fonction d'origine pour rediriger sa requête HTTP vers la nouvelle fonction (elles peuvent avoir le même nom). Si les clients de votre fonction HTTP sont compatibles avec les redirections, vous pouvez simplement modifier votre fonction d'origine pour qu'elle renvoie un état de redirection HTTP (301) avec l'URL de votre nouvelle fonction. Si vos clients ne gèrent pas les redirections correctement, vous pouvez transférer la requête de la fonction d'origine vers la nouvelle fonction en envoyant une nouvelle requête de la fonction d'origine vers la nouvelle fonction. La dernière étape consiste à vous assurer que tous les clients appellent la nouvelle fonction.
Sélection de l'emplacement côté client pour les fonctions appelables
En ce qui concerne la fonction appelable, les configurations appelables par le client doivent suivre les mêmes
consignes que les fonctions HTTP. Le client peut également spécifier une région, et
doit le faire si la fonction s'exécute dans une région autre que us-central1.
Pour définir des régions sur le client, spécifiez la région souhaitée lors de l'initialisation :
Swift
lazy var functions = Functions.functions(region:"europe-west1")
Objective-C
@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];
Web
var functions = firebase.app().functions('europe-west1');
Android
private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");
C++
firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");
Unity
firebase.Functions.FirebaseFunctions functions;
functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");
Fonctions d'arrière-plan
Les fonctions d'arrière-plan adoptent la sémantique de diffusion d'événements "au moins une fois" : cela signifie que dans certaines circonstances, elles peuvent recevoir des événements dupliqués. Vous devez donc implémenter des fonctions pour qu'elles soient idempotentes. Si votre fonction est déjà idempotente, vous pouvez la redéployer dans la nouvelle région avec le même déclencheur d'événements et supprimer l'ancienne fonction après avoir vérifié que la nouvelle fonction reçoit correctement le trafic. Pendant cette transition, les deux fonctions recevront des événements. Pour connaître la séquence de commandes recommandée pour modifier les régions des fonctions, consultez la section Modifier la région d'une fonction.
Si votre fonction n'est pas idempotente pour le moment ou si son idempotence ne s' étend pas au-delà de la région, nous vous conseillons de commencer par implémenter l'idempotence avant de déplacer la fonction.
Les recommandations optimales concernant les régions varient en fonction du type de déclencheur d'événement :
| Type de déclencheur | Recommandation concernant la région |
|---|---|
| Cloud Firestore | Région la plus proche de l'emplacement de l'instance Cloud Firestore (voir la section suivante) |
| Realtime Database | Même région que l'instance Realtime Database |
| Cloud Storage | Région la plus proche de l'emplacement du bucket Cloud Storage (voir la section suivante) |
| Autres | Si vous interagissez avec une Realtime Database instance, une Cloud Firestore
instance ou un Cloud Storage bucket dans la fonction, la région recommandée
est la même que si vous aviez une fonction déclenchée par l'une de ces
ressources. Sinon, utilisez la région par défaut us-central1.
Les fonctions connectées à Firebase Hosting peuvent se trouver dans n'importe quelle région, mais consultez
la présentation de l'hébergement sans serveur pour obtenir des recommandations. |
Sélectionner des régions en fonction des emplacements Cloud Firestore et Cloud Storage
Les régions disponibles pour les fonctions ne correspondent pas toujours précisément aux régions disponibles pour votre Cloud Firestore base de données et vos Cloud Storage buckets.
Notez que si votre fonction et votre ressource (instance de base de données ou Cloud Storage bucket) se trouvent à des emplacements différents, il se peut que vous rencontriez des taux de latence plus élevés et que vous constatiez une hausse des coûts de facturation.
Voici un mappage des régions compatibles avec les fonctions les plus proches pour Cloud Firestore et Cloud Storage, dans les cas où la même région n'est pas compatible :
| Région/Multirégion pour Cloud Firestore et Cloud Storage | Région la plus proche pour les fonctions |
|---|---|
nam5 ou us-central (multirégion) |
us-central1 |
eur3 ou europe-west (multirégion) |
europe-west1 |
europe-west4 (Pays-Bas) |
europe-west1 |
asia-south1 (Mumbai) |
asia-east2 |
asia-south2 (Delhi) |
asia-east2 |
australia-southeast2 (Melbourne) |
australia-southeast1 |