Flux de travail gérés par Amazon pour Apache Airflow (Amazon MWAA) est un service géré pour Flux d'air Apache qui rationalise la configuration et le fonctionnement de l'infrastructure pour orchestrer les pipelines de données dans le cloud. Les clients utilisent Amazon MWAA pour gérer l'évolutivité, la disponibilité et la sécurité de leurs environnements Apache Airflow. Alors qu'ils conçoivent des pipelines de traitement de données de plus en plus intensifs, complexes et en constante évolution, les clients nous ont demandé des ressources sous-jacentes supplémentaires pour offrir une plus grande simultanéité et une plus grande capacité pour leurs tâches et flux de travail.

Pour résoudre ce problème, nous annonçons aujourd'hui la disponibilité de classes d'environnement plus grandes dans Amazon MWAA. Dans cet article, nous examinons les capacités de ces nouveaux environnements XL et 2XL, les scénarios pour lesquels ils sont bien adaptés et comment vous pouvez configurer ou mettre à niveau votre environnement Amazon MWAA existant pour tirer parti des ressources accrues.

Défis actuels

Lorsque vous créez un environnement Amazon MWAA, un ensemble de Service de conteneur élastique Amazon (Amazon ECS) avec AWSFargate les conteneurs sont dotés de processeurs virtuels et de RAM définis.

Lorsque vous travaillez avec des charges de travail plus volumineuses, complexes et gourmandes en ressources, ou que vous exécutez des milliers de Graphes acycliques dirigés (DAG) par jour, vous pouvez commencer à épuiser la disponibilité du processeur sur les planificateurs et les nœuds de calcul, ou à atteindre les limites de mémoire chez les nœuds de calcul. L'exécution d'Apache Airflow à grande échelle impose une charge proportionnellement plus importante à la base de données de métadonnées Airflow, entraînant parfois des problèmes de processeur et de mémoire sur le serveur sous-jacent. Service de base de données relationnelle Amazon (Amazon RDS). Une base de données de métadonnées manquant de ressources peut entraîner des interruptions de connexion de la part de vos collaborateurs, ce qui entraînera l'échec prématuré des tâches.

Pour améliorer les performances et la résilience de vos tâches, pensez à suivre Meilleures pratiques Apache Airflow pour créer des DAG. Vous pouvez également créer plusieurs environnements Amazon MWAA pour répartir les charges de travail. Cependant, cela nécessite des efforts supplémentaires d’ingénierie et de gestion.

Nouvelles classes d'environnement

Avec la version d'aujourd'hui, vous pouvez désormais créer des environnements XL et 2XL dans Amazon MWAA en plus des classes d'environnement existantes. Ils disposent respectivement de deux et quatre fois plus de calcul et de trois et six fois plus de mémoire que la grande classe d'instance d'environnement Amazon MWAA actuelle. Ces instances ajoutent du calcul et de la RAM de manière linéaire pour améliorer directement la capacité et les performances de tous les composants Apache Airflow. Le tableau suivant résume les capacités de l'environnement.

Avec l'introduction de ces environnements plus grands, votre base de données de métadonnées Amazon Aurora utilisera désormais des instances plus grandes et à mémoire optimisée, optimisées par AWSGraviton2. Avec la famille de processeurs Graviton2, vous bénéficiez d'améliorations en matière de calcul, de stockage et de mise en réseau, ainsi que de la réduction de votre empreinte carbone offerte par la famille de processeurs AWS.

Prix

Les dimensions tarifaires d'Amazon MWAA restent inchangées et vous ne payez que pour ce que vous utilisez :

• La classe environnement
• Instances de travail supplémentaires
• Instances de planificateur supplémentaires
• Stockage de la base de données de métadonnées consommé

Vous disposez désormais de deux options supplémentaires dans les trois premières dimensions : XL et 2XL pour la classe d'environnement, les instances de travail supplémentaires et les instances de planificateurs. Les tarifs de stockage des bases de données de métadonnées restent les mêmes. Faire référence à Amazon Managed Workflows pour Apache Airflow Tarification pour les tarifs et plus de détails.

Observez les performances d'Amazon MWAA pour planifier la mise à l'échelle vers des environnements plus grands

Avant de commencer à utiliser les nouvelles classes d'environnement, il est important de comprendre si vous vous trouvez dans un scénario lié à des problèmes de capacité, tels qu'une base de données de métadonnées saturée en mémoire, ou des travailleurs ou des planificateurs s'exécutant avec une utilisation élevée du processeur. Comprendre les performances des ressources de votre environnement est essentiel pour résoudre les problèmes liés à la capacité. Nous vous recommandons de suivre les conseils décrits dans Présentation des métriques d'utilisation des conteneurs, des bases de données et des files d'attente pour l'environnement Amazon MWAA pour mieux comprendre l'état des environnements Amazon MWAA et obtenir des informations permettant de dimensionner correctement vos instances.

Dans le test suivant, nous simulons un scénario de charge élevée, utilisons le Métriques d'observabilité CloudWatch pour identifier les problèmes courants et prendre une décision éclairée pour planifier la mise à l'échelle vers des environnements plus grands afin d'atténuer les problèmes.

Au cours de nos tests, nous avons exécuté un DAG complexe qui crée dynamiquement plus de 500 tâches et utilise des capteurs externes pour attendre l'achèvement d'une tâche dans un autre DAG. Après une exécution sur une grande classe d'environnement Amazon MWAA avec une mise à l'échelle automatique configurée jusqu'à un maximum de 10 nœuds de travail, nous avons remarqué les métriques et valeurs suivantes dans le fichier Tableau de bord CloudWatch.

Les nœuds de travail ont atteint la capacité maximale du processeur, ce qui entraîne une augmentation continue du nombre de tâches en file d'attente. L'utilisation du processeur de la base de données de métadonnées a culminé à plus de 65 % de sa capacité et la mémoire libre disponible de la base de données a été réduite. Dans cette situation, nous pourrions augmenter davantage le nombre de nœuds de travail pour les mettre à l'échelle, mais cela imposerait une charge supplémentaire sur le processeur de la base de données de métadonnées. Cela peut entraîner une baisse du nombre de connexions à la base de données de travail et de la mémoire libre disponible de la base de données.

Avec les nouvelles classes d'environnement, vous pouvez évoluer verticalement pour augmenter les ressources disponibles en modifiant l'environnement et en sélectionnant une classe d'environnement supérieure, comme indiqué dans la capture d'écran suivante.

Dans la liste des environnements, nous sélectionnons celui utilisé pour ce test. Choisir Modifier pour accéder au Configurer les paramètres avancés et sélectionnez l'environnement xlarge ou 2xlarge approprié selon vos besoins.

Une fois la modification enregistrée, la mise à niveau de l’environnement prendra 20 à 30 minutes. Tout DAG en cours d'exécution qui a été interrompu lors de la mise à niveau est programmé pour une nouvelle tentative, en fonction de la façon dont vous avez configuré les tentatives pour vos DAG. Vous pouvez désormais choisir de les appeler manuellement ou d'attendre la prochaine exécution planifiée.

Après avoir mis à niveau la classe d'environnement, nous avons testé le même DAG et observé que les métriques affichaient des valeurs améliorées car davantage de ressources sont désormais disponibles. Avec cet environnement XL, vous pouvez exécuter plus de tâches sur moins de nœuds de travail, et donc le nombre de tâches en file d'attente continue de diminuer. Alternativement, si vous avez des tâches qui nécessitent plus de mémoire et/ou de processeur, vous pouvez réduire le nombre de tâches par travailleur, tout en atteignant un nombre élevé de tâches par travailleur avec une taille d'environnement plus grande. Par exemple, si vous disposez d'un environnement étendu dans lequel le processeur du nœud de travail est saturé avec celery.worker_autoscale (la configuration Airflow qui définit le nombre de tâches par travailleur) Fixé à 20,20, vous pouvez passer à un environnement XL et définir celery.worker_autoscale à 20,20 sur le XL, plutôt que les 40 tâches par défaut par travailleur dans un environnement XL et la charge CPU devrait être considérablement réduite.

Configurer un nouvel environnement XL dans Amazon MWAA

Vous pouvez débuter avec Amazon MWAA dans votre compte et votre région AWS préférée à l'aide du Console de gestion AWS, API ou Interface de ligne de commande AWS (AWS CLI). Si vous adoptez l'infrastructure en tant que code (IaC), vous pouvez automatiser la configuration à l'aide de AWS CloudFormation, Kit de développement AWS Cloud (AWS CDK) ou des scripts Terraform.

Les classes d'environnement Amazon MWAA XL et 2XL sont disponibles aujourd'hui dans toutes les régions où Amazon MWAA est actuellement disponible.

Conclusion

Aujourd'hui, nous annonçons la disponibilité de deux nouvelles classes d'environnement dans Amazon MWAA. Avec les classes d'environnement XL et 2XL, vous pouvez orchestrer de plus grands volumes de flux de travail complexes ou gourmands en ressources. Si vous exécutez des DAG avec un nombre élevé de dépendances, si vous exécutez des milliers de DAG dans plusieurs environnements ou dans un scénario qui nécessite une utilisation intensive des nœuds de calcul pour le calcul, vous pouvez désormais surmonter les problèmes de capacité associés en augmentant les ressources de votre environnement en quelques secondes. étapes simples.

Dans cet article, nous avons discuté des capacités des deux nouvelles classes d'environnement, y compris la tarification et certains problèmes courants de contraintes de ressources qu'elles résolvent. Nous avons fourni des conseils et un exemple sur la façon d'observer vos environnements existants pour planifier la mise à l'échelle vers XL ou 2XL, et nous avons décrit comment vous pouvez mettre à niveau les environnements existants pour utiliser les ressources accrues.

Pour plus de détails et des exemples de code sur Amazon MWAA, visitez le Guide de l'utilisateur Amazon MWAA et par Exemples de dépôt GitHub d'Amazon MWAA.

Apache, Apache Airflow et Airflow sont soit des marques déposées, soit des marques commerciales de Apache Software Foundation aux États-Unis et/ou dans d'autres pays.

À propos des auteurs

Hernán García est un architecte de solutions senior chez AWS basé aux Pays-Bas. Il travaille dans le secteur des services financiers, accompagnant les entreprises dans leur adoption du cloud. Il est passionné par les technologies sans serveur, la sécurité et la conformité. Il aime passer du temps avec sa famille et ses amis et essayer de nouveaux plats de différentes cuisines.

Jeetendra Vaidya est architecte de solutions senior chez AWS, apportant son expertise aux domaines de l'IA/ML, du sans serveur et de l'analyse de données. Il se passionne pour aider les clients à concevoir des solutions sécurisées, évolutives, fiables et rentables.

Sriharsh Adari est architecte de solutions senior chez AWS, où il aide les clients à remonter les résultats commerciaux pour développer des solutions innovantes sur AWS. Au fil des années, il a aidé plusieurs clients dans la transformation des plateformes de données dans tous les secteurs verticaux. Son principal domaine d'expertise comprend la stratégie technologique, l'analyse des données et la science des données. Dans ses temps libres, il aime faire du sport, regarder des émissions de télévision et jouer au Tabla.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/big-data/introducing-amazon-mwaa-larger-environment-sizes/