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, versiones 23.10 y 24.10

• Todas las versiones de CWL

nota

HealthOmics no admite el almacenamiento en caché de llamadas para los flujos de trabajo de Ready2Run.

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 dar como resultado 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 Entradas de procesos no deterministas 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, como la exclusión de la memoria caché en Nextflow, para evitar almacenar en caché tareas específicas que no sean deterministas.

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 el almacenamiento en caché de llamadas ineficaz o los 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. Con 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.

Temas

• Actualizaciones de la versión del manifiesto y actualización de los datos

• Ejecute el comportamiento de la caché

• Controle el tamaño de la caché de ejecución

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 para cada entrada de caché. Para las ejecuciones que comiencen 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é.

2. Para las siguientes ejecuciones, establezca la retención de 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 failurees ú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 alwayses ú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.

2. 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é.

3. Repita el paso 2 según sea necesario, hasta que se complete el desarrollo de la tarea actualizada.

4. 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

Recomendamos 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.