翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# HealthOmics 実行のコールキャッシュ
AWS HealthOmics は、プライベートワークフローの再開とも呼ばれるコールキャッシュをサポートしています。コールキャッシュは、実行の完了後に完了したワークフロータスクの出力を保存します。後続の実行では、タスク出力を再度計算するのではなく、キャッシュからのタスク出力を使用できます。コールキャッシュにより、コンピューティングリソースの使用量が減少し、実行時間が短縮され、コンピューティングコストが削減されます。
実行が完了したら、キャッシュされたタスク出力ファイルにアクセスできます。高度なタスクのデバッグとトラブルシューティングを実行するには、ワークフロー定義でこれらのファイルをタスク出力として指定することで、中間タスクファイルをキャッシュできます。
呼び出しキャッシュを使用して、失敗した実行から完了したタスク結果を保存できます。次の実行は、完了したタスクを再計算するのではなく、最後に正常に完了したタスクから開始されます。
HealthOmics がタスクに一致するキャッシュエントリを見つけられない場合、実行は失敗しません。HealthOmics は、タスクとその依存タスクを再計算します。
コールキャッシュの問題のトラブルシューティングについては、「」を参照してください[コールキャッシュの問題のトラブルシューティング](troubleshooting.md#workflow-cache-troubleshooting)。
**Topics**
+ [コールキャッシュの仕組み](how-run-cache.md)
+ [実行キャッシュの作成](workflow-cache-create.md)
+ [実行キャッシュの更新](workflow-cache-update.md)
+ [実行キャッシュの削除](workflow-cache-delete.md)
+ [実行キャッシュの内容](workflow-cache-contents.md)
+ [エンジン固有のキャッシュ機能](workflow-cache-per-engine.md)
+ [実行キャッシュの使用](workflow-cache-startrun.md)
# コールキャッシュの仕組み
コールキャッシュを使用するには、実行キャッシュを作成し、キャッシュされたデータに関連付けられた 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 ワークフローのコールキャッシュをサポートしていません。
**Topics**
+ [責任共有モデル](#run-cache-srm)
+ [タスクのキャッシュ要件](#workflow-cache-task-prereqs)
+ [キャッシュパフォーマンスを実行する](#run-cache-performance)
+ [キャッシュデータの保持と無効化イベント](#workflow-cache-data)
## 責任共有モデル
タスクと実行が通話キャッシュに適した候補かどうかを判断する AWS には、 ユーザーと の間で責任が共有されます。コールキャッシュは、すべてのタスクがべき等である場合に最良の結果を達成します (同じ入力を使用してタスクを繰り返し実行すると、同じ結果が得られます）。
ただし、タスクに非決定的な要素 (乱数生成やシステム時間など) が含まれている場合、同じ入力を使用してタスクを繰り返し実行すると、出力が異なる場合があります。これは、次の方法でコールキャッシュの有効性に影響を与える可能性があります。
+ HealthOmics が、タスク実行が現在の実行に対して生成する出力と同じではないキャッシュエントリ (前回の実行で作成) を使用する場合、実行はキャッシュなしで同じ実行とは異なる結果を生成する可能性があります。
+ HealthOmics は、非決定的なタスク出力のため、一致する必要があるタスクに一致するキャッシュエントリを見つけられない場合があります。有効なキャッシュエントリが見つからない場合、 実行はタスクを不必要に再計算するため、コールキャッシュを使用するコスト削減のメリットが減ります。
以下は、コールキャッシュの結果に影響を与える非決定的な結果を引き起こす可能性のある既知のタスク動作です。
+ 乱数ジェネレーターの使用。
+ システム時刻によって異なります。
+ 同時実行 (レース条件により出力の変動が発生する可能性があります) を使用する。
+ タスク入力パラメータで指定されている範囲を超えるローカルファイルまたはリモートファイルを取得します。
非決定的な動作を引き起こす可能性のあるその他のシナリオについては、Nextflow ドキュメントサイトの[「非決定的なプロセス入力](https://www.nextflow.io/docs/latest/cache-and-resume.html#non-deterministic-process-inputs)」を参照してください。
タスクが非決定的な出力を生成すると思われる場合は、ワークフローエンジン機能を使用して、非決定的な特定のタスクをキャッシュしないようにすることを検討してください。サポートされている各ワークフロー言語で個々のタスクのキャッシュをオプトアウトする方法については、「」を参照してください[エンジン固有のキャッシュ機能](workflow-cache-per-engine.md)。
無効なコールキャッシュや予想とは異なる出力がリスクをもたらす可能性がある環境では、コールキャッシュを有効にする前に、特定のワークフローとタスクの要件を徹底的に確認することをお勧めします。例えば、コールキャッシュが臨床ユースケースに適しているかどうかを判断する際には、コールキャッシュの潜在的な制限を慎重に検討する必要があります。
## タスクのキャッシュ要件
HealthOmics は、次の要件を満たすタスクのタスク出力をキャッシュします。
+ タスクはコンテナを定義する必要があります。HealthOmics は、コンテナのないタスクの出力をキャッシュしません。
+ タスクは 1 つ以上の出力を生成する必要があります。ワークフロー定義でタスク出力を指定します。
+ ワークフロー定義で動的値を使用しないでください。たとえば、実行ごとに増加する値を持つタスクにパラメータを渡すと、HealthOmics はタスク出力をキャッシュしません。
**注記**
実行内の複数のタスクが同じコンテナイメージを使用する場合、HealthOmics はこれらのタスクすべてに同じイメージバージョンを提供します。HealthOmics がイメージをプルすると、実行期間中のコンテナイメージの更新は無視されます。このアプローチは、予測可能で一貫したエクスペリエンスを提供し、実行中にデプロイされるコンテナイメージの更新によって発生する可能性のある問題を防止します。
## キャッシュパフォーマンスを実行する
実行のコールキャッシュを有効にすると、実行パフォーマンスに次のような影響が生じることがあります。
+ 最初の実行中、HealthOmics はタスクのキャッシュデータを実行中に保存します。コールキャッシュはエクスポートデータの量を増やすため、この実行のエクスポート時間が長くなることがあります。
+ 以降の実行では、キャッシュから実行を再開するときに、処理ステップの数が短縮され、実行時間が短縮される可能性があります。
+ また、中間ファイルを出力として宣言することを選択した場合、このデータが詳細になる可能性があるため、エクスポート時間がさらに長くなる可能性があります。
## キャッシュデータの保持と無効化イベント
実行キャッシュの主な目的は、実行中のタスクの計算を最適化することです。タスクに有効な一致するキャッシュエントリがある場合、HealthOmics はタスクを再計算する代わりにキャッシュエントリを使用します。それ以外の場合、HealthOmics はデフォルトのサービス動作に戻ります。これは、タスクとその依存タスクを再計算することです。このアプローチを使用しても、キャッシュミスによって実行が失敗することはありません。
実行キャッシュサイズを管理することをお勧めします。時間の経過とともに、ワークフローエンジンまたは HealthOmics サービスの更新、または実行タスクまたは実行タスクで行った変更が原因で、キャッシュエントリが無効になる場合があります。以下のセクションでは、追加の詳細について説明します。
**Topics**
+ [マニフェストバージョンの更新とデータの鮮度](#workflow-cache-data-versions)
+ [キャッシュ動作の実行](#run-cache-behavior)
+ [実行キャッシュサイズの制御](#workflow-cache-manage)
### マニフェストバージョンの更新とデータの鮮度
HealthOmics サービスは定期的に、一部またはすべての実行キャッシュエントリを無効にする新機能またはワークフローエンジンの更新を導入することがあります。この場合、実行で 1 回限りのキャッシュミスが発生する可能性があります。
HealthOmics は、キャッシュエントリごとに [JSON マニフェストファイル](workflow-cache-contents.md)を作成します。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,
}
```
有効でなくなったキャッシュエントリを含む実行の場合は、キャッシュを再構築して新しい有効なエントリを作成します。実行ごとに次の手順を実行します。
1. キャッシュ保持を CACHE ALWAYS に設定して実行を 1 回開始します。この実行により、新しいキャッシュエントリが作成されます。
1. 以降の実行では、キャッシュ保持を以前の設定 (CACHE ALWAYS または CACHE ON FAILURE) に設定します。
有効でなくなったキャッシュエントリをクリーンアップするには、キャッシュ Amazon S3 バケットからこれらのキャッシュエントリを削除できます。HealthOmics はこれらのキャッシュエントリを再利用しません。有効でないエントリを保持することを選択した場合、実行には影響しません。
**注記**
コールキャッシュは、キャッシュに指定された Amazon S3 の場所にタスク出力データを保存し、 に料金が発生します AWS アカウント。
### キャッシュ動作の実行
実行キャッシュ動作を設定して、失敗した実行 (失敗時のキャッシュ) またはすべての実行 (常にキャッシュ) のタスク出力を保存できます。実行キャッシュを作成するときは、このキャッシュを使用するすべての実行に対してデフォルトのキャッシュ動作を設定します。実行を開始するときに、デフォルトの動作を上書きできます。
**Cache on failure** は、複数のタスクが正常に完了した後に失敗するワークフローをデバッグする場合に便利です。ハッシュによって考慮されるすべての一意の変数が前回の実行と同じである場合、後続の実行は最後に正常に完了したタスクから再開されます。
**Cache always** は、正常に完了したワークフローでタスクを更新する場合に便利です。以下のステップに従うことをお勧めします。
1. 新しい実行を作成します。**キャッシュ動作**を常に**キャッシュ**に設定し、実行を開始します。
1. 実行が完了したら、ワークフローのタスクを更新し、動作セット**キャッシュで常に**新しい実行を開始します。この実行は、更新されたタスクと、更新されたタスクに依存する後続のタスクを処理します。他のすべてのタスクでは、キャッシュされた結果が使用されます。
1. 必要に応じて、更新されたタスクの開発が完了するまで、ステップ 2 を繰り返します。
1. 必要に応じて、今後の実行で更新されたタスクを使用します。これらの実行に新規または異なる入力を使用する予定がある場合は、後続の実行を**失敗時にキャッシュ**に切り替えることを忘れないでください。
**注記**
**Cache always** モードは、同じテストデータセットを使用している間は推奨されますが、実行のバッチには推奨されません。このモードを大量のバッチ実行に設定すると、システムは大量のデータを Amazon S3 にエクスポートできるため、エクスポート時間とストレージコストが増加します。
### 実行キャッシュサイズの制御
HealthOmics は、実行キャッシュデータを削除または自動アーカイブしたり、キャッシュデータを管理するための Amazon S3 クリーンアップルールを適用したりしません。Amazon S3 ストレージコストを節約し、実行キャッシュサイズを管理できるように、定期的なキャッシュクリーンアップを実行することをお勧めします。ファイルを直接削除することも、実行キャッシュバケットにデータ保持/レプリケーションポリシーを設定することもできます。
たとえば、90 日後にオブジェクトを期限切れにするように Amazon S3 ライフサイクルポリシーを設定したり、各開発プロジェクトの終了時にキャッシュデータを手動でクリーンアップしたりできます。
以下の情報は、キャッシュデータサイズを管理するのに役立ちます。
+ Amazon S3 を確認することで、キャッシュ内のデータ量を表示できます。HealthOmics はキャッシュサイズをモニタリングまたはレポートしません。
+ 有効なキャッシュエントリを削除しても、後続の実行は失敗しません。HealthOmics は、タスクとその依存タスクを再計算します。
+ HealthOmics がタスクに一致するエントリを見つけられないようにキャッシュ名またはディレクトリ構造を変更すると、HealthOmics はタスクを再計算します。
キャッシュエントリがまだ有効かどうかを確認する必要がある場合は、キャッシュマニフェストのバージョン番号を確認してください。詳細については、「[マニフェストバージョンの更新とデータの鮮度](#workflow-cache-data-versions)」を参照してください。
# 実行キャッシュの作成
実行キャッシュを作成するときは、キャッシュデータの Amazon S3 の場所を指定します。このデータはすぐにアクセス可能である必要があります。コールキャッシュは、Glacier にアーカイブされたオブジェクト (GFR や GDA ストレージクラスなど) を取得しません。
キャッシュデータの Amazon S3 バケットが別の によって所有されている場合は AWS アカウント、実行キャッシュを作成するときにそのアカウント ID を指定します。
## コンソールを使用した実行キャッシュの作成
コンソールから、以下の手順に従って実行キャッシュを作成します。
1. [HealthOmics コンソール](https://console.aws.amazon.com/omics/)を開きます。
1. 必要に応じて、左側のナビゲーションペイン (≡) を開きます。**キャッシュの実行** を選択します。
1. Run **caches** ページから、**Create run cache** を選択します。
1. **実行キャッシュの作成ページのキャッシュ詳細****の実行**パネルで、次のフィールドを設定します。
1. 実行キャッシュの名前を入力します。
1. (オプション) 説明を入力します。
1. キャッシュされた出力の S3 の場所を入力します。ワークフローと同じリージョンのバケットを選択します。
1. (オプション) バケット所有者 AWS アカウント の を入力して、バケットの所有権を確認します。値を入力しない場合、デフォルト値はアカウント ID です。
1. **キャッシュ動作**で、デフォルトの動作 (失敗した実行の出力をキャッシュするか、すべての実行の出力をキャッシュするか) を設定します。実行を開始するときに、オプションでデフォルトの動作を上書きできます。
1. (オプション) 1 つ以上のタグを実行キャッシュに関連付けます。
1. **実行キャッシュの作成** を選択します。コンソールには、新しい実行キャッシュが**キャッシュの実行**テーブルに表示されます。
## CLI を使用した実行キャッシュの作成
create**create-run-cache** CLI コマンドを使用して、実行キャッシュを作成します。デフォルトのキャッシュ動作は です`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"
```
作成が成功すると、次のフィールドを含むレスポンスを受け取ります。
```
{
"arn": "string",
"id": "string",
"status": "ACTIVE"
"tags": {}
}
```
# 実行キャッシュの更新
キャッシュ名、説明、タグ、またはキャッシュ動作は変更できますが、キャッシュの S3 の場所は変更できません。
## コンソールを使用した実行キャッシュの更新
コンソールから、以下の手順に従って実行キャッシュを更新します。
1. [HealthOmics コンソール](https://console.aws.amazon.com/omics/)を開きます。
1. 必要に応じて、左側のナビゲーションペイン (≡) を開きます。**キャッシュの実行** を選択します。
1. Run **caches **テーブルから、更新する実行キャッシュを選択し、**Edit** を選択します。
1. **キャッシュ詳細の実行**パネルでは、実行キャッシュ名、説明、キャッシュ動作フィールドを更新できます。
1. (オプション) 1 つ以上の新しいタグを実行キャッシュに関連付けるか、既存のタグを削除します。
1. **実行キャッシュの保存** を選択します。
## CLI を使用した実行キャッシュの更新
update**update-run-cache** CLI コマンドを使用して、実行キャッシュを更新します。
```
aws omics update-run-cache \
--name "workflow 123 run cache" \
--id "workflow id" \
--description "my run cache" \
--cache-behavior "CACHE_ALWAYS"
```
更新が成功すると、データフィールドのないレスポンスを受け取ります。
# 実行キャッシュの削除
アクティブな実行が使用していない場合は、実行キャッシュを削除できます。実行キャッシュを使用している場合は、実行が完了するまで待機するか、実行をキャンセルできます。
実行キャッシュを削除すると、リソースとそのメタデータは削除されますが、Amazon S3 内のデータは削除されません。キャッシュを削除した後は、キャッシュを再アタッチしたり、後続の実行に使用したりすることはできません。
キャッシュされたデータは、検査のために Amazon S3 に残ります。標準の S3 **Delete**オペレーションを使用して、古いキャッシュデータを削除できます。または、Amazon S3 ライフサイクルポリシーを作成して、使用しなくなったキャッシュデータを期限切れにします。
## コンソールを使用した実行キャッシュの削除
コンソールから、以下の手順に従って実行キャッシュを削除します。
1. [HealthOmics コンソール](https://console.aws.amazon.com/omics/)を開きます。
1. 必要に応じて、左側のナビゲーションペイン (≡) を開きます。**キャッシュの実行** を選択します。
1. **キャッシュの実行** テーブルから、削除するキャッシュの実行を選択します。
1. Run **caches **テーブルメニューから、**Delete** を選択します。
1. モーダルダイアログから、後で参照できるように Amazon S3 キャッシュデータリンクを保存し、実行キャッシュを削除することを確認します。
Amazon S3 リンクを使用してキャッシュされたデータを検査できますが、データを別の実行キャッシュに再リンクすることはできません。検査が完了したら、キャッシュデータを削除します。
## CLI を使用した実行キャッシュの削除
delete**delete-run-cache** CLI コマンドを使用して、実行キャッシュを削除します。
```
aws omics delete-run-cache \
--id "my cache id"
```
削除が成功すると、データフィールドのないレスポンスを受け取ります。
# 実行キャッシュの内容
HealthOmics は、S3 バケット内の次の構造で実行キャッシュを整理します。
```
s3://{cache.S3location}/{cache.uuid}/runID/taskID/{cacheentry.uuid}/
```
cache.uuid は、キャッシュのグローバルに一意の ID です。cacheentry.uuid は、キャッシュされたタスクのグローバルに一意の uuid です。HealthOmics は、uuid をキャッシュとタスクに割り当てます。
すべてのワークフローエンジンについて、キャッシュには次のファイルが含まれます。
+ **\$1cacheentryuuid\$1.json** ファイル – HealthOmics はこのマニフェストファイルを作成します。このマニフェストファイルには、キャッシュ内のすべての項目のリストや[キャッシュバージョン](how-run-cache.md#workflow-cache-data-versions)など、キャッシュに関する情報が含まれています。
+ タスク出力ファイル – 各タスク出力は、タスクで定義された 1 つ以上のファイルで構成されます。
Nextflow を使用するワークフローの場合、Nextflow エンジンはキャッシュにこれらの追加ファイルを作成します。
+ **command.out** ファイル – このファイルには、タスク実行の stdout コンテンツが含まれています。
+ **.exitcode** ファイル – このファイルには、タスク終了コード (整数) が含まれています。
**注記**
高度なトラブルシューティングのために実行キャッシュ内の中間タスクファイルにアクセスする場合は、ワークフロー定義でこれらのファイルをタスク出力として宣言します。
# エンジン固有のキャッシュ機能
HealthOmics は、ワークフローエンジン間でコールキャッシュの一貫した実装を提供しようとします。各ワークフローエンジンが特定のケースをどのように処理するかによって、いくつかの違いがあります。
+ ネクストフロー
+ 異なる Nextflow バージョン間でのキャッシュは保証されません。たとえば、v23.10.0 でタスクを実行し、その後 v24.10.8 で同じタスクを実行すると、HealthOmics は 2 回目の実行をキャッシュミスと見なす場合があります。
+ キャッシュ**false**ディレクティブを使用して、個々のタスクのキャッシュをオフにできます。このディレクティブの詳細については、Nextflow 仕様の[「プロセス](https://www.nextflow.io/docs/latest/process.html#process-cache)」を参照してください。
+ HealthOmics は Nextflow lenient モードを使用しますが、ディープキャッシュモードはサポートしていません。
+ タスクの入力への S3 パスで glob パターンを使用する場合、キャッシュは個々の S3 オブジェクトを評価します。新しいオブジェクトを追加すると、HealthOmics は新しいオブジェクトを使用するタスクのみを再計算します。
+ HealthOmics はタスクの再試行をキャッシュしません。この動作は、Nextflow のデフォルトの動作と一致します。
+ WDL
+ HealthOmics は、WDL ワークフローの開発バージョンを使用する場合、入力用の新しい「ディレクトリ」タイプをサポートしています。コールキャッシュの場合、ディレクトリ内のオブジェクトが変更されると、HealthOmics はディレクトリを入力するすべてのタスクを再計算します。
+ HealthOmics はタスクレベルのキャッシュをサポートしていますが、ワークフローレベルのキャッシュはサポートしていません。
+ **揮発性**属性を使用して、個々のタスクのキャッシュを無効にすることができます。詳細については、「[volatile 属性を使用してタスクレベルのキャッシュを無効にする](workflow-languages-wdl.md#workflow-wdl-volatile-attribute)」を参照してください。
+ CWL
+ タスクからの定数出力は、マニフェストから明示的には表示されません。HealthOmics は、定数出力を中間ファイルとしてキャッシュします。
+ [WorkReuse](https://www.commonwl.org/v1.1/Workflow.html#WorkReuse) 機能を使用して、個々のタスクのキャッシュを制御できます。
# 実行キャッシュの使用
デフォルトでは、 実行は実行キャッシュを使用しません。実行にキャッシュを使用するには、実行を開始するときに実行キャッシュと実行キャッシュの動作を指定します。
実行が完了したら、 コンソール、CloudWatch Logs、または API オペレーションを使用して、キャッシュヒットを追跡したり、キャッシュの問題をトラブルシューティングしたりできます。詳細については、「[通話キャッシュ情報の追跡](#workflow-cache-track)」および「[コールキャッシュの問題のトラブルシューティング](troubleshooting.md#workflow-cache-troubleshooting)」を参照してください。
実行の 1 つ以上のタスクが非決定的な出力を生成する場合は、実行にコールキャッシュを使用しないか、これらの特定のタスクをキャッシュから除外することを強くお勧めします。詳細については、「[責任共有モデル](how-run-cache.md#run-cache-srm)」を参照してください。
**注記**
実行を開始するときに IAM サービスロールを指定します。コールキャッシュを使用するには、サービスロールに実行キャッシュの Amazon S3 の場所にアクセスするためのアクセス許可が必要です。詳細については、「[のサービスロール AWS HealthOmics](permissions-service.md)」を参照してください。
[Amazon Q CLI ](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)を使用して、実行キャッシュデータを分析および管理できます。詳細については、GitHub の[「Amazon Q CLI のプロンプトの例](getting-started.md#omics-q-prompts)[」およびHealthOmics エージェント生成 AI チュートリアル](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai)」を参照してください。
**Topics**
+ [コンソールを使用した実行キャッシュを使用した実行の設定](#workflow-cache-startrun-console)
+ [CLI を使用した実行キャッシュを使用した実行の設定](#workflow-cache-startrun-api)
+ [実行キャッシュのエラーケース](#workflow-cache-errors)
+ [通話キャッシュ情報の追跡](#workflow-cache-track)
## コンソールを使用した実行キャッシュを使用した実行の設定
コンソールから、実行の開始時に実行キャッシュを設定します。
1. [HealthOmics コンソール](https://console.aws.amazon.com/omics/)を開きます。
1. 必要に応じて、左側のナビゲーションペイン (≡) を開きます。**[実行]** を選択します。
1. **Runs** ページで、開始する実行を選択します。
1. **「実行の開始**」を選択し、**「実行の開始**」のステップ 1 と 2 を完了します[コンソールを使用した実行の開始](starting-a-run.md#starting-a-run-console)。
1. **実行の開始**のステップ 3 **で、既存の実行キャッシュの選択**を選択します。
1. キャッシュ **ID の実行ドロップダウンリストからキャッシュ**を選択します。
1. デフォルトの実行キャッシュ動作を上書きするには、実行の**キャッシュ動作**を選択します。詳細については、「[キャッシュ動作の実行](how-run-cache.md#run-cache-behavior)」を参照してください。
1. **「実行を開始する**」のステップ 4 に進みます。
## CLI を使用した実行キャッシュを使用した実行の設定
実行キャッシュを使用する実行を開始するには、cache-id パラメータを **start-run** CLI コマンドに追加します。必要に応じて、 `cache-behavior`パラメータを使用して、実行キャッシュ用に設定したデフォルトの動作を上書きします。次の例は、 コマンドのキャッシュフィールドのみを示しています。
```
aws omics start-run \
...
--cache-id "xxxxxx" \
--cache-behavior CACHE_ALWAYS
```
オペレーションが成功すると、データフィールドのないレスポンスを受け取ります。
## 実行キャッシュのエラーケース
以下のシナリオでは、キャッシュ動作が**常に**キャッシュに設定されている実行であっても、HealthOmics がタスク出力をキャッシュしない場合があります。
+ 最初のタスクが正常に完了する前に実行でエラーが発生した場合、エクスポートするキャッシュ出力はありません。
+ エクスポートプロセスが失敗した場合、HealthOmics はタスク出力を Amazon S3 キャッシュの場所に保存しません。
+ **filesystem out of space** エラーが原因で実行が失敗した場合、呼び出しキャッシュはタスク出力を保存しません。
+ 実行をキャンセルした場合、呼び出しキャッシュはタスク出力を保存しません。
+ 実行に実行タイムアウトが発生した場合、失敗時にキャッシュを使用するように実行を設定しても、呼び出しキャッシュはタスク出力を保存しません。
## 通話キャッシュ情報の追跡
コンソール、 CLI、または CloudWatch Logs を使用して、コールキャッシュイベント (キャッシュヒットの実行など) を追跡できます。
**Topics**
+ [コンソールを使用してキャッシュヒットを追跡する](#workflow-cache-track-console)
+ [CLI を使用して通話キャッシュを追跡する](#workflow-cache-track-cli)
+ [CloudWatch Logs を使用して通話キャッシュを追跡する](#workflow-cache-track-cwl)
### コンソールを使用してキャッシュヒットを追跡する
実行の詳細ページで、**タスクの実行**テーブルに各タスクの**キャッシュヒット**情報が表示されます。このテーブルには、関連付けられたキャッシュエントリへのリンクも含まれています。次の手順を使用して、実行のキャッシュヒット情報を表示します。
1. [HealthOmics コンソール](https://console.aws.amazon.com/omics/)を開きます。
1. 必要に応じて、左側のナビゲーションペイン (≡) を開きます。**[実行]** を選択します。
1. **実行**ページで、検査する実行を選択します。
1. 実行の詳細ページで、**タスクの実行**タブを選択してタスクテーブルを表示します。
1. タスクにキャッシュヒットがある場合、**キャッシュヒット**列には Amazon S3 の実行キャッシュエントリの場所へのリンクが含まれます。
1. リンクを選択して、実行キャッシュエントリを検査します。
### CLI を使用して通話キャッシュを追跡する
**get-run** CLI コマンドを使用して、実行でコールキャッシュが使用されたかどうかを確認します。
```
aws omics get-run --id 1234567
```
レスポンスで、 `cacheId`フィールドが設定されている場合、実行はそのキャッシュを使用します。
**list-run-tasks** CLI コマンドを使用して、実行中の各キャッシュされたタスクのキャッシュデータの場所を取得します。
```
aws omics list-run-tasks --id 1234567
```
レスポンスで、タスクの cacheHit フィールドが true の場合、cacheS3Uri フィールドはそのタスクのキャッシュデータの場所を提供します。
**get-run-task** CLI コマンドを使用して、特定のタスクのキャッシュデータの場所を取得することもできます。
```
aws omics get-run-task --id 1234567 --task-id
```
### CloudWatch Logs を使用して通話キャッシュを追跡する
HealthOmics は `/aws/omics/WorkflowLog` CloudWatch ロググループにキャッシュアクティビティログを作成します。実行キャッシュごとにログストリームがあります: **runCache//**。
コールキャッシュを使用する実行の場合、HealthOmics はこれらのイベントの CloudWatch Logs エントリを生成します。
+ キャッシュエントリの作成 (CACHE\$1ENTRY\$1CREATED)
+ キャッシュエントリの一致 (CACHE\$1HIT)
+ キャッシュエントリの一致に失敗する (CACHE\$1MISS)
これらのログの詳細については、「」を参照してください[CloudWatch のログ](monitoring-cloudwatch-logs.md#cloudwatch-logs)。
`/aws/omics/WorkflowLog` ロググループで次の CloudWatch Insights クエリを使用して、このキャッシュの実行ごとのキャッシュヒット数を返します。
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_HIT'
parse "run: *," as run
stats count(*) as cacheHits by run
```
次のクエリを使用して、実行ごとに作成されたキャッシュエントリの数を返します。
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_ENTRY_CREATED'
parse "run: *," as run
stats count(*) as cacheEntries by run
```