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.
Annulation de l'exécution d'une tâche EMR sans serveur avec délai de grâce
Dans les systèmes de traitement des données, les interruptions brusques peuvent entraîner un gaspillage de ressources, des opérations incomplètes et des incohérences potentielles dans les données. Amazon EMR Serverless vous permet de définir un délai de grâce lors de l'annulation de l'exécution d'une tâche. Cette fonctionnalité laisse le temps de procéder au nettoyage approprié et de terminer les travaux en cours avant la fin du travail.
Lorsque vous annulez l'exécution d'une tâche, vous pouvez spécifier un délai de grâce (en secondes) à l'aide du paramètre shutdownGracePeriodInSeconds pendant lequel la tâche peut effectuer des opérations de nettoyage avant son arrêt final. Le comportement et les paramètres par défaut varient entre les tâches par lots et les tâches de streaming.
Période de grâce pour les tâches par lots
Pour les tâches par lots, EMR Serverless vous permet de mettre en œuvre des opérations de nettoyage personnalisées qui s'exécutent pendant la période de grâce. Vous pouvez enregistrer ces opérations de nettoyage dans le cadre du hook d'arrêt de la JVM dans le code de votre application.
Comportement par défaut
Le comportement par défaut pour l'arrêt est de n'avoir aucun délai de grâce. Il comprend les deux actions suivantes :
Résiliation immédiate
Les ressources sont débloquées immédiatement
Options de configuration
Vous pouvez définir des paramètres qui se traduiront par un arrêt progressif :
Plage valide pour la période de grâce d'arrêt : 15 à 1800 secondes (facultatif)
Résiliation immédiate (sans délai de grâce) : 0 seconde
Activez l'arrêt progressif
Pour implémenter un arrêt progressif pour les tâches par lots, procédez comme suit :
-
Ajoutez un hook d'arrêt dans le code de votre application contenant une logique d'arrêt personnalisée.
-
Spécifiez un délai de grâce lors de l'annulation de la tâche afin de laisser le temps aux hooks ajoutés ci-dessus de s'exécuter
Exemple
# Default (immediate termination) aws emr-serverless cancel-job-run \ --application-idAPPLICATION_ID\ --job-run-idJOB_RUN_ID# With 5-minute grace period aws emr-serverless cancel-job-run \ --application-idAPPLICATION_ID\ --job-run-idJOB_RUN_ID\ --shutdown-grace-period-in-seconds 300
Période de grâce pour les emplois de streaming
Dans Spark Structured Streaming, où les calculs impliquent la lecture ou l'écriture dans des sources de données externes, les arrêts brusques peuvent entraîner des résultats indésirables. Les tâches de streaming traitent les données par microlots, et l'interruption de ces opérations en cours de route peut entraîner un double traitement lors de tentatives ultérieures. Cela se produit lorsque le dernier point de contrôle du microlot précédent n'a pas été écrit, ce qui entraîne le nouveau traitement des mêmes données au redémarrage de la tâche de streaming. Un tel traitement dupliqué gaspille non seulement des ressources informatiques, mais peut également avoir un impact sur les opérations commerciales, d'où la nécessité d'éviter les arrêts brusques.
EMR Serverless fournit un support intégré pour un arrêt progressif via un écouteur de requêtes en streaming. Cela garantit l'achèvement correct des microlots en cours avant la fin du travail. Le service gère automatiquement l'arrêt progressif entre les microlots pour les applications de streaming, en veillant à ce que le microlot en cours termine le traitement, que les points de contrôle soient correctement écrits et que le contexte de diffusion soit correctement arrêté sans ingestion de nouvelles données pendant le processus d'arrêt.
Comportement par défaut
Période de grâce de 120 secondes activée par défaut.
L'écouteur de requêtes de streaming intégré gère un arrêt progressif.
Options de configuration
Plage valide pour la période de grâce d'arrêt : 15 à 1800 secondes (facultatif)
Fin immédiate : 0 seconde
Activer Graceful Shutdown
Pour implémenter un arrêt progressif pour les tâches de streaming, procédez comme suit :
Spécifiez une période de grâce lors de l'annulation de la tâche afin de laisser le temps au microlot en cours d'être terminé.
Exemple
# Default graceful shutdown (120 seconds) aws emr-serverless cancel-job-run \ --application-idAPPLICATION_ID\ --job-run-idJOB_RUN_ID# Custom grace period (e.g. 300 seconds) aws emr-serverless cancel-job-run \ --application-idAPPLICATION_ID\ --job-run-idJOB_RUN_ID\ --shutdown-grace-period-in-seconds 300 # Immediate Termination aws emr-serverless cancel-job-run \ --application-idAPPLICATION_ID\ --job-run-idJOB_RUN_ID\ --shutdown-grace-period-in-seconds 0
Ajoutez des crochets d'arrêt personnalisés (facultatif)
Alors qu'EMR Serverless gère l'arrêt progressif par défaut via son écouteur de requêtes de streaming intégré, vous pouvez éventuellement implémenter une logique d'arrêt personnalisée pour les requêtes de streaming individuelles. EMR Serverless enregistre son écouteur d'arrêt progressif avec la priorité 60 (utilisation). ShutdownHookManager Étant donné que les hooks à priorité plus élevée s'exécutent en premier, vous pouvez enregistrer vos opérations de nettoyage personnalisées avec une priorité supérieure à 60 pour vous assurer qu'elles s'exécutent avant le début du processus d'arrêt d'EMR Serverless.
Pour ajouter un hook personnalisé, reportez-vous au premier exemple de cette rubrique qui montre comment ajouter un hook d'arrêt dans le code de votre application. Ici, 100 est la priorité, ce qui est supérieur à 60. Par conséquent, un tel hook d'arrêt s'exécutera en premier.
Note
Les hooks d'arrêt personnalisés sont facultatifs et ne sont pas nécessaires pour la fonctionnalité d'arrêt progressif, qui est gérée automatiquement par EMR Serverless.
Frais liés à la période de grâce et durée du Batch
Si la valeur par défaut du délai de grâce (120 secondes) est utilisée :
Si la durée de votre lot est inférieure à 120 secondes, vous ne serez facturé que pour le temps réellement nécessaire pour terminer le lot.
Si la durée de votre lot dépasse 120 secondes, le délai de grâce maximal (120 secondes) vous sera facturé, mais la requête risque de ne pas s'arrêter correctement car elle sera interrompue de force.
Pour optimiser les coûts et garantir un arrêt progressif :
Pour les durées de lot supérieures à 120 secondes : envisagez d'augmenter le délai de grâce pour qu'il corresponde à la durée de votre lot
Pour les durées de lot inférieures à 120 secondes : il n'est pas nécessaire d'ajuster le délai de grâce car vous ne serez facturé que pour le temps de traitement réel
Considérations
Comportement du délai de grâce
La période de grâce vous donne le temps de terminer les interruptions enregistrées.
Job se termine dès que le crochet d'arrêt est terminé, même si c'est bien avant la période de grâce.
Si les opérations de nettoyage dépassent le délai de grâce, le travail sera résilié de force.
Comportement du service
L'arrêt par période de grâce n'est disponible que pour les tâches en cours d'exécution.
Les demandes d'annulation suivantes pendant l'état CANCELING sont ignorées.
-
Si EMR Serverless ne parvient pas à initier l'arrêt du délai de grâce en raison d'erreurs de service internes :
Le service réessaiera pendant 2 minutes au maximum.
Si les nouvelles tentatives échouent, la tâche sera interrompue de force.
Facturation
Les tâches sont facturées en fonction des ressources informatiques utilisées jusqu'à leur arrêt complet, y compris le temps nécessaire pendant la période de grâce.
