Fonctionnement de la mise en cache des appels

Pour utiliser la mise en cache des appels, vous créez un cache d'exécution et vous le configurez pour qu'il soit associé à un emplacement Amazon S3 pour les données mises en cache. Lorsque vous lancez une exécution, vous spécifiez le cache d'exécution. Un cache d'exécution n'est pas dédié à un seul flux de travail. Les exécutions à partir de plusieurs flux de travail peuvent utiliser le même cache.

Pendant la phase d'exportation d'une exécution, le système exporte les résultats des tâches terminées vers l'emplacement Amazon S3. Pour exporter des fichiers de tâches intermédiaires, déclarez ces fichiers en tant que résultats de tâches dans la définition du flux de travail. La mise en cache des appels enregistre également les métadonnées en interne et crée des hachages uniques pour chaque entrée du cache.

Pour chaque tâche exécutée, le moteur de flux de travail détecte s'il existe une entrée de cache correspondante pour cette tâche. Si aucune entrée de cache ne correspond, HealthOmics calcule la tâche. Si une entrée de cache correspond, le moteur récupère les résultats mis en cache.

Pour faire correspondre les entrées du cache, HealthOmics utilise le mécanisme de hachage inclus dans les moteurs de flux de travail natifs. HealthOmicsétend ces implémentations de hachage existantes pour tenir compte de HealthOmics variables, telles que les ETags S3 et les résumés de conteneurs ECR.

HealthOmics prend en charge la mise en cache des appels pour les versions linguistiques du flux de travail suivantes :

• Versions WDL 1.0, 1.1 et version de développement

• Nextflow versions 23.10 et 24.10

• Toutes les versions de CWL

Note

HealthOmics ne prend pas en charge la mise en cache des appels pour les flux de travail Ready2Run.

Modèle de responsabilité partagée

La responsabilité est partagée entre les utilisateurs et consiste AWS à déterminer si les tâches et les exécutions sont de bons candidats pour la mise en cache des appels. La mise en cache des appels donne les meilleurs résultats lorsque toutes les tâches sont idempotentes (les exécutions répétées d'une tâche utilisant les mêmes entrées produisent les mêmes résultats).

Toutefois, si une tâche inclut des éléments non déterministes (tels que des générations de nombres aléatoires ou l'heure du système), des exécutions répétées de la tâche utilisant les mêmes entrées peuvent entraîner des sorties différentes. Cela peut avoir un impact sur l'efficacité de la mise en cache des appels des manières suivantes :

• Si elle HealthOmics utilise une entrée de cache (créée lors d'une exécution précédente) qui n'est pas identique à la sortie que l'exécution de la tâche produirait pour l'exécution en cours, l'exécution peut donner des résultats différents de ceux de la même exécution sans mise en cache.

• HealthOmics peut ne pas trouver d'entrée de cache correspondante pour une tâche qui devrait correspondre, en raison de sorties de tâche non déterministes. Si elle ne trouve pas l'entrée de cache valide, l'exécution recalcule inutilement la tâche, ce qui réduit les économies liées à l'utilisation de la mise en cache des appels.

Les comportements de tâches connus suivants peuvent entraîner des résultats non déterministes affectant les résultats de la mise en cache des appels :

• Utilisation de générateurs de nombres aléatoires.

• Dépendance de l'heure du système.

• Utilisation de la simultanéité (les conditions de course peuvent entraîner une variation de sortie).

• Extraction de fichiers locaux ou distants au-delà de ce qui est spécifié dans les paramètres d'entrée de la tâche.

Pour d'autres scénarios susceptibles de provoquer un comportement non déterministe, consultez la section Entrées de processus non déterministes sur le site de documentation de Nextflow.

Si vous pensez qu'une tâche produit des résultats non déterministes, pensez à utiliser les fonctionnalités du moteur de flux de travail, telles que la désactivation du cache dans Nextflow, pour éviter de mettre en cache des tâches spécifiques non déterministes.

Nous vous recommandons de revoir attentivement vos exigences spécifiques en matière de flux de travail et de tâches avant d'activer la mise en cache des appels dans les environnements dans lesquels une mise en cache inefficace ou des résultats différents de ceux attendus peuvent présenter un risque. Par exemple, les limites potentielles de la mise en cache des appels doivent être soigneusement prises en compte pour déterminer si la mise en cache des appels est appropriée pour les cas d'utilisation cliniques.

Exigences de mise en cache pour les tâches

HealthOmics met en cache les résultats des tâches répondant aux exigences suivantes :

• La tâche doit définir un conteneur. HealthOmics ne mettra pas en cache les sorties pour une tâche sans conteneur.

• La tâche doit produire une ou plusieurs sorties. Vous spécifiez les résultats des tâches dans la définition du flux de travail.

• La définition du flux de travail ne doit pas utiliser de valeurs dynamiques. Par exemple, si vous transmettez un paramètre à une tâche dont la valeur augmente à chaque exécution, les résultats de la tâche HealthOmics ne sont pas mis en cache.

Note

Si plusieurs tâches en cours d'exécution utilisent la même image de conteneur, HealthOmics fournit la même version d'image pour toutes ces tâches. Une fois HealthOmics l'image extraite, elle ignore toute mise à jour de l'image du conteneur pendant toute la durée de l'exécution. Cette approche fournit une expérience prévisible et cohérente et permet d'éviter les problèmes potentiels susceptibles de découler des mises à jour de l'image du conteneur déployées en cours d'exécution.

Exécuter les performances du cache

Lorsque vous activez la mise en cache des appels pour une exécution, vous pouvez constater les impacts suivants sur les performances d'exécution :

• Lors de la première exécution, HealthOmics enregistre les données du cache pour les tâches en cours d'exécution. Les délais d'exportation peuvent être plus longs pour cette exécution, car la mise en cache des appels augmente la quantité de données d'exportation.

• Lors des exécutions suivantes, lorsque vous reprenez une exécution depuis le cache, le nombre d'étapes de traitement peut être réduit et le temps d'exécution peut être réduit.

• Si vous choisissez également de déclarer des fichiers intermédiaires en tant que sorties, vos délais d'exportation peuvent être encore plus longs car ces données peuvent être plus détaillées.

Événements de conservation et d'invalidation des données du cache

L'objectif principal d'un cache d'exécution est d'optimiser le calcul des tâches en cours d'exécution. S'il existe une entrée de cache correspondante valide pour une tâche, HealthOmics utilise l'entrée de cache au lieu de recalculer la tâche. Sinon, HealthOmics revient au comportement de service par défaut, qui consiste à recalculer la tâche et ses tâches dépendantes. En utilisant cette approche, les erreurs de cache n'entraînent pas l'échec de l'exécution.

Nous vous recommandons de gérer la taille du cache d'exécution. Au fil du temps, les entrées du cache peuvent ne plus être valides en raison de mises à jour du moteur de flux de travail ou du HealthOmics service ou en raison de modifications apportées lors de l'exécution ou des tâches d'exécution. Les sections suivantes fournissent des informations supplémentaires.

Rubriques

• Mises à jour des versions du manifeste et fraîcheur des données

• Exécuter le comportement du cache

• Contrôler la taille du cache d'exécution

Mises à jour des versions du manifeste et fraîcheur des données

Le HealthOmics service peut régulièrement introduire de nouvelles fonctionnalités ou des mises à jour du moteur de flux de travail qui invalident certaines ou toutes les entrées du cache d'exécution. Dans ce cas, le cache peut manquer une seule fois lors de vos exécutions.

HealthOmics crée un fichier manifeste JSON pour chaque entrée de cache. Pour les exécutions démarrées après le 12 février 2025, le fichier manifeste inclut un paramètre de version. Si une mise à jour du service invalide des entrées de cache, le numéro de version est HealthOmics incrémenté afin que vous puissiez identifier les anciennes entrées de cache à supprimer.

L'exemple suivant montre un fichier manifeste dont la version est définie sur 2 :

{
     "arn": "arn:aws:omics:us-west-2:12345678901:runCache/0123456/cacheEntry/1234567-195f-3921-a1fa-ffffcef0a6a4",
     "s3uri": "s3://example/1234567-d0d1-e230-d599-10f1539f4a32/1348677/4795326/7e8c69b1-145f-3991-a1fa-ffffcef0a6a4",
     "taskArn": "arn:aws:omics:us-west-2:12345678901:task/4567891",
     "workDir": "/mnt/workflow/1234567-d0d1-e230-d599-10f1539f4a32/workdir/call-TxtFileCopyTask/5w6tn5feyga7noasjuecdeoqpkltrfo3/wxz2fuddlo6hc4uh5s2lreaayczduxdm",
     "files": [
         {
             "name": "output_txt_file",
             "path": "out/output_txt_file/outfile.txt",
             "etag": "ajdhyg9736b9654673b9fbb486753bc8"
         }
     ],
     "nextflowContext": {},
     "otherOutputs": {},
     "version": 2,       
  }     

Pour les exécutions avec des entrées de cache qui ne sont plus valides, reconstruisez le cache pour créer de nouvelles entrées valides. Effectuez les étapes suivantes pour chaque exécution :

1. Lancez l'exécution une fois avec la rétention du cache définie sur CACHE ALWAYS. Cette exécution crée les nouvelles entrées de cache.

2. Pour les exécutions suivantes, réglez la rétention du cache sur son ancien paramètre (CACHE ALWAYS ou CACHE ON FAILURE).

Pour nettoyer les entrées de cache qui ne sont plus valides, vous pouvez les supprimer du compartiment de cache Amazon S3. HealthOmics ne réutilise jamais ces entrées de cache. Si vous choisissez de conserver les entrées non valides, cela n'a aucun impact sur vos courses.

Note

La mise en cache des appels enregistre les données de sortie des tâches dans l'emplacement Amazon S3 spécifié pour le cache, ce qui entraîne des frais pour vous. Compte AWS

Exécuter le comportement du cache

Vous pouvez définir le comportement du cache d'exécution pour enregistrer les résultats des tâches pour les exécutions qui échouent (cache en cas d'échec) ou pour toutes les exécutions (cache toujours). Lorsque vous créez un cache d'exécution, vous définissez le comportement de cache par défaut pour toutes les exécutions utilisant ce cache. Vous pouvez modifier le comportement par défaut lorsque vous démarrez une course.

Cache on failureest utile si vous débugguez un flux de travail qui échoue après l'exécution réussie de plusieurs tâches. L'exécution suivante reprend à partir de la dernière tâche terminée avec succès si toutes les variables uniques prises en compte par le hachage sont identiques à celles de l'exécution précédente.

Cache alwaysest utile si vous mettez à jour une tâche dans un flux de travail qui s'exécute correctement. Nous vous recommandons de suivre les étapes suivantes :

1. Créez une nouvelle course. Définissez le comportement du cache sur Cache always, puis lancez l'exécution.

2. Une fois l'exécution terminée, mettez à jour la tâche dans le flux de travail et lancez une nouvelle exécution avec le comportement défini Cache always. Cette exécution traite la tâche mise à jour et toutes les tâches suivantes qui dépendent de la tâche mise à jour. Toutes les autres tâches utilisent les résultats mis en cache.

3. Répétez l'étape 2 selon les besoins, jusqu'à ce que le développement de la tâche mise à jour soit terminé.

4. Utilisez la tâche mise à jour selon vos besoins lors de futures exécutions. N'oubliez pas de basculer les exécutions suivantes vers le cache en cas d'échec si vous prévoyez d'utiliser des entrées nouvelles ou différentes pour ces exécutions.

Note

Nous recommandons de toujours utiliser le mode Cache lorsque vous utilisez le même ensemble de données de test, mais pas pour un lot d'exécutions. Si vous définissez ce mode pour un grand nombre d'exécutions, le système peut exporter de grandes quantités de données vers Amazon S3, ce qui augmente les délais d'exportation et les coûts de stockage.

Contrôler la taille du cache d'exécution

HealthOmics ne supprime ni n'archive automatiquement les données d'exécution du cache et n'applique pas les règles de nettoyage d'Amazon S3 pour gérer les données du cache. Nous vous recommandons de nettoyer régulièrement le cache afin de réduire les coûts de stockage d'Amazon S3 et de maintenir la taille de votre cache d'exécution à un niveau gérable. Vous pouvez supprimer des fichiers directement ou définir des retention/replication politiques de données sur le bucket de cache d'exécution.

Par exemple, vous pouvez configurer une politique de cycle de vie Amazon S3 pour faire expirer les objets après 90 jours, ou vous pouvez nettoyer manuellement les données du cache à la fin de chaque projet de développement.

Les informations suivantes peuvent vous aider à gérer la taille des données du cache :

• Vous pouvez voir la quantité de données dans le cache en consultant Amazon S3. HealthOmics ne surveille ni ne rend compte de la taille du cache.

• Si vous supprimez une entrée de cache valide, l'exécution suivante n'échoue pas. HealthOmics recalcule la tâche et ses tâches dépendantes.

• Si vous modifiez les noms de cache ou les structures de répertoires de telle sorte qu'aucune entrée correspondante ne HealthOmics puisse être trouvée pour une tâche, HealthOmics recalcule la tâche.

Si vous devez vérifier si une entrée de cache est toujours valide, vérifiez le numéro de version du manifeste de cache. Pour de plus amples informations, veuillez consulter Mises à jour des versions du manifeste et fraîcheur des données.