Environnements de travail Elastic Beanstalk

Si votre application AWS Elastic Beanstalk effectue des opérations ou des flux de travail qui prennent beaucoup de temps, vous pouvez décharger ces tâches dans un environnement de travail dédié. Le découplage de l'élément frontal de votre application web d'un processus qui effectue des opérations de blocage est une façon courante de garantir que votre application reste réactive sous charge.

Une tâche à long terme est tout ce qui accroît considérablement le temps nécessaire pour effectuer une demande, tel que le traitement d'images ou de vidéos, l'envoi d'e-mails ou la génération d'une archive ZIP. Ces opérations peuvent ne prendre qu'une ou deux secondes, mais un délai de quelques secondes est beaucoup pour une requête web qui aboutirait sinon en moins de 500 ms.

Une option consiste à générer dynamiquement un processus de travail localement, à renvoyer une réussite et à traiter la tâche de manière asynchrone. Cela fonctionne si votre instance peut faire face à toutes les tâches qui lui sont envoyées. Sous une charge élevée, toutefois, une instance peut être submergée par des tâches en arrière-plan et arrêter de répondre à des demandes de priorité plus élevée. Si des utilisateurs peuvent générer plusieurs tâches, l'augmentation de la charge peut ne pas correspondre à une augmentation des utilisateurs, ce qui complique l'augmentation de la taille de votre niveau de serveur web efficacement.

Pour éviter d'exécuter des tâches de longue durée localement, vous pouvez utiliser le kit SDK AWS comme langage de programmation pour les envoyer à une file d'attente Amazon Simple Queue Service (Amazon SQS) et exécuter le processus qui les exécute sur un ensemble distinct d'instances. Les instances de travail prennent des éléments de la file d'attente uniquement lorsqu'elles ont la capacité nécessaire pour les exécuter, ce qui leur évite d'être submergées.

Les environnements de travail Elastic Beanstalk simplifient ce processus en gérant la file d'attente Amazon SQS et en exécutant un processus démon sur chaque instance qui lit automatiquement depuis la file d'attente. Lorsque le démon extrait un élément de la file d'attente, il envoie une demande HTTP POST localement à http://localhost/ sur le port 80 avec le contenu du message de file d'attente dans le corps. Tout ce que votre application doit faire consiste à effectuer la tâche longue durée en réponse au POST. Vous pouvez configurer le démon pour publier vers un chemin d'accès différent, utiliser un type MIME autre qu'application/JSON, vous connecter à une file d'attente existante ou personnaliser des connexions (nombre maximal de demandes simultanées), des expirations et des nouvelles tentatives de connexion.

Avec des tâches périodiques, vous pouvez également configurer le démon de travail pour mettre en attente les messages en fonction d'une planification CRON. Chaque tâche périodique peut PUBLIER vers un chemin différent. Activez des tâches périodiques en incluant un fichier YAML dans votre code source qui définit le calendrier et le chemin d'accès pour chaque tâche.

Note

La plateforme .NET sous Windows Server ne prend pas en charge les environnements de travail.

Démon SQS d'environnement de travail

Les environnements de travail exécutent un processus démon fourni par Elastic Beanstalk. Ce démon est mis à jour régulièrement pour ajouter des fonctionnalités et résoudre des bogues. Pour obtenir la dernière version du démon, effectuez la mise à jour vers la version de la plateforme la plus récente.

Lorsque l'application dans l'environnement de travail renvoie une réponse 200 OK pour reconnaître qu'elle a reçu et traité avec succès la demande, le démon envoie un appel DeleteMessage à la file d'attente Amazon SQS afin que le message soit supprimé de la file d'attente. Si l'application renvoie une réponse autre que 200 OK, Elastic Beanstalk attend l'expiration de la période ErrorVisibilityTimeout configurée pour remettre le message dans la file d'attente. S'il n'y a pas de réponse, Elastic Beanstalk attend pour remettre le message dans la file d'attente après la période InactivityTimeout afin que le message soit disponible pour une autre tentative au moment du traitement.

Note

Les propriétés des files d'attente Amazon SQS (ordre des messages, livraison au moins une fois et échantillonnage de message) peuvent affecter la façon dont vous concevez une application web pour un environnement de travail. Pour plus amples informations, veuillez consulter à Propriétés des files d'attente distribuées dans le Guide du développeur Amazon Simple Queue Service.

Amazon SQS supprime automatiquement les messages qui ont été dans une file d'attente pendant une durée supérieure à la RetentionPeriod configurée.

Le démon définit les en-têtes HTTP suivants.

En-têtes HTTP
Name (Nom)	Valeur
User-Agent	aws-sqsd aws-sqsd/1.11
X-Aws-Sqsd-Msgid	ID de message SQS, utilisé pour détecter des tempête de messages (un nombre anormalement élevé de nouveaux messages).
X-Aws-Sqsd-Queue	Nom de la file d'attente SQS.
X-Aws-Sqsd-First-Received-At	Le temps UTC, au format ISO 8601, lorsque le message a été reçu pour la première fois.
X-Aws-Sqsd-Receive-Count	Nombre de message SQS reçus.
X-Aws-Sqsd-Attr-message-attribute-name	Attributs de message personnalisé attribués au message en cours de traitement. Le message-attribute-name est le nom d'attribut de message réel. Tous les attributs de message de numéro et de chaîne sont ajoutés à l'en-tête. Les attributs binaires sont ignorés et ils ne sont pas inclus dans l'en-tête.
Content-Type	Configuration de type MIME ; par défaut, application/json.

Files d'attente de lettres mortes

Les environnements de travail Elastic Beanstalk prennent en charge les files d'attente de lettres mortes Amazon Simple Queue Service (Amazon SQS). Une file d'attente de lettres mortes est une file d'attente où les autres files d'attente (source) peuvent envoyer des messages qui, pour une raison quelconque, n'ont pas pu être traités avec succès. Un avantage principal de l'utilisation d'une file d'attente de lettres mortes est la possibilité d'isoler les messages dont le traitement a échoué. Vous pouvez ensuite analyser les messages envoyés à la file d'attente de lettres mortes pour tenter de déterminer pourquoi leur traitement a échoué.

Une file d'attente de lettres mortes est activée par défaut pour un environnement de travail si vous spécifiez une file d'attente Amazon SQS générée automatiquement au moment de la création de votre couche d'environnement de travail. Si vous sélectionnez une file d'attente SQS existante pour votre environnement de travail, vous devez utiliser SQS pour configurer une file d'attente de lettres mortes de façon indépendante. Pour de plus amples informations sur la manière d'utiliser SQS pour configurer une file d'attente de lettres mortes, veuillez consulter Utilisation des files d'attente de lettres mortes Amazon SQS.

Vous ne pouvez pas désactiver les files d'attente de lettres mortes. Les messages qui ne peuvent pas être diffusés sont toujours envoyés à terme vers une file d'attente de lettres mortes. Vous pouvez, toutefois, désactivez effectivement cette fonctionnalité en définissant l'option MaxRetries à la valeur valide maximale de 100.

Si une file d'attente de lettres mortes n'est pas configurée pour la file d'attente Amazon SQS de votre environnement de travail, Amazon SQS conserve les messages dans la file d'attente jusqu'à l'expiration de la période de rétention. Pour de plus amples informations sur la configuration de la période de rétention, veuillez consulter Configuration des environnements de travail.

Note

L'option Elastic Beanstalk MaxRetries est équivalente à l'option SQS MaxReceiveCount. Si votre environnement de travail n'utilise pas une file d'attente SQS générée automatiquement, utilisez l'option MaxReceiveCount dans SQS pour désactiver efficacement votre file d'attente de lettres mortes. Pour de plus amples informations, veuillez consulter Utilisation des files d'attente de lettres mortes Amazon SQS.

Pour de plus amples informations sur le cycle de vie d'un message SQS, veuillez consulter Cycle de vie des messages.

Tâches périodiques

Vous pouvez définir des tâches périodiques dans un fichier nommé cron.yaml dans votre groupe source pour ajouter des tâches à la file d'attente de votre environnement de travail automatiquement à intervalles réguliers.

Par exemple, le fichier cron.yaml suivant crée deux tâches périodiques. La première s’exécute toutes les 12 heures et la seconde à 23 h UTC tous les jours.

Exemple cron.yaml

version: 1
cron:
 - name: "backup-job"
   url: "/backup"
   schedule: "0 */12 * * *"
 - name: "audit"
   url: "/audit"
   schedule: "0 23 * * *"

Le name doit être unique pour chaque tâche. L'URL est le chemin d'accès auquel la demande POST est envoyée pour déclencher la tâche. Le programme est une expression CRON qui détermine le moment d'exécution de la tâche.

Lorsqu'une tâche s'exécute, le démon publie un message dans la file d'attente SQS de l'environnement avec un en-tête indiquant la tâche qui doit être effectuée. Toute instance de l'environnement peut prélever le message et traiter la tâche.

Note

Si vous configurez votre environnement de travail avec une file d'attente SQS et que vous choisissez une file d'attente FIFO Amazon SQS, les tâches périodiques ne sont pas pris en charge.

Elastic Beanstalk utilise le choix principal pour déterminer quelle instance dans votre environnement de travail met en attente la tâche périodique. Chaque instance tente de devenir leader en écrivant dans une table Amazon DynamoDB. La première instance qui réussit est la principale et elle doit continuer à écrire dans la table pour conserver l'état de principale. Si la principale devient hors service, une autre instance prend rapidement sa place.

Pour les tâches périodiques, le démon de travail définit les en-têtes supplémentaires suivants.

En-têtes HTTP
Name (Nom)	Valeur
X-Aws-Sqsd-Taskname	Pour les tâches périodiques, le nom de la tâche à effectuer.
X-Aws-Sqsd-Scheduled-At	Heure à laquelle la tâche périodique a été planifiée
X-Aws-Sqsd-Sender-Id	Numéro de compte AWS de l'expéditeur du message

Utilisation d'Amazon CloudWatch pour la mise à l'échelle automatique dans les niveaux d'environnement de travail

Ensemble, Amazon EC2 Auto Scaling et CloudWatch surveillent l'utilisation de l'UC des instances en cours d'exécution dans l'environnement de travail. La manière dont vous configurez la limite de mise à l'échelle automatique pour la capacité de l'UC détermine le nombre d'instances que le groupe Auto Scaling exécute pour gérer adéquatement le débit de messages dans la file d'attente Amazon SQS. Chaque instance EC2 publie ses métriques d'utilisation de l'UC dans CloudWatch. Amazon EC2 Auto Scaling récupère à partir de CloudWatch l'utilisation moyenne de l'UC sur toutes les instances dans l'environnement de travail. Vous configurez les seuils supérieur et inférieur, ainsi que le nombre d'instances à ajouter ou à résilier, selon la capacité de l'UC. Quand Amazon EC2 Auto Scaling détecte que vous avez atteint le seuil supérieur spécifié sur la capacité de l'UC, Elastic Beanstalk crée les instances dans l'environnement de travail. Les instances sont supprimées quand la charge de l'UC est inférieure au seuil.

Note

Les messages qui n'ont pas été traités au moment de la résiliation d'une instance sont renvoyés à la file d'attente où ils peuvent être traités par un autre démon sur une instance qui est encore en cours d'exécution.

Vous pouvez également configurer d'autres alarmes CloudWatch, en fonction des besoins, à l'aide de la console Elastic Beanstalk, de l'interface de ligne de commande ou du fichier d'options. Pour de plus amples informations, veuillez consulter Utilisation d'Elastic Beanstalk avec Amazon CloudWatch et Création d'un groupe Auto Scaling avec des stratégies de mise à l'échelle par étape.

Configuration des environnements de travail

Vous pouvez gérer la configuration d'un environnement de travail en modifiant la catégorie Worker (Environnement de travail) sur la page Configuration dans la console de gestion de l'environnement.

Note

Vous pouvez configurer le chemin d'URL pour la publication des messages de file d'attente de travail, mais vous ne pouvez pas configurer le port IP. Elastic Beanstalk publie toujours les messages de file d'attente de travail sur le port 80. L'application de l'environnement de travail ou son proxy doit être à l'écoute sur le port 80.

Pour configurer le démon de travail

1. Ouvrez la console Elastic Beanstalk et, dans la liste Regions (Régions), sélectionnez votre Région AWS.

2. Dans le panneau de navigation, choisissez Environments (Environnements), puis choisissez le nom de votre environnement dans la liste.

   Note

   Si vous avez plusieurs environnements, utilisez la barre de recherche pour filtrer la liste des environnements.

3. Dans le panneau de navigation, choisissez Configuration.

4. Dans la catégorie de configuration de l’Worker (Environnement de travail, choisissez Edit (Modifier).

La page de configuration Modify worker (Modifier l’environnement de travail) propose les options suivantes.

Dans la section Queue (File d'attente) :

• Worker queue (File d'attente de travail) : spécifiez la file d'attente Amazon SQS à partir de laquelle le démon lit. Vous pouvez choisir une file d'attente existante, si vous en avez une. Si vous choisissez Autogenerated queue (File d'attente générée automatiquement), Elastic Beanstalk crée une nouvelle file d'attente Amazon SQS et une Worker queue URL (URL de file d'attente de travail)correspondante.

  Note

  Lorsque vous choisissez File d'attente générée automatiquement, la file d'attente créée par Elastic Beanstalk est une file d'attente Amazon SQS standard . Lorsque vous choisissez une file d'attente existante, vous pouvez fournir une file standard ou une file d'attente Amazon SQS FIFO. Sachez que si vous spécifiez une file d'attente FIFO, les tâches périodiques ne sont pas prises en charge.

• Worker queue URL (URL de la file d'attente de travail) : si vous choisissez une Worker queue (File d'attente de travail) existante, ce paramètre affiche l'URL associée à cette file d'attente Amazon SQS.

Dans la section Messages :

• HTTP path (Chemin HTTP) : spécifiez le chemin d'accès relatif à l'application qui reçoit les données à partir de la file d'attente Amazon SQS. Les données sont insérées dans le corps du message d'un message HTTP POST. La valeur par défaut est /.

• MIME type (Type MIME) : indiquez le type MIME que le message HTTP POST utilise. La valeur par défaut est application/json. Cependant, n'importe quelle valeur est valide car vous pouvez créer, puis spécifier votre propre type MIME.

• HTTP Connections (Connexions HTTP) : spécifiez le nombre maximal de connexions simultanées que le démon peut réaliser sur toute application au sein d'une instance Amazon EC2. La valeur par défaut est 50. Vous pouvez spécifier une valeur de 1 à 100.

• Visibility timeout (Délai de visibilité) : indiquez la durée, en secondes, pendant laquelle un message entrant à partir de la file d'attente Amazon SQS est verrouillé pour traitement. Une fois que la durée configurée est écoulée, le message est à nouveau rendu visible dans la file d'attente permettant à un autre démon de le lire. Choisissez une valeur supérieure au délai estimé nécessaire à votre application pour traiter des messages, jusqu'à 43200 secondes.

• Error visibility timeout (Délai de visibilité de l'erreur) : indiquez la durée, en secondes, qui s'écoule avant qu'Elastic Beanstalk renvoie un message à la file d'attente Amazon SQS après qu'une tentative de le traiter a échoué avec une erreur explicite. Vous pouvez spécifier une valeur de 0 à 43200 secondes.

Dans la section Advanced options (Options avancées) :

• Max retries (Nombre maximal de nouvelles tentatives) : spécifiez le nombre maximal de fois qu'Elastic Beanstalk tente d'envoyer le message à la file d'attente Amazon SQS avant de déplacer le message dans la file d'attente des lettres mortes. La valeur par défaut est 10. Vous pouvez spécifier une valeur de 1 à 100.

  Note

  Le Max retries (Nombre maximum de nouvelles tentatives) ne s'applique qu'aux files d'attente Amazon SQS configurées avec une file d'attente de lettres mortes. Pour toutes les files d'attente Amazon SQS qui ne sont pas configurées avec une file d'attente de lettres mortes, Amazon SQS conserve les messages dans la file d'attente et les traite jusqu'à l'expiration de la période spécifiée par l'option Retention period (Période de conservation).

• Connection timeout (Délai de connexion) : indiquez la durée, en secondes, d'attente de connexions réussies à une application. La valeur par défaut est 5. Vous pouvez spécifier une valeur de 1 à 60 secondes.

• Inactivity timeout (Délai d'inactivité) : indiquez la durée, en secondes, d'attente d'une réponse sur une connexion existante à une application. La valeur par défaut est 180. Vous pouvez spécifier une valeur de 1 à 36000 secondes.

• Retention period (Période de conservation) : indiquez la durée, en secondes, de validité et de traitement actif d'un message. La valeur par défaut est 345600. Vous pouvez spécifier une valeur de 60 à 1209600 secondes.

Si vous utilisez une file d'attente Amazon SQS existante, les paramètres que vous configurez lorsque vous créez un environnement de travail peuvent entrent en conflit avec les paramètres que vous avez configurés directement dans Amazon SQS. Par exemple, si vous configurez un environnement de travail avec une valeur RetentionPeriod qui est supérieure à la valeur MessageRetentionPeriod que vous avez définie dans Amazon SQS, Amazon SQS supprime le message quand il dépasse la valeur MessageRetentionPeriod.

À l'inverse, si la valeur RetentionPeriod que vous configurez dans les paramètres d'environnement de travail est inférieure à la valeur MessageRetentionPeriod que vous définissez dans Amazon SQS, alors le démon supprime le message avant qu'Amazon SQS puisse le faire. Pour VisibilityTimeout, la valeur que vous configurez pour le démon dans les paramètres d'environnement de travail remplace la valeur Amazon SQS VisibilityTimeout. Assurez-vous que les messages sont supprimés correctement en comparant vos paramètres Elastic Beanstalk à vos paramètres Amazon SQS.