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 LambdaLimitations

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 dimensionner les événements, 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 fonctionnalités d'actualisation de l'instance. Il génère également une charge utile JSON correspondant à l'ampleur des événements qu'il peut déclencher 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 mise hors service en raison de l'ampleur des événements et des résiliations basées sur le rafraîchissement de l'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. Quelle que soit l'échelle, elle continue d'essayer tant que la capacité souhaitée par le 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 est terminé, il détecte que la capacité actuelle de votre groupe est supérieure à la capacité souhaitée et lance une échelle en cas d'événement.

  • Une politique de résiliation personnalisée n'affecte pas votre capacité à utiliser également l'échelle de protection pour empêcher la résiliation de certaines instances. Pour de plus amples informations, veuillez consulter Utiliser la protection évolutive de l'instance pour contrôler la fermeture de l'instance.

  • Si votre fonction Lambda ne renvoie aucune instance, cela n'empêche pas automatiquement toute terminaison. Amazon EC2 Auto Scaling continuera de mettre fin aux instances considérées comme incorrectes par les bilans de santé d'Auto Scaling, quelles que soient les politiques de résiliation.

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 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 de plus amples informations, veuillez consulter 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.

Limitations

  • 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 échelle active 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.

  • Les fonctions Lambda entre comptes ne sont pas prises en charge. La fonction Lambda utilisée comme politique de terminaison personnalisée doit appartenir au même groupe Compte AWS que le groupe Auto Scaling. Les instructions de configuration de cette page se concentrent spécifiquement sur les configurations de même compte.

  • Les politiques de résiliation personnalisées ne s'appliquent pas aux instances défectueuses. Les instances défectueuses sont toujours considérées comme éligibles à la résiliation, et la fonction Lambda évalue uniquement l'ordre de résiliation pour les instances restantes.