Créer une politique de résiliation personnalisée avec Lambda - Amazon EC2 Auto Scaling
Données d'entréeDonnées de réponse ConsidérationsCréer la fonction LambdaLimites

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.

Créer une politique de résiliation personnalisée avec Lambda

Amazon EC2 Auto Scaling utilise des politiques de résiliation pour hiérarchiser les instances à résilier en premier lorsque vous diminuez la taille de votre groupe Auto Scaling (appelé Mise à l'échelle horizontale). Votre groupe Auto Scaling utilise une politique de résiliation par défaut, mais vous pouvez éventuellement choisir ou créer vos propres politiques de résiliation. Pour plus d'informations sur le choix d'une politique de résiliation prédéfinie, consultez Configurer les politiques de résiliation pour Amazon EC2 Auto Scaling.

Dans cette rubrique, vous allez apprendre à créer une politique de résiliation personnalisée à l'aide d'une fonction AWS Lambda qu'Amazon EC2 Auto Scaling appelle en réponse à certains événements. La fonction Lambda que vous créez traite les informations contenues dans les données d'entrée envoyées par Amazon EC2 Auto Scaling et renvoie une liste d'instances prêtes à être résiliées.

Une politique de résiliation personnalisée offre un meilleur contrôle sur les instances qui sont résiliées et à quel moment. Par exemple, lorsque votre groupe Auto Scaling est dimensionné, Amazon EC2 Auto Scaling ne peut pas déterminer si certaines charges de travail en cours d'exécution ne doivent pas être perturbées. Avec une fonction Lambda, vous pouvez valider la demande de résiliation et attendre que la charge de travail soit terminée avant de renvoyer l'ID d'instance à Amazon EC2 Auto Scaling pour la résiliation.

Données d'entrée

Amazon EC2 Auto Scaling génère une charge utile JSON pour les événements de mise à l'échelle horizontale, et le fait également lorsque les instances sont sur le point d'être résiliées en raison de la durée de vie maximale de l'instance ou des fonctions d'actualisation de l'instance. Il génère également une charge utile JSON pour les événements de mise à l'échelle horizontale qu'il peut initier lors du rééquilibrage de votre groupe entre les zones de disponibilité.

Cette charge utile contient des informations sur la capacité qu'Amazon EC2 Auto Scaling doit résilier, une liste des instances qu'il suggère pour la résiliation et l'événement qui a déclenché la résiliation.

Voici un exemple de charge utile :

{
  "AutoScalingGroupARN": "arn:aws:autoscaling:us-east-1:<account-id>:autoScalingGroup:d4738357-2d40-4038-ae7e-b00ae0227003:autoScalingGroupName/my-asg",
  "AutoScalingGroupName": "my-asg",
  "CapacityToTerminate": [
    {
      "AvailabilityZone": "us-east-1b",
      "Capacity": 2,
      "InstanceMarketOption": "on-demand"
    },
    {
      "AvailabilityZone": "us-east-1b",
      "Capacity": 1,
      "InstanceMarketOption": "spot"
    },
    {
      "AvailabilityZone": "us-east-1c",
      "Capacity": 3,
      "InstanceMarketOption": "on-demand"
    }
  ],
  "Instances": [
    {
      "AvailabilityZone": "us-east-1b",
      "InstanceId": "i-0056faf8da3e1f75d",
      "InstanceType": "t2.nano",
      "InstanceMarketOption": "on-demand"
    },
    {
      "AvailabilityZone": "us-east-1c",
      "InstanceId": "i-02e1c69383a3ed501",
      "InstanceType": "t2.nano",
      "InstanceMarketOption": "on-demand"
    },
    {
      "AvailabilityZone": "us-east-1c",
      "InstanceId": "i-036bc44b6092c01c7",
      "InstanceType": "t2.nano",
      "InstanceMarketOption": "on-demand"
    },
    ...
  ],
  "Cause": "SCALE_IN"
}

La charge utile inclut le nom du groupe Auto Scaling, son nom Amazon Resource Name (ARN) et les éléments suivants :

  • CapacityToTerminate décrit la quantité de votre capacité Spot ou à la demande définie pour être résiliée dans une zone de disponibilité donnée.

  • Instances représente les instances qu'Amazon EC2 Auto Scaling suggère pour la résiliation en fonction des informations contenues dans CapacityToTerminate.

  • Cause décrit l'événement qui a provoqué la résiliation : SCALE_IN, INSTANCE_REFRESH, MAX_INSTANCE_LIFETIME ou REBALANCE.

Les informations suivantes décrivent les facteurs les plus significatifs dans la façon dont Amazon EC2 Auto Scaling génère les Instances dans les données d'entrée :

  • Le maintien de l'équilibre entre les zones de disponibilité est prioritaire lorsqu'une instance est résiliée en raison d'événements de mise à l'échelle horizontale et de résiliations basées sur l'actualisation d'instance. Par conséquent, si une zone de disponibilité compte plus d'instances que les autres zones de disponibilité utilisées par le groupe, les données d'entrée contiennent des instances qui ne peuvent être résiliées qu'à partir de la zone de disponibilité déséquilibrée. Si les zones de disponibilité utilisées par le groupe sont équilibrées, les données en entrée contiennent des instances de toutes les zones de disponibilité pour le groupe.

  • Lors de l'utilisation d'une politique d'instances mixtes, le maintien de l'équilibre de vos capacités Spot et à la demande en fonction des pourcentages souhaités pour chaque option d'achat est également prioritaire. Nous identifions d'abord lequel des deux types (Spot ou à la demande) doit être résilié. Nous identifions ensuite les instances (dans le cadre de l'option d'achat identifiée) dans lesquelles nous pouvons résilier les zones de disponibilité qui permettront d'équilibrer les zones de disponibilité.

Données de réponse

Les données d'entrée et les données de réponse fonctionnent ensemble pour affiner la liste des instances à résilier.

Avec l'entrée donnée, la réponse de votre fonction Lambda devrait ressembler à l'exemple suivant :

{
  "InstanceIDs": [
    "i-02e1c69383a3ed501",
    "i-036bc44b6092c01c7",
    ...
  ]
}

Dans la réponse, InstanceIDs représentent les instances qui sont prêtes à être résiliées.

Vous pouvez également renvoyer un ensemble différent d'instances prêtes à être résiliées, ce qui remplace les instances dans les données d'entrée. Si aucune instance n'est prête à être résiliée lorsque votre fonction Lambda est invoquée, vous pouvez également choisir de ne pas renvoyer d'instances.

Si aucune instance n'est prête à être mise hors service, la réponse de votre fonction Lambda devrait ressembler à l'exemple suivant :

{
  "InstanceIDs": [ ]
}

Considérations

Tenez compte des éléments suivants lors de l'utilisation d'une politique de résiliation personnalisée :

  • Le renvoi d'une instance en premier dans les données de réponse ne garantit pas sa résiliation. Si le nombre d'instances renvoyées lors de l'appel de votre fonction Lambda est supérieur au nombre requis, Amazon EC2 Auto Scaling évalue chaque instance en fonction des autres politiques de résiliation que vous avez spécifiées pour votre groupe Auto Scaling. Lorsqu'il existe plusieurs politiques de résiliation, il tente d'appliquer la politique de résiliation suivante dans la liste, et s'il y a plus d'instances que nécessaire pour la résiliation, il passe à la politique de résiliation suivante, et ainsi de suite. Si aucune autre politique de résiliation n'est spécifiée, la politique de résiliation par défaut est utilisée pour déterminer les instances à résilier.

  • Si aucune instance n'est renvoyée ou si votre fonction Lambda expire, Amazon EC2 Auto Scaling attend peu de temps avant d'appeler à nouveau votre fonction. Pour tout événement de mise à l'échelle horizontale, il continue d'essayer tant que la capacité souhaitée du groupe est inférieure à sa capacité actuelle. Pour les résiliations basées sur l'actualisation d'instance, il effectue de nouvelles tentatives pendant une heure. Après cela, s'il ne parvient toujours pas à résilier les instances, l'opération d'actualisation de l'instance échoue. Avec la durée de vie maximale de l'instance, Amazon EC2 Auto Scaling continue d'essayer de résilier l'instance qui est identifiée comme dépassant sa durée de vie maximale.

  • Parce que votre fonction est retentée à plusieurs reprises, assurez-vous de tester et de corriger toutes les erreurs permanentes dans votre code avant d'utiliser une fonction Lambda comme politique de résiliation personnalisée.

  • Si vous remplacez les données en entrée par votre propre liste d'instances à résilier et que la résiliation de ces instances déséquilibre les zones de disponibilité, Amazon EC2 Auto Scaling rééquilibre progressivement la distribution de la capacité entre les zones de disponibilité. Tout d'abord, il appelle votre fonction Lambda pour voir si des instances sont prêtes à être résiliées afin de déterminer s'il faut commencer le rééquilibrage. Si des instances sont prêtes à être résiliées, elles lancent d'abord de nouvelles instances. Lorsque le lancement des instances se termine, il détecte alors que la capacité actuelle de votre groupe est supérieure à la capacité désirée et lance un événement évolutif.

  • Une politique de résiliation personnalisée n’affecte pas votre capacité à utiliser également une protection contre la mise à l’échelle horizontale des tâches pour empêcher la résiliation de certaines instances. Pour plus d’informations, consultez Utiliser la protection de la taille d'instance.

Créer la fonction Lambda

Commencez par créer la fonction Lambda afin que vous puissiez spécifier son Amazon Resource Name (ARN) dans les politiques de résiliation de votre groupe Auto Scaling.

Pour créer une fonction Lambda (console)

  1. Ouvrez la page Functions (Fonctions) sur la console Lambda.

  2. Dans la barre de navigation située en haut de l'écran, choisissez la même région que celle utilisée lorsque vous avez créé le groupe Auto Scaling.

  3. Sélectionnez Create function (Créer une fonction), puis Author from scratch (Créer à partir de zéro).

  4. Sous Informations de base, dans Nom de fonction, entrez le nom de votre fonction.

  5. Sélectionnez Create function (Créer une fonction). Vous retournez au code et à la configuration de la fonction.

  6. Avec votre fonction toujours ouverte dans la console, sous Function code (Code de fonction), collez votre code dans l'éditeur.

  7. Choisissez Deploy (Déployer).

  8. Vous pouvez également créer une version publiée de la fonction Lambda en choisissant l'option Versions, puis Publish new version (Publier une nouvelle version). Pour en savoir plus sur la gestion des versions dans Lambda, veuillez consulter Versions de fonctions Lambda dans le Guide du développeur AWS Lambda .

  9. Si vous avez choisi de publier une version, choisissez l'option Alias si vous voulez associer un alias à cette version de la fonction Lambda. Pour plus d'informations sur l'utilisation des alias Lambda, consultez Alias de fonction Lambda dans le Guide du développeur AWS Lambda .

  10. Ensuite, choisissez l'onglet Configuration, puis Permissions (Autorisations).

  11. Faites défiler l'écran jusqu'à Resource-based policy (Politique basée sur des ressources) puis choisissez Add permissions (Ajouter des autorisations). Une politique basée sur des ressources est utilisée pour accorder des autorisations pour appeler votre fonction au principal qui est spécifié dans la politique. Dans ce cas, le principal sera le rôle lié au service Amazon EC2 Auto Scaling associée au groupe Auto Scaling.

  12. Dans Policy statement (Déclaration de politique), configurez vos autorisations :

    1. Sélectionnez Compte AWS.

    2. Pour Principal , saisissez l'ARN du rôle lié au service appelant, par exemple, arn:aws:iam::<aws-account-id>:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling.

    3. Pour Action, choisissez lambda : InvokeFunction.

    4. Pour Statement ID (ID de l'instruction), saisissez un ID d'instruction unique, tel que AllowInvokeByAutoScaling.

    5. Choisissez Save (Enregistrer).

  13. Une fois que vous avez suivi ces instructions, l'étape suivante consiste à spécifier l'ARN de votre fonction dans les politiques de résiliation de votre groupe Auto Scaling. Pour plus d’informations, consultez Modifier la politique de résiliation d'un groupe Auto Scaling.

Note

Pour des exemples que vous pouvez utiliser comme référence pour développer votre fonction Lambda, consultez le GitHub référentiel Amazon EC2 Auto Scaling.

Limites

  • Vous ne pouvez spécifier qu'une seule fonction Lambda dans les politiques de résiliation pour un groupe Auto Scaling. Si plusieurs politiques de résiliation sont spécifiées, la fonction Lambda doit d'abord être spécifiée.

  • Vous pouvez référencer votre fonction Lambda en utilisant soit un ARN non qualifié (sans suffixe), soit un ARN qualifié qui a une version ou un alias comme suffixe. Si un ARN non qualifié est utilisé (par exemple, function:my-function), votre politique basée sur des ressources doit être créée sur la version non publiée de votre fonction. Si un ARN qualifié est utilisé (par exemple, function:my-function:1 ou function:my-function:prod), votre politique basée sur les ressources doit être créée sur cette version publiée spécifique de votre fonction.

  • Vous ne pouvez pas utiliser un ARN qualifié avec le suffixe $LATEST. Si vous essayez d'ajouter une politique de résiliation personnalisée qui fait référence à un ARN qualifié avec le suffixe $LATEST, cela entraînera une erreur.

  • Le nombre d'instances fournies dans les données d'entrée est limité à 30 000 instances. Si plus de 30 000 instances peuvent être résiliées, les données en entrée incluent "HasMoreInstances": truepour indiquer que le nombre maximal d'instances renvoyées sont renvoyées.

  • La durée maximale d'exécution de votre fonction Lambda est de deux secondes (2 000 millisecondes). Il est recommandé de définir la valeur de délai d'expiration de votre fonction Lambda en fonction du temps d'exécution prévu. Les fonctions Lambda ont un délai d'attente par défaut de trois secondes, mais cela peut être réduit.

  • Si votre temps d'exécution dépasse la limite de 2 secondes, toute action évolutive sera suspendue jusqu'à ce que le temps d'exécution tombe en dessous de ce seuil. Pour les fonctions Lambda dont les temps d'exécution sont constamment plus longs, trouvez un moyen de réduire le temps d'exécution, par exemple en mettant en cache les résultats afin qu'ils puissent être récupérés lors des appels Lambda suivants.