기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# HealthOmics 워크플로 작업을 위한 임시 스토리지
HealthOmics는 `/tmp` 디렉터리를 사용하여 워크플로 작업을 위한 임시 스토리지를 제공합니다. 이 스토리지는 임시 스토리지이며 워크플로의 각 작업에 고유합니다. HealthOmics는 기본적으로 각 작업 인스턴스에 16GiB의 임시 스토리지를 할당합니다. 워크플로 정의의 개별 작업에 할당된 임시 스토리지 양을 작업당 최대 3,072GiB까지 늘릴 수 있습니다. 에 저장된 모든 데이터는 저장 시 암호화`/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 임시 스토리지를 사용하며 항상 GPU 작업에 `scratchStorageMode` `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}}
```
## 기본 스토리지 할당
기본 임시 스토리지 할당은 모든 표준, 컴퓨팅 및 메모리 최적화 인스턴스 유형에 대해 작업당 16GiB입니다. 이 기본값을 받기 위해 `disk` 지시문을 지정할 필요는 없습니다. 추가 스토리지를 구성하려면 `disk` 명령을 사용합니다. 워크플로 정의의 개별 작업에 할당된 임시 스토리지 양을 작업당 최대 3,072GiB까지 늘릴 수 있습니다. 기본값인 16GiB를 초과하는 스토리지에 대해서는 요금이 청구됩니다.
임시 스토리지는 16GiB 단위로 구성할 수 있습니다. 자세한 내용은 [지원되는 크기](#ephemeral-storage-supported-sizes) 단원을 참조하십시오.
### 가속 컴퓨팅 인스턴스를 위한 임시 스토리지
GPU 인스턴스 스토리지 용량은 인스턴스 유형별로 고정되며 추가 비용 없이 제공됩니다.
GPU 작업은 항상 로컬 NVMe 임시 스토리지를 사용합니다. 의 `scratchStorageMode` 설정은 GPU 작업에 적용되지 `StartRun` 않으며이 값을 로 설정`SHARED`해도 GPU 인스턴스에는 영향을 미치지 않습니다. 용량은 인스턴스 유형별로 고정되며 `disk` 명령을 사용하여 사용자 지정할 수 없습니다. NVMe 용량은 작업의 `cpu`, `memory`및 `acceleratorType` 요구 사항에 대해 선택한 인스턴스 유형에 따라 미리 결정됩니다.
| Size: | GPU | vCPU | 메모리(GiB) | G4dn NVMe(T4) | G5 NVMe(A10G) | G6 NVMe(L4) | G6e NVMe(L40S) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| xlarge | 1 | 4 | 16 | 125GiB | 250GiB | 250GiB | 250GiB |
| 2xlarge | 1 | 8 | 32 | 225GiB | 450GiB | 450GiB | 450GiB |
| 4xlarge | 1 | 16 | 64 | 225GiB | 600GiB | 600GiB | 600GiB |
| 8xlarge | 1 | 32 | 128 | 900GiB | 900GiB | 900GiB | 900GiB |
| 12xlarge | 4 | 48 | 192 | 900GiB | 3,800GiB | 3,760GiB | 3,800GiB |
| 16xlarge | 1 | 64 | 256 | 900GiB | 1,900GiB | 1,880GiB | 1,900GiB |
| 24xlarge | 4 | 96 | 384 | — | 3,800GiB | 3,760GiB | 3,800GiB |
## 임시 스토리지 크기 구성
`scratchStorageMode`를 로 설정하면 워크플로 정의의 `disk` 명령(또는 이에 상응하는 명령)을 사용하여 작업당 임시 스토리지 증가를 요청할 `LOCAL`수 있습니다. HealthOmics는 `disk` 지시문을 힌트로 취급하고 다음 16GiB로 반올림된 볼륨을 프로비저닝합니다. `disk` 지시문의 사용은 인스턴스 유형 선택에 영향을 주지 않습니다. 인스턴스 유형은 `cpu`, `memory`및 만 기반으로 선택됩니다`acceleratorType`. 자세한 내용은 [HealthOmics 워크플로 정의의 태스크 리소스](task-resources.md) 단원을 참조하십시오.
`disk` 명령이 없는 경우 작업은 기본값인 16GiB를 수신합니다. 작업은 기본 임시 스토리지보다 작을 수 없습니다.
별도로 고려되는 풀링된 컨테이너 이미지의 경우 임시 스토리지의 크기를 조정할 필요가 없습니다. 자세한 내용은 [프라이빗 워크플로용 컨테이너 이미지](workflows-ecr.md) 단원을 참조하십시오.
### 디스크 지시문을 사용해야 하는 경우
선택한 인스턴스 유형의 기본 임시 스토리지가 작업 요구 사항에 충분하지 않은 경우 작업 정의에서 `disk` 명령을 사용합니다. 예를 들어, 작업이 대량의 데이터를에 쓰는 경우입니다`/tmp`.
### 증가된 임시 스토리지에 대한 일반적인 사용 사례
1. **ALT-Seq 융합 감지:** ALT-seq 워크플로는 대규모 중간 BAMs 생성하며 작업 프로세스에는 원시 FASTQs와 정렬된 출력이 모두 동시에 있어야 하므로 대용량 스크래치 디스크(예: 작업당 512GiB)가 필요합니다.
1. **De" Genome Assembly:** 원시 읽기와 출력 전에 반복적으로 재작성 및 재구성되는 임시 어셈블리 아티팩트를 처리하려면 읽기가 긴 어셈블리 워크플로에 큰 스크래치 볼륨이 필요합니다. 이러한 작업은 메모리 및 디스크 집약적이며, 경우에 따라 여러 TiB의 임시 스토리지가 필요합니다.
1. **변형 호출/BAM 처리:** 변형 호출 워크플로에는 대용량 BAM 또는 CRAM 파일을 반복적으로 읽고 다시 쓰는 정렬 및 정렬 단계를 위해 상당한 스크래치 스토리지가 필요합니다. 임시 스토리지 요구 사항은 일반적으로 수백 GiB입니다.
### 엔진별 지침 구문
다음 표에는 각 워크플로 언어에 해당하는 지시문이 나와 있습니다.
| Engine | 지침 | 예제 |
| --- | --- | --- |
| WDL 1.1 | disks | disks: "/tmp 700 GiB" |
| 다음 흐름 | disk | disk '700 GB' |
| CWL | tmpdirMin | tmpdirMin: 716800 (MiB의 값) |
다음 예제에서는 700GiB의 임시 스토리지를 요청하는 작업을 구성하는 방법을 보여줍니다. HealthOmics는 이를 704GiB 티어로 올림합니다.
------
#### [ 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
```
------
### 지원되는 크기
요청된 크기는 기본값인 16GiB(16, 32, 48, 64, ... 최대 3,072GiB)부터 시작하여 가장 가까운 16GiB 증분으로 반올림됩니다. 지원되는 최대 크기는 작업당 3,072GiB입니다.
요청된 크기가 3,072GiB를 초과하는 경우 HealthOmics는 3,072GiB를 프로비저닝하고 실행 로그에 경고를 기록합니다. 작업은 자동으로 실패하지 않습니다.
**참고**
Nextflow 종료 또는 같은 WDL 표현식과 같은 표현식 기반 `disk` 지시문`disks: ceil(size(input_bam, "GiB") * 2.5)`의 경우 값은가 아닌 런타임에 평가됩니다`CreateWorkflow`. 평가된 크기가 3,072GiB를 초과하면 런타임 시 작업이 실패하고 해당 시점까지 발생한 모든 컴퓨팅 비용이 청구됩니다.
### 지원되는 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 매니페스트 로그에 기록합니다. 지표에는 각 작업에 `scratchStorageUtilizedGiB`대해 프로비저닝된 볼륨 크기() 및 사용량(`scratchStorageReservedGiB`)의 작업당 임시 스토리지 데이터가 포함됩니다. 매니페스트 로그를 검토하여 CloudWatch를 직접 쿼리하지 않고 작업이 과다 프로비저닝되었는지 과소 프로비저닝되었는지 확인합니다. 매니페스트 로그에 대한 자세한 내용은 섹션을 참조하세요[CloudWatch Logs를 사용하여 HealthOmics 모니터링](monitoring-cloudwatch-logs.md).
## 임시 스토리지에 요금이 청구되는 방법
기본 할당을 초과하여 프로비저닝된 임시 스토리지에 대해서만 요금이 청구됩니다. `disk` 지시문의 기본값을 초과하는 요청은 지원되는 가장 가까운 계층으로 반올림됩니다.
GPU 인스턴스에는 인스턴스 요금에 이미 임시 스토리지가 포함되어 있습니다. GPU 작업의 임시 스토리지에는 추가 요금이 부과되지 않습니다.
## 고려 사항 및 제한 사항
| 고려 사항 | 세부 정보 |
| --- | --- |
| 임시 스토리지는 영구적이지 않습니다. | 임시 스토리지 볼륨은 작업이 종료될 때 항상 삭제됩니다. 의 데이터는 저장, 내보내기 또는 후속 작업이나 실행에 사용할 수 /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,072GiB(CPU) | 3,072GiB를 초과하는 요청은 실행 로그 경고와 함께 3,072GiB로 프로비저닝됩니다. 작업이 실패하지 않습니다. |
| 지원되는 티어만(CPU) | 요청된 크기는 가장 가까운 16GiB 증분(16, 32, 48, 64, ... 최대 3,072GiB)으로 반올림됩니다. |
| 런타임 시 평가된 표현식 기반 지시문 | disk 표현식에서 계산된 값은가 아닌 작업 시작 시 검증됩니다CreateWorkflow. 런타임에 작업이 실패할 경우 해당 시점까지의 컴퓨팅 비용이 청구됩니다. |
| SHARED 모드는 모든 디스크 지시문을 무시합니다(CPU만 해당). | scratchStorageMode가 인 경우 SHARED, disktmpdirMin, 및 이에 상응하는 명령은 CPU 작업에 대해 무시됩니다. 로컬 스토리지 볼륨이 프로비저닝되지 않습니다. 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}}
```