기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
프라이빗 HealthOmics 워크플로에 대한 최적화 실행
총 비용, 총 실행 시간 또는 둘 다에 대해 실행을 최적화할 수 있습니다. HealthOmics는 최적화 결정을 실행하는 데 도움이 되는 데이터와 도구를 제공합니다. 실행 최적화는 Ready2Run 워크플로에는 적용되지 않습니다. 서비스가 이러한 워크플로에 대한 리소스 프로비저닝을 관리하는 방법을 제어할 수 없기 때문입니다.
첫 번째 단계는 실행 중인 작업에 대한 현재 작업 리소스 사용량과 비용을 파악한 다음 실행 비용 및 성능을 최적화하는 방법을 적용하는 것입니다.
분석기 실행
HealthOmics는 Run Analyzer
참고
실행 분석기는 도구를 실행할 때 AWS 정가를 기준으로 작업 비용과 잠재적 비용 절감을 추정합니다. 최적화 권장 사항을 평가하고 사용 사례에 적합한 권장 사항을 구현합니다. 채택한 최적화를 테스트하여 실행에 적합한지 확인합니다.
Run Analyzer는 다음 작업을 수행합니다.
-
메모리 및 컴퓨팅 병목 현상을 평가합니다.
-
메모리 또는 CPU용으로 과다 프로비저닝된 작업을 식별하고 비용을 절감할 수 있는 새 인스턴스 크기를 권장합니다.
-
개별 작업에 대한 예상 비용을 계산하고 권장 사항을 적용할 경우 잠재적 비용 절감을 계산합니다.
-
작업 종속성과 처리 순서를 확인할 수 있도록 작업에 대한 타임라인 보기를 제공합니다. 타임라인은 장기 실행 작업을 식별하는 데도 도움이 됩니다.
-
실행 스토리지의 파일 시스템 크기에 대한 권장 사항을 제공합니다.
-
대용량 컨테이너 로드로 인해 프로비저닝 시간이 느려질 수 있는 영역을 식별할 수 있도록 작업 프로비저닝 시간을 표시합니다.
-
이 도구에는 최적화 권장 사항의 공격성을 제어하는 데 사용할 수 있는 입력 파라미터(헤드룸)가 포함되어 있습니다.
다음 섹션에는 Run Analyzer를 사용하여 실행을 최적화하기 위한 특정 제안 사항이 포함되어 있습니다.
실행 비용 결정
다음 방법 및 지침을 사용하여 실행 비용을 결정할 수 있습니다.
-
결제 기간의 총 실행 비용을 보려면 다음 단계를 따르세요.
-
Billing and Cost Management
콘솔을 열고 청구서를 선택합니다. 서비스별 요금에서 Omics를 확장합니다.
리전을 확장한 다음 omics 인스턴스 유형, 실행 스토리지 유형 및 Ready2Run 워크플로별로 항목화된 모든 실행의 비용을 확인합니다.
-
-
각 실행에 대한 정보가 포함된 비용 보고서를 생성하려면 다음 단계를 따릅니다.
-
Billing and Cost Management
콘솔을 열고 데이터 내보내기를 선택합니다. -
생성을 선택하여 새 데이터 내보내기를 생성합니다.
-
데이터 내보내기의 내보내기 이름을 입력합니다. 다른 필드를 기본값으로 유지하여 CUR(비용 및 사용량) 보고서를 생성합니다.
-
시간 세분화에서 시간별 또는 일별을 선택합니다.
-
데이터 내보내기 스토리지 설정에서 다음 구성 단계를 수행합니다.
-
데이터 내보내기를 위해 Amazon S3 버킷을 구성합니다.
-
파일 버전 관리에서 기존 내보내기 파일을 덮어쓸지 아니면 매번 새 파일을 생성할지 선택합니다.
시스템은 향후 24시간 이내에 첫 번째 보고서를 생성하고 하루에 한 번 후속 보고서를 생성합니다.
-
데이터 내보내기를 생성하는 방법에 대한 자세한 내용은 데이터 내보내기 사용 설명서AWS 의 데이터 내보내기 생성을 참조하세요.
-
-
실행에 태그를 지정하여 팀 또는 프로젝트와 같은 범주별로 비용을 모니터링하고 최적화할 수 있습니다. 태그를 사용하는 경우 다음 단계에 따라 태그 범주별로 실행 비용을 확인합니다.
-
Billing and Cost Management
콘솔을 열고 Cost Explorer를 선택합니다. 보고서 파라미터 > 그룹화 기준에서 차원으로 태그를 선택하고 원하는 태그 이름을 선택합니다.
-
-
작업에 대한 리소스 사용량을 보려면 CloudWatch에서 실행 매니페스트 로그를 확인합니다. 자세한 내용은 CloudWatch Logs를 사용하여 HealthOmics 모니터링 단원을 참조하십시오.
-
분석기 실행 도구를 사용하여 실행에 대한 작업 리소스 사용 정보를 추출합니다.
런타임 사용량 결정
다음 방법을 사용하여 런타임 사용량을 조사할 수 있습니다.
-
콘솔의 실행 페이지에서 실행의 총 실행 시간을 볼 수 있습니다.
-
실행 세부 정보 페이지에서 다음 항목을 볼 수 있습니다.
-
실행의 총 실행 시간을 봅니다.
-
실행 중인 각 작업의 실행 시간을 확인합니다.
-
링크 중 하나를 선택하여 Amazon S3에서 로그를 보거나 CloudWatch에서 실행 로그를 보거나 매니페스트 로그를 실행합니다.
-
-
작업 실행 목록에서 작업에 대한 로그 보기 링크를 선택하여 CloudWatch에서 작업 로그를 봅니다.
-
listRuns
API 작업에 대한 응답에는 실행 시작 시간과 중지 시간이 포함되므로 총 실행 시간을 계산할 수 있습니다. -
이 분석기 실행 도구는 타임라인 보기에 작업 기간을 표시합니다. 이 도구는 예상 순서와 일치시킬 수 있는 작업 처리 시퀀스의 시각적 표현을 제공합니다.
실행을 최적화하는 방법
HealthOmics는 데이터 스테이징(예: 데이터 가져오기 및 데이터 내보내기)을 수행하는 리소스를 자동으로 프로비저닝, 관리 및 최적화합니다. HealthOmics는 워크플로에 대한 워크플로 엔진도 시작하고 실행합니다. 그러나 다양한 실행 구성을 설정하여 실행 시작 시간, 작업 시작 시간 및 전체 작업 실행 시간에 영향을 미칠 수 있습니다. 워크플로 정의 및 설계에 대한 전반적인 접근 방식은 작업 실행 시간에도 영향을 미칩니다. 다음 목록은 실행 및 작업 성능에 영향을 미칠 수 있는 요소를 설명합니다.
- 스토리지 유형 실행
-
실행 스토리지 유형은 실행 성능 및 실행 프로비저닝 시간에 영향을 미칩니다. 동적 실행 스토리지는 실행 스토리지 요구 사항에 따라 동적으로 확장되므로 더 빠르게 프로비저닝되고 메모리가 부족해지지 않습니다. 동적 실행 스토리지는 문제를 해결하기 위해 워크플로를 시작하고 중지할 수 있는 개발 중인 워크플로에도 적합합니다.
정적 실행 스토리지는 더 긴 파일 시스템 프로비저닝 시간이 필요하지만 일반적으로 실행의 작업 동시성이 높거나 9.6TiB 이상의 파일 시스템 용량이 필요한 경우 일부 실행을 더 빠르게 완료할 수 있습니다. 정적 실행 스토리지는 I/O 요구 사항이 높은 장기 실행 워크플로에 적합합니다.
지정된 실행에 대한 각 실행 스토리지 유형의 비용 대비 성능을 평가하는 데 도움이 되도록 A/B 테스트를 시도하여 어떤 실행 스토리지 유형이 더 나은 성능을 제공하는지 확인할 수 있습니다. 또한 개발 주기에 동적 실행 스토리지를 사용하는 것을 고려한 다음 대규모 프로덕션 실행에 정적 실행 스토리지를 사용하세요.
실행 스토리지 유형에 대한 자세한 내용은 HealthOmics 워크플로에서 스토리지 유형 실행
- 오버프로비저닝 실행 정적 스토리지
-
워크플로 작업 계산이 I/O에 의해 제한되는 경우 정적 실행 스토리지를 오버프로비저닝하는 것이 좋습니다. 스토리지 비용은 크기에 따라 증가하지만 파일 시스템의 최대 처리량도 증가합니다. 비용이 많이 드는 컴퓨팅 작업에 I/O 병목 현상이 발생하는 경우 파일 시스템 크기를 늘려 작업 실행 시간을 줄이면 전체 비용이 절감될 수 있습니다.
- 컨테이너 이미지 크기 축소
-
각 작업이 시작되면 HealthOmics는 작업에 지정한 컨테이너를 로드합니다. 컨테이너가 클수록 로드하는 데 시간이 더 오래 걸립니다. 컨테이너를 최대한 작게 최적화하여 새 작업을 시작하는 효율성을 개선합니다. 컨테이너에 대용량 데이터 세트를 추가하는 경우 데이터 세트를 S3에 저장하고 워크플로가 S3에서 데이터를 가져오도록 하는 것이 좋습니다. HealthOmics가 지원하는 최대 컨테이너 크기는 섹션을 참조하세요HealthOmics 워크플로 고정 크기 할당량.
- 태스크 크기
-
작은 순차 태스크를 단일 태스크로 결합하여 태스크 프로비저닝 시간을 절약할 수 있습니다. 또한 HealthOmics에는 최소 1분의 작업 기간 요금이 부과되므로 작업을 결합하면 비용이 절감될 수 있습니다. 결합된 작업 내에서 Unix 파이프를 사용하여 파일 직렬화 및 역직렬화의 I/O 비용을 방지할 수 있습니다.
- 파일 압축
-
워크플로 중간 파일을 과도하게 압축하지 마세요. 대부분의 유전체학 형식은 “gzip” 또는 “block gzip” 압축을 사용합니다. 작업 입력 파일을 압축 해제하고 작업 출력 파일을 다시 압축하면 전체 작업 CPU 사용량의 많은 비율을 소비할 수 있습니다. 일부 유전체 애플리케이션에서는 출력을 직렬화할 때 압축 수준을 설정할 수 있습니다. 압축 수준을 줄이면 CPU 시간을 줄일 수 있지만 파일이 클수록 디스크에 쓰는 데 걸리는 시간이 늘어납니다. 작업 및 애플리케이션에 따라 실행 시간이 가장 짧은 중간 파일에 대한 최적의 압축 수준을 찾을 수 있습니다. 먼저 출력 파일이 가장 큰 태스크를 대상으로 지정하는 것이 좋습니다. 압축 수준이 2이면 여러 시나리오에 적합합니다. 사용 사례에 대해이 수준으로 시작하고 다른 압축 수준을 시도하여 결과를 비교할 수 있습니다.
- 스레드 수
-
작업 정의에서 스레드를 지정하는 경우 스레드 수를 요청된 vCPUs 수와 동일한 값으로 설정합니다.
- 컴퓨팅 및 메모리 지정
-
작업에서 메모리 또는 컴퓨팅 리소스를 지정하지 않으면 HealthOmics는 가장 작은 인스턴스 유형(
omics.c.large
)을 기본 로 할당합니다. HealthOmics에서 더 큰 인스턴스 유형을 할당하도록 하려면 메모리 및 컴퓨팅 요구 사항을 명시적으로 선언합니다.HealthOmics는 사용자가 요청하는 vCPUs, 메모리 및 GPU 리소스 수를 할당합니다. 예를 들어 15vCPUs 및 33GiB를 요청하면 HealthOmics는 작업에 omics.m.4xl 인스턴스(16vCPUs, 64GB)를 할당하지만 작업은 15개의 vCPUs와 33GiB만 사용할 수 있습니다. 따라서 omics 인스턴스와 일치하는 vCPUs 및 메모리 리소스를 요청하는 것이 좋습니다.
- 여러 샘플을 한 번의 실행으로 일괄 처리
-
파일 시스템 프로비저닝은 실행 시작 시 시간이 걸리므로 여러 샘플을 동일한 실행으로 일괄 처리하여 프로비저닝 시간을 절약할 수 있습니다. 이 접근 방식을 결정하기 전에 다음 요소를 고려하세요.
-
하나의 잘못된 샘플로 인해 워크플로가 실패할 수 있으므로 샘플을 일괄 처리하면 실패한 워크플로 수가 증가할 수 있습니다. 워크플로가 대부분 성공할 것이라고 확신하지 못하는 경우 샘플당 하나의 실행이 더 나은 접근 방식이 될 수 있습니다.
-
HealthOmics는 전체 워크플로에 하나의 실행 스토리지 파일 시스템을 할당합니다. 샘플 배치의 경우 모든 샘플을 처리하기에 충분한 양의 실행 스토리지를 지정해야 합니다.
-
워크플로당 최대 실행 스토리지 양이 있으므로가 배치에 추가할 수 있는 샘플 수를 제한할 수 있습니다.
-
최소 실행 스토리지 크기는 1.2TiB이므로 워크플로에서 각 샘플의 최소 스토리지보다 훨씬 적은 스토리지를 사용하는 경우 일괄 처리로 인해 비용이 절감될 수 있습니다.
-
실행 스토리지는 여러 동시 연결을 처리할 수 있으므로 동일한 실행 스토리지를 사용하는 여러 작업이 있더라도 I/O 병목 현상이 발생하지 않습니다.
-
각 실행에는 고유한 태그 세트가 있습니다. 예산 책정 또는 추적을 위한 정보로 워크플로에 태그를 지정하는 경우 별도의 실행을 사용하는 것이 더 좋을 수 있습니다.
-
IAM 역할은 전체 실행에 적용됩니다. 각 사용자는 샘플 배치의 모든 데이터에 액세스할 수 있습니다. 워크플로를 분리하면 더 세분화된 권한을 사용할 수 있습니다.
-
HealthOmics는 최대 동시 워크플로 수와 워크플로의 최대 동시 작업 수에 대한 계정 수준 할당량을 설정합니다. 이러한 할당량 증가를 요청하는 방법에 대한 자세한 내용은 섹션을 참조하세요HealthOmics 서비스 할당량.
-
- 컨테이너 이미지에 파라미터 사용
-
워크플로에 URIs 포함하는 대신 컨테이너 이미지를 파라미터화합니다. 실행 파라미터인 경우 HealthOmics는 실행이 시작되기 전에 실행이 컨테이너에 액세스할 수 있는지 확인합니다. 그렇지 않으면 완료된 작업에 대해 요금이 발생했을 때 실행 중에 작업이 실패합니다. 또한 파라미터화된 입력이므로 HealthOmics는 실행 매니페스트에 체크섬을 생성하여 실행 출처를 개선합니다.
- 린터 사용
-
새 워크플로를 실행하기 전에 린터를 사용하여 일반적인 워크플로 오류를 찾습니다. 자세한 내용은 HealthOmics의 워크플로 린터 단원을 참조하십시오.
- EventBridge를 사용하여 문제에 플래그 지정
-
EventBridge 사용자 지정 알림을 사용하여 비즈니스 로직과 관련된 이상을 파악합니다.
- 시퀀스 스토어 사용
-
소스 데이터에 시퀀스 스토어를 사용하여 스토리지 비용을 절감하는 것이 좋습니다. 자세한 내용은 HealthOmics
.
실행 간 파일 크기 차이의 영향
사용자는 종종 작은 테스트 데이터 세트를 사용하여 실행을 설계하고 테스트한 다음 프로덕션 실행에서 파일 크기가 크게 달라지는 다양한 데이터를 접합니다. 실행을 최적화할 때이 차이를 고려해야 합니다.
다음 목록은 파일 크기에 상당한 차이가 있는 최적화를 위한 권장 사항을 설명합니다.
- 테스트 데이터의 다양한 파일 크기
-
개발 중에 대표적인 분산량이 있는 테스트 데이터를 사용하세요.
- Run Analyzer 사용
-
다양한 샘플에서 Run Analyzer 도구를 사용하여 데이터 크기의 차이를 고려하세요.
실행 분석기를 사용하여 프로덕션 데이터 샘플의 실행 간 차이를 이해할 수 있습니다. Run Analyzer에서
--batch
모드를 사용하여 실행 배치에 대한 통계를 생성하고 데이터 세트에서 이상값을 처리하는 데 필요한 최대 컴퓨팅 리소스를 분석합니다.예를 들어 실행 분석기에 배치 모드의 전체 데이터 흐름 셀을 제공하여 전체 흐름 셀의 최대 vCPU 및 메모리 사용률을 이해할 수 있습니다.
- 입력 데이터 세트의 크기 분산 감소
-
샘플 크기의 차이가 높으면 HealthOmics 업스트림의 샘플을 분기하고 각 배치에 대해 서로 다른 파일 시스템 크기를 선택하여 실행 스토리지 비용을 절감할 수 있습니다.
WDL에서
size
함수를 사용하여 대규모 샘플과 소규모 샘플의 개별 작업에 대한 리소스 할당을 분기합니다. 가장 많은 영향을 미치려면 가장 비용이 많이 드는 작업에이 전략을 적용합니다.Nextflow에서 파일 크기 또는 파일 이름을 기반으로 리소스 할당을 계층화하는 데 조건부 리소스를 사용합니다. 자세한 내용은 Nextflow GitHub 사이트의 조건부 프로세스 리소스를
참조하세요. - 너무 빨리 최적화하지 마세요.
-
상당한 성능 튜닝 노력에 투자하기 전에 워크플로 코드와 로직을 마무리합니다. 코드를 변경하면 필요한 리소스에 상당한 영향을 미칠 수 있습니다. 개발 프로세스에서 실행을 너무 빨리 최적화하는 경우 과도하게 최적화하거나 나중에 워크플로 정의가 변경되면 다시 최적화해야 할 수 있습니다.
- Run Analyzer 도구를 주기적으로 다시 실행
-
시간 경과에 따라 워크플로 정의를 변경하거나 샘플 분산이 변경되는 경우 주기적으로 Run Analyzer 도구를 실행하여 추가 최적화를 수행할 수 있습니다.
리소스 동시성을 최적화하는 방법
HealthOmics는 대규모 실행을 처리할 때 비용을 제어하고 관리하는 데 도움이 되는 다음과 같은 기능을 제공합니다.
-
실행 그룹을 사용하여 비용 및 리소스 사용량을 제어합니다. 동시 실행 수, vCPUs, GPUs 및 작업당 총 실행 시간에 대해 실행 그룹의 최대값을 설정할 수 있습니다. 별도의 팀 또는 그룹이 동일한 계정을 사용하는 경우 각 팀에 대해 별도의 실행 그룹을 생성할 수 있습니다. 실행 그룹 최대값을 구성하여 팀당 리소스 사용량과 비용을 제어할 수 있습니다. 자세한 내용은 HealthOmics 실행 그룹 생성 단원을 참조하십시오.
-
개발 중에 최대값이 더 낮은 별도의 실행 그룹을 구성하여 런어웨이 작업을 포착할 수 있습니다.
-
Service Quotas는 과도한 리소스 요청으로부터 계정을 보호하는 데도 도움이 됩니다. 할당량 값 증가를 요청하는 방법을 포함하여 Service Quotas에 대한 자세한 내용은 섹션을 참조하세요. HealthOmics 서비스 할당량