翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# HealthOmics ワークフロータスク用のエフェメラルストレージ
HealthOmics は、 `/tmp` ディレクトリを使用してワークフロータスク用のエフェメラルストレージを提供します。このストレージは一時的であり、ワークフロー内の各タスクに固有です。HealthOmics は、デフォルトで各タスクインスタンスに 16 GiB のエフェメラルストレージを割り当てます。ワークフロー定義の個々のタスクに割り当てられるエフェメラルストレージの量は、タスクあたり最大 3,072 GiB まで増やすことができます。に保存されているすべてのデータは、保管時に暗号化`/tmp`されます。
**Topics**
+ [主な利点](#ephemeral-storage-key-benefits)
+ [エフェメラルストレージの仕組み](#ephemeral-storage-how-it-works)
+ [エフェメラルストレージの有効化](#ephemeral-storage-enable)
+ [デフォルトのストレージ割り当て](#ephemeral-storage-default-allocation)
+ [エフェメラルストレージサイズの設定](#ephemeral-storage-configure-size)
+ [エフェメラルストレージのモニタリング](#ephemeral-storage-monitoring)
+ [エフェメラルストレージの請求方法](#ephemeral-storage-billing)
+ [考慮事項と制限事項](#ephemeral-storage-considerations)
+ [エフェメラルストレージのトラブルシューティング](#ephemeral-storage-troubleshooting)
## 主な利点
+ **タスク実行の高速化:** エフェメラルストレージは、共有ファイルシステムの I/O を減らすことで実行パフォーマンスを向上させることができます。
+ **予測可能なパフォーマンス:** タスクは I/O 帯域幅の他の同時実行タスクと競合しないため、共有ネットワークファイルシステムに関連する変動性とスロットリングが減少します。
+ **コストの削減:** タスクの実行を高速化することで、 を利用する I/O バインドタスクのコンピューティング時間とコストを直接削減できます`/tmp`。静的実行ストレージを使用する実行の場合、これにより必要なプロビジョニングされた実行ストレージの量を減らすことができます。動的実行には変更は必要ありません。
## エフェメラルストレージの仕組み
エフェメラルストレージを有効にすると、HealthOmics はワークフロータスクインスタンスごとに `/tmp`に専用のローカルストレージボリュームをマウントします。エフェメラルストレージは、タスクの実行中に生成される一時ファイルを対象としています。エフェメラルストレージボリュームは、タスクが終了すると常に削除されます。に書き込まれたデータは、保持、エクスポートされず、他のタスクや後続の実行にもアクセス`/tmp`できません。
### ワークフローが一時ファイルを書き込む場所
ワークフローは、タスクがスクラッチ I/O を に直接処理するときに、エフェメラルストレージの恩恵を受けます`/tmp`。バイオインフォマティクスワークフロー言語は`$TMP`、タスクの実行中に一時的な存続期間の短い中間ファイルに `/tmp` ディレクトリ (および 、`$TMPDIR`環境変数) を使用します。タスクコマンドが`$TMPDIR`別の場所にマッピングされていないことを確認します。
ワークフロータスクプロセスが有効になると、エフェメラルストレージ`/tmp`を自動的に使用するように書き込むため、ワークフローの変更は必要ありません。スクラッチプロセスを に明示的に指示しないワークフロー`/tmp`では、実行ストレージに使用される共有ファイルシステムの作業ディレクトリにスクラッチデータが書き込まれますが、使用されるツールはエフェメラルストレージ`/tmp`で を利用する可能性があります。
### 保管中の暗号化
すべてのエフェメラルストレージは、サービスマネージド AWS KMS キーを使用して保管時に暗号化されます。高速コンピューティングインスタンスは、インスタンスの終了時に破棄されるボリュームごとの一意のキーでハードウェア暗号化されます。
### アクセス許可
HealthOmics は、ユーザーに代わってエフェメラルストレージボリュームのアタッチメントとライフサイクルを管理します。タスク実行ロールに追加の IAM アクセス許可は必要ありません。
## エフェメラルストレージの有効化
`StartRun` API `scratchStorageMode`で を設定することで、スクラッチ I/O をローカルストレージにリダイレクトできます。`scratchStorageMode` この設定は CPU インスタンスにのみ適用され、その実行のすべてのタスクに適用されます。
`scratchStorageMode` は、ワークフローがスクラッチデータを書き込む場所を決定します。使用できる値:
+ `LOCAL` — エフェメラルストレージはローカルディスクに配置されます。スクラッチ I/O には専用の IOPS とスループットがあります。
+ `SHARED` — 共有ファイルシステムが使用されます (デフォルト）。スクラッチ I/O は作業ディレクトリと競合します。
詳細については、「[HealthOmics で実行を開始する](starting-a-run.md)」を参照してください。
**注記**
GPU タスクは常にスクラッチデータにローカル NVMe エフェメラルストレージを使用し、 `scratchStorageMode`は常に GPU タスク`LOCAL`に使用します。
### エフェメラルストレージへのオプトイン
実行のエフェメラルストレージを有効にするには、実行を開始する`LOCAL`ときに `scratchStorageMode` を に設定します。
```
aws omics start-run \
--workflow-id {{workflow-id}} \
--role-arn {{arn:aws:iam::123456789012:role/OmicsServiceRole}} \
--output-uri s3://{{amzn-s3-demo-bucket}}/{{output-folder}}/ \
--parameters file://{{/path/to/parameters.json}} \
--scratch-storage-mode LOCAL
```
バッチ実行の場合は、 `scratchStorageMode`を渡します`defaultRunSetting`。この設定は、バッチ内のすべての実行に適用されます。
```
aws omics start-run-batch \
--batch-name "{{my-batch}}" \
--default-run-setting '{
"workflowId": "{{workflow-id}}",
"roleArn": "arn:aws:iam::{{123456789012}}:role/{{OmicsServiceRole}}",
"outputUri": "s3://{{amzn-s3-demo-bucket}}/{{output-folder}}/",
"storageType": "DYNAMIC",
"parameters": {"{{referenceUri}}": "s3://{{amzn-s3-demo-bucket}}/{{reference.fasta}}"},
"scratchStorageMode": "LOCAL"
}' \
--batch-run-settings '{
"inlineSettings": [
{
"runSettingId": "{{sample-A}}",
"parameters": {"{{inputUri}}": "s3://{{amzn-s3-demo-bucket}}/{{sampleA.fastq}}"}
},
{
"runSettingId": "{{sample-B}}",
"parameters": {"{{inputUri}}": "s3://{{amzn-s3-demo-bucket}}/{{sampleB.fastq}}"}
}
]
}'
```
### エフェメラルストレージからオプトアウトする
特定の実行のエフェメラルストレージを無効にするには (たとえば、障害を分離するには）、 `scratchStorageMode` を に設定します`SHARED`。
```
aws omics start-run \
--workflow-id {{workflow-id}} \
--role-arn {{arn:aws:iam::123456789012:role/OmicsServiceRole}} \
--output-uri s3://{{amzn-s3-demo-bucket}}/{{output-folder}}/ \
--scratch-storage-mode SHARED
```
`scratchStorageMode` が の場合`SHARED`、ワークフロー定義のすべての `disk`および同等のディレクティブは無視され`/tmp`、共有ファイルシステムによってバックアップされます。この設定は CPU インスタンスにのみ適用されます。GPU タスクは常にローカル NVMe エフェメラルストレージを使用し、オプトアウトすることはできません。
### 有効モードを確認する
エフェメラルストレージはデフォルトでオフになっています。`scratchStorageMode` が`StartRun`リクエストから省略されると、 `scratchStorageMode`は `SHARED` (デフォルト) に設定されます。
`scratchStorageMode` は、`StartRun`リクエストで明示的に渡された場合にのみ`GetRun`レスポンスで返されます。 `SHARED`は省略された場合のデフォルト値です。`GetRun` を呼び出して、実行の有効なストレージモードを確認します。
```
aws omics get-run --id {{run-id}}
```
## デフォルトのストレージ割り当て
デフォルトのエフェメラルストレージ割り当ては、すべての標準、コンピューティング、メモリ最適化インスタンスタイプでタスクあたり 16 GiB です。このデフォルトを受信するには、`disk`ディレクティブを指定する必要はありません。追加のストレージを設定するには、 `disk`ディレクティブを使用します。ワークフロー定義の個々のタスクに割り当てられるエフェメラルストレージの量は、タスクあたり最大 3,072 GiB まで増やすことができます。デフォルトの 16 GiB を超えるストレージに対して課金されます。
エフェメラルストレージは 16 GiB 単位で設定できます。詳細については、「[サポートされているサイズ](#ephemeral-storage-supported-sizes)」を参照してください。
### 高速コンピューティングインスタンス用のエフェメラルストレージ
GPU インスタンスのストレージ容量はインスタンスタイプごとに固定され、追加料金なしで提供されます。
GPU タスクは常にローカル NVMe エフェメラルストレージを使用します。の `scratchStorageMode`設定`StartRun`は GPU タスクには適用されません。この値を に設定すると`SHARED`、GPU インスタンスには影響しません。容量はインスタンスタイプごとに固定され、 `disk`ディレクティブを使用してカスタマイズすることはできません。NVMe 容量は、タスクの `cpu`、、`memory`および `acceleratorType`要件用に選択されたインスタンスタイプによって事前に決まります。
| サイズ | GPUs | vCPU | メモリ (GiB) | G4dn NVMe (T4) | G5 NVMe (A10G) | G6 NVMe (L4) | G6e NVMe (L40S) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| xlarge | 1 | 4 | 16 | 125 GiB | 250 GiB | 250 GiB | 250 GiB |
| 2xlarge | 1 | 8 | 32 | 225 GiB | 450 GiB | 450 GiB | 450 GiB |
| 4xlarge | 1 | 16 | 64 | 225 GiB | 600 GiB | 600 GiB | 600 GiB |
| 8xlarge | 1 | 32 | 128 | 900 GiB | 900 GiB | 900 GiB | 900 GiB |
| 12xlarge | 4 | 48 | 192 | 900 GiB | 3,800 GiB | 3,760 GiB | 3,800 GiB |
| 16xlarge | 1 | 64 | 256 | 900 GiB | 1,900 GiB | 1,880 GiB | 1,900 GiB |
| 24xlarge | 4 | 96 | 384 | — | 3,800 GiB | 3,760 GiB | 3,800 GiB |
## エフェメラルストレージサイズの設定
`scratchStorageMode` を に設定すると`LOCAL`、ワークフロー定義の `disk`ディレクティブ (または同等のもの) を使用して、タスクごとのエフェメラルストレージの増加をリクエストできます。HealthOmics は`disk`ディレクティブをヒントとして扱い、次の 16 GiB に丸められたボリュームをプロビジョニングします。`disk` ディレクティブの使用は、インスタンスタイプの選択には影響しません。インスタンスタイプは、`cpu`、、`memory`および のみに基づいて選択されます`acceleratorType`。詳細については、「[HealthOmics ワークフロー定義のタスクリソース](task-resources.md)」を参照してください。
`disk` ディレクティブが存在しない場合、タスクはデフォルトの 16 GiB を受け取ります。タスクは、デフォルトのエフェメラルストレージよりも小さくすることはできません。
個別に考慮されるプルコンテナイメージのエフェメラルストレージのサイズを設定する必要はありません。詳細については、「[プライベートワークフローのコンテナイメージ](workflows-ecr.md)」を参照してください。
### ディスクディレクティブを使用するタイミング
選択したインスタンスタイプのデフォルトのエフェメラルストレージがタスク要件に十分でない場合は、タスク定義で `disk`ディレクティブを使用します。たとえば、タスクが大量のデータを に書き込む場合です`/tmp`。
### エフェメラルストレージを増やす一般的なユースケース
1. **RNA-Seq フュージョン検出:** RNA-seq ワークフローは大規模な中間 BAMs を生成し、タスクプロセスでは多くの場合、未加工の FASTQs と調整された出力の両方を同時に存在させる必要があり、大きなスクラッチディスク (タスクあたり 512 GiB など) が必要になります。
1. **デノボゲノムアセンブリ:** ロングリードアセンブリワークフローでは、未加工の読み取りと一時的なアセンブリアーティファクトを処理するために大きなスクラッチボリュームが必要です。これらは、出力前に繰り返し書き換えられ、再編成されます。これらのタスクはメモリとディスクを大量に消費するため、複数の TiB のエフェメラルストレージが必要になる場合があります。
1. **バリアント呼び出し/BAM 処理:** バリアント呼び出しワークフローでは、大規模な BAM または CRAM ファイルを繰り返し読み書きする調整およびソートステップに、かなりのスクラッチストレージが必要です。エフェメラルストレージのニーズは通常数百 GiB です。
### エンジン別のディレクティブ構文
次の表は、各ワークフロー言語の同等のディレクティブを示しています。
| エンジン | ディレクティブ | 例 |
| --- | --- | --- |
| WDL 1.1 | disks | disks: "/tmp 700 GiB" |
| ネクストフロー | disk | disk '700 GB' |
| CWL | tmpdirMin | tmpdirMin: 716800 (MiB 単位の値) |
次の例は、700 GiB のエフェメラルストレージをリクエストするタスクを設定する方法を示しています。HealthOmics はこれを 704 GiB 階層に切り上げます。
------
#### [ WDL ]
```
task sort_bam {
runtime {
cpu: 16
disks: "700 GiB"
}
command <<<
samtools sort -T /tmp/sort_buffer ~{input_bam} -o ~{output_bam}
>>>
}
```
------
#### [ Nextflow ]
```
process sort_bam {
disk '700 GB'
script:
"""
samtools sort -T /tmp/sort_buffer ${input} -o ${output}
"""
}
```
------
#### [ CWL ]
```
requirements:
ResourceRequirement:
tmpdirMin: 716800 # 700 GiB expressed in MiB
```
------
サポートされているディレクティブ構文の詳細については、[WDL ワークフロー定義の詳細](workflow-languages-wdl.md)「」および「」を参照してください[Nextflow ワークフロー定義の詳細](workflow-definition-nextflow.md)。
### 一般的なバイオインフォマティクスツールとエフェメラルストレージ
多くのバイオインフォマティクスツールは、実行中に大きな一時ファイルを書き込みます。`scratchStorageMode` が に設定されている場合`LOCAL`、スクラッチ I/O `/tmp`が共有実行ファイルシステムではなく高速ローカルボリュームになるように、これらのツールを にリダイレクトします。次の例は、一般的に使用されるツールに関連するフラグを示しています。
------
#### [ WDL ]
```
task sort_bam {
runtime {
cpu: 16
disks: "700 GiB"
}
command <<<
# samtools: -T sets the temp-file prefix
samtools sort -T /tmp/sort_buffer ~{input_bam} -o ~{sorted_bam}
# GATK / Picard: --TMP_DIR flag (older Picard uses TMP_DIR=/tmp)
gatk MarkDuplicates -I ~{sorted_bam} -O ~{output_bam} --TMP_DIR /tmp
# STAR: --outTmpDir (path must not pre-exist; STAR creates it)
STAR --runThreadN 16 --readFilesIn ~{reads} --outTmpDir /tmp/star_tmp --outFileNamePrefix out_
# bcftools sort: -T / --temp-dir
bcftools sort -T /tmp ~{vcf} -o ~{output_vcf}
# GNU sort: -T / --temporary-directory
sort -T /tmp ~{big_table} -o ~{sorted_table}
>>>
}
# HealthOmics rounds 700 GiB up to the 704 GiB tier
```
------
#### [ Nextflow ]
```
process sort_bam {
disk '700 GB'
script:
"""
# samtools: -T sets the temp-file prefix
samtools sort -T /tmp/sort_buffer input.bam -o sorted.bam
# GATK / Picard: --TMP_DIR flag (older Picard uses TMP_DIR=/tmp)
gatk MarkDuplicates -I sorted.bam -O dedup.bam --TMP_DIR /tmp
# STAR: --outTmpDir (path must not pre-exist; STAR creates it)
STAR --runThreadN 16 --readFilesIn reads.fastq --outTmpDir /tmp/star_tmp --outFileNamePrefix out_
# bcftools sort: -T / --temp-dir
bcftools sort -T /tmp input.vcf -o sorted.vcf
# GNU sort: -T / --temporary-directory
sort -T /tmp big_table.tsv -o sorted_table.tsv
"""
}
// HealthOmics rounds 700 GB up to the 704 GiB tier
```
------
#### [ CWL ]
```
class: CommandLineTool
cwlVersion: v1.2
requirements:
ResourceRequirement:
coresMin: 16
tmpdirMin: 716800 # 700 GiB expressed in MiB
baseCommand: [bash, -c]
arguments:
- |
set -euo pipefail
# samtools: -T sets the temp-file prefix
samtools sort -T /tmp/sort_buffer input.bam -o sorted.bam
# GATK / Picard: --TMP_DIR flag (older Picard uses TMP_DIR=/tmp)
gatk MarkDuplicates -I sorted.bam -O dedup.bam --TMP_DIR /tmp
# STAR: --outTmpDir (path must not pre-exist; STAR creates it)
STAR --runThreadN 16 --readFilesIn reads.fastq --outTmpDir /tmp/star_tmp --outFileNamePrefix out_
# bcftools sort: -T / --temp-dir
bcftools sort -T /tmp input.vcf -o sorted.vcf
# GNU sort: -T / --temporary-directory
sort -T /tmp big_table.tsv -o sorted_table.tsv
```
------
### サポートされているサイズ
リクエストされたサイズは、デフォルトの 16 GiB (16、32、48、64 ... 最大 3,072 GiB) から最も近い 16 GiB 増分に切り上げられます。サポートされている最大サイズは、タスクあたり 3,072 GiB です。
リクエストされたサイズが 3,072 GiB を超える場合、HealthOmics は 3,072 GiB をプロビジョニングし、実行ログに警告を書き込みます。タスクは自動的に失敗しません。
**注記**
Nextflow クロージャや WDL 式などの式ベースの`disk`ディレクティブの場合、`disks: ceil(size(input_bam, "GiB") * 2.5)`値は ではなくランタイムに評価されます`CreateWorkflow`。評価されたサイズが 3,072 GiB を超える場合、タスクは実行時に失敗し、それまでに発生したコンピューティングコストが課金されます。
### サポートされている WDL `disks`フォーム
承認された WDL `disks`フォームの完全なリストについては、「」を参照してください[サポートされている WDL `disks`フォーム](workflow-languages-wdl.md#workflow-wdl-disks-forms)。
### Nextflow スクラッチディレクティブの使用
Nextflow ワークフローでは、 `scratch`ディレクティブを使用して、プロセスが一時的な作業ファイルを書き込む場所を制御できます。エフェメラルストレージでサポートされている値と推奨される使用方法については、「」を参照してください[Nextflow でスクラッチストレージを効率的に使用する](workflow-definition-nextflow.md#nextflow-scratch-storage)。
## エフェメラルストレージのモニタリング
HealthOmics は、タスクごとのエフェメラルストレージメトリクスを CloudWatch マニフェストログに書き込みます。メトリクスには、各タスクのプロビジョニングされたボリュームサイズ ( として`scratchStorageReservedGiB`) と使用状況 ( として`scratchStorageUtilizedGiB`) のタスクごとのエフェメラルストレージデータが含まれます。マニフェストログを確認して、CloudWatch を直接クエリせずにタスクが過剰プロビジョニングされたか過小プロビジョニングされたかを判断します。マニフェストログの詳細については、「」を参照してください[CloudWatch Logs による HealthOmics のモニタリング](monitoring-cloudwatch-logs.md)。
## エフェメラルストレージの請求方法
デフォルトの割り当てを超えてプロビジョニングされたエフェメラルストレージに対してのみ課金されます。`disk` ディレクティブのデフォルトを超えるリクエストは、サポートされている最も近い階層に切り上げられます。
GPU インスタンスには、インスタンス料金ですでにエフェメラルストレージが考慮されています。GPU タスクのエフェメラルストレージには追加料金はかかりません。
## 考慮事項と制限事項
| 考慮事項 | [Detail] (詳細) |
| --- | --- |
| エフェメラルストレージが永続的ではない | エフェメラルストレージボリュームは、タスクが終了すると常に削除されます。/tmp のデータは保存、エクスポートされず、後続のタスクや実行では使用できません。エフェメラルストレージ/tmpの のデータをタスク出力またはワークフロー出力にすることはできません。これにより、実行時に障害が発生します。 |
| エフェメラルストレージがタスク間で共有されない | 各タスクは、独自の分離されたエフェメラルストレージボリュームを受け取ります。タスクは互いの/tmpディレクトリにアクセスできません。タスク間で共有する必要があるデータは、共有実行ファイルシステムに書き込む必要があります。 |
| ストレージはタスクの途中でサイズ変更できません | ストレージサイズはタスクの開始時に固定されます。タスクの実行中に割り当てられたストレージを増減することはできません。 |
| 作業ディレクトリのスクラッチは自動的にリダイレクトされません | 、、 など、作業ディレクトリにスクラッチを書き込むワークフローにはinput/./、自動的にメリットout/はありません。ワークフローを更新して、スクラッチ I/O を /tmpまたは にリダイレクトします$TMPDIR。 |
| スクラッチデータが期待/tmpどおりに書き込まれていない | タスクプロセスが明示的に に書き込み/tmp、タスクコマンドが$TMPDIR別の場所にマッピングされていないことを確認します。 |
| GPU インスタンスは常にエフェメラルストレージを使用します | GPU タスクは常にローカル NVMe インスタンスストア/tmpにマウントされます。scratchStorageMode を に設定SHAREDしても、GPU タスクのエフェメラルストレージは無効になりません。 |
| GPU インスタンス: NVMe 容量が固定されています | GPU インスタンスでは、カスタムディスクサイズ設定はサポートされていません。HealthOmics はdiskディレクティブを無視し、インスタンスタイプのデフォルトの NVMe 容量を提供します。 |
| タスクあたり最大 3,072 GiB (CPU) | 3,072 GiB を超えるリクエストは、実行ログ警告とともに 3,072 GiB にプロビジョニングされます。タスクは失敗しません。 |
| サポートされている階層のみ (CPU) | リクエストされたサイズは、最も近い 16 GiB の増分 (16、32、48、64、... 最大 3,072 GiB) に切り上げられます。 |
| 実行時に評価される式ベースのディレクティブ | disk 式から計算された値は、 ではなくタスクの開始時に検証されますCreateWorkflow。その時点までのコンピューティングコストは、実行時にタスクが失敗した場合に課金されます。 |
| SHARED モードはすべてのディスクディレクティブを無視します (CPU のみ) | scratchStorageMode が の場合SHARED、、tmpdirMin、、および同等のディレクティブは CPU diskタスクでは無視されます。ローカルストレージボリュームはプロビジョニングされません。GPU タスクは影響を受けず、常にローカル NVMe を使用します。 |
## エフェメラルストレージのトラブルシューティング
### エフェメラルストレージを使い果たすとタスクが失敗する
エフェメラルストレージが容量に達すると、タスクは失敗します。CloudWatch マニフェストログを確認して、タスクが実際に使用したストレージの量を確認し、`disk`ディレクティブを追加または増やしてより大きな階層をリクエストします。
```
# Before: 4-vCPU task using the 16 GiB default
runtime { cpu: 4 }
# After: explicitly request 400 GiB
runtime { cpu: 4, disks: "400 GiB" }
```
### エフェメラルストレージが使用されていないように見える
を呼び出し`GetRun`て `scratchStorageMode`フィールドを確認します。値が の場合`SHARED`、エフェメラルストレージはその実行に対して有効になっていません。次の`start-run`通話`--scratch-storage-mode LOCAL`で を設定します。
```
aws omics get-run --id {{run-id}}
```