Azure Batch 모범 사례

아티클
04/02/2024

이 문서에서는 Azure Batch 서비스를 효과적이고 사용하기 위한 모범 사례와 유용한 팁에 대해 설명합니다. 이러한 팁은 Batch 솔루션에서 성능을 향상시키고 디자인 문제를 방지하는 데 유용합니다.

팁

Azure Batch의 보안 관련 지침은 Batch 보안 및 규정 준수 모범 사례를 참조하세요.

풀

풀은 Batch 서비스에서 작업을 실행하기 위한 컴퓨팅 리소스입니다. 다음 섹션에서는 Batch 풀 작업에 대한 추천 사항을 제공합니다.

풀 구성 및 이름 지정

풀 할당 모드: Batch 계정을 만들 때 Batch 서비스 또는 사용자 구독의 두 가지 풀 할당 모드 중에서 선택할 수 있습니다. 대부분의 경우 풀이 Batch 관리형 구독에서 내부적으로 할당되는 기본 Batch 서비스를 사용해야 합니다. 대체 사용자 구독 모드인 경우 Batch VM 및 기타 리소스는 풀이 만들어질 때 구독에서 직접 만들어집니다. 사용자 구독 계정은 주로 시나리오의 작지만 중요한 하위 집합을 사용하도록 설정하는 데 사용됩니다. 자세한 내용은 사용자 구독 모드에 대한 구성을 참조하세요.
virtualMachineConfiguration 또는 cloudServiceConfiguration: 현재 두 구성 중 하나를 사용하여 풀을 만들 수 있지만 새 풀은 cloudServiceConfiguration이 아닌 virtualMachineConfiguration을 사용하여 구성해야 합니다. Batch의 모든 현재 및 새 기능은 가상 머신 구성 풀에서 지원됩니다. 클라우드 서비스 구성 풀은 모든 기능을 지원하지 않으며 새로운 기능도 계획되어 있지 않습니다. 2024년 2월 29일 이후에는 새 cloudServiceConfiguration 풀을 만들거나 기존 풀에 새 노드를 추가할 수 없습니다. 자세한 내용은 Cloud Services에서 Virtual Machine으로 Batch 풀 구성 마이그레이션을 참조하세요.
classic 또는 simplified 노드 통신 모드: 풀은 클래식 또는 단순화의 두 가지 노드 통신 모드 중 하나로 구성할 수 있습니다. 클래식 노드 통신 모델에서 Batch 서비스는 컴퓨팅 노드에 대한 통신을 시작하고 컴퓨팅 노드도 Azure Storage와 통신해야 합니다. 단순화된 노드 통신 모델에서 컴퓨팅 노드는 Batch 서비스와의 통신을 시작합니다. 필요한 인바운드/아웃바운드 연결 범위가 줄어들고 기본 작업에 Azure Storage 아웃바운드 액세스가 필요하지 않기 때문에 단순화된 노드 통신 모델을 사용하는 것이 좋습니다. Batch 서비스의 일부 향후 개선 사항에는 단순화된 노드 통신 모델도 필요합니다. 클래식 노드 통신 모델은 2026년 3월 31일에 사용 중지됩니다.
작업 및 태스크 실행 시간 고려 사항: 주로 단기 실행 태스크로 구성된 작업이 있고 예상 총 태스크 수가 작으므로 전체 예상 작업 런타임이 길지 않은 경우 새 풀을 각 작업에 할당하지 않습니다. 노드의 할당 시간은 작업 실행 시간을 줄입니다.
여러 컴퓨팅 노드: 개별 노드가 항상 사용 가능한 것은 아닙니다. 흔치 않은 경우이지만 하드웨어 오류, 운영 체제 업데이트 및 기타 여러 가지 문제로 인해 개별 노드가 오프라인 상태가 될 수 있습니다. Batch 워크로드에 결정적이고 보장된 진행률이 필요한 경우 여러 노드가 있는 풀을 할당해야 합니다.
수명 종료(EOL) 날짜가 임박한 이미지: Batch 지원 수명 종료(EOL) 날짜가 임박한 이미지는 사용하지 않는 것이 좋습니다. 해당 날짜는 ListSupportedImages API, PowerShell 또는 Azure CLI를 통해 검색할 수 있습니다. 풀에 해당하는 EOL 날짜의 보기를 정기적으로 새로 고치고 EOL 날짜가 되기 전에 워크로드를 마이그레이션하는 것은 사용자의 책임입니다. 지정된 노드 에이전트에서 사용자 지정 이미지를 사용하는 경우 사용자 지정 이미지가 파생되거나 정렬된 이미지에 대한 Batch 지원 수명 종료(EOL) 날짜를 준수해야 합니다. 지정된 batchSupportEndOfLife 날짜가 없는 이미지는 해당 날짜가 Batch 서비스에서 아직 결정되지 않았음을 나타냅니다. 날짜가 없다고 해서 해당 이미지가 무기한 지원된다는 의미는 아닙니다. EOL 날짜는 향후 언제든지 추가되거나 업데이트될 수 있습니다.
EOL(수명 종료) 날짜가 임박한 VM SKU: VM 이미지와 마찬가지로 VM SKU 또는 제품군도 Batch 지원 EOL(수명 종료)에 도달할 수 있습니다. 해당 날짜는 ListSupportedVirtualMachineSkus API, PowerShell 또는 Azure CLI를 통해 검색할 수 있습니다. 적절하게 지원되는 VM SKU가 포함된 새 풀을 만들어 워크로드를 EOL VM이 아닌 SKU로 마이그레이션하도록 계획합니다. VM SKU에 연결된 batchSupportEndOfLife 날짜가 없다고 해서 특정 VM SKU가 무기한 지원된다는 의미는 아닙니다. EOL 날짜는 향후 언제든지 추가되거나 업데이트될 수 있습니다.
고유한 리소스 이름: Batch 리소스(작업, 풀 등)는 시간이 지남에 따라 변하는 경우가 많습니다. 예를 들어 월요일에 풀을 만들고, 화요일에 풀을 삭제한 다음, 목요일에 더 작은 다른 풀을 만들 수 있습니다. 새로 만드는 각 리소스에는 이전에 사용하지 않은 고유한 이름을 지정해야 합니다. GUID(전체 리소스 이름 또는 일부로)를 사용하거나 리소스 이름에 리소스가 만들어진 날짜 및 시간을 포함하여 고유성을 만들 수 있습니다. Batch는 DisplayName을 지원합니다. 이를 통해 실제 리소스 ID가 그다지 친숙하지 않은 경우에도 리소스에 읽기 가능한 이름을 지정할 수 있습니다. 고유한 이름을 사용하면 로그 및 메트릭에서 작업을 수행한 특정 리소스를 쉽게 구분할 수 있습니다. 또한 리소스에 대한 지원 사례를 제출해야 하는 경우 모호성도 제거됩니다.
풀 유지 관리 및 실패 시 연속성: 작업에서 풀을 동적으로 사용하도록 하는 것이 가장 좋습니다. 작업에서 동일한 풀을 모든 대상에 사용하는 경우 풀에 문제가 있으면 작업이 실행되지 않을 수 있습니다. 이 원칙은 시간에 중요한 워크로드에 있어 특히 중요합니다. 예를 들어, 각 작업을 예약할 때 풀을 동적으로 선택하거나 만들거나, 비정상 풀을 무시할 수 있도록 풀 이름을 재정의하는 방법을 사용합니다.
풀 유지 관리 및 실패 시 비즈니스 연속성: 내부 오류, 용량 제약 조건 등과 같이 풀이 필요한 크기로 조정되지 않도록 하는 여러 가지 원인이 있습니다. 필요한 경우 다른 풀(UpdateJob을 사용하여 다른 VM 크기 가능)에서 작업 대상을 재지정할 수 있는지 확인합니다. 정적 풀 ID는 절대로 삭제되거나 변경되지 않는다는 가정 하에 사용하지 않도록 합니다.

풀 보안

격리 경계

격리를 위해 시나리오에서 작업 및 태스크를 서로 격리해야 하는 경우 이 작업은 별도의 풀에 배치하여 수행합니다. 풀은 Batch의 보안 격리 경계이며, 기본적으로 두 개의 풀이 표시되지 않거나 서로 통신할 수 없습니다. 배치 계정이 작동하는 대규모 환경에서 격리가 필요한 경우가 아니면 보안 격리 수단으로 별도의 배치 계정을 사용하지 마세요.

Batch 노드 에이전트 업데이트

0이 아닌 컴퓨팅 노드가 있는 풀에 대해서는 Batch 노드 에이전트가 자동으로 업그레이드되지 않습니다. Batch 풀이 Batch 노드 에이전트에 대한 최신 보안 수정 및 업데이트를 수신하도록 하려면 풀 크기를 0개의 컴퓨팅 노드로 조정하거나 풀을 다시 만들어야 합니다. 새 Batch 노드 에이전트 버전의 변경 사항을 이해하려면 Batch 노드 에이전트 릴리스 정보를 모니터링하는 것이 좋습니다. 릴리스된 업데이트를 정기적으로 확인하면 최신 에이전트 버전으로의 업그레이드를 계획할 수 있습니다.

풀을 다시 만들거나 크기를 조정하기 전에 Batch 풀 또는 컴퓨팅 노드에 문제가 있는 경우 디버깅 목적으로 노드 에이전트 로그를 다운로드해야 합니다. 이 프로세스는 노드 섹션에서 자세히 설명합니다.

참고 항목

Azure Batch의 보안에 대한 일반적인 지침은 Batch 보안 및 규정 준수 모범 사례를 참조하세요.

운영 체제 업데이트

Batch 풀에 대해 선택된 VM 이미지는 게시자가 제공한 최신 보안 업데이트로 최신 상태여야 합니다. 일부 이미지는 부팅 시(또는 그 직후) 자동 업데이트를 수행할 수 있으며, 이는 패키지 리포지토리 업데이트 검색(예: apt update) 또는 StartTask와 같은 작업 중 패키지 설치와 같은 특정 사용자 지정 작업을 방해할 수 있습니다.

Azure Batch는 서비스에 사용할 수 있는 이미지에 최신 보안 업데이트가 있는지 확인하거나 보장하지 않습니다. 이미지 업데이트는 Azure Batch가 아닌 이미지 게시자의 권한에 속합니다. microsoft-azure-batch에 게시된 특정 이미지의 경우 이러한 이미지가 업스트림 파생 이미지로 최신 상태로 유지된다는 보장이 없습니다.

풀 수명 및 청구

풀 수명은 풀 구성에 적용되는 할당 방법 및 옵션에 따라 달라질 수 있습니다. 풀의 수명은 임의로 지정할 수 있으며, 컴퓨팅 노드 수는 언제든지 달라질 수 있습니다. 사용자가 풀의 컴퓨팅 노드를 명시적으로 관리하거나 서비스에서 제공하는 기능(자동 스케일링 또는 자동 풀)을 통해 관리해야 합니다.

풀 다시 만들기: 매일 수영장을 삭제하고 다시 만들지 않도록 합니다. 대신 새 풀을 만들고 기존 작업에서 새 풀을 가리키도록 업데이트합니다. 모든 태스크가 새 풀로 이동되었으면 이전 풀을 삭제합니다.
풀 효율성 및 청구: Batch 자체에는 추가 요금이 발생하지 않습니다. 그러나 Batch 워크로드에 필요할 수 있는 컴퓨팅, 스토리지, 네트워킹 및 기타 리소스와 같이 활용되는 Azure 리소스에 대해서는 요금이 청구됩니다. 상태에 관계없이 풀의 모든 컴퓨팅 노드에 대해 요금이 청구됩니다. 자세한 내용은 Azure Batch 비용 분석 및 예산을 참조하세요.
임시 OS 디스크: Virtual Machine 구성 풀은 관리 디스크와 관련된 추가 비용을 방지하기 위해 VM 캐시 또는 임시 SSD에 OS 디스크를 만드는 임시 OS 디스크를 사용할 수 있습니다.

풀 할당 실패

풀 할당 실패는 첫 번째 할당 또는 후속 크기 조정 중에 언제든지 발생할 수 있습니다. 이러한 오류는 지역의 일시적인 용량 부족 또는 Batch가 의존하는 다른 Azure 서비스의 오류로 인해 발생할 수 있습니다. 핵심 할당량은 보장이 아니라 제한입니다.

계획되지 않은 가동 중지 시간

Batch 풀에서 Azure의 가동 중지 시간 이벤트를 경험할 수 있습니다. 문제가 발생할 수 있다는 점을 이해하고 재실행에 대한 복원력을 갖도록 워크플로를 개발해야 합니다. 노드가 실패하면 Batch에서 자동으로 사용자를 대신하여 이러한 컴퓨팅 노드를 복구하려고 시도합니다. 이 복구는 복원된 노드 또는 사용 가능한 다른 노드에서 실행 중인 모든 작업의 일정 재조정을 트리거할 수 있습니다. 중단되는 태스크에 대한 자세한 내용은 다시 시도 디자인을 참조하세요.

사용자 지정 이미지 풀

Virtual Machine 구성을 사용하여 Azure Batch 풀을 만들 경우 풀에서 각 컴퓨팅 노드에 대해 운영 체제를 제공하는 VM 이미지를 지정합니다. 지원되는 Azure Marketplace 이미지로 풀을 만들거나 Azure Compute Gallery 이미지를 사용하여 사용자 지정 이미지를 만들 수 있습니다. 관리형 이미지를 사용하여 사용자 지정 이미지 풀을 만들 수도 있지만 가능하면 항상 Azure Compute Gallery를 사용하여 사용자 지정 이미지를 만드는 것이 좋습니다. Azure Compute Gallery를 사용하면 풀을 더 빠르게 프로비전하고, 더 많은 수의 VM을 스케일링하고, VM을 프로비전할 때 안정성을 개선할 수 있습니다.

타사 이미지

Azure Marketplace에 게시된 타사 이미지를 사용하여 풀을 만들 수 있습니다. 사용자 구독 모드 Batch 계정을 사용하면 특정 타사 이미지를 사용하여 풀을 만들 때 "Marketplace 구매 자격 확인으로 인해 할당하지 못했습니다."라는 오류가 표시될 수 있습니다. 이 오류를 해결하려면 이미지 게시자가 설정한 약관에 동의합니다. 이 작업은 Azure PowerShell 또는 Azure CLI를 사용하여 수행할 수 있습니다.

Azure 지역 종속성

시간이 중요한 워크로드 또는 프로덕션 워크로드가 있는 경우 단일 Azure 지역에 의존하지 않아야 합니다. 흔치 않은 경우이지만 전체 지역에 영향을 줄 수 있는 문제가 있습니다. 예를 들어 처리를 특정 시간에 시작해야 하는 경우 시작 시간 훨씬 전에 주 지역의 풀 크기를 강화하는 것이 좋습니다. 풀 크기 조정이 실패하면 하나 이상의 백업 지역에서 풀 크기를 강화하는 것으로 대체할 수 있습니다.

다른 풀에서 문제가 발생하면 다른 지역의 여러 계정에 걸쳐 있는 풀에서 쉽게 액세스할 수 있는 준비된 백업을 제공합니다. 자세한 내용은 고가용성 애플리케이션 디자인을 참조하세요.

작업

작업은 수백, 수천, 심지어 수백만 개의 태스크를 포함하도록 설계된 컨테이너입니다. 작업을 만드는 경우 다음 지침을 따릅니다.

더 적은 작업, 더 많은 태스크

작업을 사용하여 단일 태스크를 실행하는 것은 비효율적입니다. 예를 들어 각각 10개의 태스크가 포함된 100개의 작업을 만드는 대신 1,000개의 태스크가 포함된 단일 작업을 사용하는 것이 더 효율적입니다. 1,000개의 작업을 사용한 경우 각각 단일 작업이 있는 작업은 가장 비효율적이고 느리며 가장 비용이 많이 드는 방식입니다.

수천 개의 동시 활성 작업이 필요한 Batch 솔루션을 설계하지 마세요. 태스크에 대한 할당량이 없으므로 가능한 한 적은 수의 작업에서 많은 태스크를 실행하면 작업 및 작업 일정 할당량을 효율적으로 사용할 수 있습니다.

작업 수명

Batch 작업의 수명은 시스템에서 해당 작업이 삭제될 때까지 무한합니다. 해당 상태는 더 많은 태스크를 예약할 수 있는지 여부를 나타냅니다.

작업은 명시적으로 종료되지 않는 한 자동으로 완료 상태로 이동하지 않습니다. 이 작업은 onAllTasksComplete 속성 또는 maxWallClockTime을 통해 자동으로 트리거될 수 있습니다.

기본 활성 작업 및 작업 일정 할당량이 있습니다. 완료 상태의 작업 및 작업 일정은 이 할당량에 포함되지 않습니다.

작업이 완료된 상태에서도 더 이상 필요하지 않은 경우 작업을 삭제합니다. 완료된 작업은 활성 작업 할당량에 포함되지 않지만 완료된 작업을 주기적으로 정리하는 것이 좋습니다. 예를 들어 작업 총 작업 수가 더 작은 세트일 때(요청에 적절한 필터가 적용되는 경우에도) 작업 나열이 더 효율적입니다.

작업

태스크는 작업을 구성하는 개별 활동 단위입니다. 태스크는 사용자가 제출하고 Batch에서 컴퓨팅 노드에 예약합니다. 다음 섹션에서는 문제를 처리하고 효율적으로 수행할 수 있도록 태스크를 디자인하기 위한 제안 사항을 제공합니다.

태스크 데이터 저장

컴퓨팅 노드는 기본적으로 사용 후에 삭제됩니다. 자동 풀, 자동 스케일링과 같은 Batch 기능을 사용하면 노드를 쉽게 숨길 수 있습니다. 크기 조정 또는 풀 삭제로 인해 노드가 풀을 벗어나면 해당 노드의 모든 파일도 삭제됩니다. 이 동작으로 인해 작업은 완료되기 전에 실행 중인 노드에서 내구성 있는 저장소로 출력을 이동해야 합니다. 마찬가지로, 태스크가 실패하면 실패를 진단하는 데 필요한 로그를 지속형 저장소로 이동해야 합니다.

Batch는 OutputFiles 및 다양한 공유 파일 시스템을 통해 데이터를 업로드하기 위해 Azure Storage 지원을 통합했습니다. 또는 작업에서 직접 업로드를 수행할 수 있습니다.

태스크 수명 관리

태스크가 더 이상 필요하지 않은 경우 삭제하거나 retentionTime 태스크 제약 조건을 설정합니다. retentionTime이 설정되면 retentionTime이 만료될 때 태스크에서 사용한 디스크 공간을 Batch에서 자동으로 정리합니다.

태스크를 삭제하는 경우 두 가지 작업이 수행됩니다.

작업에 태스크가 쌓이지 않도록 합니다. 이 작업은 완료된 태스크를 필터링해야 하므로 관심 있는 작업을 찾는 데 어려움을 겪는 것을 방지하는 데 도움이 됩니다.
노드에서 해당 작업 데이터를 정리합니다(retentionTime이 아직 다가오지 않은 경우). 이 작업은 노드가 태스크 데이터로 꽉 차지 않고 디스크 공간이 부족하지 않도록 하는 데 도움이 됩니다.

참고 항목

방금 Batch에 제출된 작업의 경우 DeleteTask API 호출이 적용되는 데 최대 10분이 걸립니다. 적용되기 전에 다른 작업이 예약되지 않을 수 있습니다. Batch Scheduler가 방금 삭제한 작업을 계속 예약하려고 하기 때문입니다. 작업이 제출된 직후에 하나의 작업을 삭제하려면 대신 작업을 종료하세요(작업 종료 요청은 즉시 적용되므로). 그런 다음 10분 후에 작업을 삭제합니다.

많은 수의 태스크를 컬렉션에 제출

태스크는 개별 기준 또는 컬렉션 단위에 제출할 수 있습니다. 오버헤드 및 제출 시간을 줄이기 위해 태스크를 대량으로 제출하는 경우 한 번에 최대 100개의 태스크를 컬렉션에 제출할 수 있습니다.

노드당 최대 태스크 수를 적절하게 설정

Batch는 노드에 대한 과도한 구독 태스크를 지원합니다(노드에 있는 코어 수보다 더 많은 작업을 실행함). 태스크가 풀의 노드에 적합한 크기인지 확인하는 것은 사용자에게 달려 있습니다. 예를 들어 각각 하나의 노드에서 25%의 CPU 사용량을 소비하는 8개의 태스크를 예약하려고 하면(taskSlotsPerNode = 8인 풀의 경우) 성능이 저하될 수 있습니다.

다시 시도 및 다시 실행 디자인

Batch는 태스크를 자동으로 다시 시도할 수 있습니다. 사용자 제어 다시 시도 및 내부 다시 시도의 두 가지 유형이 있습니다. 사용자 제어 다시 시도는 태스크의 maxTaskRetryCount로 지정됩니다. 태스크에 지정된 프로그램이 0이 아닌 종료 코드를 사용하여 종료되면 태스크가 maxTaskRetryCount 값까지 다시 시도됩니다.

흔치 않은 경우이지만 태스크가 실행되는 동안 내부 상태를 업데이트할 수 없거나 노드에 오류가 발생하는 것과 같이 컴퓨팅 노드의 오류로 인해 태스크를 내부적으로 다시 시도할 수 있습니다. 태스크를 포기하고 Batch(잠재적으로 다른 컴퓨팅 노드)에서 다시 예약할 태스크를 지연시키기 전에 가능한 경우 태스크는 내부 제한까지 동일한 컴퓨팅 노드에서 다시 시도됩니다.

전용 노드 또는 스폿 노드에서 태스크를 실행하는 경우 디자인상의 차이점이 없습니다. 우선 순위가 스폿 노드에서 실행되는 동안 태스크가 선점되든지, 아니면 전용 노드에서 발생한 오류로 인해 중단되든지 간에 두 상황은 모두 오류를 극복할 수 있도록 태스크를 설계함으로써 완화됩니다.

지속형 태스크 빌드

태스크는 오류를 극복하고 다시 시도를 수용할 수 있도록 설계되어야 합니다. 이 원칙은 장기 실행 태스크에 특히 중요합니다. 태스크가 두 번 이상 실행되더라도 동일한 단일 결과를 생성하는지 확인합니다. 이 결과를 구현하기 위한 한 가지 방법은 태스크를 “목표 검색”으로 만드는 것입니다. 또 다른 방법은 태스크가 idempotent(멱등원)인지 확인하는 것입니다(실행 횟수에 관계없이 태스크의 결과가 동일함).

일반적인 예로 파일을 컴퓨팅 노드에 복사하는 태스크가 있습니다. 간단한 방법은 실행될 때마다 지정된 모든 파일을 복사하는 태스크이지만, 이는 비효율적이고 오류를 극복할 수 있도록 구축되지 않습니다. 대신 파일이 컴퓨팅 노드에 있는지 확인하는 태스크, 즉 이미 있는 파일을 다시 복사하지 않는 태스크를 만듭니다. 이러한 방식으로 태스크가 중단되면 중단된 위치를 선택합니다.

단기 실행 시간 회피

1~2초 동안만 실행되는 태스크는 이상적이지 않습니다. 개별 태스크에서 많은 양의 활동을 수행합니다(최소 10초, 최대 시간 또는 일). 각 태스크가 1분 이상 실행되는 경우 전체 컴퓨팅 시간의 일부인 예약 오버헤드가 낮습니다.

Windows 노드에서 짧은 태스크에 풀 범위 사용

Batch 노드에서 태스크를 예약할 때 태스크 범위 또는 풀 범위를 사용하여 실행할지를 선택할 수 있습니다. 태스크가 짧은 시간 동안만 실행되는 경우 해당 태스크에 대한 자동 사용자 계정을 만드는 데 필요한 리소스로 인해 태스크 범위가 비효율적일 수 있습니다. 효율성을 높이기 위해 이러한 태스크를 풀 범위로 설정하는 것이 좋습니다. 자세한 내용은 풀 범위가 지정된 자동 사용자로 태스크 실행을 참조하세요.

노드

컴퓨팅 노드는 애플리케이션의 워크로드 중 일부를 처리하는 데 전적으로 사용되는 Azure VM(가상 머신) 또는 클라우드 서비스 VM입니다. 노드를 사용하는 경우 다음 지침을 따릅니다.

시작 태스크: 수명 및 멱등성

다른 태스크와 마찬가지로 시작 태스크 노드는 멱등적이어야 합니다. 컴퓨팅 노드가 다시 시작되거나 Batch 에이전트가 다시 시작될 때 시작 태스크가 다시 실행됩니다. idempotent 태스크는 여러 번 실행될 때 일관된 결과를 생성하는 태스크일 뿐입니다.

시작 태스크는 오래 실행되거나 컴퓨팅 노드의 수명에 결합되어서는 안 됩니다. 본질적으로 서비스이거나 서비스와 유사한 프로그램을 시작해야 하는 경우 Linux 또는 Windows 서비스 systemd 같은 운영 체제 기능에서 이러한 프로그램을 시작하고 관리할 수 있도록 하는 시작 태스크를 구성하세요. 이러한 프로그램이 이전에 서비스로 설치된 경우에도 시작 태스크의 후속 실행이 제대로 처리되도록 시작 태스크는 멱등적으로 구성되어야 합니다.

팁

Batch에서 시작 태스크를 다시 실행하면 시작 태스크 디렉터리를 삭제하고 다시 만들려고 시도합니다. Batch에서 시작 태스크 디렉터리를 다시 만들지 못하면 컴퓨팅 노드가 시작 태스크를 시작하지 못합니다.

이러한 서비스는 노드의 Batch 관리 디렉터리에 있는 파일에 대해 파일 잠금을 수행하면 안 됩니다. 파일 잠금으로 인해 Batch가 해당 디렉터리를 삭제할 수 없기 때문입니다. 예를 들어 시작 태스크 작업 디렉터리에서 직접 서비스 시작을 구성하는 대신 멱등적 방식으로 파일을 다른 곳에 복사합니다. 그런 다음 운영 체제 기능을 사용하여 해당 위치에서 서비스를 설치합니다.

격리된 노드

규정 준수 또는 규정 요구 사항을 준수하는 워크로드에 대해 격리된 VM 크기를 사용하는 것이 좋습니다. 가상 머신 구성 모드에서 지원되는 격리된 크기는 Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5Standard_GS5 및 Standard_E64i_v3입니다. 격리된 VM 크기에 대한 자세한 내용은 Azure의 가상 머신 격리를 참조하세요.

Windows에서 디렉터리 접합을 만들지 않음

디렉터리 접합(디렉터리 하드 링크라고도 함)은 태스크 및 작업 정리 중에 처리하기가 어렵습니다. 하드 링크 대신 symlink(소프트 링크)를 사용합니다.

임시 디스크 및 `AZ_BATCH_NODE_ROOT_DIR`

Batch는 Batch와 호환되는 VM 크기의 경우 VM 임시 디스크를 사용하여 이 임시 디스크에서 각 태스크 실행의 아티팩트와 함께 작업 실행과 관련된 메타데이터를 저장합니다. 이러한 임시 디스크 탑재 지점 또는 디렉터리의 예는 /mnt/batch, /mnt/resource/batch 및 D:\batch\tasks입니다. 바꾸기, 재탑재, 연결, symlinking 또는 이러한 탑재 지점 및 디렉터리 또는 부모 디렉터리의 리디렉션은 지원되지 않으며 불안정해질 수 있습니다. 더 많은 디스크 공간이 필요한 경우 요구 사항을 충족하는 임시 디스크 공간이 있는 VM 크기 또는 제품군을 사용하거나 데이터 디스크를 연결하는 것이 좋습니다. 자세한 내용은 컴퓨팅 노드용 데이터 디스크 연결 및 준비에 대한 다음 섹션을 참조하세요.

데이터 디스크 연결 및 준비

각 개별 컴퓨팅 노드에는 Batch 풀 인스턴스의 일부로 지정된 경우 완벽하게 동일한 데이터 디스크 사양이 연결됩니다. 새 데이터 디스크만 Batch 풀에 연결할 수 있습니다. 컴퓨팅 노드에 연결된 이러한 데이터 디스크는 자동으로 분할, 포맷 또는 탑재되지 않습니다. 시작 태스크의 일부로 이러한 작업을 수행하는 것은 사용자의 책임입니다. 이러한 시작 작업은 idempotent가 되도록 제작되어야 합니다. 컴퓨팅 노드에서 시작 태스크를 다시 실행할 수 있습니다. 시작 태스크가 멱등성이 아닌 경우 데이터 디스크에서 잠재적인 데이터 손실이 발생할 수 있습니다.

팁

Linux에서 데이터 디스크를 탑재할 때 /mnt 또는 /mnt/resource와 같은 Azure 임시 탑재 지점 아래에 디스크 탑재 지점을 중첩하는 경우 종속성 경쟁이 도입되지 않도록 주의해야 합니다. 예를 들어, 이러한 탑재가 OS에서 자동으로 수행되는 경우 탑재되는 임시 디스크와 부모 디스크 아래에 탑재되는 데이터 디스크 사이에 경합이 있을 수 있습니다. systemd와 같은 사용 가능한 기능으로 적절한 종속성을 적용하거나 멱등 데이터 디스크 준비 스크립트의 일부로 시작 작업에 대한 데이터 디스크 탑재를 연기하도록 조치를 취해야 합니다.

Linux Batch 풀에서 데이터 디스크 준비

Linux의 Azure 데이터 디스크는 블록 디바이스로 표시되며 일반적인 sd[X] 식별자가 할당됩니다. 정적 sd[X] 할당에 의존해서는 안 됩니다. 이러한 레이블은 부팅 시 동적으로 할당되고 첫 번째 부팅과 후속 부팅 간에 일관성이 보장되지 않기 때문입니다. /dev/disk/azure/scsi1/에 표시된 매핑을 통해 연결된 디스크를 식별해야 합니다. 예를 들어, AddPool API에서 데이터 디스크에 대해 LUN 0을 지정한 경우 이 디스크는 /dev/disk/azure/scsi1/lun0으로 매니페스트됩니다. 예를 들어, 이 디렉터리를 나열하면 잠재적으로 다음을 볼 수 있습니다.

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

준비 스크립트에서 참조를 다시 sd[X] 매핑으로 변환할 필요가 없으며 대신 디바이스를 직접 참조하세요. 이 예에서 이 디바이스는 /dev/disk/azure/scsi1/lun0입니다. 이 ID를 fdisk, mkfs 및 워크플로에 필요한 기타 도구에 직접 제공할 수 있습니다. 또는 blkid과(와) lsblk을(를) 함께 사용하여 디스크의 UUID를 매핑할 수 있습니다.

데이터 디스크를 찾는 대체 방법 및 /etc/fstab 옵션을 포함하여 Linux의 Azure 데이터 디스크에 대한 자세한 내용은 이 문서를 참조하세요. 메서드를 프로덕션 용도로 승격하기 전에 팁 노트에서 설명한 대로 종속성 또는 경합이 없는지 확인하세요.

Windows Batch 풀에서 데이터 디스크 준비

Batch Windows 컴퓨팅 노드에 연결된 Azure 데이터 디스크는 분할 및 포맷되지 않은 상태로 표시됩니다. 시작 태스크의 일부로 작업하려면 RAW 파티션이 있는 디스크를 열거해야 합니다. 이 정보는 Get-Disk PowerShell cmdlet을 사용하여 검색할 수 있습니다. 예를 들어, 잠재적으로 다음을 볼 수 있습니다.

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

여기서 디스크 번호 2는 이 컴퓨팅 노드에 연결된 초기화되지 않은 데이터 디스크입니다. 그런 다음 이러한 디스크는 워크플로에 필요한 대로 초기화, 분할 및 포맷할 수 있습니다.

샘플 PowerShell 스크립트를 포함하여 Windows의 Azure 데이터 디스크에 대한 자세한 내용은 이 문서를 참조하세요. 프로덕션으로 사용으로 승격하기 전에 모든 샘플 스크립트의 멱등성을 검증하세요.

Batch 에이전트 로그 수집

노드에서 실행되는 노드 또는 태스크의 동작과 관련된 문제가 있으면 해당 노드를 할당 취소하기 전에 Batch 에이전트 로그를 수집해야 합니다. Batch 에이전트 로그는 Batch 서비스 로그 업로드 API를 사용하여 수집할 수 있습니다. 이러한 로그는 지원 티켓의 일부로 Microsoft에 제공될 수 있으며 문제를 해결하는 데 도움이 됩니다.

OS 업그레이드 관리

사용자 구독 모드 Batch 계정에 대해 자동화된 OS 업그레이드는 특히 태스크가 장기간 실행되는 경우 태스크 진행을 방해할 수 있습니다. Idempotent 태스크를 빌드하면 이러한 중단으로 인해 발생하는 오류를 줄일 수 있습니다. 또한 태스크가 실행될 것으로 예상되지 않는 시간 동안 OS 이미지 업그레이드를 예약하는 것이 좋습니다.

Windows 풀의 경우 enableAutomaticUpdates는 기본적으로 true로 설정됩니다. 자동 업데이트를 허용하는 것이 좋지만 OS 업데이트가 예기치 않게 발생하지 않도록 하려면 이 값을 false로 설정할 수 있습니다.

Batch API

시간 제한 실패

시간 제한 오류가 반드시 서비스에서 요청을 처리하지 못했음을 나타내는 것은 아닙니다. 시간 제한 오류가 발생하면 작업을 다시 시도하거나 리소스의 상태를 상황에 맞게 검색하여 작업이 성공했는지 또는 실패했는지 여부를 확인해야 합니다.

연결

Batch 솔루션의 연결과 관련된 다음 지침을 검토합니다.

NSG(네트워크 보안 그룹) 및 UDR(사용자 정의 경로)

가상 네트워크에서 Batch 풀을 프로비전할 때 BatchNodeManagement.region 서비스 태그, 포트, 프로토콜 및 규칙 방향의 사용과 관련된 가이드라인을 철저히 따르고 있는지 확인합니다. 서비스 태그를 사용하는 것이 좋습니다. 기본 Batch 서비스 IP 주소는 시간이 경과함에 따라 변경될 수 있으므로 사용하지 마세요. Batch 서비스 IP 주소를 직접 사용하면 불안정성, 중단 또는 가동 중단이 Batch 풀에 발생할 수 있습니다.

UDR(사용자 정의 경로)의 경우 시간 경과에 따라 변경될 수 있으므로 Batch 서비스 IP 주소 대신 BatchNodeManagement.region서비스 태그를 사용하는 것이 좋습니다.

DNS 적용

시스템에서 DNS TTL(Time-to-Live)을 Batch 계정 서비스 URL에 적용해야 합니다. 또한 Batch 서비스 클라이언트 및 Batch 서비스에 대한 다른 연결 메커니즘에서 IP 주소를 사용하지 않도록 합니다.

응답의 "Connection: close" 헤더와 함께 5xx 수준 상태 코드가 있는 모든 HTTP 요청은 Batch 서비스 클라이언트 동작을 조정해야 합니다. Batch 서비스 클라이언트는 기존 연결을 닫고 Batch 계정 서비스 URL에 대한 DNS를 다시 확인한 뒤 새 연결에서 다음 요청을 시도하는 등 권장 사항을 준수해야 합니다.

자동으로 요청 다시 시도

Batch 서비스 클라이언트에는 서비스 유지 관리 기간 동안만이 아니라 정상 작업 중에도 요청을 자동으로 다시 시도할 수 있는 적절한 다시 시도 정책이 있어야 합니다. 이러한 다시 시도 정책에는 5분 이상의 간격이 적용되어야 합니다. 자동 다시 시도 기능은 .NET RetryPolicyProvider 클래스와 같은 다양한 Batch SDK와 함께 제공됩니다.

고정 공용 IP 주소

일반적으로 Batch 풀의 가상 머신은 풀의 수명 동안 변경될 수 있는 공용 IP 주소를 통해 액세스됩니다. 이러한 동적 특성으로 인해 특정 IP 주소에 대한 액세스를 제한하는 데이터베이스 또는 기타 외부 서비스와 상호 작용하기 어려울 수 있습니다. 이 문제를 해결하기 위해 제어하는 고정 공용 IP 주소 집합을 사용하여 풀을 만들 수 있습니다. 자세한 내용은 지정된 공용 IP 주소를 사용하여 Azure Batch 풀 만들기를 참조하세요.

Cloud Services 구성을 사용하여 연결 테스트

Azure Load Balancer를 통해 ICMP 프로토콜을 사용할 수 없기 때문에 클라우드 서비스에서 일반적인 "ping"/ICMP 프로토콜을 사용할 수 없습니다. 자세한 내용은 Azure Cloud Services에 대한 연결 및 네트워킹을 참조하세요.

Batch 노드 기본 종속성

Batch 솔루션을 설계하는 경우 고려해야 할 종속성 및 제한 사항은 다음과 같습니다.

시스템에서 만든 리소스

Azure Batch는 VM에서 사용자 및 그룹 세트를 만들고 관리합니다. 이러한 사용자 및 그룹 세트는 변경할 수 없습니다.

Windows:

PoolNonAdmin 사용자
WATaskCommon 사용자 그룹

Linux:

_azbatch 사용자

팁

이러한 사용자 또는 그룹의 이름 지정은 구현 아티팩트이며 언제든지 변경될 수 있습니다.

파일 정리

보존 시간이 만료되면 Batch에서 태스크가 실행되는 작업 디렉터리를 적극적으로 정리하려고 시도합니다. 이 디렉터리 외부에 작성된 파일은 디스크 공간을 채우지 않도록 사용자가 정리해야 합니다.

시작 태스크 작업 디렉터리에서 Windows의 서비스를 실행하는 경우 폴더가 아직 사용 중이므로 작업 디렉터리에 대한 자동화된 정리가 차단됩니다. 이 작업은 성능 저하로 이어집니다. 이 문제를 해결하려면 해당 서비스의 디렉터리를 Batch에서 관리하지 않는 별도의 디렉터리로 변경합니다.

다음 단계

풀, 노드, 작업 및 태스크와 같은 Batch 서비스 워크플로 및 기본 리소스에 대해 알아봅니다.
기본 Azure Batch 할당량, 한도 및 제약 조건에 대해 알아보고 할당량 증가를 요청하는 방법에 대해 알아봅니다.
풀 및 노드 백그라운드 작업에서 오류를 감지하고 방지하는 방법을 알아봅니다.