Azure Batch 안정성

Azure Batch Azure에서 대규모 병렬 및 HPC(고성능 컴퓨팅) 일괄 처리 작업을 실행합니다. Batch는 컴퓨팅 노드 풀을 만들고 관리하고, 실행하려는 애플리케이션을 설치하고, 노드에서 실행할 작업을 예약합니다.

Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.

이 문서에서는 Azure Batch를 일시적인 오류, 컴퓨팅 노드 오류, 가용성 영역 오류, 지역 전체 오류 및 서비스 유지 관리에 대해 복원력 있게 만드는 방법을 설명합니다. 또한 프로덕션 배포 권장 사항, Batch 안정성 아키텍처, 백업 및 복원 및 Azure Batch SLA(서비스 수준 계약)에 대한 주요 정보를 설명합니다.

프로덕션 배포 권장 사항

프로덕션 워크로드의 경우 다음과 같은 안정성 권장 사항을 포함하여 Azure Batch에 대한 모범 사례를 따릅니다.

중단 및 재실행을 견딜 수 있도록 작업을 설계합니다. 작업을 멱등하게 만들고, 장기 실행 작업에 체크포인트를 설정하고, 필요한 출력 및 진단 데이터를 지속형 스토리지에 저장합니다. 자세한 내용은 일시적인 오류에 대한 복원력 및 컴퓨트 노드 실패에 대한 복원력을(를) 참조하세요.
노드에 장애가 발생해도 워크로드를 계속해야 하는 경우 여러 컴퓨팅 노드를 사용합니다. 개별 컴퓨팅 노드는 계속 사용 가능하도록 보장되지 않습니다. 나머지 사용 가능한 노드가 다시 예약된 작업을 실행할 수 있도록 충분한 노드를 프로비전합니다.
지원되는 경우 가용성 영역 배치를 사용합니다. 지역, VM(가상 머신) SKU 및 워크로드 구성이 이를 지원하는 경우 가용성 영역 배치를 구성합니다. 정상 영역의 노드는 영역 중단 중에 작업을 계속 실행할 수 있지만 대체 용량은 정상 영역의 할당량 및 VM 가용성에 따라 달라지므로 용량 감소를 예상해야 합니다. 자세한 내용은 가용성 영역 오류에 대한 복원력을 참조하세요.
고정 풀 ID가 아닌 동적으로 풀을 대상으로 하는 작업을 디자인합니다. 이 디자인을 사용하면 원래 풀이 사용할 수 없게 되거나 원하는 용량으로 확장되지 않는 경우 작업 대상을 정상 상태의 풀로 다시 지정할 수 있습니다. 리소스 풀 유지 관리 또는 장애 시 비즈니스 연속성을 향상시킵니다.
풀 구성을 최신 상태로 유지합니다. Batch는 VM 이미지 및 SKU의 EOL(수명 종료) 날짜를 모니터링하고 해당 VM 이미지 및 SKU의 EOL 전에 풀을 마이그레이션합니다. 서비스 유지 관리 지침을 따라 Batch 노드 에이전트를 최신 상태로 유지하세요.

안정성 아키텍처 개요

이 섹션에서는 안정성 관점에서 가장 관련성이 높은 서비스가 작동하는 방식의 몇 가지 중요한 측면을 설명합니다. 이 섹션에서는 배포하고 사용하는 일부 리소스 및 기능을 포함하는 논리 아키텍처를 소개합니다. 또한 서비스의 작동 방식에 대한 세부 정보를 제공하는 물리적 아키텍처에 대해서도 설명합니다.

논리 아키텍처

Azure Batch는 여러 리소스 유형을 사용하여 일괄 처리 워크로드를 실행합니다. 이러한 리소스의 구성은 워크로드가 장애에 응답하는 방법을 결정합니다.

모든 Batch 처리 및 리소스는 Batch 계정과 연결됩니다. Batch 솔루션은 다음과 같은 논리 구성 요소를 사용합니다.

Batch 계정: 풀, 작업, 태스크 및 기타 Batch 리소스가 연결된 지역 리소스입니다. 계정을 만들고 계정의 지역, 풀 할당 모드 및 인증 설정을 선택합니다.
풀: 태스크가 실행되는 컴퓨팅 노드의 컬렉션입니다. 풀의 구성은 VM 이미지 및 크기, 대상 노드 수, 크기 조정 동작, 네트워킹 및 영역 배치를 정의합니다. 워크로드에 필요한 용량, 배치 및 운영 환경을 제공하도록 각 풀을 구성합니다. 대상 노드 수는 요청된 수용량이지만 할당량 제한, 용량 제약 조건 또는 할당 오류로 인해 할당된 노드 수가 더 적을 수 있습니다.
작업 및 태스크:작업은 태스크 컬렉션을 관리하고 풀과 연결됩니다. 태스크는 컴퓨팅 노드에서 애플리케이션 또는 스크립트를 실행합니다. 작업, 태스크, 제약 조건, 종속성, 재시도 동작 및 각 작업이 실행되는 풀을 정의합니다.
연결된 스토리지 계정: 선택적으로 Batch 계정에 연결할 수 있는 Azure Storage 계정입니다. 대부분의 Batch 솔루션은 애플리케이션 파일, 작업 리소스 파일, 입력 데이터 및 출력 데이터를 위한 관련 스토리지 계정을 사용합니다.

스토리지 계정을 Batch 계정에 연결한 후 Batch는 이를 autostorage 계정이라고 참조합니다. autostorage 계정은 애플리케이션 패키지에 필요하며 작업 리소스 파일을 저장할 수도 있습니다.

Batch 솔루션의 신뢰성은 스토리지 리소스에 따라 달라집니다. 스토리지 계정을 만들 때 복구 요구 사항을 충족하는 스토리지 중복 구성을 선택할 책임이 있습니다. 컴퓨팅 노드에서 스토리지로 작업 출력 및 기타 지속성 데이터를 이동합니다. Azure Storage 안정성 옵션에 대한 자세한 내용은 Azure Blob Storage의 안정성을 참조하세요.

자세한 내용은 Batch 서비스 워크플로 및 리소스,Batch 계정 및 Azure Storage 계정을 참조하세요.

물리적 아키텍처

Azure Batch에는 Batch 계정 및 풀, 작업, 태스크와 같은 기타 Batch 리소스에 대한 관리 작업을 처리하는 지역 제어 평면이 있습니다. 태스크를 실행하는 컴퓨팅 노드와는 별개입니다.

Azure Batch 풀은 Azure Virtual Machines 및 Virtual Machine Scale Sets를 사용합니다. 컴퓨팅 노드는 Batch 워크로드의 일부를 처리하는 VM입니다. 각 노드는 풀에 속하며 Batch 서비스에서 할당하는 작업을 실행합니다. Batch 노드 에이전트는 각 노드에서 실행되며 노드와 Batch 서비스 간의 명령 및 제어 인터페이스를 제공합니다. 컴퓨팅 노드 및 해당 로컬 스토리지는 일시적이며 영구적이지 않습니다. 노드가 풀을 벗어나면 해당 운영 체제 및 파일에 대한 변경 내용이 손실됩니다.

Batch 계정의 풀 할당 모드는 Batch가 컴퓨팅 및 VM 관련 리소스를 만드는 위치를 결정합니다.

Batch 서비스 풀 할당 모드: Batch는 Batch 서비스 관리 Azure 구독에 리소스를 할당합니다.
사용자 구독 풀 할당 모드: Batch는 Batch 계정이 포함된 구독에 직접 리소스를 생성합니다.

물리적 아키텍처에 대한 책임은 다음과 같이 나뉩니다.

Microsoft: Microsoft는 지역 Batch 제어 평면 및 서비스 인프라를 운영합니다. Batch는 풀 구성 및 사용 가능한 용량에 따라 컴퓨팅 노드를 프로비전하고, 작업을 예약하고, 노드 상태를 모니터링하고, 인프라 오류 후 노드를 복구하려고 시도합니다. Batch는 사용 가능한 다른 노드에서 실행하기 위해 중단된 작업을 다시 큐에 추가할 수 있습니다.
사용자: VM 이미지 및 크기, 노드 유형, 대상 노드 수, 크기 조정 구성, 네트워킹 및 가용성 영역 배치를 선택합니다.

또한 노드 오류를 허용할 수 있는 충분한 용량을 유지 관리하고, 노드 및 작업 상태를 모니터링하고, 게스트 운영 체제 및 노드 에이전트를 최신 상태로 유지하고, 재실행을 견딜 수 있도록 작업을 설계하고, 컴퓨팅 노드 밖으로 내구성 데이터를 이동할 책임이 있습니다.

일괄 처리 노드 복구는 워크로드가 중단 없이 계속되도록 보장하지 않습니다. 자세한 내용은 컴퓨팅 노드 장애에 대한 복원력을 참조하세요.

일시적인 오류에 대한 복원력

일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.

모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 일시적 결함 처리를 위한 권장 사항을 참조하세요.

Batch 솔루션 내에서 일시적인 오류는 태스크로 실행되는 애플리케이션 및 스크립트와 Batch API를 호출하여 Batch 리소스를 관리하는 모든 애플리케이션에 영향을 줄 수 있습니다. Batch는 작업 수준에서 재시도 메커니즘을 제공합니다. 작업 제약 조건을 구성하고, 작업을 idempotent 로 만들고(두 번 이상 실행해도 안전함) Batch 서비스 및 기타 종속성에 대한 호출에 대한 재시도 동작을 구성할 책임이 있습니다.

작업 재시도 및 시간 제한

maxTaskRetryCount를 구성하여 프로세스가 0이 아닌 종료 코드로 종료된 후 Batch가 작업을 다시 시도할 횟수를 제어합니다:

기본값인 0는 Batch가 0이 아닌 종료 코드로 종료된 후에 작업을 다시 시도하지 않음을 의미합니다.
양수 정수는 초기 시도 후 최대 재시도 횟수를 설정합니다.
-1 값이면 무제한으로 다시 시도할 수 있습니다. 지속적인 실패로 인해 작업이 무기한 실행될 수 있으므로 이 값은 권장되지 않습니다.

재시도로 인해 데이터가 손상되거나 출력이 중복되지 않도록 모든 작업을 idempotent로 디자인합니다. 장기 실행 작업의 경우 저장된 진행률에서 재시도를 계속할 수 있도록 검사점을 사용합니다. 자세한 내용은 재시도 및 재실행을 위한 설계를 참조하세요.

허용되는 기간 내에 진행되지 않는 작업을 종료하도록 작업 또는 태스크에 maxWallClockTime 제약 조건을 설정합니다. 시간 제한은 반복적인 실패의 영향도 제한합니다. 워크로드의 복구 목표에 맞는 재시도 횟수 및 시간 제한을 선택합니다.

작업 종속성의 일시적 장애

Batch 작업으로 실행되는 애플리케이션 및 스크립트는 종종 Azure Storage, 데이터베이스 또는 API와 같은 다른 구성 요소를 호출합니다. Batch는 태스크 코드가 이러한 종속성에 보내는 개별 요청을 관리하지 않습니다. 작업 코드에서 일시적인 오류 처리를 구현하거나 종속성의 SDK에서 제공하는 재시도 기능을 사용합니다. 각 종속성의 지침에 따라 재시도 가능한 오류를 식별하고, 적절한 백오프 및 시간 제한 설정을 선택하고, Retry-After 헤더와 같은 재시도 지침을 적용합니다. 반복하기에 안전한 작업만 다시 시도합니다.

종속성 실패로 인해 0이 아닌 종료 코드로 작업 프로세스가 종료되는 경우 Batch는 maxTaskRetryCount에 따라 전체 작업을 다시 시도할 수 있습니다. 그러나 Batch는 실행 중인 작업 내에서 개별 종속성 요청을 다시 시도하지 않습니다.

Batch API 요청 다시 시도

서비스 외부에서 실행되는 애플리케이션은 Batch API를 호출하여 풀, 작업, 태스크, 컴퓨팅 노드 및 기타 Batch 리소스를 만들고 관리할 수 있습니다. 일시적인 Batch 서비스 또는 네트워크 오류를 처리하기 위해 최소 5분 이상 지속되는 재시도 정책을 사용하여 이러한 클라이언트를 구성합니다.

사용 가능한 경우 기본 제공 SDK 재시도 지원을 사용합니다. 예를 들어 .NET용 Azure.Compute.Batch 클라이언트 라이브러리는 Azure.Core 재시도 옵션을 통해 재시도 동작을 노출합니다.

코드에서 Batch 서비스의 API와 직접 상호 작용하는 경우 다시 시도하기 전에 몇 초 정도 기다린 다음, 임의화(지터)와 함께 지수 백오프를 사용하여 동기화된 재시도 요청을 방지하고, Retry-After 및 429 Too Many Requests와 같은 제한 응답과 함께 반환되는 503 Service Unavailable 헤더를 준수합니다.

요청 시간 제한이 반드시 Batch가 요청을 처리하지 못했다는 의미는 아닙니다. 제한 시간이 초과된 후 안전하게 다시 시도할 수 있을 때 작업을 다시 시도하거나 리소스 상태를 검색하여 원래 작업이 성공했는지 확인합니다. 자세한 내용은 Azure Batch 오류 처리 및 감지를 참조하세요.

컴퓨트 노드 실패에 대한 복원력

인프라 오류, 운영 체제 문제 또는 구성 문제로 인해 컴퓨팅 노드를 사용할 수 없게 될 수 있습니다. Batch는 인프라 장애의 영향을 받는 노드를 복구하려고 시도하지만 모든 구성 관련 오류를 자동으로 복구할 수는 없습니다. 예를 들어 애플리케이션 패키지 또는 컨테이너가 설치에 실패하는 경우 기본 문제를 수정해야 하며 영향을 받는 노드를 제거하고 교체해야 할 수 있습니다.

노드 오류가 작업을 중단시키는 경우 Batch는 가능한 경우 내부 제한까지 동일한 노드에서 작업을 다시 시도할 수 있습니다. 해당 노드에서 작업을 계속할 수 없는 경우 Batch는 사용 가능한 다른 노드에서 실행을 위해 다시 큐에 추가할 수 있습니다. 이러한 서비스 기반 복구 재시도는 maxTaskRetryCount와 독립적이며 해당 값이 0인 경우에도 발생할 수 있습니다.

Microsoft에서 관리하는 노드 복구 프로세스

Microsoft는 서비스 기반 노드 복구 및 태스크 재대기열 처리를 관리합니다. Batch 서비스가 노드로부터 하트비트를 복구가 트리거될 만큼 충분히 오랫동안 받지 못하는 경우 Batch는 다음 작업을 수행할 수 있습니다.

노드 격리: Batch는 노드를 비정상으로 처리하고, 상태를 unusable로 설정하며, 노드에 대한 새 작업 예약을 중지합니다.
영향을 받는 작업 식별: Batch는 노드에서 실행 중인 작업을 다시 예약할 후보로 식별합니다.
적격 작업을 다시 큐에 넣기: 영향을 받는 작업이 여전히 running 상태로 유지되는 경우 Batch는 이를 active로 다시 설정하여 스케줄러가 다른 노드에 할당할 수 있도록 할 수 있습니다. Batch는 이미 completed 상태로 유지된 작업을 다시 설정하거나 다시 실행하지 않습니다.
노드 복구: Batch는 노드를 정상 상태로 복원하거나 기본 VM을 바꾸려고 시도합니다.

복구는 즉각적이지 않습니다. Batch가 노드 오류를 감지하고 태스크를 다시 예약하려고 시도하는 동안 태스크는 running 상태로 유지될 수 있습니다. 다른 컴퓨팅 노드를 사용할 수 없는 경우 Batch가 일정을 조정할 수 있을 때까지 태스크가 해당 상태로 유지될 수 있습니다. 자세한 내용은 Batch 작업에 대한 알려진 제한 사항을 참조하세요.

대체가 시작되기 전에 원래 노드가 정상 하트비트를 다시 시작하는 경우 Batch는 이를 안정적인 상태로 되돌릴 수 있습니다. 교체가 이미 시작된 경우 Batch는 대신 원래 VM을 제거하고 대체 VM을 프로비전할 수 있습니다.

귀하의 책임

서비스 기반 복구는 중단 없는 작업 실행 또는 충분한 남은 용량을 보장하지 않습니다. 사용자는 다음 조치에 대한 책임이 있습니다.

충분한 용량을 유지 관리합니다. 노드 하나를 사용할 수 없는 동안 워크로드를 계속해야 하는 경우 나머지 노드가 다시 예약된 작업을 실행할 수 있도록 충분한 노드를 프로비전합니다. 다른 사용 가능한 노드가 없으면 중단된 작업이 대기해야 합니다.
사용 가능한 용량 모니터링: 풀에 더 이상 워크로드에 사용할 수 있는 노드가 충분하지 않은 경우를 감지할 수 있도록 집계 노드 수 및 상태를 추적합니다. unusable, startTaskFailed, unknown, preempted와 같은 상태는 용량 감소를 나타냅니다. 자세한 내용은 상태별로 작업 및 노드 수를 계산하여 Batch 솔루션 모니터링을 참조하세요.
문제 노드 조사: 태스크가 반복적으로 실패하거나, 다시 큐에 추가되거나, 할당된 노드를 사용할 수 없게 되거나 풀을 떠난 후에도 running 상태로 유지되는 경우 작업 메타데이터를 사용하여 문제가 특정 노드와 연결되어 있는지 확인하세요.

문제 노드를 제거하기 전에, 노드를 제거하면 로컬 파일이 삭제되므로 Batch 노드 에이전트 로그를 업로드하고 관련 태스크 로그를 유지합니다. 노드 에이전트 로그는 Microsoft 지원가 Batch 서비스 또는 노드 문제를 진단하는 데 도움이 될 수 있으며 stdout 및 stderr와 같은 작업 로그는 애플리케이션 및 구성 문제를 식별하는 데 도움이 될 수 있습니다. 자세한 내용은 노드 에이전트 로그 파일을 참조하세요.
작업 진행률 및 데이터 보호: 중단 및 다시 실행이 허용되도록 작업을 디자인합니다. 로컬 스토리지가 임시적이므로 계산 노드에서 검사점, 출력 및 기타 지속성 데이터를 이동하세요.

자세한 내용은 Azure Batch 풀 및 노드 오류 및 Azure Batch의 오류 처리 및 감지를 참조하세요.

가용성 영역 오류에 대한 복원력

가용성 영역은 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.

Batch는 다음 두 가지 주요 방법으로 가용성 영역을 지원합니다.

컨트롤 플레인: Batch 컨트롤 플레인은 많은 지역에서 영역 복원력이 있습니다. 이러한 지역에서는 영역 장애 발생 시 Batch 계정 및 기타 Batch 리소스에 대한 관리 작업을 계속할 수 있습니다. Microsoft 이 컨트롤 플레인 복원력을 제공하는 지역을 게시하지 않습니다.
풀: Batch 풀이 가용성 영역 배치를 사용하도록 구성할 수 있습니다. 영역을 사용할 수 없게 되면 정상 영역의 컴퓨팅 노드는 작업 스케줄링에 계속 사용할 수 있습니다.

컴퓨팅 노드 배치의 경우 단일 풀에 여러 가용성 영역의 컴퓨팅 노드가 포함될 수 있으므로 이 지원 모델은 다른 Azure 서비스의 영역 중복성과 유사합니다. 그러나 Batch는 가능한 범위에서 영역 간에 노드를 분산합니다. 해당 지역의 모든 가용 영역을 사용하려고 시도하지만 모든 가용 영역에 배치되거나 균등한 분포를 보장하지는 않습니다. 특정 영역을 선택하거나 각 영역에 배치된 노드 수를 제어할 수 없습니다.

다음 다이어그램은 예제 Batch 계정을 보여줍니다. 계정에는 노드가 세 개의 가용성 영역에 분산된 단일 풀이 있습니다.

세 가지 가용성 영역에 분산된 컴퓨팅 노드가 있는 Batch 풀을 보여 주는 다이어그램.

스토리지 계정과 같은 다른 종속 리소스를 영역 복원성을 갖추도록 할 책임이 있습니다. 각 서비스에 대한 안정성 가이드를 검토합니다. 자세한 내용은 Azure 서비스에 대한 안정성 가이드를 참조하세요.

Requirements

지역 지원:가용성 영역을 지원하는 Azure 지역에 풀을 만듭니다.
VM SKU 가용성: 선택한 VM SKU는 해당 지역의 둘 이상의 영역에서 사용할 수 있어야 합니다. 리소스 SKU 목록 API를 사용하여 VM SKU의 locationInfo 필드를 확인합니다.
구독 액세스:사용자 구독 풀 할당 모드의 경우 구독에 선택한 VM SKU에 대한 가용성 영역 제안 제한이 없어야 합니다. ResourceSkuRestrictions를 리소스 SKU 목록 API 응답에서 확인합니다. 제한이 있는 경우 지원 요청을 제출하여 제거를 요청하세요.
노드 간 통신:InfiniBand 사용 VM SKU를 사용하여 노드 간 통신을 사용하도록 설정한 경우 풀은 가용성 영역 배치 정책을 사용할 수 없습니다.

영역 간 인스턴스 배포

가용성 영역 배치를 사용하도록 설정하면 Batch는 선택한 지역의 모든 가용성 영역에 컴퓨팅 노드를 할당하려고 시도합니다. 이 할당은 가능한 범위에서 수행됩니다. Batch는 배포를 제어하며 각 영역의 노드 수가 같지 않을 수 있습니다.

Cost

Batch는 가용성 영역 배치를 사용하도록 설정하는 요금을 추가하지 않습니다. 워크로드에서 사용하는 컴퓨팅, 스토리지, 네트워킹 및 기타 Azure 리소스에 대한 요금이 청구됩니다. 영역 손실을 견딜 수 있도록 추가 노드를 프로비전하는 경우 해당 노드는 정상 요금이 발생합니다. 자세한 내용은 Azure Batch 가격 책정을 참조하세요.

가용성 영역 지원 구성

가용성 영역 배치를 사용하여 새 풀을 만듭니다. 가용성 영역 배치를 사용하도록 설정된 풀을 만들려면 여러 가용성 영역에 걸친 Batch 풀 만들기를 참조하세요.
기존 풀에서 가용성 영역 배치를 변경 합니다. 풀을 만들 때 가용성 영역 배치를 선택해야 합니다. 가용성 영역을 사용하도록 기존 풀을 변경할 수 없습니다.

다음 단계를 사용하여 대체 풀을 만들고 각 작업이 해당 대체 풀을 사용하도록 업데이트할 수 있습니다.
1. 작업 비활성화:작업 사용 안 함 작업을 사용하여 요청을 제출할 때 Batch에서 실행 중인 작업을 처리하는 방법을 선택합니다.
  - 대기: Batch는 새 작업 시작을 중지하고 기존 풀에서 실행 작업을 완료할 수 있도록 합니다. 작업은 실행 중인 작업이 완료될 때까지 disabling 상태로 유지됩니다.
  - 다시 큐에 넣기: Batch는 실행 중인 작업을 중단하고 큐에 반환합니다. 작업을 사용하도록 설정한 후 작업을 다시 실행할 수 있습니다.
  - 종료: Batch는 실행 중인 작업을 중단하고 종료되었음을 나타내는 실패 정보와 함께 완료된 것으로 표시합니다. 작업을 사용하도록 설정한 후에는 태스크가 다시 실행되지 않습니다.
  이미 active 상태에 있는 작업(큐에 대기 중이지만 실행되지 않음)은 모든 옵션에서 큐에 대기 상태로 유지됩니다.
  
  계속하기 전에 작업이 disabled 상태에 도달할 때까지 기다립니다. 이 시점에서는 실행 중인 작업이 없으며 Batch는 새 작업을 예약하지 않습니다.
2. 작업의 풀 편집:작업 업데이트 작업을 사용하여 해당 작업의 poolInfo.poolId 풀을 대체 풀로 설정합니다. Batch는 작업이 disabled 상태에 있는 동안에만 이 속성을 변경할 수 있도록 허용합니다. 작업을 사용하도록 설정하기 전에 대체 풀이 존재하고 사용 가능한 용량이 있는지 확인합니다. 풀이 존재하지 않는 경우 Batch는 업데이트를 수락하지만, 풀을 만들 때까지 작업을 예약할 수 없습니다.
3. 작업 활성화:Enable Job 작업을 사용합니다. 작업은 enabling 상태를 거쳐 active 상태로 전환됩니다. 그런 다음 Batch는 Requeue 옵션으로 큐에 반환된 작업을 포함하여 대기 중인 작업을 대체 풀에서 예약합니다. Batch가 대기 옵션을 적용하는 동안 완료된 작업과 종료 옵션으로 완료된 작업은 다시 실행되지 않습니다.

용량 계획 및 관리

Batch의 일반 노드 복구 프로세스 는 영역 오류 중에 사용할 수 없는 노드를 바꾸고 풀을 구성된 대상 노드 수로 복원하려고 시도합니다. 해당 대상을 증가시키지 않습니다. 한 영역을 사용할 수 없을 때 워크로드가 계속되도록 충분한 용량을 유지하려면 자동 크기 조정을 사용하거나 수동으로 풀 용량의 오버 프로비저닝을 고려하세요.

자동 크기 조정을 사용하는 경우: 풀의 자동 크기 조정 수식에서 $UsableNodeCount서비스에서 정의한 변수를 참조하여 사용 가능한 용량이 워크로드에 필요한 기준보다 낮아지는 시점을 감지합니다. $UsableNodeCount는 Azure Monitor 메트릭이 아니라 수식이 평가되는 풀에 대한 Batch 자동 크기 조정 변수입니다. Azure Monitor Batch 계정 범위에서 Batch 노드 수 메트릭을 게시하며 해당 메트릭에는 poolId 차원이 없습니다.
용량을 수동으로 관리하는 경우:풀 노드 개수 나열 작업을 사용하여 각 풀의 각 상태에서 전용 및 스폿 노드 수를 검색합니다. 이 작업은 단일 사용 가능한 노드 수를 반환하지 않습니다. idle 및 running와 같은 작업 가능한 상태를 unusable, unknown, offline, startTaskFailed와 같은 사용할 수 없거나 문제 상태와 비교하여 평가합니다. 반환된 개수가 최신이 아닐 수 있으므로 정확한 개수가 필요할 때 풀의 컴퓨팅 노드를 나열하여 확인합니다.

Batch는 노드를 가능한 범위에서 영역에 분산하므로 실제 분산은 같지 않을 수 있습니다. 용량을 계획할 때 노드가 영역 간에 동일하게 분산된다고 가정하지 마세요. 워크로드가 축소된 풀 용량으로 복구 목표를 충족할 수 있는지 확인합니다.

모든 영역이 정상인 경우의 동작

이 섹션에서는 Batch 풀이 가용성 영역 배치를 사용하고 모든 영역이 작동할 때 예상되는 사항에 대해 설명합니다.

영역 간 작업: Batch는 각 노드를 포함하는 영역에 관계없이 풀 전체에서 사용 가능한 컴퓨팅 노드에서 작업을 예약합니다.
영역 간 데이터 복제: Batch 컴퓨팅 노드는 임시 노드이며 Batch는 영역 간에 작업 파일을 복제하지 않습니다. 노드 손실 시에도 유지되어야 하는 입력, 출력, 검사점 및 진단 데이터를 영구 스토리지로 이동할 책임이 있습니다. 가용성 요구 사항을 충족하도록 스토리지 계정 중복성을 구성합니다.

영역 오류 중 동작

이 섹션에서는 Batch 풀에서 가용성 영역 배치를 사용하고 하나의 가용성 영역을 사용할 수 없는 경우 예상되는 사항에 대해 설명합니다.

탐지 및 대응: Microsoft는 Batch 서비스 및 컴퓨팅 노드 상태를 모니터링합니다. 영역 오류 중에 Batch는 영향을 받는 노드에서 지속적인 하트비트 손실을 감지하고 일반적인 노드 복구 프로세스를 시작합니다. 정상 영역의 노드는 계속 사용할 수 있으며 Batch는 해당 노드에서 작업을 계속 스케줄링할 수 있습니다.

Batch는 정상적인 복구 프로세스를 통해 구성된 대상 노드 수로 풀을 복원하려고 시도하지만, 그 대상 노드 수를 늘리지는 않습니다. 대상이 워크로드에 충분한 용량을 제공하지 않는 경우 추가 용량을 요청할 책임이 있습니다.

통지: 영역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Service Health 를 사용하여 영역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.

활성 작업: 영향을 받는 노드에서 실행되는 작업은 중단됩니다. Batch는 내부 복구 동작의 일부로 사용 가능한 노드에서 작업을 다시 예약할 수 있습니다. 일시적인 오류에 대한 복원력 및 컴퓨팅 노드 장애에 대한 복원력에서 설명된 대로 재시도 및 재실행을 허용하도록 작업을 디자인합니다.
예상 데이터 손실: 영향을 받는 컴퓨팅 노드의 파일은 중단 중에 사용할 수 없으며 노드가 풀에서 다시 이미지 처리되거나 제거되면 손실됩니다. Batch는 이러한 파일을 영역 간에 복제하지 않습니다. 지속형 스토리지에 유지되는 데이터는 해당 스토리지 리소스의 중복 구성에 따라 계속 사용할 수 있습니다.
예상 가동 중지 시간: 정상 노드의 작업은 계속됩니다. 중단된 작업은 Batch가 사용 가능한 노드로 일정을 조정할 수 있을 때까지 가동 중지 시간이 발생합니다. 사용할 수 있는 노드가 없으면 Batch에서 이를 다시 예약할 수 있을 때까지 작업이 running 상태로 유지될 수 있습니다. 복구 시간은 사용 가능한 풀 용량 및 대기 중인 워크로드에 따라 달라집니다.

계정이 컨트롤 플레인이 영역 복원력이 있는 지역에 있는 경우 Batch 계정 및 기타 Batch 리소스에 대한 관리 작업이 계속됩니다. 다른 지역에서는 영향을 받는 영역이 복구될 때까지 관리 작업을 사용할 수 없습니다.
재배포: 지속적인 하트비트 손실 후 Batch는 영향을 받는 노드를 unusable 상태로 표시하고 정상적인 노드 복구 프로세스를 통해 교체를 위해 제출합니다. Batch는 풀을 구성된 대상 노드 수로 복원하려고 시도하지만 대체 용량은 정상 영역의 할당량 및 VM 가용성에 따라 달라집니다.

이 프로세스 동안 작업은 풀과 연결된 상태로 유지됩니다. Batch는 정상 영역에 있는 사용 가능한 노드의 활성 작업에서 작업을 계속 예약합니다. 대체 노드가 할당되어 사용할 수 있게 되면 Batch는 해당 노드에서 작업을 예약할 수도 있습니다.

이 복구 프로세스는 구성된 대상 노드 수를 증가시키지 않습니다. 워크로드에 해당 목표값을 초과하는 용량이 필요한 경우 수동으로 늘리거나 풀의 자동 크기 조정 수식을 구성합니다.

영역 복구

Batch는 장애 발생 후 영역이 복구되는 경우 복구 프로세스를 관리합니다. Batch는 컴퓨팅 노드 장애에 대한 복원력에 정의된 것과 동일한 프로세스를 따릅니다.

Batch는 복구 후 가용성 영역 간에 노드의 균형이 균등하게 조정되도록 보장하지 않습니다. 영역 배치는 가능한 범위 내에서 이루어집니다.

영역 오류 테스트

테스트를 위해 실제 Azure 가용성 영역 중단을 시뮬레이션할 수 없습니다. 대신 비프로덕션 풀을 사용하여 대표 작업을 중단하고 충분한 컴퓨팅 노드를 서비스에서 제외하여 예상 용량 손실을 근사화합니다. 다음 지원되는 노드 작업을 사용하는 것이 좋습니다.

선택한 노드를 다시 부팅합니다.
선택한 노드에서 작업 예약을 사용하지 않도록 설정합니다.
풀에서 선택한 노드를 제거합니다.

작업에서 실행 중인 태스크를 처리하는 방법을 선택할 수 있는 경우 Batch가 나머지 노드에서 중단된 태스크를 예약할 수 있도록 Requeue 옵션을 선택합니다.

테스트 중에 Batch가 중단된 작업을 다시 예약하고 재실행해도 중복되거나 일관되지 않은 출력이 생성되지 않는지 확인합니다. 검사점 및 출력이 내구성 스토리지에서 계속 사용 가능하고, 모니터링을 통해 노드 손실 및 용량 감소가 감지되며, 워크로드가 남은 용량으로 완료될 수 있는지 확인합니다.

이러한 작업은 작업 중단 및 다시 예약, 멱등성, 검사점 및 지속성 출력 처리의 유효성을 검사합니다. 그러나 영역 전체 장애의 모든 효과를 재현하지는 않습니다.

지역 전체 오류에 대한 복원력

Batch 계정 및 해당 풀의 범위가 하나의 Azure 지역으로 한정됩니다. 지역에 오류가 발생하면 Batch 작업 및 풀이 영향을 받을 수 있습니다.

Batch는 계정, 풀 구성, 작업 및 태스크, 애플리케이션 패키지 또는 태스크 데이터를 다른 지역에 복제하지 않으며 기본 제공 지역 간 장애 조치를 제공하지 않습니다. 워크로드가 리전 전체 장애를 견딜 수 있어야 하는 경우 다중 Region Batch 솔루션을 배포하고 운영해야 합니다.

복원성을 위한 사용자 지정 다중 리전 솔루션

다중Region 솔루션을 빌드하려면 복구 디자인에서 사용하는 각 지역에 하나 이상의 Batch 계정을 배포합니다. Batch 계정은 지역 간에 독립적으로 작동합니다. 지역을 선택하고, 각 지역에서 리소스를 배포 및 운영하고, 구성, 복제, 장애 조치(failover) 및 장애 복구(failback)를 조정해야 합니다.

정상 작업 중에 여러 지역에서 작업을 제출하는 활성-활성 접근 방식 또는 장애 조치(failover)를 위해 보조 배포를 준비하는 활성-수동 접근 방식을 디자인할 수 있습니다. 액티브-액티브 디자인은 두 배포가 정상 운영 중에도 작업을 처리하므로 복구 시간을 줄일 수 있지만 액티브-패시브 디자인은 안정적인 상태 컴퓨팅 비용을 줄일 수 있습니다.

다음 목록에서는 솔루션을 디자인할 때 귀하의 책임의 예시를 제공합니다.

배포: 각 지역의 Batch 계정, 풀 또는 풀 배포 정의, 스토리지 계정, 네트워킹 리소스 및 기타 종속성을 미리 생성합니다. 선택한 각 지역이 워크로드에 필요한 Batch 기능, VM 크기 및 종속 서비스를 지원하는지 확인합니다. 불필요한 대기 시간을 방지하기 위해 가능한 경우 각 Batch 계정과 해당 태스크에서 사용하는 스토리지 리소스를 동일한 지역에 유지합니다. 지역 간에 구성을 일관되게 재현할 수 있도록 코드로 인프라를 사용하여 Batch 계정, 풀 및 지원 리소스를 정의합니다.
할당량 및 용량: 모든 복구 지역에서 해당 Batch 계정, 구독 및 VM 제품군 할당량을 확인하고 필요한 경우 가동 중단 전에 증가 요청을 하십시오. 할당량은 용량 보장이 아니라 한도입니다. VM 가용성은 지역, VM 제품군 및 시간에 따라 다릅니다. 자세한 내용은 Batch 계정 및 코어 할당량을 참조하세요.
데이터 복제: 애플리케이션 패키지, 컨테이너 이미지, 입력 데이터 및 참조 데이터를 모든 복구 리전에서 사용할 수 있도록 유지합니다. Batch는 사용자를 위해 이러한 항목을 복제하지 않습니다.
스토리지 복제: 복구 지점 목표에 따라 스토리지 중복성 및 지역 간 데이터 복제를 구성합니다. 각 복구 지역에서 복제된 데이터에 액세스할 수 있는지 확인합니다. 스토리지 안정성 옵션은 Azure Blob Storage의 안정성을 참조하세요.
지역 대상 지정: 애플리케이션이 Batch 계정과 함께 작동하는 경우 코드 배포 없이 다른 Batch 계정 및 연결된 스토리지 리소스를 선택할 수 있도록 디자인합니다.
장애 조치(failover): Batch는 워크로드를 다른 지역으로 자동으로 이동하지 않습니다. 중단을 감지하고, 중단이 워크로드에 미치는 영향을 확인하고, 영향을 받는 Batch 계정에 대한 제출을 중지하고, 새 작업을 정상 지역의 Batch 계정으로 전달하고, 중단된 작업을 다시 제출할지 여부를 결정할 책임이 있습니다. 영향을 받는 지역 외부에 복제해 두지 않은 작업이나 작업 결과물은 사용할 수 없거나 손실될 수 있습니다. 복구 시간은 배포 모델, 사용 가능한 용량, 데이터 복제 및 자동화에 따라 달라집니다.
지역 복구: 영향을 받는 지역에서 서비스 가용성이 복원된 후 해당 지역에 작업을 보내기 전에 Batch 계정, 풀, 스토리지 종속성 및 작업 상태의 유효성을 검사합니다. 다시 제출하기 전에 중복되거나 부분적으로 완료된 작업을 정리하세요. Batch는 이 프로세스를 조정하거나 지역 계정 간의 상태를 일치시키지 않습니다.
테스트: 비프로덕션 환경에서 전체 지역 복구 프로세스를 정기적으로 테스트합니다. 하나의 지역 배포를 사용할 수 없게 만들고, 다른 지역 Batch 계정에 직접 제출하고, 애플리케이션 패키지 및 입력 데이터에 대한 액세스를 검증하고, 대표 작업을 실행하고, 출력을 수집하고, 복구된 배포를 서비스에 다시 복귀시키는 연습을 시뮬레이션합니다. 복구 시간 목표 및 복구 지점 목표를 기준으로 결과를 측정합니다.

백업 및 복원

Azure Batch 워크로드 입력 및 출력 데이터에 대한 지속형 저장소가 아닙니다. Microsoft Batch 서비스를 유지 관리하지만 워크로드를 다시 만드는 데 필요한 구성 및 데이터를 보존해야 합니다.

일괄 처리 구성: Bicep 및 버전 제어 작업 정의와 같은 코드로 인프라를 사용하여 Batch 계정, 풀, 작업 및 지원 리소스를 정의합니다. 이러한 아티팩트를 사용하면 동일한 지역 또는 다른 지역에서 구성을 다시 만들 수 있습니다. 정의가 에이전트 풀을 프로비저닝하고 대표적인 작업을 실행할 수 있도록 정기적으로 테스트합니다.
일괄 처리 메타데이터: 일괄 처리는 연결된 작업 또는 태스크를 삭제할 때까지 작업(job) 및 태스크(task) 레코드를 유지하지만 이러한 레코드는 백업이 아닙니다. 이 기록을 유지해야 하는 경우 필요한 레코드를 Batch 외부에 보존하십시오.
컴퓨팅 노드의 데이터: 컴퓨팅 노드는 임시이며 해당 파일 시스템은 백업 또는 지속형 저장소가 아닙니다. 노드가 이미지로 다시 설치되거나 풀을 떠날 때 노드의 데이터가 손실됩니다. Batch는 보존 기간이 만료된 후 작업 파일을 삭제할 수도 있습니다. 태스크가 완료되기 전에 필요한 출력 및 진단 로그를 지속형 스토리지에 저장합니다. 장기 실행 작업의 경우 실행 중에 체크포인트를 저장합니다. 자세한 내용은 작업 및 태스크 출력 유지 및 Azure Batch 모니터링을 참조하세요.
자동 저장소 계정의 데이터: 연결된 자동 저장소 계정은 애플리케이션 패키지 및 작업 리소스 파일을 보유할 수 있습니다. 복구 목표를 충족하는 중복성을 구성하는 것 외에도 이 데이터를 실수로 삭제하거나 손상하는 것으로부터 보호해야 하는지 여부를 고려하세요. 자세한 내용은 Azure Blob Storage 백업 및 복구를 참조하세요.

복원 및 복구 테스트

복구하려면 Batch 및 지원 리소스 구성을 배포하고, 필요한 입력 데이터 및 애플리케이션 아티팩트를 복원하거나 다시 연결하고, 완료되지 않은 작업을 다시 제출하세요. 격리 또는 비프로덕션 복구 환경에서 리소스 재구성 및 데이터 복원을 주기적으로 테스트합니다. 버전 관리되는 정의 및 백업 데이터를 사용하고, 대표 작업을 실행하고, 결과 출력 및 종속성에 대한 액세스를 확인하고, 목표에 대해 달성된 복구 시간 및 복구 지점을 측정합니다. 불확실한 작업을 다시 제출해도 데이터가 손상되거나 중복 출력이 생성되지 않도록 태스크가 idempotent인지 확인합니다.

서비스 유지 관리에 대한 복원력

Microsoft 플랫폼 유지 관리를 수행하고 Azure Batch 및 기타 서비스에 대한 인프라 업데이트를 조정합니다. 풀 업데이트 동작을 구성하고 중단을 허용하도록 작업을 디자인할 책임이 있습니다.

호스트 유지 관리: Azure는 가능한 경우 실시간 마이그레이션과 같은 유지 관리 기술을 사용합니다. 유지 관리에서 컴퓨팅 노드를 다시 시작하거나 이동해야 하는 경우 실행 중인 작업이 중단될 수 있으며 Batch가 해당 작업을 다시 예약할 수 있습니다. 작업을 멱등하게 만들고 검사점 및 출력을 지속형 스토리지에 저장합니다.
게스트 운영 체제: 게스트 운영 체제 및 Batch 노드 에이전트를 최신 상태로 유지해야 합니다. 운영 체제 업데이트 동작은 이미지 및 업데이트 구성에 따라 달라집니다. 적절한 구성으로 Batch 풀에 대한 자동 OS 이미지 업그레이드는 실행 중인 작업을 중단하지 않고 풀 노드를 업데이트할 수 있습니다. 자동 OS 이미지 업그레이드는 모든 Batch 운영 체제 이미지를 지원하지 않습니다.
노드 에이전트 업데이트: 자동 OS 이미지 업그레이드는 Batch 노드 에이전트를 자동으로 업데이트하지 않습니다. 풀에 컴퓨팅 노드가 있는 동안에는 Batch 노드 에이전트가 자동으로 업그레이드되지 않습니다. 최신 노드 에이전트를 받으려면 풀의 크기를 노드 0개로 조정한 다음 다시 확장하거나 풀을 교체합니다. 노드를 제거하기 전에 필요한 작업 출력 및 진단 로그를 유지하세요. 자세한 내용은 Batch 노드 에이전트 업데이트를 참조하세요.

유지 관리로 인해 작업이 중단되거나 컴퓨팅 노드를 사용할 수 없게 되는 경우에도 워크로드가 계속 실행되거나 복구될 수 있도록 프로덕션 배포 권장 사항 및 컴퓨팅 노드 실패 지침을 따릅니다.

서비스 수준 약정

Azure 서비스에 대한 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 솔루션이 가용성 기대치를 달성하기 위해 충족해야 하는 조건을 설명합니다. 자세한 내용은 온라인 서비스에 대한 SLA를 참조하세요.

Azure Batch 가용성 SLA는 Batch API에 대해 수행하는 작업에 적용됩니다. 포함된 작업 유형에 대한 자세한 내용은 SLA 문구를 검토하세요. 풀 크기, 영역 배포 및 종속 서비스는 워크로드의 엔드 투 엔드 가용성에 영향을 주지만 Batch SLA의 조건은 변경하지 않습니다.

피드백

이 페이지가 도움이 되었나요?

2026-10-12 에 마지막으로 업데이트됨