Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Almacenamiento en caché de llamadas para ejecuciones HealthOmics
AWS HealthOmics admite el almacenamiento en caché de llamadas, también conocido como currículum, para flujos de trabajo privados. El almacenamiento en caché de llamadas guarda los resultados de las tareas de flujo de trabajo completadas una vez finalizada la ejecución. Las ejecuciones posteriores pueden utilizar los resultados de las tareas de la memoria caché, en lugar de volver a calcular los resultados de las tareas. El almacenamiento en caché de las llamadas reduce el uso de recursos informáticos, lo que se traduce en una menor duración de las ejecuciones y en un ahorro de costes informáticos.
Puede acceder a los archivos de salida de las tareas en caché una vez finalizada la ejecución. Para realizar tareas avanzadas de depuración y solución de problemas, puede almacenar en caché los archivos de tareas intermedias especificando estos archivos como resultados de las tareas en la definición del flujo de trabajo.
Puede utilizar el almacenamiento en caché de llamadas para guardar los resultados de las tareas finalizadas tras las ejecuciones fallidas. La siguiente ejecución comienza con la última tarea completada correctamente, en lugar de volver a calcular las tareas completadas.
Si HealthOmics no encuentra una entrada de caché que coincida con una tarea, la ejecución no fallará. HealthOmics vuelve a calcular la tarea y las tareas dependientes.
Para obtener información sobre la solución de problemas de almacenamiento en caché de llamadas, consulte. [Solución de problemas de almacenamiento en caché de llamadas](troubleshooting.md#workflow-cache-troubleshooting)
**Topics**
+ [Cómo funciona el almacenamiento en caché de llamadas](how-run-cache.md)
+ [Crear una caché de ejecución](workflow-cache-create.md)
+ [Actualización de una caché de ejecución](workflow-cache-update.md)
+ [Eliminar una caché de ejecución](workflow-cache-delete.md)
+ [Contenido de una caché de ejecución](workflow-cache-contents.md)
+ [Funciones de almacenamiento en caché específicas del motor](workflow-cache-per-engine.md)
+ [Uso de la caché de ejecución](workflow-cache-startrun.md)
# Cómo funciona el almacenamiento en caché de llamadas
Para usar el almacenamiento en caché de llamadas, debe crear una caché de ejecución y configurarla para que tenga una ubicación de Amazon S3 asociada para los datos en caché. Al iniciar una ejecución, debe especificar la caché de ejecución. Una caché de ejecución no está dedicada a un flujo de trabajo. Las ejecuciones de varios flujos de trabajo pueden usar la misma caché.
Durante la fase de exportación de una ejecución, el sistema exporta los resultados de las tareas completadas a la ubicación de Amazon S3. Para exportar archivos de tareas intermedias, declare estos archivos como resultados de tareas en la definición del flujo de trabajo. El almacenamiento en caché de llamadas también guarda internamente los metadatos y crea hashes únicos para cada entrada de la caché.
Para cada tarea de una ejecución, el motor de flujo de trabajo detecta si hay una entrada de caché coincidente para esta tarea. Si no hay ninguna entrada de caché coincidente, HealthOmics calcula la tarea. Si hay una entrada de caché coincidente, el motor recupera los resultados almacenados en caché.
Para hacer coincidir las entradas de la caché, HealthOmics utiliza el mecanismo de hash que se incluye en los motores de flujo de trabajo nativos. HealthOmicsamplía estas implementaciones de hash existentes para tener en cuenta HealthOmics variables, como las ETags de S3 y los resúmenes de contenedores ECR.
HealthOmics admite el almacenamiento en caché de llamadas para las siguientes versiones de lenguajes de flujo de trabajo:
+ Las versiones 1.0 y 1.1 de WDL y la versión de desarrollo
+ Nextflow, versión 23.10 y posteriores
+ Todas las versiones de CWL
**nota**
HealthOmics no admite el almacenamiento en caché de llamadas para los flujos de trabajo de Ready2Run.
**Topics**
+ [Modelo de responsabilidad compartida](#run-cache-srm)
+ [Requisitos de almacenamiento en caché para las tareas](#workflow-cache-task-prereqs)
+ [Ejecute el rendimiento de la caché](#run-cache-performance)
+ [Almacene en caché los eventos de retención e invalidación de datos](#workflow-cache-data)
## Modelo de responsabilidad compartida
Los usuarios comparten la responsabilidad de determinar si las tareas y AWS las ejecuciones son buenas candidatas para el almacenamiento de llamadas en caché. El almacenamiento en caché de llamadas logra los mejores resultados cuando todas las tareas son idempotentes (las ejecuciones repetidas de una tarea con las mismas entradas producen los mismos resultados).
Sin embargo, si una tarea incluye elementos no deterministas (como la generación de números aleatorios o la hora del sistema), las ejecuciones repetidas de la tarea con las mismas entradas pueden generar resultados diferentes. Esto puede afectar a la eficacia del almacenamiento en caché de las llamadas de las siguientes maneras:
+ Si HealthOmics utiliza una entrada de caché (creada por una ejecución anterior) que no es idéntica a la salida que generaría la ejecución de la tarea para la ejecución actual, la ejecución puede producir resultados diferentes a los de la misma ejecución sin almacenamiento en caché.
+ HealthOmics es posible que no encuentre una entrada de caché coincidente para una tarea que debería coincidir, debido a que los resultados de la tarea no son deterministas. Si no encuentra la entrada de caché válida, la ejecución vuelve a calcular innecesariamente la tarea, lo que reduce las ventajas de ahorro de costes que supone el uso del almacenamiento en caché de llamadas.
Los siguientes son comportamientos conocidos de las tareas que pueden provocar resultados no deterministas que afecten a los resultados del almacenamiento en caché de las llamadas:
+ Uso de generadores de números aleatorios.
+ Depende del tiempo del sistema.
+ Uso de la simultaneidad (las condiciones de carrera pueden provocar una variación en la salida).
+ Obtener archivos locales o remotos más allá de lo especificado en los parámetros de entrada de la tarea.
Para ver otros escenarios que pueden provocar un comportamiento no determinista, consulte las [entradas de procesos no deterministas](https://www.nextflow.io/docs/latest/cache-and-resume.html#non-deterministic-process-inputs) en el sitio de documentación de Nextflow.
Si sospecha que una tarea produce resultados que no son deterministas, considere la posibilidad de utilizar las funciones del motor de flujo de trabajo para evitar almacenar en caché tareas específicas que no sean deterministas. Para obtener instrucciones sobre cómo inhabilitar el almacenamiento en caché para tareas individuales en cada uno de los lenguajes de flujo de trabajo compatibles, consulte. [Funciones de almacenamiento en caché específicas del motor](workflow-cache-per-engine.md)
Le recomendamos que revise detenidamente sus requisitos específicos de flujo de trabajo y tareas antes de habilitar el almacenamiento en caché de llamadas en cualquier entorno en el que un almacenamiento en caché de llamadas ineficaz o resultados diferentes a los esperados puedan suponer un riesgo. Por ejemplo, las posibles limitaciones del almacenamiento en caché de llamadas deben considerarse detenidamente al determinar si el almacenamiento en caché de llamadas es adecuado para los casos de uso clínico.
## Requisitos de almacenamiento en caché para las tareas
HealthOmics almacena en caché los resultados de las tareas que cumplen los siguientes requisitos:
+ La tarea debe definir un contenedor. HealthOmics no almacenará en caché los resultados de una tarea sin contenedor.
+ La tarea debe producir uno o más resultados. Los resultados de la tarea se especifican en la definición del flujo de trabajo.
+ La definición del flujo de trabajo no debe utilizar valores dinámicos. Por ejemplo, si pasa un parámetro a una tarea con un valor que aumenta con cada ejecución, HealthOmics no se almacenan en caché los resultados de la tarea.
**nota**
Si varias tareas de una ejecución utilizan la misma imagen de contenedor, HealthOmics proporciona la misma versión de imagen para todas estas tareas. Tras HealthOmics extraer la imagen, ignora cualquier actualización de la imagen del contenedor durante la ejecución. Este enfoque proporciona una experiencia predecible y coherente y evita los posibles problemas que puedan surgir a causa de las actualizaciones de la imagen del contenedor que se despliegan a mitad de la ejecución.
## Ejecute el rendimiento de la caché
Al activar el almacenamiento en caché de llamadas durante una ejecución, es posible que notes los siguientes impactos en el rendimiento de la ejecución:
+ Durante la primera ejecución, HealthOmics guarda los datos en caché de las tareas de la ejecución. Es posible que los tiempos de exportación sean más largos durante esta ejecución, ya que el almacenamiento en caché de las llamadas aumenta la cantidad de datos de exportación.
+ En las siguientes ejecuciones, al reanudar una ejecución desde la memoria caché, es posible que se reduzca el número de pasos de procesamiento y el tiempo de ejecución.
+ Si también opta por declarar los archivos intermedios como salidas, los tiempos de exportación podrían ser incluso más largos, ya que estos datos pueden ser más detallados.
## Almacene en caché los eventos de retención e invalidación de datos
El objetivo principal de una caché de ejecución es optimizar el cálculo de las tareas en ejecución. Si hay una entrada de caché válida que coincida con una tarea, HealthOmics utiliza la entrada de caché en lugar de volver a calcular la tarea. De lo contrario, HealthOmics vuelve al comportamiento predeterminado del servicio, que consiste en volver a calcular la tarea y las tareas dependientes. Al usar este enfoque, los errores en la memoria caché no provocan un error en la ejecución.
Se recomienda administrar el tamaño de la caché de ejecución. Con el tiempo, es posible que las entradas de la caché dejen de ser válidas debido a las actualizaciones del motor de flujo de trabajo o del HealthOmics servicio, o a los cambios realizados en la ejecución o en las tareas de ejecución. En las siguientes secciones se proporcionan detalles adicionales.
**Topics**
+ [Actualizaciones de la versión del manifiesto y actualización de los datos](#workflow-cache-data-versions)
+ [Ejecute el comportamiento de la caché](#run-cache-behavior)
+ [Controle el tamaño de la caché de ejecución](#workflow-cache-manage)
### Actualizaciones de la versión del manifiesto y actualización de los datos
Periódicamente, el HealthOmics servicio puede introducir nuevas funciones o actualizaciones del motor de flujo de trabajo que invaliden algunas o todas las entradas de la memoria caché de ejecución. En esta situación, es posible que las ejecuciones pierdan la memoria caché una sola vez.
HealthOmics crea un [archivo de manifiesto JSON](workflow-cache-contents.md) para cada entrada de caché. En el caso de las ejecuciones iniciadas después del 12 de febrero de 2025, el archivo de manifiesto incluye un parámetro de versión. Si una actualización del servicio invalida alguna entrada de la caché, HealthOmics incrementa el número de versión para que puedas identificar las entradas de la caché antiguas para eliminarlas.
En el siguiente ejemplo, se muestra un archivo de manifiesto con la versión establecida en 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,
}
```
Para las ejecuciones con entradas de caché que ya no son válidas, reconstruya la caché para crear nuevas entradas válidas. Realice los siguientes pasos para cada ejecución:
1. Inicie la ejecución una vez con la retención de caché establecida en CACHE ALWAYS. Esta ejecución crea las nuevas entradas de caché.
1. Para las siguientes ejecuciones, establezca la retención de la caché en su configuración anterior (CACHE ALWAYS o CACHE ON FAILURE).
Para limpiar las entradas de caché que ya no son válidas, puede eliminarlas del bucket de caché de Amazon S3. HealthOmics nunca reutiliza estas entradas de caché. Si decides conservar las entradas que no son válidas, esto no afectará a tus tiradas.
**nota**
El almacenamiento en caché de llamadas guarda los datos de salida de las tareas en la ubicación de Amazon S3 especificada para la caché, lo que supone un coste para usted. Cuenta de AWS
### Ejecute el comportamiento de la caché
Puede configurar el comportamiento de la caché de ejecución para guardar los resultados de las tareas de las ejecuciones que fallan (caché en caso de error) o de todas las ejecuciones (caché siempre). Al crear una caché de ejecuciones, se establece el comportamiento predeterminado de la caché para todas las ejecuciones que utilizan esta caché. Puede anular el comportamiento predeterminado al iniciar una ejecución.
**Cache on failure**es útil si está depurando un flujo de trabajo que falla después de que varias tareas se hayan completado correctamente. La ejecución siguiente se reanudará desde la última tarea completada correctamente si todas las variables únicas consideradas en el hash son idénticas a las de la ejecución anterior.
**Cache always**es útil si está actualizando una tarea en un flujo de trabajo que se completa correctamente. Te recomendamos que sigas estos pasos:
1. Cree una nueva ejecución. Establezca el **comportamiento** de la **caché en Caché siempre** e inicie la ejecución.
1. Una vez completada la ejecución, actualice la tarea en el flujo de trabajo e inicie una nueva ejecución con el comportamiento configurado Guardar **siempre en caché**. Esta ejecución procesa la tarea actualizada y cualquier tarea posterior que dependa de la tarea actualizada. Todas las demás tareas utilizan los resultados almacenados en caché.
1. Repita el paso 2 según sea necesario, hasta que se complete el desarrollo de la tarea actualizada.
1. Utilice la tarea actualizada según sea necesario en futuras ejecuciones. Recuerde cambiar las siguientes ejecuciones a la **memoria caché en caso de error** si piensa utilizar entradas nuevas o diferentes para estas ejecuciones.
**nota**
Se recomienda utilizar **siempre el modo Caché** mientras se utiliza el mismo conjunto de datos de prueba, pero no para un lote de ejecuciones. Si configura este modo para un lote grande de ejecuciones, el sistema puede exportar grandes cantidades de datos a Amazon S3, lo que se traduce en un aumento de los tiempos de exportación y de los costes de almacenamiento.
### Controle el tamaño de la caché de ejecución
HealthOmics no elimina ni archiva automáticamente ningún dato de la caché de ejecución ni aplica las reglas de limpieza de Amazon S3 para gestionar los datos de la caché. Le recomendamos que realice limpiezas de caché periódicas para ahorrar en los costes de almacenamiento de Amazon S3 y mantener el tamaño de la caché de ejecución manejable. Puede eliminar los archivos directamente o establecer retention/replication políticas de datos en el depósito de caché de ejecución.
Por ejemplo, puede configurar una política de ciclo de vida de Amazon S3 para que los objetos caduquen después de 90 días, o puede limpiar manualmente los datos de la caché al final de cada proyecto de desarrollo.
La siguiente información puede ayudarle a administrar el tamaño de los datos de la caché:
+ Puede ver la cantidad de datos que hay en la memoria caché consultando Amazon S3. HealthOmics no supervisa ni informa sobre el tamaño de la caché.
+ Si eliminas una entrada de caché válida, la ejecución posterior no fallará. HealthOmics vuelve a calcular la tarea y las tareas dependientes.
+ Si modifica los nombres de la caché o las estructuras de directorios de manera que no HealthOmics pueda encontrar una entrada coincidente para una tarea, HealthOmics vuelve a calcular la tarea.
Si necesitas comprobar si una entrada de caché sigue siendo válida, comprueba el número de versión del manifiesto de la caché. Para obtener más información, consulte [Actualizaciones de la versión del manifiesto y actualización de los datos](#workflow-cache-data-versions).
# Crear una caché de ejecución
Cuando crea una caché de ejecución, especifica una ubicación de Amazon S3 para los datos de la caché. Se debe poder acceder a estos datos de forma inmediata. El almacenamiento en caché de llamadas no recupera los objetos archivados en Glacier (como las clases de almacenamiento GFR y GDA).
Si el depósito de Amazon S3 para los datos de la caché es propiedad de otra Cuenta de AWS persona, proporcione ese ID de cuenta al crear la caché de ejecución.
## Crear una caché de ejecución mediante la consola
Desde la consola, sigue estos pasos para crear una caché de ejecución.
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abre el panel de navegación izquierdo (≡). Seleccione **Ejecutar cachés**.
1. En la página **Ejecutar cachés**, selecciona **Crear caché de ejecución**.
1. En el panel de **detalles de la caché de ejecución** de la página **Crear caché de ejecución**, configure estos campos:
1. Introduzca un nombre para la caché de ejecución.
1. (Opcional) Introduzca una descripción.
1. Introduzca una ubicación S3 para la salida almacenada en caché. Elija un depósito en la misma región que su flujo de trabajo.
1. (Opcional) Introduzca el nombre Cuenta de AWS del propietario del bucket para verificar la propiedad del bucket. Si no ingresas ningún valor, el valor predeterminado es tu ID de cuenta.
1. En **Comportamiento de la caché**, configura el comportamiento predeterminado (ya sea para almacenar en caché los resultados de las ejecuciones fallidas o de todas las ejecuciones). Al iniciar una ejecución, si lo desea, puede anular el comportamiento predeterminado.
1. (Opcional) Asocie una o más etiquetas a la caché de ejecución.
1. Seleccione **Crear caché de ejecución**. La consola muestra la nueva caché de ejecución en la tabla **Cachés de ejecución**.
## Creación de una caché de ejecución mediante la CLI
Utilice el comando **create-run-cache**CLI para crear una caché de ejecución. El comportamiento predeterminado de la caché es`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 creación se realiza correctamente, recibirá una respuesta con los siguientes campos.
```
{
"arn": "string",
"id": "string",
"status": "ACTIVE"
"tags": {}
}
```
# Actualización de una caché de ejecución
Puede cambiar el nombre, la descripción, las etiquetas o el comportamiento de la caché, pero no su ubicación en S3.
## Actualización de una caché de ejecución mediante la consola
Desde la consola, sigue estos pasos para actualizar una caché de ejecución.
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abre el panel de navegación izquierdo (≡). Seleccione **Ejecutar cachés**.
1. **En la tabla **Ejecutar cachés**, elija la caché de ejecución que desee actualizar y, a continuación, seleccione Editar.**
1. En el panel de **detalles de la caché** de ejecución, puede actualizar los campos de nombre, descripción y comportamiento de la caché de ejecución.
1. (Opcional) Asocie una o más etiquetas nuevas a la caché de ejecución o elimine las etiquetas existentes.
1. Selecciona **Guardar caché de ejecución**.
## Actualización de una caché de ejecución mediante la CLI
Utilice el comando **update-run-cache**CLI para actualizar una caché de ejecución.
```
aws omics update-run-cache \
--name "workflow 123 run cache" \
--id "workflow id" \
--description "my run cache" \
--cache-behavior "CACHE_ALWAYS"
```
Si la actualización se realiza correctamente, recibirá una respuesta sin campos de datos.
# Eliminar una caché de ejecución
Puede eliminar una caché de ejecución si no la está utilizando ninguna ejecución activa. Si alguna ejecución utiliza la caché de ejecuciones, espere a que se completen o puede cancelarlas.
Al eliminar una caché de ejecución, se eliminan el recurso y sus metadatos, pero no se eliminan los datos de Amazon S3. Después de eliminar la caché, no podrá volver a adjuntarla ni usarla para ejecuciones posteriores.
Los datos en caché permanecen en Amazon S3 para su inspección. Puede eliminar los datos de caché antiguos mediante **Delete** las operaciones estándar de S3. También puede crear una política de ciclo de vida de Amazon S3 para caducar los datos en caché que ya no utilice.
## Eliminar una caché de ejecución mediante la consola
Desde la consola, sigue estos pasos para eliminar una caché de ejecución.
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abre el panel de navegación izquierdo (≡). Seleccione **Ejecutar cachés**.
1. En la tabla **Ejecutar cachés**, elija la caché de ejecución que desee eliminar.
1. **En el menú de la tabla **Ejecutar cachés**, seleccione Eliminar.**
1. En el cuadro de diálogo modal, guarde el enlace de datos de la caché de Amazon S3 para consultarlo en el futuro y, a continuación, confirme que desea eliminar la caché de ejecución.
Puede usar el enlace de Amazon S3 para inspeccionar los datos en caché, pero no puede volver a vincular los datos a otra caché de ejecución. Elimine los datos de la caché cuando haya terminado la inspección.
## Eliminar una caché de ejecución mediante la CLI
Utilice el comando **delete-run-cache**CLI para eliminar una caché de ejecución.
```
aws omics delete-run-cache \
--id "my cache id"
```
Si la eliminación se realiza correctamente, recibirá una respuesta sin campos de datos.
# Contenido de una caché de ejecución
HealthOmics organiza la caché de carreras con la siguiente estructura en el bucket de S3:
```
s3://{cache.S3location}/{cache.uuid}/runID/taskID/{cacheentry.uuid}/
```
El cache.uuid es el identificador único global de la caché. El cacheentry.uuid es el uuid único a nivel mundial para una tarea en caché. HealthOmics asigna los uuids a las cachés y a las tareas.
Para todos los motores de flujo de trabajo, la caché contiene los siguientes archivos:
+ El **\$1cacheentryuuid\$1.json** archivo: HealthOmics crea este archivo de manifiesto, que contiene información sobre la caché, incluida una lista de todos los elementos de la caché y la [versión de la caché](how-run-cache.md#workflow-cache-data-versions).
+ Archivos de salida de la tarea: cada resultado de la tarea consta de uno o más archivos, según lo defina la tarea.
Para un flujo de trabajo que usa Nextflow, el motor de Nextflow crea estos archivos adicionales en la memoria caché:
+ El **command.out** archivo: este archivo contiene el contenido estándar de la ejecución de la tarea.
+ El **.exitcode** archivo: este archivo contiene el código de salida de la tarea (un entero).
**nota**
Si desea acceder a los archivos de tareas intermedias de su caché de ejecución para solucionar problemas avanzados, declare estos archivos como resultados de tareas en la definición del flujo de trabajo.
# Funciones de almacenamiento en caché específicas del motor
HealthOmics intenta proporcionar una implementación coherente del almacenamiento de llamadas en caché en todos los motores de flujo de trabajo. Existen algunas diferencias según la forma en que cada motor de flujo de trabajo gestiona casos específicos:
+ Nextflow
+ No se garantiza el almacenamiento en caché en diferentes versiones de Nextflow. Si ejecuta una tarea en una versión de Nextflow y, a continuación, ejecuta la misma tarea en una versión diferente de Nextflow, HealthOmics podría considerarse que la segunda ejecución es una falta de memoria caché.
+ Puedes desactivar el almacenamiento en caché para tareas individuales mediante la directiva de caché. **false** Para obtener información sobre esta directiva, consulte [los procesos](https://www.nextflow.io/docs/latest/process.html#process-cache) de la especificación Nextflow.
+ HealthOmics usa el modo indulgente de Nextflow, pero no admite el modo de almacenamiento en caché profundo.
+ El almacenamiento en caché evalúa cada objeto S3 individual si se utiliza un patrón global en la ruta de S3 hacia las entradas de una tarea. Si añades un objeto nuevo, HealthOmics vuelve a calcular solo las tareas que utilizan el nuevo objeto.
+ HealthOmics no almacena en caché los reintentos de tareas. Este comportamiento es coherente con el comportamiento predeterminado de Nextflow.
+ WDL
+ HealthOmics admite el nuevo tipo de «directorio» para las entradas cuando se utiliza la versión de desarrollo del flujo de trabajo de la WDL. Para el almacenamiento en caché de llamadas, si algún objeto del directorio cambia, HealthOmics vuelve a calcular todas las tareas que entran en el directorio.
+ HealthOmics admite el almacenamiento en caché a nivel de tarea, pero no el almacenamiento en caché a nivel de flujo de trabajo.
+ **Puede deshabilitar el almacenamiento en caché para tareas individuales mediante el atributo volatile.** Para obtener más información, consulte [Deshabilite el almacenamiento en caché a nivel de tarea con el atributo volatile](workflow-languages-wdl.md#workflow-wdl-volatile-attribute).
+ CWL
+ Los resultados constantes de las tareas no se ven de forma explícita en los manifiestos. HealthOmics almacena en caché las salidas constantes como archivos intermedios.
+ Puede controlar el almacenamiento en caché de tareas individuales mediante esta función. [WorkReuse](https://www.commonwl.org/v1.1/Workflow.html#WorkReuse)
# Uso de la caché de ejecución
De forma predeterminada, las ejecuciones no utilizan una caché de ejecución. Para usar una caché para la ejecución, debe especificar la caché de ejecución y el comportamiento de la caché de ejecución al iniciar la ejecución.
Una vez completada una ejecución, puedes usar la consola, los CloudWatch registros o las operaciones de la API para realizar un seguimiento de las visitas a la caché o solucionar los problemas de la caché. Para más detalles, consulte [Seguimiento de la información de almacenamiento en caché de las llamadas](#workflow-cache-track) y [Solución de problemas de almacenamiento en caché de llamadas](troubleshooting.md#workflow-cache-troubleshooting).
Si una o más tareas de una ejecución generan resultados no deterministas, te recomendamos encarecidamente que no utilices el almacenamiento en caché de llamadas durante la ejecución o que excluyas estas tareas específicas del almacenamiento en caché. Para obtener más información, consulte [Modelo de responsabilidad compartida](how-run-cache.md#run-cache-srm).
**nota**
Al iniciar una ejecución, proporciona una función de servicio de IAM. Para utilizar el almacenamiento en caché de llamadas, el rol de servicio necesita permiso para acceder a la ubicación Amazon S3 de la caché de ejecución. Para obtener más información, consulte [Funciones de servicio para AWS HealthOmics](permissions-service.md).
Puede utilizar la [CLI de Kiro](https://docs.aws.amazon.com/kiro/latest/userguide/what-is.html) para analizar y gestionar los datos de la caché de ejecución. Para obtener más información, consulte [Ejemplos de instrucciones para la CLI de Kiro](getting-started.md#omics-kiro-prompts) y el tutorial sobre IA [generativa de HealthOmics Agentic](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) en. GitHub
**Topics**
+ [Configuración de una ejecución con caché de ejecución mediante la consola](#workflow-cache-startrun-console)
+ [Configuración de una ejecución con caché de ejecución mediante la CLI](#workflow-cache-startrun-api)
+ [Casos de error en las cachés de ejecución](#workflow-cache-errors)
+ [Seguimiento de la información de almacenamiento en caché de las llamadas](#workflow-cache-track)
## Configuración de una ejecución con caché de ejecución mediante la consola
Desde la consola, se configura la caché de ejecución de una ejecución al iniciarla.
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abre el panel de navegación izquierdo (≡). Elija **Ejecuciones**.
1. En la página **Ejecuciones**, seleccione la ejecución que desee iniciar.
1. Seleccione **Iniciar ejecución** y complete los pasos 1 y 2 de **Iniciar ejecución** tal y como se describe en[Iniciar una ejecución mediante la consola](starting-a-run.md#starting-a-run-console).
1. En el paso 3 de **Iniciar ejecución**, elija **Seleccionar una caché de ejecución existente**.
1. Seleccione la caché en la lista desplegable del **ID de caché de ejecución**.
1. Para anular el comportamiento predeterminado de la caché de ejecución, elija el **comportamiento de la caché** de la ejecución. Para obtener más información, consulte [Ejecute el comportamiento de la caché](how-run-cache.md#run-cache-behavior).
1. Continúe con el paso 4 de **Iniciar la ejecución**.
## Configuración de una ejecución con caché de ejecución mediante la CLI
**Para iniciar una ejecución que utilice una caché de ejecución, añada el parámetro cache-id al comando CLI start-run.** Si lo desea, utilice el `cache-behavior` parámetro para anular el comportamiento predeterminado que configuró para la caché de ejecución. El siguiente ejemplo muestra solo los campos de caché del comando:
```
aws omics start-run \
...
--cache-id "xxxxxx" \
--cache-behavior CACHE_ALWAYS
```
Si la operación se realiza correctamente, recibirá una respuesta sin campos de datos.
## Casos de error en las cachés de ejecución
En los siguientes escenarios, es HealthOmics posible que no se almacenen en caché los resultados de las tareas, ni siquiera en una ejecución con el comportamiento de caché establecido en Almacenar **siempre en caché**.
+ Si la ejecución detecta un error antes de que la primera tarea se complete correctamente, no habrá ningún resultado de caché que exportar.
+ Si se produce un error en el proceso de exportación, HealthOmics no guarda los resultados de la tarea en la ubicación de caché de Amazon S3.
+ Si la ejecución falla debido a un **filesystem out of space** error, el almacenamiento en caché de llamadas no guarda ningún resultado de la tarea.
+ Si cancelas una ejecución, el almacenamiento en caché de llamadas no guarda los resultados de ninguna tarea.
+ Si se agota el tiempo de espera de la ejecución, el almacenamiento en caché de llamadas no guarda ningún resultado de la tarea, incluso si configuraste la ejecución para usar la caché en caso de error.
## Seguimiento de la información de almacenamiento en caché de las llamadas
Puede realizar un seguimiento de los eventos de almacenamiento en caché de llamadas (como las visitas a la caché de ejecución) mediante la consola, la CLI o CloudWatch los registros.
**Topics**
+ [Realice un seguimiento de las visitas a la caché mediante la consola](#workflow-cache-track-console)
+ [Realice un seguimiento del almacenamiento en caché de llamadas mediante la CLI](#workflow-cache-track-cli)
+ [Realice un seguimiento del almacenamiento en caché de llamadas mediante registros CloudWatch](#workflow-cache-track-cwl)
### Realice un seguimiento de las visitas a la caché mediante la consola
En la página de detalles de una ejecución, la tabla **Ejecutar tareas** muestra la información sobre los **aciertos de caché** de cada tarea. La tabla también incluye un enlace a la entrada de caché asociada. Utilice el siguiente procedimiento para ver la información de aciertos de la caché de una ejecución.
1. Abra la [consola de HealthOmics ](https://console.aws.amazon.com/omics/).
1. Si es necesario, abra el panel de navegación izquierdo (≡). Elija **Ejecuciones**.
1. En la página **Ejecuciones**, elija la ejecución que desee inspeccionar.
1. En la página de detalles de la ejecución, seleccione la pestaña **Ejecutar tareas** para ver la tabla de tareas.
1. Si una tarea tiene un acceso de caché, la columna de **aciertos de caché** contiene un enlace a la ubicación de entrada de la caché de ejecución en Amazon S3.
1. Elija el enlace para inspeccionar la entrada de la caché de ejecución.
### Realice un seguimiento del almacenamiento en caché de llamadas mediante la CLI
Utilice el comando **CLI get-run** para confirmar si la ejecución utilizó una caché de llamadas.
```
aws omics get-run --id 1234567
```
En la respuesta, si el `cacheId` campo está establecido, la ejecución utiliza esa caché.
Utilice el comando **list-run-tasks**CLI para recuperar la ubicación de los datos de la caché de cada tarea en caché de la ejecución.
```
aws omics list-run-tasks --id 1234567
```
En la respuesta, si el campo cacheHit de una tarea es verdadero, el campo Caches3uri proporciona la ubicación de los datos de la caché de esa tarea.
También puede usar el comando **get-run-task**CLI para recuperar la ubicación de los datos de la caché para una tarea específica:
```
aws omics get-run-task --id 1234567 --task-id
```
### Realice un seguimiento del almacenamiento en caché de llamadas mediante registros CloudWatch
HealthOmics crea registros de actividad en caché en el grupo de `/aws/omics/WorkflowLog` CloudWatch registros. Hay un flujo de registro para cada caché de ejecución: **RunCache//**.
Para las ejecuciones que utilizan el almacenamiento en caché de llamadas, HealthOmics genera entradas de CloudWatch registro para los siguientes eventos:
+ crear una entrada de caché (CACHE\$1ENTRY\$1CREATED)
+ hacer coincidir una entrada de caché (CACHE\$1HIT)
+ no coincide con una entrada de caché (CACHE\$1MISS)
Para obtener más información sobre estos registros, consulte. [Inicia sesión CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs)
Utilice la siguiente consulta de CloudWatch Insights en el grupo de `/aws/omics/WorkflowLog` registros para obtener el número de visitas a la caché por ejecución de esta caché:
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_HIT'
parse "run: *," as run
stats count(*) as cacheHits by run
```
Utilice la siguiente consulta para devolver el número de entradas de caché creadas por cada ejecución:
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_ENTRY_CREATED'
parse "run: *," as run
stats count(*) as cacheEntries by run
```