Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Multi-Region déploiement
Pour les points de PerRegionterminaison MultiRegionet les points de terminaison, Lambda réplique les artefacts d'exécution dans toutes les régions cibles afin que votre application puisse desservir le trafic à proximité des utilisateurs finaux. Vous gérez la fonction Web entièrement depuis la région d'origine. Les ressources répliquées ne sont ni visibles ni modifiables dans les régions de réplication.
Le schéma suivant montre comment le plan de contrôle de la région d'origine prépare une révision et réplique son code et sa configuration dans une région de réplication, et comment les clients atteignent MultiRegionles points de PerRegionterminaison. Une région de réplique ne possède aucun plan de contrôle. Un MultiRegionpoint de terminaison possède un domaine global qui est acheminé par latence, et non par état de santé de la région. Pour un PerRegionpoint de terminaison, vous gérez la manière dont les clients accèdent au domaine régional dans chaque région, par exemple avec les enregistrements Route 53 ou CloudFront. Vous définissez le type de point de terminaison et les régions lorsque vous créez le point de terminaison, et vous ne pourrez pas les modifier ultérieurement.
Rubriques
Ce que Lambda reproduit
Lambda réplique les éléments suivants dans chaque région cible :
-
Artefact de code préparé : artefact d'exécution interne que Lambda dérive de l'objet source Amazon S3 versionné.
-
Configuration des révisions : délai d'expiration, simultanéité, variables d'environnement et paramètres d'exécution.
-
Resource-based politiques — Politiques associées à la fonction Web qui accordent l'accès à celle-ci.
-
Balises — Les balises de la fonction Web.
Les quotas pour les fonctions Web s'appliquent par Région AWS. Chaque région cible applique ses propres quotas de compte sur le point de terminaison répliqué. Par exemple, le dimensionnement de l'environnement d'exécution dans une région de réplication est limité par le quota de vCPU du compte de cette région. Pour les quotas de compte, voirQuotas de comptes.
Visibilité des répliques
Les ressources répliquées ne sont pas visibles dans les régions de réplication. Le plan de contrôle d'une fonction Web n'est desservi que dans sa région d'origine, de sorte que toutes les demandes d'API doivent être envoyées à la région d'origine. Cela inclut notamment les éléments suivants :
-
Répertoriez, obtenez et décrivez les demandes relatives à la fonction Web, à ses révisions et à ses points de terminaison.
-
Créez, mettez à jour et supprimez des demandes pour la fonction, les révisions et la configuration du point de terminaison.
Une demande d'API envoyée au point de terminaison du plan de contrôle d'une région répliquée échoue, quel que soit l'endroit où se trouve l'appelant. Les artefacts d'exécution répliqués existent uniquement pour que le plan de données serve le trafic.
Quand la réplication a lieu
La réplication est déclenchée lorsque vous créez ou mettez à jour un MultiRegionpoint de PerRegionterminaison. Plus précisément, la réplication a lieu lorsque :
-
Vous créez un point de PerRegion terminaison MultiRegion ou avec des pondérations de révision pointant vers une révision.
-
Vous mettez à jour les pondérations de révision sur un MultiRegion PerRegion point de terminaison pour inclure une nouvelle révision.
-
Vous mettez à jour d'autres paramètres de point de terminaison
authType, tels quescalingConfig, outhrottleConfig, sur un point de PerRegion terminaison MultiRegion ou.
La création d'une révision à elle seule ne déclenche pas la réplication. La révision doit être incluse dans les poids de révision d'un point de terminaison dont les régions cibles sont configurées. Étant donné que seul le mode de déploiement automatique désactivé est disponible pour les PerRegion terminaux MultiRegion et les terminaux, la réplication est toujours le résultat d'une modification apportée au point de terminaison.
Fonctionnement du routage
Le comportement du routage dépend du type de point de terminaison :
- MultiRegion
-
Lambda fournit un nom de domaine global unique. Les demandes sont acheminées à l'aide d'un routage basé sur la latence. Les demandes sont acheminées vers la région qui fournit généralement la latence réseau la plus faible pour l'appelant, sur la base des mesures de latence collectées par Route 53 au fil du temps. Étant donné que la latence d'Internet change, Lambda ne garantit pas que chaque requête soit envoyée vers la région à latence la plus faible. Lambda gère automatiquement les itinéraires pour vous.
- PerRegion
-
Lambda fournit un nom de domaine régional distinct dans chaque région cible. Vous êtes responsable de la gestion de la manière dont le trafic atteint chaque domaine régional. Par exemple, vous pouvez configurer votre propre politique de routage Route 53 ou placer une CloudFront distribution devant les domaines régionaux.
Défaillances de réplication
La réplication peut échouer dans une région en raison d'un problème de service temporaire. Si vous chiffrez votre fonction Web avec une clé gérée par le client, une réplique de clé manquante dans la région cible entraîne également l'échec de la réplication. Pour les principales exigences relatives à plusieurs régions, voirConfiguration d'une clé gérée par le client.
L'effet d'un échec de réplication dépend de la création ou de la mise à jour du point de terminaison. Si la réplication échoue dans une région pendant que Lambda crée le point de terminaison, le point de terminaison passe à l'état d'échec et n'est invoquable dans aucune région. Pour réessayer, supprimez le point de terminaison et créez-le à nouveau. Si la réplication échoue dans une région lors de la mise à jour d'un terminal, l'échec est limité à cette région. Le point de terminaison reste invocable et les autres régions continuent de fonctionner normalement.
Lorsque la réplication d'une nouvelle révision échoue dans une région, cette région continue de desservir le trafic en utilisant la révision précédente qui a été déployée avec succès. Le point de terminaison ne revient pas en arrière. Il continue de fonctionner avec le dernier bon état connu de chaque région.
Vous pouvez consulter l'état de chaque région et le mettre à jour dans le regionalEndpoints champ de la GetWebFunctionEndpoint réponse. L'inscription de chaque région inclut :
-
stateetstateReason— État de déploiement de la région lors de la création du point de terminaison. -
updateStatusetupdateStatusReason— Le résultat de la dernière mise à jour (par exemple, le déploiement d'une révision) pour cette région.
Pour résoudre un échec de réplication, traitez la cause première (par exemple, créez une réplique AWS KMS clé dans la région affectée). Pour réessayer la mise à jour d'un terminal qui a échoué une fois que vous en avez résolu la cause première, appelez UpdateWebFunctionEndpoint à nouveau. Vous pouvez répéter les mêmes paramètres ou spécifier uniquement le nom de la fonction et le nom du point de terminaison. L'une ou l'autre demande lance un nouveau déploiement dans les régions cibles. Cela ne fonctionne que lorsque le point de terminaison est actif. Si la création du point de terminaison a échoué, supprimez-le et créez-le à nouveau.
Cohérence à terme
La réplication des artefacts d'exécution est finalement cohérente. Ne partez pas du principe que chaque région exécute la nouvelle configuration tant que chaque région ne figure pas updateStatus dans regionalEndpoints les rapportsSuccessful.
Resource-based les modifications de politique peuvent cesser de se propager après les modifications du code et de la configuration. Au cours de la fenêtre de réplication, les demandes dans les régions de réplication peuvent être évaluées par rapport à la version précédente de la politique. Pour plus d'informations, consultez Réplication et cohérence éventuelle.
