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.
# Mise en cache des appels pour les exécutions HealthOmics
AWS HealthOmics prend en charge la mise en cache des appels, également appelée reprise, pour les flux de travail privés. La mise en cache des appels enregistre les résultats des tâches de flux de travail terminées une fois l'exécution terminée. Les exécutions suivantes peuvent utiliser les résultats des tâches du cache, plutôt que de les calculer à nouveau. La mise en cache des appels réduit l'utilisation des ressources informatiques, ce qui se traduit par des durées d'exécution plus courtes et des économies de coûts de calcul.
Vous pouvez accéder aux fichiers de sortie des tâches mis en cache une fois l'exécution terminée. Pour effectuer un débogage et un dépannage avancés des tâches, vous pouvez mettre en cache des fichiers de tâches intermédiaires en les spécifiant en tant que résultats de tâches dans la définition du flux de travail.
Vous pouvez utiliser la mise en cache des appels pour enregistrer les résultats des tâches terminées en cas d'échec d'exécution. La prochaine exécution commence à partir de la dernière tâche terminée avec succès, plutôt que de calculer à nouveau les tâches terminées.
Si HealthOmics aucune entrée de cache correspondante n'est trouvée pour une tâche, l'exécution n'échoue pas. HealthOmics recalcule la tâche et ses tâches dépendantes.
Pour plus d'informations sur la résolution des problèmes de mise en cache des appels, consultez[Résolution des problèmes de mise en cache des appels](troubleshooting.md#workflow-cache-troubleshooting).
**Topics**
+ [Comment fonctionne la mise en cache des appels](how-run-cache.md)
+ [Création d'un cache d'exécution](workflow-cache-create.md)
+ [Mettre à jour un cache d'exécution](workflow-cache-update.md)
+ [Supprimer un cache d'exécution](workflow-cache-delete.md)
+ [Contenu d'un cache d'exécution](workflow-cache-contents.md)
+ [Fonctionnalités de mise en cache spécifiques au moteur](workflow-cache-per-engine.md)
+ [Utilisation du cache d'exécution](workflow-cache-startrun.md)
# Comment fonctionne 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 d'une exécution, 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 version 23.10 et versions ultérieures
+ Toutes les versions de CWL
**Note**
HealthOmics ne prend pas en charge la mise en cache des appels pour les flux de travail Ready2Run.
**Topics**
+ [Modèle de responsabilité partagée](#run-cache-srm)
+ [Exigences de mise en cache pour les tâches](#workflow-cache-task-prereqs)
+ [Exécuter les performances du cache](#run-cache-performance)
+ [Événements de conservation et d'invalidation des données du cache](#workflow-cache-data)
## 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](https://www.nextflow.io/docs/latest/cache-and-resume.html#non-deterministic-process-inputs) 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 pour éviter de mettre en cache des tâches spécifiques non déterministes. Pour savoir comment désactiver la mise en cache pour des tâches individuelles dans chaque langue de flux de travail prise en charge, consultez[Fonctionnalités de mise en cache spécifiques au moteur](workflow-cache-per-engine.md).
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.
**Topics**
+ [Mises à jour des versions du manifeste et fraîcheur des données](#workflow-cache-data-versions)
+ [Exécuter le comportement du cache](#run-cache-behavior)
+ [Contrôler la taille du cache d'exécution](#workflow-cache-manage)
### Mises à jour des versions du manifeste et fraîcheur des données
Régulièrement, le HealthOmics service peut 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](workflow-cache-contents.md) 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. Procédez comme suit 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.
1. 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 lancez une course.
**Cache on failure**est 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 always**est 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.
1. 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.
1. Répétez l'étape 2 selon les besoins, jusqu'à ce que le développement de la tâche mise à jour soit terminé.
1. 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 du cache d'exécution et n'applique pas les règles de nettoyage d'Amazon S3 pour gérer les données du cache. Nous vous recommandons d'effectuer des nettoyages de cache réguliers 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](#workflow-cache-data-versions).
# Création d'un cache d'exécution
Lorsque vous créez un cache d'exécution, vous spécifiez un emplacement Amazon S3 pour les données du cache. Ces données doivent être immédiatement accessibles. La mise en cache des appels ne permet pas de récupérer les objets archivés dans Glacier (tels que les classes de stockage GFR et GDA).
Si le compartiment Amazon S3 contenant les données du cache appartient à une autre personne Compte AWS, fournissez cet ID de compte lorsque vous créez le cache d'exécution.
## Création d'un cache d'exécution à l'aide de la console
À partir de la console, procédez comme suit pour créer un cache d'exécution.
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez **Exécuter les caches**.
1. Sur la page **Exécuter les caches**, choisissez **Create run cache**.
1. Dans le panneau **Détails du cache d'exécution** de la page **Créer un cache d'exécution**, configurez les champs suivants :
1. Entrez un nom pour le cache d'exécution.
1. (Facultatif) Entrez une description.
1. Entrez un emplacement S3 pour la sortie mise en cache. Choisissez un bucket dans la même région que votre flux de travail.
1. (Facultatif) Entrez le nom Compte AWS du propriétaire du compartiment pour vérifier qu'il est bien le propriétaire du compartiment. Si vous ne saisissez aucune valeur, la valeur par défaut est votre numéro de compte.
1. Sous **Comportement du cache**, configurez le comportement par défaut (pour mettre en cache les sorties en cas d'échec ou pour toutes les exécutions). Lorsque vous lancez une exécution, vous pouvez éventuellement modifier le comportement par défaut.
1. (Facultatif) Associez une ou plusieurs balises au cache d'exécution.
1. Choisissez **Create run cache**. La console affiche le nouveau cache d'exécution dans le tableau des **caches d'exécution**.
## Création d'un cache d'exécution à l'aide de la CLI
Utilisez la commande **create-run-cache**CLI pour créer un cache d'exécution. Le comportement du cache par défaut est`CACHE_ON_FAILURE`.
```
aws omics create-run-cache \
--name "workflow 123 run cache" \
--description "my run cache" \
--cache-s3-location "s3://amzn-s3-demo-bucket" \
--cache-behavior "CACHE_ALWAYS" \
--cache-bucket-owner-id "111122223333"
```
Si la création est réussie, vous recevez une réponse contenant les champs suivants.
```
{
"arn": "string",
"id": "string",
"status": "ACTIVE"
"tags": {}
}
```
# Mettre à jour un cache d'exécution
Vous pouvez modifier le nom, la description, les balises ou le comportement du cache, mais pas l'emplacement S3 du cache.
## Mettre à jour un cache d'exécution à l'aide de la console
Depuis la console, procédez comme suit pour mettre à jour un cache d'exécution.
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez **Exécuter les caches**.
1. Dans le tableau **Exécuter les caches**, choisissez le cache d'exécution à mettre à jour, puis sélectionnez **Modifier**.
1. Dans le panneau **Détails du cache d'exécution**, vous pouvez mettre à jour les champs du nom, de la description et du comportement du cache d'exécution.
1. (Facultatif) Associez une ou plusieurs nouvelles balises au cache d'exécution ou supprimez les balises existantes.
1. Choisissez **Enregistrer le cache d'exécution**.
## Mise à jour d'un cache d'exécution à l'aide de la CLI
Utilisez la commande **update-run-cache**CLI pour mettre à jour un cache d'exécution.
```
aws omics update-run-cache \
--name "workflow 123 run cache" \
--id "workflow id" \
--description "my run cache" \
--cache-behavior "CACHE_ALWAYS"
```
Si la mise à jour est réussie, vous recevez une réponse sans champs de données.
# Supprimer un cache d'exécution
Vous pouvez supprimer un cache d'exécution s'il n'est utilisé par aucun essai actif. Si des exécutions utilisent le cache d'exécution, attendez qu'elles soient terminées ou annulez-les.
La suppression d'un cache d'exécution supprime la ressource et ses métadonnées, mais ne supprime pas les données dans Amazon S3. Une fois le cache supprimé, vous ne pouvez pas le rattacher ou l'utiliser pour les exécutions suivantes.
Les données mises en cache restent dans Amazon S3 pour que vous puissiez les inspecter. Vous pouvez supprimer les anciennes données du cache à l'aide **Delete** des opérations S3 standard. Vous pouvez également créer une politique de cycle de vie Amazon S3 pour faire expirer les données mises en cache que vous n'utilisez plus.
## Supprimer un cache d'exécution à l'aide de la console
Depuis la console, procédez comme suit pour supprimer un cache d'exécution.
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez **Exécuter les caches**.
1. Dans le tableau **Exécuter les caches**, choisissez le cache d'exécution à supprimer.
1. Dans le menu du tableau **Exécuter les caches**, choisissez **Supprimer**.
1. Dans la boîte de dialogue modale, enregistrez le lien de données du cache Amazon S3 pour référence future, puis confirmez que vous souhaitez supprimer le cache d'exécution.
Vous pouvez utiliser le lien Amazon S3 pour inspecter les données mises en cache, mais vous ne pouvez pas les relier à un autre cache d'exécution. Supprimez les données du cache lorsque vous avez terminé l'inspection.
## Supprimer un cache d'exécution à l'aide de la CLI
Utilisez la commande **delete-run-cache**CLI pour supprimer un cache d'exécution.
```
aws omics delete-run-cache \
--id "my cache id"
```
Si la suppression est réussie, vous recevez une réponse sans champs de données.
# Contenu d'un cache d'exécution
HealthOmics organise votre cache d'exécution selon la structure suivante dans votre compartiment S3 :
```
s3://{cache.S3location}/{cache.uuid}/runID/taskID/{cacheentry.uuid}/
```
Le cache.uuid est l'identifiant unique mondial du cache. Le cacheentry.uuid est l'uuid unique au monde pour une tâche mise en cache. HealthOmics attribue les UUID aux caches et aux tâches.
Pour tous les moteurs de flux de travail, le cache contient les fichiers suivants :
+ Le **\$1cacheentryuuid\$1.json** fichier — HealthOmics crée ce fichier manifeste, qui contient des informations sur le cache, y compris une liste de tous les éléments du cache et la [version du cache](how-run-cache.md#workflow-cache-data-versions).
+ Fichiers de sortie de tâche : chaque sortie de tâche se compose d'un ou de plusieurs fichiers, tels que définis par la tâche.
Pour un flux de travail utilisant Nextflow, le moteur Nextflow crée les fichiers supplémentaires suivants dans le cache :
+ Le **command.out** fichier — Ce fichier contient le contenu standard de l'exécution de la tâche.
+ Le **.exitcode** fichier : ce fichier contient le code de sortie de la tâche (un entier).
**Note**
Si vous souhaitez accéder aux fichiers de tâches intermédiaires de votre cache d'exécution pour un dépannage avancé, déclarez ces fichiers en tant que résultats de tâches dans la définition du flux de travail.
# Fonctionnalités de mise en cache spécifiques au moteur
HealthOmics essaie de fournir une implémentation cohérente de la mise en cache des appels dans tous les moteurs de flux de travail. Il existe certaines différences en fonction de la façon dont chaque moteur de flux de travail gère des cas spécifiques :
+ Flux suivant
+ La mise en cache entre les différentes versions de Nextflow n'est pas garantie. Si vous exécutez une tâche sur une version de Nextflow, puis que vous exécutez la même tâche sur une autre version de Nextflow, HealthOmics vous pouvez considérer la deuxième exécution comme un échec du cache.
+ Vous pouvez désactiver la mise en cache pour des tâches individuelles à l'aide de la **false** directive cache. Pour plus d'informations sur cette directive, consultez les [processus](https://www.nextflow.io/docs/latest/process.html#process-cache) de la spécification Nextflow.
+ HealthOmics utilise le mode indulgent de Nextflow, mais ne prend pas en charge le mode de mise en cache approfondie.
+ La mise en cache évalue chaque objet S3 individuel si vous utilisez un modèle global dans le chemin S3 vers les entrées d'une tâche. Si vous ajoutez un nouvel objet, HealthOmics recalcule uniquement les tâches qui utilisent le nouvel objet.
+ HealthOmics ne met pas en cache les nouvelles tentatives de tâches. Ce comportement est cohérent avec le comportement par défaut de Nextflow.
+ WDL
+ HealthOmics prend en charge le nouveau type de « répertoire » pour les entrées lorsque vous utilisez la version de développement du flux de travail WDL. Pour la mise en cache des appels, si un objet du répertoire change, toutes les tâches entrées dans le répertoire HealthOmics sont recalculées.
+ HealthOmics prend en charge la mise en cache au niveau des tâches, mais pas la mise en cache au niveau du flux de travail.
+ Vous pouvez désactiver la mise en cache pour des tâches individuelles à l'aide de l'attribut **volatile**. Pour de plus amples informations, veuillez consulter [Désactiver la mise en cache au niveau des tâches avec l'attribut volatile](workflow-languages-wdl.md#workflow-wdl-volatile-attribute).
+ CWL
+ Les résultats constants des tâches ne sont pas explicitement visibles dans les manifestes. HealthOmics met en cache les sorties constantes sous forme de fichiers intermédiaires.
+ Vous pouvez contrôler la mise en cache pour des tâches individuelles à l'aide de [WorkReuse](https://www.commonwl.org/v1.1/Workflow.html#WorkReuse)cette fonctionnalité.
# Utilisation du cache d'exécution
Par défaut, les exécutions n'utilisent pas de cache d'exécution. Pour utiliser un cache pour l'exécution, vous devez spécifier le cache d'exécution et le comportement du cache d'exécution lorsque vous démarrez l'exécution.
Une fois l'exécution terminée, vous pouvez utiliser la console, les CloudWatch journaux ou les opérations de l'API pour suivre les accès au cache ou résoudre les problèmes liés au cache. Pour plus d’informations, consultez [Suivi des informations de mise en cache des appels](#workflow-cache-track) et [Résolution des problèmes de mise en cache des appels](troubleshooting.md#workflow-cache-troubleshooting).
Si une ou plusieurs tâches d'une exécution génèrent des résultats non déterministes, nous vous recommandons vivement de ne pas utiliser la mise en cache des appels pour l'exécution ou de désactiver ces tâches spécifiques de la mise en cache. Pour de plus amples informations, veuillez consulter [Modèle de responsabilité partagée](how-run-cache.md#run-cache-srm).
**Note**
Vous fournissez un rôle de service IAM lorsque vous lancez une exécution. Pour utiliser la mise en cache des appels, le rôle de service doit être autorisé à accéder à l'emplacement du cache d'exécution Amazon S3. Pour de plus amples informations, veuillez consulter [Rôles de service pour AWS HealthOmics](permissions-service.md).
Vous pouvez utiliser la [CLI Kiro](https://docs.aws.amazon.com/kiro/latest/userguide/what-is.html) pour analyser et gérer les données de votre cache d'exécution. Pour plus d'informations, consultez les [exemples d'instructions pour la CLI Kiro](getting-started.md#omics-kiro-prompts) et le didacticiel [HealthOmics Agentic Generative AI](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) sur. GitHub
**Topics**
+ [Configuration d'une exécution avec cache d'exécution à l'aide de la console](#workflow-cache-startrun-console)
+ [Configuration d'une exécution avec cache d'exécution à l'aide de la CLI](#workflow-cache-startrun-api)
+ [Cas d'erreur pour les caches d'exécution](#workflow-cache-errors)
+ [Suivi des informations de mise en cache des appels](#workflow-cache-track)
## Configuration d'une exécution avec cache d'exécution à l'aide de la console
À partir de la console, vous configurez le cache d'exécution pour une exécution lorsque vous démarrez l'exécution.
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez **Runs**.
1. Sur la page **Exécutions**, choisissez la course à démarrer.
1. Choisissez **Démarrer l'exécution** et effectuez les étapes 1 et 2 de **Démarrer l'exécution** comme décrit dans[Démarrer une course à l'aide de la console](starting-a-run.md#starting-a-run-console).
1. À l'étape 3 de **Démarrer l'exécution**, choisissez **Sélectionner un cache d'exécution existant**.
1. Sélectionnez le cache dans la liste déroulante **Run cache ID**.
1. Pour remplacer le comportement de cache d'exécution par défaut, choisissez le **comportement de cache** pour l'exécution. Pour de plus amples informations, veuillez consulter [Exécuter le comportement du cache](how-run-cache.md#run-cache-behavior).
1. Passez à l'étape 4 de **Démarrer l'exécution**.
## Configuration d'une exécution avec cache d'exécution à l'aide de la CLI
Pour démarrer une exécution utilisant un cache d'exécution, ajoutez le paramètre cache-id à la commande **start-run** CLI. Utilisez éventuellement le `cache-behavior` paramètre pour remplacer le comportement par défaut que vous avez configuré pour le cache d'exécution. L'exemple suivant montre uniquement les champs de cache de la commande :
```
aws omics start-run \
...
--cache-id "xxxxxx" \
--cache-behavior CACHE_ALWAYS
```
Si l'opération est réussie, vous recevez une réponse sans champs de données.
## Cas d'erreur pour les caches d'exécution
Dans les scénarios suivants, il est HealthOmics possible que les résultats des tâches ne soient pas mis en cache, même dans le cas d'une exécution avec un comportement de cache défini sur **Toujours mettre en cache**.
+ Si l'exécution rencontre une erreur avant que la première tâche ne soit terminée correctement, il n'y a aucune sortie de cache à exporter.
+ Si le processus d'exportation échoue, les résultats de la tâche HealthOmics ne sont pas enregistrés dans l'emplacement du cache Amazon S3.
+ Si l'exécution échoue en raison d'une **filesystem out of space** erreur, la mise en cache des appels n'enregistre aucun résultat de tâche.
+ Si vous annulez une exécution, la mise en cache des appels n'enregistre aucun résultat de tâche.
+ Si le délai d'exécution est dépassé, la mise en cache des appels n'enregistre aucun résultat de tâche, même si vous avez configuré l'exécution pour utiliser le cache en cas d'échec.
## Suivi des informations de mise en cache des appels
Vous pouvez suivre les événements de mise en cache des appels (tels que les accès au cache d'exécution) à l'aide de la console, de la CLI ou CloudWatch des journaux.
**Topics**
+ [Suivez les accès au cache à l'aide de la console](#workflow-cache-track-console)
+ [Suivez la mise en cache des appels à l'aide de la CLI](#workflow-cache-track-cli)
+ [Suivez la mise en cache des appels à l'aide des journaux CloudWatch](#workflow-cache-track-cwl)
### Suivez les accès au cache à l'aide de la console
Dans la page des détails de l'exécution d'une exécution, le tableau **Exécuter les tâches** affiche les informations relatives **aux accès au cache** pour chaque tâche. Le tableau inclut également un lien vers l'entrée de cache associée. Utilisez la procédure suivante pour afficher les informations relatives aux accès au cache lors d'une exécution.
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez **Runs**.
1. Sur la page **Exécutions**, choisissez l'exécution à inspecter.
1. Sur la page des détails de l'exécution, choisissez l'onglet **Exécuter les tâches** pour afficher le tableau des tâches.
1. Si une tâche a un accès au cache, la colonne **Accès au cache** contient un lien vers l'emplacement d'entrée du cache d'exécution dans Amazon S3.
1. Cliquez sur le lien pour inspecter l'entrée du cache d'exécution.
### Suivez la mise en cache des appels à l'aide de la CLI
Utilisez la commande **get-run CLI** pour vérifier si l'exécution a utilisé un cache d'appels.
```
aws omics get-run --id 1234567
```
Dans la réponse, si le `cacheId` champ est défini, l'exécution utilise ce cache.
Utilisez la commande **list-run-tasks**CLI pour récupérer l'emplacement des données du cache pour chaque tâche mise en cache en cours d'exécution.
```
aws omics list-run-tasks --id 1234567
```
Dans la réponse, si le champ CacheHit d'une tâche est vrai, le champ Caches3URI indique l'emplacement des données du cache pour cette tâche.
Vous pouvez également utiliser la commande **get-run-task**CLI pour récupérer l'emplacement des données du cache pour une tâche spécifique :
```
aws omics get-run-task --id 1234567 --task-id
```
### Suivez la mise en cache des appels à l'aide des journaux CloudWatch
HealthOmics crée des journaux d'activité du cache dans le groupe de `/aws/omics/WorkflowLog` CloudWatch journaux. Il existe un flux de journal pour chaque cache d'exécution : **RunCache//**.
Pour les exécutions utilisant la mise en cache des appels, HealthOmics génère CloudWatch des entrées de journal pour les événements suivants :
+ création d'une entrée de cache (CACHE\$1ENTRY\$1CREATED)
+ correspondant à une entrée de cache (CACHE\$1HIT)
+ ne correspond pas à une entrée de cache (CACHE\$1MISS)
Pour plus d'informations sur ces journaux, consultez[Se connecte CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs).
Utilisez la requête CloudWatch Insights suivante sur le groupe de `/aws/omics/WorkflowLog` journaux pour renvoyer le nombre de visites au cache par exécution pour ce cache :
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_HIT'
parse "run: *," as run
stats count(*) as cacheHits by run
```
Utilisez la requête suivante pour renvoyer le nombre d'entrées de cache créées par chaque exécution :
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_ENTRY_CREATED'
parse "run: *," as run
stats count(*) as cacheEntries by run
```