One Article Review
| Source |  ProofPoint |
|---|---|
| Identifiant | 8400148 |
| Date de publication | 2023-10-25 09:54:27 (vue: 2023-10-25 14:08:11) |
| Titre | Utilisation d'AWS SQS pour créer un planificateur de tâches distribué et un cadre d'exécution Using AWS SQS to Create a Distributed Task Scheduler and Execution Framework |
| Texte | Engineering Insights est une série de blogs en cours qui donne à des coulisses sur les défis techniques, les leçons et les avancées qui aident nos clients à protéger les personnes et à défendre les données chaque jour.Chaque message est un compte de première main de l'un de nos ingénieurs sur le processus qui a conduit à une innovation de preuves. Un exécuteur de tâches distribué est un composant crucial lorsque vous créez des systèmes évolutifs et résilients qui peuvent gérer une large gamme de tâches, du traitement des données et des travaux de lots au traitement d'événements en temps réel et à l'orchestration des microservices. Chez ProofPoint, nous recherchions un exécuteur de tâches distribué simple pour le sous-ensemble des tâches à exécuter dans AWS.Nous voulions qu'il soit facile à entretenir et à déployer, à fournir une commande cohérente des tâches, à avoir une bonne gestion des erreurs et à réessayer les tâches ratées.L'intégration avec des composants sans serveur était un plus car il nous fournirait beaucoup plus d'options pour augmenter et paralléliser le traitement des tâches. Parmi les nombreux cadres que nous avons évalués les plus notables figuraient Hazelcast, Apache Air Flow et Facebook Bistro.Apache Air Flow et Bistro ont besoin d'un déploiement d'infrastructures supplémentaires, tandis que Hazelcast a besoin de persistance pour être configurée pour stocker l'état de la tâche.Nous voulions limiter les dépendances autres que ce que nous utilisons déjà dans AWS.En fin de compte, nous avons décidé qu'AWS SQS était le meilleur de toutes les options. En utilisant les fonctionnalités des files d'attente AWS SQS, nous avons pu assembler un planificateur de tâches distribué et un cadre d'exécution comme indiqué ci-dessous dans la figure 1. Figure 1: La file d'attente FIFO AWS SQS en tant qu'orchestrateur entre la source de tâche et les exécuteurs. Caractéristiques de conception clés de l'architecture ci-dessus Le plan de l'architecture ci-dessus est partagé en tant que module Terraform afin que chaque équipe ou service puisse déployer son propre planificateur de tâches distribué hautement disponible.Voici ce que vous devez savoir sur ses caractéristiques de conception clés: Fonctionnalité Description Disponibilité Un aspect clé de tout exécuteur de tâches distribué est d'éliminer le point de défaillance unique.Étant donné que AWS SQS est résilient et très disponible, cela signifie que la file d'attente des tâches l'est aussi. Évolutivité SQS propose l'intégration hors de la boîte avec AWS LAMDA à l'aide de la LAMDA Invocation via des déclencheurs de source d'événements. La configuration de contrôle de concurrence sur SQS augmente la parallélisation. Par défaut, la taille du message prise en charge est 256KIB;Il peut être étendu jusqu'à 2 Go avec la lib client étendu. Tolérance aux défauts La configuration du délai d'expiration de visibilité du message garantit que les tâches d'exécution ratées sont redistribuées aux travailleurs disponibles. Des battements cardiaques peuvent être ajoutés pour prolonger les délais de visibilité pour les tâches de longue date. Tentatives Une fois le nombre défini de tentatives atteintes, SQS fournit des files d'attente dans les lettres d'adolescents (DLQ) où les événements sont redirigés.Cela nous permet d'intervenir manuellement, de déboguer ou de revoir les tâches.Cela nous aide également à atténuer et à éliminer les tâches de pilule de poison si elles apparaissent dans la file d'attente. Commande et regroupement de messages Les files d'attente SQS FIFO fournissent un regroupement de messages et une commande au sein des groupes. La déduplication des files d'attente FIFO aide à prévenir l'exécution des tâches en double. Flux de travail En utilisant les fonctions AWS Step, nous pouvons réaliser des workflows pour l'exécution des tâches. Déploiement Il est possible d'utiliser la format |
| Envoyé | Oui |
| Condensat | 256kib; 2gb ability able about above access account achieve added additional advances aimed airflow all allows already also among any apache architecture architecture are aspect author availability available aws batch because behind below best between bistro blog blueprint box build building can capture care challenges client cloud cloudwatch component components concurrency configuration configured consistent constructing consumer control cost cost create crucial currently customers data day dead debug decided decreases deduplication default defend delivering dependencies dependent deploy deployment deployment description design distributed dlqs duplicate each easy effort eliminate encrypted encryption end engineer engineering engineers enhance ensures error evaluated event events every executed executing execution executor executors expected extend extended facebook failed failures fault features features: feature fifo figure firsthand forefront formation framework frameworks from functions further gives good grouping grouping groups handle handling has have hazelcast heartbeats help helps here highly his iam identity increases infrastructure initiatives innovation insights integration intervene invocation its jobs key know krishna lamda lead led lessons letter lib limit logging logs long look looking maintain managed management manually many mean means message metrics microservices minimal mitigate module monitoring more most mttr need needs notable number numerous observability once one ones ongoing operations options orchestration orchestrator ordering organization other out own parallelization parallelize people persistence pill pipeline pipelines plus point poison policies possible post prevent process processing proofpoint protect provide provides put queue queues raju range reached real redirected redistributed remove resilient respond rest restricts retries retries retry role running sathish scalability scalable scale scenes scheduler search security senior series server serverless service services set setup several shared should show shown side simple single size source spearheaded sqs sse staff state step store subset supported system systems taken task tasks team teams technical terraform test testing than themselves through time timeout timeouts together tolerance triggers use using utilize utilizing very visibility wanted well what when where wide within workers workflows workflows would you |
| Tags | Cloud |
| Stories | |
| Notes | ★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.