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.
Stratégies de reprise d'emploi dans le secteur des services dans AWS Batch
Les stratégies de relance des tâches de service permettent AWS Batch de réessayer automatiquement les tâches de service ayant échoué dans des conditions spécifiques.
Les tâches de service peuvent nécessiter plusieurs tentatives pour plusieurs raisons :
-
Problèmes de service temporaires : des erreurs de service internes, des blocages ou des interruptions temporaires peuvent entraîner l'échec des tâches lors de leur soumission ou de leur exécution.
-
Échecs d'initialisation de la formation : les problèmes rencontrés lors du démarrage de la tâche, tels que les problèmes liés à l'extraction d'images ou les erreurs d'initialisation, peuvent être résolus lors d'une nouvelle tentative.
En configurant des stratégies de nouvelle tentative appropriées, vous pouvez améliorer les taux de réussite des tâches et réduire le besoin d'interventions manuelles, en particulier pour les charges de travail de formation de longue durée.
Note
Lorsqu'une tâche de SageMaker formation échoue en raison d'une capacité insuffisante, la tâche est automatiquement AWS Batch relancée jusqu'à ce que la capacité soit disponible. La tâche de SageMaker formation la plus récente qui a échoué en raison d'une capacité insuffisante sera conservée, et les tâches de SageMaker formation précédentes qui ont échoué en raison d'une capacité insuffisante seront supprimées dans la mesure du possible.
Ces nouvelles tentatives basées sur la capacité ne consomment pas les tentatives de nouvelle tentative que vous avez configurées. Votre stratégie de nouvelle tentative gère principalement d'autres types d'échecs, tels que les erreurs d'algorithme ou les problèmes de service qui surviennent une fois qu'une tâche est entrée en « DÉBUT ».
Configuration des stratégies de nouvelle tentative
Les stratégies de nouvelle tentative de tâche de service sont configurées à l'aide de ServiceJobRetryStrategy, qui prend en charge à la fois le nombre de tentatives simples et la logique des nouvelles tentatives conditionnelles.
Nouvelle tentative de configuration
La stratégie de nouvelle tentative la plus simple spécifie le nombre de nouvelles tentatives à effectuer en cas d'échec d'une tâche de service :
{ "retryStrategy": { "attempts": 3 } }
Cette configuration permet de réessayer la tâche de service jusqu'à 3 fois en cas d'échec.
Important
La attempts valeur représente le nombre total de fois que la tâche peut être placée dans RUNNABLE cet état, y compris lors de la tentative initiale. Une valeur de 3 signifie que la tâche sera tentée une fois initialement, puis réessayée jusqu'à deux fois supplémentaires en cas d'échec.
Réessayez la configuration avec evaluer OnExit
Vous pouvez utiliser ce evaluateOnExit paramètre pour spécifier les conditions dans lesquelles les tâches doivent être réessayées ou autorisées à échouer. Ceci est utile lorsque différents types de défaillances nécessitent une gestion différente.
Le evaluateOnExit tableau peut contenir jusqu'à 5 stratégies de nouvelle tentative, chacune spécifiant une action (RETRYouEXIT) et des conditions en fonction des raisons du statut :
{ "retryStrategy": { "attempts": 5, "evaluateOnExit": [ { "action": "RETRY", "onStatusReason": "Received status from SageMaker: InternalServerError*" }, { "action": "EXIT", "onStatusReason": "Received status from SageMaker: ValidationException*" }, { "action": "EXIT", "onStatusReason": "*" } ] } }
Cette configuration :
-
Réessaie les tâches qui ont échoué en raison d'erreurs internes au serveur SageMaker AI
-
Échoue immédiatement les tâches qui rencontrent des exceptions de validation (erreurs du client qui ne seront pas résolues par une nouvelle tentative)
-
Inclut une règle fourre-tout permettant de sortir pour tout autre type de panne
Correspondance entre le statut et les motifs
Le onStatusReason paramètre prend en charge la correspondance de motifs avec un maximum de 512 caractères. Les modèles peuvent utiliser des caractères génériques (*) et correspondre aux raisons de statut renvoyées par l' SageMaker IA.
Pour les tâches de service, les messages d'état de l' SageMaker IA sont précédés du préfixe « État reçu de SageMaker : » pour les distinguer des messages AWS Batch générés. Les modèles courants incluent :
-
Received status from SageMaker: InternalServerError*- Corrigez les erreurs de service interne -
Received status from SageMaker: ValidationException*- Corrigez les erreurs de validation du client -
Received status from SageMaker: ResourceLimitExceeded*- Corrigez les erreurs de limite de ressources -
*CapacityError*- Corrigez les défaillances liées à la capacité
Astuce
Utilisez une correspondance de modèles spécifique pour gérer les différents types d'erreurs de manière appropriée. Par exemple, réessayez les erreurs internes du serveur, mais échouez immédiatement en cas d'erreur de validation indiquant des problèmes liés aux paramètres de la tâche.
