So funktioniert das Caching von Anrufen

Um Call Caching zu verwenden, erstellen Sie einen Run-Cache und konfigurieren ihn so, dass er über einen zugehörigen Amazon S3 S3-Speicherort für die zwischengespeicherten Daten verfügt. Wenn Sie einen Lauf starten, geben Sie den Run-Cache an. Ein Run-Cache ist nicht für einen Workflow reserviert. Läufe aus mehreren Workflows können denselben Cache verwenden.

Während der Exportphase eines Laufs exportiert das System die abgeschlossenen Aufgabenausgaben an den Amazon S3 S3-Speicherort. Um zwischengeschaltete Aufgabendateien zu exportieren, deklarieren Sie diese Dateien in der Workflow-Definition als Aufgabenausgaben. Das Aufruf-Caching speichert auch intern Metadaten und erstellt eindeutige Hashes für jeden Cache-Eintrag.

Für jede Aufgabe in einem Lauf erkennt die Workflow-Engine, ob es für diese Aufgabe einen passenden Cache-Eintrag gibt. Wenn es keinen passenden Cache-Eintrag gibt, HealthOmics berechnet die Aufgabe. Wenn es einen passenden Cache-Eintrag gibt, ruft die Engine die zwischengespeicherten Ergebnisse ab.

HealthOmics Verwendet zum Abgleichen von Cache-Einträgen den Hashing-Mechanismus, der in den systemeigenen Workflow-Engines enthalten ist. HealthOmicserweitert diese vorhandenen Hash-Implementierungen um HealthOmics Variablen wie S3-ETags und ECR-Container-Digests.

HealthOmics unterstützt das Caching von Aufrufen für diese Workflow-Sprachversionen:

• Die WDL-Versionen 1.0, 1.1 und die Entwicklungsversion

• Nextflow-Versionen 23.10 und 24.10

• Alle CWL-Versionen

Anmerkung

HealthOmics unterstützt kein Aufruf-Caching für Ready2Run-Workflows.

Modell der geteilten Verantwortung

Die Benutzer sind gemeinsam dafür verantwortlich, AWS zu bestimmen, ob Aufgaben und Läufe sich für das Call-Caching eignen. Das Aufruf-Caching erzielt die besten Ergebnisse, wenn alle Aufgaben idempotent sind (wiederholte Ausführungen einer Aufgabe mit denselben Eingaben führen zu denselben Ergebnissen).

Wenn eine Aufgabe jedoch nicht deterministische Elemente enthält (wie Zufallszahlengenerationen oder Systemzeit), können wiederholte Ausführungen der Aufgabe mit denselben Eingaben zu unterschiedlichen Ausgaben führen. Dies kann sich auf folgende Weise auf die Effektivität des Caching von Anrufen auswirken:

• Wenn ein Cache-Eintrag HealthOmics verwendet wird (der durch einen vorherigen Lauf erstellt wurde), der nicht mit der Ausgabe identisch ist, die die Ausführung der Aufgabe für den aktuellen Lauf erzeugen würde, kann der Lauf zu anderen Ergebnissen führen als derselbe Lauf ohne Zwischenspeicherung.

• HealthOmics findet möglicherweise keinen passenden Cache-Eintrag für eine Aufgabe, der entsprechen sollte, weil die Aufgabenausgabe nicht deterministisch ist. Wenn der gültige Cache-Eintrag nicht gefunden wird, wird die Aufgabe bei der Ausführung unnötig neu berechnet, wodurch die Kosteneinsparung durch die Verwendung von Aufruf-Caching beeinträchtigt wird.

Im Folgenden sind bekannte Verhaltensweisen von Aufgaben aufgeführt, die zu nicht deterministischen Ergebnissen führen können, die sich auf die Ergebnisse der Zwischenspeicherung von Aufrufen auswirken:

• Verwendung von Zufallszahlengeneratoren.

• Abhängigkeit von der Systemzeit.

• Verwendung von Parallelität (Rennbedingungen können zu Leistungsabweichungen führen).

• Abrufen von lokalen oder entfernten Dateien, die über die in den Eingabeparametern der Aufgabe angegebenen hinausgehen.

Weitere Szenarien, die zu nicht deterministischem Verhalten führen können, finden Sie unter Nicht deterministische Prozesseingaben auf der Nextflow-Dokumentationsseite.

Wenn Sie vermuten, dass eine Aufgabe nicht deterministische Ausgaben erzeugt, sollten Sie die Verwendung von Workflow-Engine-Funktionen wie der Cache-Deaktivierung in Nextflow in Betracht ziehen, um zu vermeiden, dass bestimmte Aufgaben zwischengespeichert werden, die nicht deterministisch sind.

Wir empfehlen Ihnen, Ihre spezifischen Workflow- und Aufgabenanforderungen gründlich zu überprüfen, bevor Sie das Call Caching in Umgebungen aktivieren, in denen ineffektives Caching von Anrufen oder andere als erwartete Ausgaben ein Risiko darstellen können. Beispielsweise sollten die potenziellen Einschränkungen von Call Caching bei der Entscheidung, ob Call Caching für klinische Anwendungsfälle geeignet ist, sorgfältig abgewogen werden.

Anforderungen an das Zwischenspeichern von Aufgaben

HealthOmics speichert Aufgabenausgaben für Aufgaben, die die folgenden Anforderungen erfüllen:

• Die Aufgabe muss einen Container definieren. HealthOmics speichert keine Ausgaben für eine Aufgabe ohne Container im Cache.

• Die Aufgabe muss eine oder mehrere Ausgaben erzeugen. Sie geben die Ausgaben der Aufgaben in der Workflow-Definition an.

• Die Workflow-Definition darf keine dynamischen Werte verwenden. Wenn Sie beispielsweise einen Parameter mit einem Wert an eine Aufgabe übergeben, der bei jedem Lauf erhöht wird, werden die Ausgaben der Aufgabe HealthOmics nicht zwischengespeichert.

Anmerkung

Wenn mehrere Aufgaben in einer Ausführung dasselbe Container-Image verwenden, wird HealthOmics für alle diese Aufgaben dieselbe Image-Version bereitgestellt. Nach HealthOmics dem Abrufen des Images werden alle Aktualisierungen des Container-Images für die Dauer der Ausführung ignoriert. Dieser Ansatz bietet eine vorhersehbare und konsistente Benutzererfahrung und verhindert potenzielle Probleme, die sich aus Aktualisierungen des Container-Images ergeben könnten, die während der Ausführung bereitgestellt werden.

Führen Sie die Cache-Leistung aus

Wenn Sie das Zwischenspeichern von Aufrufen für einen Lauf aktivieren, stellen Sie möglicherweise die folgenden Auswirkungen auf die Ausführungsleistung fest:

• HealthOmics Speichert beim ersten Lauf die Cache-Daten für Aufgaben in der Ausführung. Bei diesem Lauf kann es zu längeren Exportzeiten kommen, da das Aufruf-Caching die Menge der Exportdaten erhöht.

• Wenn Sie in nachfolgenden Ausführungen einen Lauf aus dem Cache wieder aufnehmen, kann dies die Anzahl der Verarbeitungsschritte und die Laufzeit verringern.

• Wenn Sie sich auch dafür entscheiden, Zwischendateien als Ausgaben zu deklarieren, können Ihre Exportzeiten sogar noch länger sein, da diese Daten ausführlicher sein können.

Ereignisse zur Aufbewahrung und Invalidierung von Daten zwischenspeichern

Der Hauptzweck eines Run-Caches besteht darin, die Berechnung der Aufgaben während der Ausführung zu optimieren. Wenn es einen gültigen passenden Cache-Eintrag für eine Aufgabe gibt, wird der Cache-Eintrag HealthOmics verwendet, anstatt die Aufgabe neu zu berechnen. Andernfalls wird das Standardverhalten des Dienstes HealthOmics wiederhergestellt, bei dem die Aufgabe und die von ihr abhängigen Aufgaben neu berechnet werden. Bei diesem Ansatz führen Cache-Fehler nicht dazu, dass die Ausführung fehlschlägt.

Es wird empfohlen, die Größe des Run-Caches zu verwalten. Im Laufe der Zeit sind Cacheeinträge aufgrund von Workflow-Engine- oder HealthOmics Service-Updates oder aufgrund von Änderungen, die Sie an der Ausführung oder den Ausführungsaufgaben vorgenommen haben, möglicherweise nicht mehr gültig. Die folgenden Abschnitte enthalten zusätzliche Informationen.

Themen

• Manifeste Versionsupdates und Datenaktualität

• Verhalten beim Ausführen des Caches

• Steuern Sie die Größe des Run-Caches

Manifeste Versionsupdates und Datenaktualität

In regelmäßigen Abständen führt der HealthOmics Dienst möglicherweise neue Funktionen oder Workflow-Engine-Updates ein, die einige oder alle Run-Cache-Einträge ungültig machen. In diesem Fall kann es bei Ihren Läufen zu einem einmaligen Cachefehler kommen.

HealthOmics erstellt für jeden Cache-Eintrag eine JSON-Manifestdatei. Für Läufe, die nach dem 12. Februar 2025 gestartet wurden, enthält die Manifestdatei einen Versionsparameter. Wenn ein Service-Update Cache-Einträge ungültig macht, wird die Versionsnummer HealthOmics erhöht, sodass Sie die Legacy-Cache-Einträge identifizieren können, die entfernt werden müssen.

Das folgende Beispiel zeigt eine Manifestdatei, deren Version auf 2 gesetzt ist:

{
     "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,       
  }     

Bei Läufen mit Cacheeinträgen, die nicht mehr gültig sind, erstellen Sie den Cache neu, um neue gültige Einträge zu erstellen. Führen Sie für jeden Lauf die folgenden Schritte aus:

1. Starten Sie den Lauf einmal, wobei die Cache-Aufbewahrung auf CACHE ALWAYS eingestellt ist. Bei diesem Lauf werden die neuen Cache-Einträge erstellt.

2. Setzen Sie für nachfolgende Läufe die Cache-Aufbewahrung auf die vorherige Einstellung (CACHE ALWAYS oder CACHE ON FAILURE).

Um Cache-Einträge zu bereinigen, die nicht mehr gültig sind, können Sie diese Cache-Einträge aus dem Amazon S3 S3-Cache-Bucket löschen. HealthOmics verwendet diese Cache-Einträge niemals wieder. Wenn Sie sich dafür entscheiden, ungültige Einträge beizubehalten, hat dies keine Auswirkungen auf Ihre Läufe.

Anmerkung

Beim Aufruf-Caching werden die Ausgabedaten der Aufgaben an dem für den Cache angegebenen Amazon S3 S3-Speicherort gespeichert, wodurch Ihnen Gebühren entstehen. AWS-Konto

Verhalten beim Ausführen des Caches

Sie können das Verhalten beim Ausführen des Caches festlegen, um die Taskausgaben für fehlgeschlagene Läufe (Cache on Failure) oder für alle Läufe (Cache immer) zu speichern. Wenn Sie einen Run-Cache erstellen, legen Sie das Standard-Cache-Verhalten für alle Läufe fest, die diesen Cache verwenden. Sie können das Standardverhalten überschreiben, wenn Sie einen Lauf starten.

Cache on failureist nützlich, wenn Sie einen Workflow debuggen, der fehlschlägt, nachdem mehrere Aufgaben erfolgreich abgeschlossen wurden. Die nachfolgende Ausführung wird mit der letzten erfolgreich abgeschlossenen Aufgabe fortgesetzt, wenn alle vom Hash berücksichtigten eindeutigen Variablen mit der vorherigen Ausführung identisch sind.

Cache alwaysist nützlich, wenn Sie eine Aufgabe in einem Workflow aktualisieren, der erfolgreich abgeschlossen wurde. Wir empfehlen, dass Sie die folgenden Schritte ausführen:

1. Erstellen Sie einen neuen Lauf. Stellen Sie das Cache-Verhalten auf Immer zwischenspeichern ein und starten Sie den Lauf.

2. Nachdem die Ausführung abgeschlossen ist, aktualisieren Sie die Aufgabe im Workflow und starten Sie eine neue Ausführung mit dem Verhalten „Immer zwischenspeichern“. Dieser Lauf verarbeitet die aktualisierte Aufgabe und alle nachfolgenden Aufgaben, die von der aktualisierten Aufgabe abhängig sind. Alle anderen Aufgaben verwenden die zwischengespeicherten Ergebnisse.

3. Wiederholen Sie Schritt 2 nach Bedarf, bis die Entwicklung für die aktualisierte Aufgabe abgeschlossen ist.

4. Verwenden Sie die aktualisierte Aufgabe bei future Läufen nach Bedarf. Denken Sie daran, nachfolgende Läufe im Fehlerfall auf Cache umzustellen, wenn Sie beabsichtigen, für diese Läufe neue oder andere Eingaben zu verwenden.

Anmerkung

Wir empfehlen den Modus Immer zwischenspeichern, wenn Sie denselben Testdatensatz verwenden, jedoch nicht für mehrere Läufe. Wenn Sie diesen Modus für eine große Anzahl von Durchläufen festlegen, kann das System große Datenmengen nach Amazon S3 exportieren, was zu erhöhten Exportzeiten und Speicherkosten führt.

Steuern Sie die Größe des Run-Caches

HealthOmics löscht oder archiviert keine Run-Cache-Daten und wendet auch keine Amazon S3 S3-Bereinigungsregeln für die Verwaltung der Cache-Daten an. Wir empfehlen Ihnen, regelmäßige Cache-Bereinigungen durchzuführen, um Amazon S3 S3-Speicherkosten zu sparen und die Größe Ihres Run-Caches überschaubar zu halten. Sie können Dateien direkt löschen oder retention/replication Datenrichtlinien für den Run-Cache-Bucket festlegen.

Sie können beispielsweise eine Amazon S3 S3-Lebenszyklusrichtlinie so konfigurieren, dass Objekte nach 90 Tagen ablaufen, oder Sie können die Cache-Daten am Ende jedes Entwicklungsprojekts manuell bereinigen.

Die folgenden Informationen können Ihnen bei der Verwaltung der Cache-Datengröße helfen:

• Sie können sehen, wie viele Daten sich im Cache befinden, indem Sie Amazon S3 überprüfen. HealthOmics überwacht oder berichtet nicht über die Cachegröße.

• Wenn Sie einen gültigen Cache-Eintrag löschen, schlägt die nachfolgende Ausführung nicht fehl. HealthOmics berechnet die Aufgabe und ihre abhängigen Aufgaben neu.

• Wenn Sie Cache-Namen oder Verzeichnisstrukturen so ändern, HealthOmics dass kein passender Eintrag für eine Aufgabe gefunden wird, HealthOmics berechnet die Aufgabe neu.

Wenn Sie überprüfen müssen, ob ein Cache-Eintrag noch gültig ist, überprüfen Sie die Versionsnummer des Cache-Manifests. Weitere Informationen finden Sie unter Manifeste Versionsupdates und Datenaktualität.