翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
コールキャッシュの仕組み
コールキャッシュを使用するには、実行キャッシュを作成し、キャッシュされたデータに関連付けられた Amazon S3 の場所を持つように設定します。実行を開始するときは、実行キャッシュを指定します。実行キャッシュは 1 つのワークフロー専用ではありません。複数のワークフローからの実行では、同じキャッシュを使用できます。
実行のエクスポートフェーズ中、システムは完了したタスク出力を Amazon S3 の場所にエクスポートします。中間タスクファイルをエクスポートするには、ワークフロー定義でこれらのファイルをタスク出力として宣言します。コールキャッシュは内部的にメタデータを保存し、キャッシュエントリごとに一意のハッシュを作成します。
実行中のタスクごとに、ワークフローエンジンは、このタスクに一致するキャッシュエントリがあるかどうかを検出します。一致するキャッシュエントリがない場合、HealthOmics はタスクを計算します。一致するキャッシュエントリがある場合、エンジンはキャッシュされた結果を取得します。
キャッシュエントリを一致させるために、HealthOmics はネイティブワークフローエンジンに含まれるハッシュメカニズムを使用します。HealthOmics は、これらの既存のハッシュ実装を拡張して、S3 eTags や ECR コンテナダイジェストなどの HealthOmics 変数を考慮します。
HealthOmics は、次のワークフロー言語バージョンのコールキャッシュをサポートしています。
-
WDL バージョン 1.0、1.1、および 開発バージョン
-
Nextflow バージョン 23.10 および 24.10
-
すべての CWL バージョン
注記
HealthOmics は、Ready2Run ワークフローのコールキャッシュをサポートしていません。
責任共有モデル
ユーザーと は、タスクと実行がコールキャッシュに適した候補 AWS かどうかを判断する責任を共有します。コールキャッシュは、すべてのタスクがべき等である場合に最良の結果を達成します (同じ入力を使用してタスクを繰り返し実行すると、同じ結果が得られます)。
ただし、タスクに非決定的な要素 (乱数生成やシステム時間など) が含まれている場合、同じ入力を使用してタスクを繰り返し実行すると、出力が異なる場合があります。これは、次の方法でコールキャッシュの有効性に影響を与える可能性があります。
HealthOmics が、タスク実行が現在の実行に対して生成する出力と同じではないキャッシュエントリ (前回の実行で作成) を使用する場合、実行はキャッシュなしで同じ実行とは異なる結果を生成する可能性があります。
HealthOmics は、非決定的なタスク出力のため、一致する必要があるタスクに一致するキャッシュエントリを見つけられない場合があります。有効なキャッシュエントリが見つからない場合、実行はタスクを不必要に再計算するため、コールキャッシュを使用するコスト削減のメリットが減ります。
以下は、コールキャッシュの結果に影響する非決定的な結果を引き起こす可能性のある既知のタスク動作です。
乱数ジェネレーターの使用。
システム時刻によって異なります。
同時実行の使用 (レース条件により出力の変動が発生する可能性があります)。
-
タスク入力パラメータで指定されている範囲を超えるローカルファイルまたはリモートファイルを取得します。
非決定的な動作を引き起こす可能性のあるその他のシナリオについては、Nextflow ドキュメントサイトの「非決定的なプロセス入力
タスクが非決定的な出力を生成すると思われる場合は、Nextflow のキャッシュオプトアウトなどのワークフローエンジン機能を使用して、非決定的な特定のタスクがキャッシュされないようにすることを検討してください。
無効なコールキャッシュや予想とは異なる出力がリスクをもたらす可能性のある環境でコールキャッシュを有効にする前に、特定のワークフローとタスクの要件を徹底的に確認することをお勧めします。例えば、コールキャッシュが臨床ユースケースに適しているかどうかを判断する際には、コールキャッシュの潜在的な制限を慎重に検討する必要があります。
タスクのキャッシュ要件
HealthOmics は、次の要件を満たすタスクのタスク出力をキャッシュします。
-
タスクはコンテナを定義する必要があります。HealthOmics は、コンテナのないタスクの出力をキャッシュしません。
-
タスクは 1 つ以上の出力を生成する必要があります。ワークフロー定義でタスク出力を指定します。
-
ワークフロー定義で動的値を使用しないでください。たとえば、実行ごとに増加する値を持つタスクにパラメータを渡すと、HealthOmics はタスク出力をキャッシュしません。
注記
実行内の複数のタスクが同じコンテナイメージを使用する場合、HealthOmics はこれらのタスクすべてに同じイメージバージョンを提供します。HealthOmics がイメージをプルすると、実行期間中のコンテナイメージの更新は無視されます。このアプローチは、予測可能で一貫したエクスペリエンスを提供し、実行中にデプロイされるコンテナイメージの更新によって発生する可能性のある問題を防ぎます。
キャッシュパフォーマンスを実行する
実行のコールキャッシュを有効にすると、実行パフォーマンスに次のような影響が生じることがあります。
最初の実行中、HealthOmics は実行中のタスクのキャッシュデータを保存します。コールキャッシュはエクスポートデータの量を増やすため、この実行ではエクスポート時間が長くなることがあります。
以降の実行では、キャッシュから実行を再開するときに、処理ステップの数が短縮され、実行時間が短縮される可能性があります。
また、中間ファイルを出力として宣言することを選択した場合、このデータが詳細になる可能性があるため、エクスポート時間がさらに長くなる可能性があります。
キャッシュデータの保持と無効化イベント
実行キャッシュの主な目的は、実行中のタスクの計算を最適化することです。タスクに一致する有効なキャッシュエントリがある場合、HealthOmics はタスクを再計算する代わりにキャッシュエントリを使用します。それ以外の場合、HealthOmics はデフォルトのサービス動作に戻ります。これは、タスクとその依存タスクを再計算することです。このアプローチを使用しても、キャッシュミスによって実行が失敗することはありません。
実行キャッシュサイズを管理することをお勧めします。時間の経過とともに、ワークフローエンジンまたは HealthOmics サービスの更新、または実行タスクまたは実行タスクで行った変更が原因で、キャッシュエントリが無効になる場合があります。以下のセクションでは、追加の詳細について説明します。
マニフェストバージョンの更新とデータの鮮度
HealthOmics サービスは定期的に新機能やワークフローエンジンの更新を導入し、一部またはすべての実行キャッシュエントリを無効にする場合があります。この場合、実行で 1 回限りのキャッシュミスが発生する可能性があります。
HealthOmics は、キャッシュエントリごとに JSON マニフェストファイルを作成します。2025 年 2 月 12 日以降に開始された実行の場合、マニフェストファイルにはバージョンパラメータが含まれます。サービスの更新によってキャッシュエントリが無効になる場合、HealthOmics は削除対象のレガシーキャッシュエントリを識別できるようにバージョン番号を増分します。
次の例は、 バージョンが 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, }
有効でなくなったキャッシュエントリを含む実行の場合は、キャッシュを再構築して新しい有効なエントリを作成します。実行ごとに次の手順を実行します。
-
キャッシュ保持を CACHE ALWAYS に設定して実行を 1 回開始します。この実行により、新しいキャッシュエントリが作成されます。
-
後続の実行では、キャッシュ保持を以前の設定 (CACHE ALWAYS または CACHE ON FAILURE) に設定します。
有効でなくなったキャッシュエントリをクリーンアップするには、キャッシュ Amazon S3 バケットからこれらのキャッシュエントリを削除できます。HealthOmics はこれらのキャッシュエントリを再利用しません。有効でないエントリを保持することを選択した場合、実行には影響しません。
注記
コールキャッシュは、キャッシュに指定された Amazon S3 の場所にタスク出力データを保存し、 に料金が発生します AWS アカウント。
キャッシュ動作の実行
実行キャッシュ動作を設定して、失敗した実行 (失敗時のキャッシュ) またはすべての実行 (常にキャッシュ) のタスク出力を保存できます。実行キャッシュを作成するときは、このキャッシュを使用するすべての実行のデフォルトのキャッシュ動作を設定します。実行を開始するときに、デフォルトの動作を上書きできます。
Cache on failure は、複数のタスクが正常に完了した後に失敗するワークフローをデバッグする場合に便利です。ハッシュによって考慮されるすべての一意の変数が前回の実行と同じである場合、後続の実行は最後に正常に完了したタスクから再開されます。
Cache always は、正常に完了したワークフローでタスクを更新する場合に便利です。以下のステップに従うことをお勧めします。
-
新しい実行を作成します。キャッシュ動作を常にキャッシュに設定し、実行を開始します。
-
実行が完了したら、ワークフローのタスクを更新し、動作セットキャッシュで常に新しい実行を開始します。この実行は、更新されたタスクと、更新されたタスクに依存する後続のタスクを処理します。他のすべてのタスクでは、キャッシュされた結果が使用されます。
-
必要に応じて、更新されたタスクの開発が完了するまで、ステップ 2 を繰り返します。
-
必要に応じて、今後の実行で更新されたタスクを使用します。これらの実行に新規または異なる入力を使用する予定がある場合は、後続の実行を失敗時にキャッシュに切り替えることを忘れないでください。
注記
Cache always モードは、同じテストデータセットを使用している間は推奨されますが、実行のバッチには推奨されません。このモードを大量のバッチ実行に設定すると、システムは大量のデータを Amazon S3 にエクスポートできるため、エクスポート時間とストレージコストが増加します。
コントロール実行キャッシュサイズ
HealthOmics は、実行キャッシュデータを削除または自動アーカイブしたり、キャッシュデータを管理するための Amazon S3 クリーンアップルールを適用したりしません。Amazon S3 ストレージコストを節約し、実行キャッシュサイズを管理できるように、定期的なキャッシュクリーンアップを実行することをお勧めします。ファイルを直接削除することも、実行キャッシュバケットにデータ保持/レプリケーションポリシーを設定することもできます。
たとえば、Amazon S3 ライフサイクルポリシーを設定して 90 日後にオブジェクトを期限切れにしたり、各開発プロジェクトの終了時にキャッシュデータを手動でクリーンアップしたりできます。
以下の情報は、キャッシュデータサイズを管理するのに役立ちます。
-
Amazon S3 を確認することで、キャッシュ内のデータ量を表示できます。HealthOmics はキャッシュサイズをモニタリングまたはレポートしません。
-
有効なキャッシュエントリを削除しても、後続の実行は失敗しません。HealthOmics は、タスクとその依存タスクを再計算します。
-
HealthOmics がタスクに一致するエントリを見つけられないようにキャッシュ名またはディレクトリ構造を変更すると、HealthOmics はタスクを再計算します。
キャッシュエントリがまだ有効かどうかを確認する必要がある場合は、キャッシュマニフェストのバージョン番号を確認してください。詳細については、「マニフェストバージョンの更新とデータの鮮度」を参照してください。