통화 캐싱 작동 방식 - AWS HealthOmics

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

통화 캐싱 작동 방식

통화 캐싱을 사용하려면 실행 캐시를 생성하고 캐시된 데이터에 연결된 Amazon S3 위치를 갖도록 구성합니다. 실행을 시작할 때 실행 캐시를 지정합니다. 실행 캐시는 하나의 워크플로에만 국한되지 않습니다. 여러 워크플로에서 실행되는는 동일한 캐시를 사용할 수 있습니다.

실행의 내보내기 단계에서 시스템은 완료된 작업 출력을 Amazon S3 위치로 내보냅니다. 중간 작업 파일을 내보내려면 워크플로 정의에서 이러한 파일을 작업 출력으로 선언합니다. 또한 호출 캐싱은 메타데이터를 내부적으로 저장하고 각 캐시 항목에 대해 고유한 해시를 생성합니다.

실행 중인 각 작업에 대해 워크플로 엔진은이 작업에 일치하는 캐시 항목이 있는지 여부를 감지합니다. 일치하는 캐시 항목이 없는 경우 HealthOmics는 작업을 계산합니다. 일치하는 캐시 항목이 있는 경우 엔진은 캐시된 결과를 검색합니다.

캐시 항목을 일치시키기 위해 HealthOmics는 기본 워크플로 엔진에 포함된 해싱 메커니즘을 사용합니다. HealthOmics는 이러한 기존 해시 구현을 확장하여 S3 eTags 및 ECR 컨테이너 다이제스트와 같은 HealthOmics 변수를 고려합니다.

HealthOmics는 다음 워크플로 언어 버전에 대한 통화 캐싱을 지원합니다.

  • WDL 버전 1.0, 1.1 및 개발 버전

  • Nextflow 버전 23.10 및 24.10

  • 모든 CWL 버전

참고

HealthOmics는 Ready2Run 워크플로에 대한 통화 캐싱을 지원하지 않습니다.

공동 책임 모델

작업과 실행이 통화 캐싱에 적합한 후보인지 AWS 확인하려면 사용자와 간에 공동 책임이 있습니다. 호출 캐싱은 모든 작업이 멱등성일 때 최상의 결과를 달성합니다(동일한 입력을 사용하여 작업을 반복 실행하면 동일한 결과가 생성됨).

그러나 작업에 비결정적 요소(예: 난수 생성 또는 시스템 시간)가 포함된 경우 동일한 입력을 사용하여 작업을 반복적으로 실행하면 출력이 다를 수 있습니다. 이는 다음과 같은 방법으로 통화 캐싱의 효과에 영향을 미칠 수 있습니다.

  • HealthOmics가 작업 실행이 현재 실행에 대해 생성하는 출력과 동일하지 않은 캐시 항목(이전 실행에서 생성)을 사용하는 경우, 실행은 캐싱 없이 동일한 실행과 다른 결과를 산출할 수 있습니다.

  • HealthOmics는 비결정적 작업 출력으로 인해 일치해야 하는 작업에 대해 일치하는 캐시 항목을 찾지 못할 수 있습니다. 유효한 캐시 항목을 찾지 못하면 실행이 작업을 불필요하게 다시 계산하므로 호출 캐싱 사용으로 인한 비용 절감 이점이 줄어듭니다.

다음은 통화 캐싱 결과에 영향을 미치는 비결정적 결과를 초래할 수 있는 알려진 작업 동작입니다.

  • 난수 생성기 사용.

  • 시스템 시간에 대한 종속성입니다.

  • 동시성 사용(레이스 조건은 출력 분산을 일으킬 수 있음).

  • 작업 입력 파라미터에 지정된 것 이상으로 로컬 또는 원격 파일을 가져옵니다.

비결정적 동작을 유발할 수 있는 다른 시나리오는 Nextflow 설명서 사이트의 비결정적 프로세스 입력을 참조하세요.

작업이 비결정적 출력을 생성한다고 의심되는 경우 비결정적 특정 작업을 캐싱하지 않도록 Nextflow의 캐시 옵트아웃과 같은 워크플로 엔진 기능을 사용하는 것이 좋습니다.

비효율적인 호출 캐싱 또는 예상과 다른 출력으로 인해 위험이 발생할 수 있는 환경에서 호출 캐싱을 활성화하기 전에 특정 워크플로 및 작업 요구 사항을 철저히 검토하는 것이 좋습니다. 예를 들어 호출 캐싱의 잠재적 제한 사항을 신중하게 고려하여 호출 캐싱이 임상 사용 사례에 적합한지 여부를 결정해야 합니다.

작업에 대한 캐싱 요구 사항

HealthOmics는 다음 요구 사항을 충족하는 작업에 대한 작업 출력을 캐싱합니다.

  • 작업은 컨테이너를 정의해야 합니다. HealthOmics는 컨테이너가 없는 작업의 출력을 캐싱하지 않습니다.

  • 작업은 하나 이상의 출력을 생성해야 합니다. 워크플로 정의에서 작업 출력을 지정합니다.

  • 워크플로 정의는 동적 값을 사용해서는 안 됩니다. 예를 들어 실행마다 값이 증가하는 작업에 파라미터를 전달하면 HealthOmics는 작업 출력을 캐싱하지 않습니다.

참고

한 실행에서 여러 작업이 동일한 컨테이너 이미지를 사용하는 경우 HealthOmics는 이러한 모든 작업에 동일한 이미지 버전을 제공합니다. HealthOmics가 이미지를 가져온 후에는 실행 기간 동안 컨테이너 이미지에 대한 모든 업데이트를 무시합니다. 이 접근 방식은 예측 가능하고 일관된 경험을 제공하며 실행 중 배포된 컨테이너 이미지 업데이트로 인해 발생할 수 있는 잠재적 문제를 방지합니다.

캐시 성능 실행

실행에 대한 호출 캐싱을 켜면 실행 성능에 다음과 같은 영향을 미칠 수 있습니다.

  • 첫 번째 실행 중에 HealthOmics는 실행 중인 작업에 대한 캐시 데이터를 저장합니다. 호출 캐싱은 내보내기 데이터의 양을 증가시키기 때문에이 실행의 내보내기 시간이 길어질 수 있습니다.

  • 후속 실행에서는 캐시에서 실행을 재개할 때 처리 단계 수를 줄이고 실행 시간을 줄일 수 있습니다.

  • 중간 파일도 출력으로 선언하도록 선택하면이 데이터가 더 상세할 수 있으므로 내보내기 시간이 더 길어질 수 있습니다.

캐시 데이터 보존 및 무효화 이벤트

실행 캐시의 주요 목적은 실행 중인 작업의 계산을 최적화하는 것입니다. 작업에 유효한 일치하는 캐시 항목이 있는 경우 HealthOmics는 작업을 다시 계산하는 대신 캐시 항목을 사용합니다. 그렇지 않으면 HealthOmics는 기본 서비스 동작으로 되돌아갑니다. 기본 서비스 동작은 작업과 해당 종속 작업을 다시 계산하는 것입니다. 이 접근 방식을 사용하면 캐시 누락으로 인해 실행이 실패하지 않습니다.

실행 캐시 크기를 관리하는 것이 좋습니다. 시간이 지남에 따라 워크플로 엔진 또는 HealthOmics 서비스 업데이트 또는 실행 또는 실행 작업의 변경으로 인해 캐시 항목이 더 이상 유효하지 않을 수 있습니다. 다음 섹션에서는 추가 세부 정보를 제공합니다.

매니페스트 버전 업데이트 및 데이터 최신성

HealthOmics 서비스는 주기적으로 일부 또는 모든 실행 캐시 항목을 무효화하는 새로운 기능 또는 워크플로 엔진 업데이트를 도입할 수 있습니다. 이 경우 실행에 일회성 캐시 누락이 발생할 수 있습니다.

HealthOmics는 각 캐시 항목에 대해 JSON 매니페스트 파일을 생성합니다. 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로 설정하여 실행을 한 번 시작합니다. 이 실행은 새 캐시 항목을 생성합니다.

  2. 후속 실행의 경우 캐시 보존을 이전 설정(CACHE Always 또는 CACHE ON FAILURE)으로 설정합니다.

더 이상 유효하지 않은 캐시 항목을 정리하려면 캐시 Amazon S3 버킷에서 이러한 캐시 항목을 삭제하면 됩니다. HealthOmics는 이러한 캐시 항목을 재사용하지 않습니다. 유효하지 않은 항목을 보존하도록 선택하면 실행에 영향을 주지 않습니다.

참고

호출 캐싱은 캐시에 지정된 Amazon S3 위치에 작업 출력 데이터를 저장하므로 요금이 발생합니다 AWS 계정.

캐시 동작 실행

실행 캐시 동작을 설정하여 실패한 실행(실패 시 캐시) 또는 모든 실행(항상 캐시)에 대한 작업 출력을 저장할 수 있습니다. 실행 캐시를 생성할 때이 캐시를 사용하는 모든 실행에 대해 기본 캐시 동작을 설정합니다. 실행을 시작할 때 기본 동작을 재정의할 수 있습니다.

Cache on failure는 여러 작업이 성공적으로 완료된 후 실패하는 워크플로를 디버깅하는 경우에 유용합니다. 해시에서 고려하는 모든 고유 변수가 이전 실행과 동일한 경우 마지막으로 성공적으로 완료된 작업에서 후속 실행이 재개됩니다.

Cache always는 워크플로에서 작업이 성공적으로 완료되는 경우 유용합니다. 다음 단계를 따르는 것이 좋습니다.

  1. 새 실행을 생성합니다. 캐시 동작을 항상 캐시로 설정하고 실행을 시작합니다.

  2. 실행이 완료되면 워크플로에서 작업을 업데이트하고 항상 캐시 동작 세트로 새 실행을 시작합니다. 이 실행은 업데이트된 작업과 업데이트된 작업에 종속된 후속 작업을 처리합니다. 다른 모든 작업은 캐시된 결과를 사용합니다.

  3. 업데이트된 작업에 대한 개발이 완료될 때까지 필요에 따라 2단계를 반복합니다.

  4. 향후 실행 시 필요에 따라 업데이트된 작업을 사용합니다. 이러한 실행에 새 입력이나 다른 입력을 사용하려는 경우 후속 실행을 실패 시 캐시로 전환해야 합니다.

참고

동일한 테스트 데이터 세트를 사용하는 동안에는 캐시를 항상 모드로 설정하는 것이 좋지만 실행 배치에는 사용하지 않는 것이 좋습니다. 대량의 실행에 대해이 모드를 설정하면 시스템에서 대량의 데이터를 Amazon S3로 내보낼 수 있으므로 내보내기 시간과 스토리지 비용이 늘어날 수 있습니다.

컨트롤 실행 캐시 크기

HealthOmics는 실행 캐시 데이터를 삭제하거나 자동 보관하거나 캐시 데이터 관리를 위한 Amazon S3 정리 규칙을 적용하지 않습니다. Amazon S3 스토리지 비용을 절감하고 실행 캐시 크기를 관리할 수 있도록 정기적인 캐시 정리를 수행하는 것이 좋습니다. 파일을 직접 삭제하거나 실행 캐시 버킷에서 데이터 보존/복제 정책을 설정할 수 있습니다.

예를 들어 90일 후에 객체를 만료하도록 Amazon S3 수명 주기 정책을 구성하거나 각 개발 프로젝트가 끝날 때 캐시 데이터를 수동으로 정리할 수 있습니다.

다음 정보는 캐시 데이터 크기를 관리하는 데 도움이 될 수 있습니다.

  • Amazon S3를 확인하여 캐시에 있는 데이터의 양을 확인할 수 있습니다. HealthOmics는 캐시 크기를 모니터링하거나 보고하지 않습니다.

  • 유효한 캐시 항목을 삭제해도 후속 실행은 실패하지 않습니다. HealthOmics는 작업과 해당 종속 작업을 다시 계산합니다.

  • HealthOmics가 작업에 대해 일치하는 항목을 찾을 수 없도록 캐시 이름 또는 디렉터리 구조를 수정하면 HealthOmics가 작업을 다시 계산합니다.

캐시 항목이 여전히 유효한지 확인해야 하는 경우 캐시 매니페스트 버전 번호를 확인합니다. 자세한 내용은 매니페스트 버전 업데이트 및 데이터 최신성 단원을 참조하십시오.