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 lors de la réduction de la taille de votre groupe Auto Scaling (ce que l'on appelle le scaling in). 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 apprendrez à créer une politique de résiliation personnalisée à l'aide d'une AWS Lambda fonction invoquée par Amazon EC2 Auto Scaling 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 mises hors service.

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 prend de l'ampleur, 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 de l'instance à Amazon EC2 Auto Scaling pour résiliation.

Données d'entrée

Amazon EC2 Auto Scaling génère une JSON charge utile 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 des instances. Il génère également une JSON charge utile 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é dont Amazon EC2 Auto Scaling a besoin pour mettre fin, une liste des instances suggérées pour la résiliation et l'événement à l'origine de 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 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.

  • Instancesreprésente les instances qu'Amazon EC2 Auto Scaling suggère de résilier sur la base des informations contenues dansCapacityToTerminate.

  • 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 principaux facteurs qui influencent la manière dont Amazon EC2 Auto Scaling génère Instances 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 est supérieur au nombre requis lorsque votre fonction Lambda est invoquée, Amazon EC2 Auto Scaling évalue chaque instance par rapport aux 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 un court instant 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 une durée de vie d'instance maximale, Amazon EC2 Auto Scaling continue d'essayer de mettre fin à l'instance 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 d'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.

Créer la fonction Lambda

Commencez par créer la fonction Lambda, afin de pouvoir 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é au groupe Auto Scaling.

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

    1. Sélectionnez Compte AWS.

    2. Pour Principal, entrez le ARN rôle lié au service d'appel, 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. Après avoir suivi ces instructions, continuez à spécifier la fonction ARN de votre fonction dans les politiques de résiliation de votre groupe Auto Scaling à l'étape suivante. 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.

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 à l'aide d'une fonction non qualifiée ARN (sans suffixe) ou d'une fonction qualifiée ARN dont le suffixe est une version ou un alias. Si une fonction non qualifiée ARN est utilisée (par exemple,function:my-function), votre politique basée sur les ressources doit être créée sur la version non publiée de votre fonction. Si une fonction qualifiée ARN est utilisée (par exemple, function:my-function:1 oufunction: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 qualificatif ARN avec le $LATEST suffixe. Si vous essayez d'ajouter une politique de résiliation personnalisée faisant référence à un qualifié ARN avec le $LATEST suffixe, une erreur se produira.

  • 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.