翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

HealthOmics ワークフロータスク用のエフェメラルストレージ

HealthOmics は、 /tmp ディレクトリを使用してワークフロータスク用のエフェメラルストレージを提供します。このストレージは一時的であり、ワークフロー内の各タスクに固有です。HealthOmics は、デフォルトで各タスクインスタンスに 16 GiB のエフェメラルストレージを割り当てます。ワークフロー定義の個々のタスクに割り当てられるエフェメラルストレージの量は、タスクあたり最大 3,072 GiB まで増やすことができます。に保存されているすべてのデータは、保管時に暗号化/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 は、ワークフローがスクラッチデータを書き込む場所を決定します。使用できる値:

詳細については、「HealthOmics で実行を開始する」を参照してください。

エフェメラルストレージへのオプトイン

実行のエフェメラルストレージを有効にするには、実行を開始する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 単位で設定できます。詳細については、「サポートされているサイズ」を参照してください。

高速コンピューティングインスタンス用のエフェメラルストレージ

GPU インスタンスのストレージ容量はインスタンスタイプごとに固定され、追加料金なしで提供されます。

GPU タスクは常にローカル NVMe エフェメラルストレージを使用します。の scratchStorageMode設定StartRunは GPU タスクには適用されません。この値を に設定するとSHARED、GPU インスタンスには影響しません。容量はインスタンスタイプごとに固定され、 diskディレクティブを使用してカスタマイズすることはできません。NVMe 容量は、タスクの cpu、、memoryおよび acceleratorType要件用に選択されたインスタンスタイプによって事前に決まります。

エフェメラルストレージサイズの設定

scratchStorageMode を に設定するとLOCAL、ワークフロー定義の diskディレクティブ (または同等のもの) を使用して、タスクごとのエフェメラルストレージの増加をリクエストできます。HealthOmics はdiskディレクティブをヒントとして扱い、次の 16 GiB に丸められたボリュームをプロビジョニングします。disk ディレクティブの使用は、インスタンスタイプの選択には影響しません。インスタンスタイプは、cpu、、memoryおよび のみに基づいて選択されますacceleratorType。詳細については、「HealthOmics ワークフロー定義のタスクリソース」を参照してください。

disk ディレクティブが存在しない場合、タスクはデフォルトの 16 GiB を受け取ります。タスクは、デフォルトのエフェメラルストレージよりも小さくすることはできません。

個別に考慮されるプルコンテナイメージのエフェメラルストレージのサイズを設定する必要はありません。詳細については、「プライベートワークフローのコンテナイメージ」を参照してください。

ディスクディレクティブを使用するタイミング

選択したインスタンスタイプのデフォルトのエフェメラルストレージがタスク要件に十分でない場合は、タスク定義で diskディレクティブを使用します。たとえば、タスクが大量のデータを に書き込む場合です/tmp。

エフェメラルストレージを増やす一般的なユースケース

エンジン別のディレクティブ構文

次の表は、各ワークフロー言語の同等のディレクティブを示しています。

次の例は、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 ワークフロー定義の詳細「」および「」を参照してくださいNextflow ワークフロー定義の詳細。

一般的なバイオインフォマティクスツールとエフェメラルストレージ

多くのバイオインフォマティクスツールは、実行中に大きな一時ファイルを書き込みます。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 をプロビジョニングし、実行ログに警告を書き込みます。タスクは自動的に失敗しません。

サポートされている WDL disksフォーム

承認された WDL disksフォームの完全なリストについては、「」を参照してくださいサポートされている WDL disksフォーム。

Nextflow スクラッチディレクティブの使用

Nextflow ワークフローでは、 scratchディレクティブを使用して、プロセスが一時的な作業ファイルを書き込む場所を制御できます。エフェメラルストレージでサポートされている値と推奨される使用方法については、「」を参照してくださいNextflow でスクラッチストレージを効率的に使用する。

エフェメラルストレージのモニタリング

HealthOmics は、タスクごとのエフェメラルストレージメトリクスを CloudWatch マニフェストログに書き込みます。メトリクスには、各タスクのプロビジョニングされたボリュームサイズ ( としてscratchStorageReservedGiB) と使用状況 ( としてscratchStorageUtilizedGiB) のタスクごとのエフェメラルストレージデータが含まれます。マニフェストログを確認して、CloudWatch を直接クエリせずにタスクが過剰プロビジョニングされたか過小プロビジョニングされたかを判断します。マニフェストログの詳細については、「」を参照してくださいCloudWatch Logs による HealthOmics のモニタリング。

エフェメラルストレージの請求方法

デフォルトの割り当てを超えてプロビジョニングされたエフェメラルストレージに対してのみ課金されます。disk ディレクティブのデフォルトを超えるリクエストは、サポートされている最も近い階層に切り上げられます。

GPU インスタンスには、インスタンス料金ですでにエフェメラルストレージが考慮されています。GPU タスクのエフェメラルストレージには追加料金はかかりません。

考慮事項と制限事項

エフェメラルストレージのトラブルシューティング

エフェメラルストレージを使い果たすとタスクが失敗する

エフェメラルストレージが容量に達すると、タスクは失敗します。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