Gestion des échecs lambda enfant

Question

Nous essayons le lambda pour notre travail ETL qui est écrit en Clojure.

Notre architecture est le planificateur va déclencher le parent lambda, puis le parent lambda déclencher 100 enfant lambda et le compteur lambda. L'enfant lambdas après l'achèvement de leur travail, il écrira les données à s3. Le compteur lambda vérifiera le nombre de fichiers dans le S3, s'il est 100, il combinera tous les fichiers et les sauvegardera dans S3, sinon il couvrira un nouveau compteur lambda et mourra.

Tout le scénario positif fonctionne bien, mais si un enfant tombe en panne, le compteur lambda finira dans la boucle indéfinie, car il n'y aura pas 100 fichiers.

S'il y a un moyen approprié de couvrir l'enfant lambda, surveillez-le et s'il échoue besoin de redémarrer ou réessayer cela seul?

Y a-t-il un bon cadre de Clojure lambda?

Answer 1

Il existe un moyen simple dans AWS est appelé AWS Step Functions. Step Functions fournit une console graphique pour organiser et visualiser les composants de votre application sous la forme d'une série d'étapes. Définissez les étapes à l'aide de la console ou de l'API AWS Step Functions, d'une API Java courante ou de modèles AWS CloudFormation.

Step simplifie l'orchestration des fonctions AWS Lambda. Indépendamment du langage de fonction, il gère tous les lambdas.

étape est bon pour suivre les cas d'utilisation

1. séquence d'exécution fonctionne
2. fonctions exécutées en parallèle
3. Sélectionner les fonctions basées sur les données
4. Réessayez les fonctions
5. try/catch/finally pour fonctions
6. Exécution du code pendant des heures

Answer 2

surveillance du processus ne se construit pas dans toutes les bibliothèques lambda Clojure que je connais, donc pour ce cas, je vous recommande de prendre une page du livre de jeu de Erlang métaphorique (supervisor trees) et dire que d'avoir un système distribué fiable chaque acteur a besoin d'un moniteur donc une approche décente serait d'avoir un observateur pour chaque tâche lambda. Cela peut vraiment simplifier les cas de gestion des erreurs le long de la philosophie "laissez tomber".

Donc, ce laisseriez-vous avec cette liste de lambdas:

• compteurs:
  • un veilleur/restarter pour le compteur (vous genre ont déjà cette)
• travailleurs x100
• superviseurs x100

Chaque superviseur vérifie uniquement la présence d'un fichier particulier et redémarre un lambda particulier s'il n'existe pas. Cela devient beaucoup plus facile si votre processus est idempotent, donc vous n'avez pas à vous inquiéter trop si un fichier est produit deux fois, bien qu'il ne soit pas trop difficile de vérifier si le superviseur de lambda est en train de fonctionner avec aws api. Ce superviseur peut être démarré par la chose qu'il supervise ou par ce qui démarre le reste du système, ce qui est plus facile pour votre base de code. Vous n'avez probablement pas besoin de démarrer explicitement les travailleurs, le superviseur peut le faire. L'important est d'ajouter cloudwatch ou quel que soit votre système d'événement favori (le mien est riemann) afin que vous puissiez ajouter des alertes pour savoir quand vous devez regarder les observateurs.