Azure Batch 안정성
이 문서에서는 Azure Batch의 안정성 지원에 대해 설명하고, 가용성 영역을 통한 지역 내 복원력과 지역 간 복구 및 비즈니스 연속성에 대한 정보 링크를 모두 다룹니다.
가용성 영역 지원
가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 장애 조치(failover)될 수 있습니다.
Azure의 가용성 영역에 대한 자세한 내용은 가용성 영역이란?을 참조하세요.
Batch는 가용성 영역 지원 시 Azure와 패리티를 유지 관리합니다.
필수 조건
사용자 구독 모드 Batch 계정에 대해 풀을 만드는 구독에 요청된 VM SKU에 대한 영역 제공 제한이 없는지 확인합니다. 구독에 제한이 없는지 확인하려면 리소스 SKU 목록 API를 호출하고
ResourceSkuRestrictions을 검사하세요. 영역 제한이 있는 경우 지원 티켓을 제출하여 영역 제한을 제거할 수 있습니다.InfiniBand는 영역 간 통신을 지원하지 않으므로, 노드 간 통신을 사용하도록 설정하고 InfiniBand를 지원하는 VM SKU를 사용하는 경우 영역 정책을 사용하여 풀을 만들 수 없습니다.
Batch는 가용성 영역 지원 시 Azure와 패리티를 유지 관리합니다. 영역 옵션을 사용하려면 가용성 영역이 지원되는 Azure 지역에 풀을 만들어야 합니다.
가용성 영역 전반에 Batch 풀을 할당하려면 풀이 생성되는 Azure 지역은 둘 이상의 영역에서 요청된 VM SKU를 지원해야 합니다. 지역이 둘 이상의 영역에서 요청된 VM SKU를 지원하는지 확인하려면 리소스 SKU 목록 API를 호출하고
resourceSku의locationInfo필드를 검사합니다. 요청된 VM SKU에 대해 둘 이상의 영역이 지원되는지 확인합니다. 다음 명령으로 Azure CLI를 사용하여 사용 가능한 모든 리소스 SKU를 나열할 수도 있습니다.az vm list-skus
가용성 영역에서 Azure Batch 풀 만들기
가용성 영역에서 Batch 풀을 만드는 방법에 대한 예제는 가용성 영역에서 Azure Batch 풀 만들기를 참조하세요.
Azure Portal, Azure CLI, PowerShell 또는 Batch 관리 API를 사용하여 Batch 계정을 만드는 방법에 대해 자세히 알아봅니다.
영역 다운 환경
영역 다운 중단 중에 해당 영역 내의 노드를 사용할 수 없게 됩니다. 다른 영역의 동일한 노드 풀 내의 모든 노드는 영향을 받지 않으며 계속 사용할 수 있습니다.
Azure Batch 계정은 중단으로 인해 다운된 노드를 보정하기 위해 새 노드를 다시 할당하거나 새 노드를 만들지 않습니다. 사용자는 노드 풀에 더 많은 노드를 추가해야 합니다. 그러면 노드는 다른 정상 영역에서 할당됩니다.
내결함성
가용성 영역 오류가 일어날 수 있기 때문에 이에 대비하려면 서비스 용량을 과도하게 프로비전하여 솔루션이 1/3 용량 손실을 허용하고 영역 전체가 중단되는 동안 성능 저하 없이 계속 작동할 수 있도록 해야 합니다. 플랫폼에서 세 영역에 걸쳐 VM을 분산하고 하나 이상의 영역 오류를 고려해야 하므로 최대 워크로드 인스턴스 수에 영역 수/(영역 수-1) 또는 3/2의 인수를 곱합니다. 예를 들어 일반적인 최대 워크로드에 4개의 인스턴스가 필요한 경우 6개의 인스턴스 프로비전해야 합니다((2/3 * 6개 인스턴스) = 4개 인스턴스).
가용성 영역 마이그레이션
기존 Batch 풀을 가용성 영역 지원으로 마이그레이션할 수 없습니다. 가용성 영역에서 Batch 풀을 다시 만들려면 가용성 영역에서 Azure Batch 풀 만들기를 참조하세요.
지역 간 재해 복구 및 비즈니스 연속성
Azure Batch 모든 Azure 지역에서 사용할 수 있습니다. 그러나 Batch 계정을 만들 때는 특정 지역 한 곳과 연결되어야 합니다. 해당 Batch 계정에 대한 모든 후속 작업은 해당 지역에만 적용됩니다. 예를 들어 풀 및 연결된 VM(가상 머신)은 Batch 계정과 같은 지역에 생성됩니다.
Batch를 사용하는 애플리케이션을 설계할 때는 해당 지역에서 Batch를 사용할 수 없을 가능성을 고려해야 합니다. 드물지만 지역 전체, 또는 지역의 전체 Batch 서비스, 특정 Batch 계정에 문제가 발생할 수도 있기 때문입니다.
Batch를 사용하는 애플리케이션이나 솔루션을 항상 사용할 수 있도록 하려면 문제 발생 시 다른 지역으로 장애 조치하거나 항상 둘 이상의 지역 간에 워크로드를 분할하도록 설계해야 합니다. 둘 중 어떤 방식을 사용하더라도 지역이 서로 다른 둘 이상의 Batch 계정이 필요합니다.
Azure Batch를 사용하여 지역 간 재해 복구를 설정할 책임이 있습니다. 특정 지역에서 여러 Batch 계정을 실행하고 가용성 영역을 활용하는 경우 Batch 계정 중 하나를 사용할 수 없게 되면 애플리케이션이 재해 복구 목표를 충족할 수 있습니다.
대체 지역으로 장애 조치하는 기능을 제공하는 경우 솔루션의 모든 구성 요소를 고려해야 합니다. 두 번째 Batch 계정을 포함하는 것만으로는 충분하지 않습니다. 예를 들어 대부분의 Batch 애플리케이션에서는 Azure Storage 계정이 필요합니다. 스토리지 계정과 Batch 계정은 허용 가능한 성능을 위해 동일한 지역에 있어야 합니다.
장애 조치(failover) 가능한 솔루션을 설계할 때는 다음 요소를 고려하세요.
Batch 계정, 스토리지 계정 등 필요한 모든 서비스를 각 지역에서 미리 만듭니다. 일반적으로 계정을 만드는 데는 요금이 부과되지 않으며 계정이 사용되거나 데이터를 저장하는 경우에만 요금이 부과됩니다.
Batch 계정을 사용하여 필요한 코어 수를 할당하려면 모든 사용자 구독 Batch 계정에 대해 적절한 할당량이 설정되어 있는지 미리 확인합니다.
템플릿 및/또는 스크립트를 사용해 특정 지역에서 애플리케이션 배포를 자동화합니다.
모든 지역에서 애플리케이션 이진 파일 및 참조 데이터를 최신 상태로 유지합니다. 최신 상태로 유지하면 파일이 업로드되고 배포될 때까지 기다리지 않고도 지역을 온라인 상태로 빠르게 전환할 수 있습니다. 예를 들어 풀 노드에 설치할 사용자 지정 애플리케이션이 Batch 애플리케이션 패키지를 사용하여 저장되고 참조되는 경우를 생각해 봅니다. 애플리케이션의 업데이트가 릴리스되면 각 Batch 계정에 업로드되고 풀 구성에서 참조해야 합니다(또는 최신 버전을 기본 버전으로 설정해야 합니다).
Batch, 스토리지 및 기타 서비스를 호출하는 애플리케이션에서 클라이언트나 부하를 다른 지역으로 쉽게 전환할 수 있습니다.
정상 작업의 일부로 대체 지역으로 자주 전환하는 것이 좋습니다. 예를 들어, 지역이 각기 다른 두 배포에서 매월 대체 지역으로 전환합니다.
재해로부터 복구하는 데 걸리는 시간은 선택한 설정에 따라 달라집니다. Batch 자체는 여러 계정을 사용하든 단일 계정을 사용하든 관계없습니다. Batch 인스턴스 두 개가 동시에 트래픽을 수신하는 활성-활성 구성에서 재해 복구는 활성-수동 구성보다 빠릅니다. 어떤 구성을 선택할지는 비즈니스 요구 사항(다른 지역, 대기 시간 요구 사항)과 기술적 고려 사항을 기반으로 결정해야 합니다.
단일 지역 재해 복구
Batch에서 재해 복구를 구현하는 방법은 단일 지역에서 작업하든 다중 지역 지역에서 작업하든 관계없이 동일합니다. 유일한 차이점은 스토리지에 사용하는 SKU와 모든 지역에서 동일한 스토리지 계정을 사용할지 다른 스토리지 계정을 사용할 것인지 여부입니다.
재해 복구 테스트
Batch 사용 솔루션에 대한 자체 재해 복구 테스트를 수행해야 합니다. 여러 지역에서 클라이언트와 서비스 부하 간을 쉽게 전환할 수 있도록 하는 것이 모범 사례로 여겨집니다.
Batch에 대한 재해 복구 계획을 테스트하는 것은 Batch 계정을 번갈아 사용하는 것만큼 간단할 수 있습니다. 예를 들어 특정 지역의 단일 Batch 계정을 운영일 단 하루 동안 사용할 수 있습니다. 그런 다음, 다음 날 다른 지역의 두 번째 Batch 계정으로 전환할 수 있습니다. 재해 복구는 주로 클라이언트 쪽에서 관리됩니다. 재해 복구에 대한 이런 다중 계정 접근 방식은 단일 지역 또는 다중 지역 지역에서 RTO 및 RPO 기대치를 처리합니다.
용량과 사전 예방적 재해 복구 복원력
Microsoft와 해당 고객은 공유 책임 모델에 따라 운영합니다. Microsoft는 플랫폼과 인프라 복원력에 대한 책임이 있습니다. 고객은 배포하고 제어하는 특정 서비스에 대한 재해 복구를 처리할 책임이 있습니다. 복구가 사전 예방적인지 확인하려면 다음을 수행합니다.
항상 보조 복제본을 미리 배포해야 합니다. 이런 리소스를 미리 할당하지 않은 고객에게 영향이 발생할 때 용량을 보장할 수 없으므로 보조 복제본의 사전 배포가 필요합니다.
Batch 계정 및 관련 스토리지 계정처럼 각 지역의 모든 필수 서비스를 미리 만듭니다. 일반적으로 계정을 새로 만드는 데는 요금이 부과되지 않으며 계정을 사용하거나 데이터를 저장하는 경우에만 요금이 부과됩니다.
모든 구독에 적절한 할당량이 설정되어 있는지 미리 확인합니다. 그래야 Batch 계정을 사용하여 필요한 수의 코어를 할당할 수 있습니다. 다른 Azure 서비스와 마찬가지로 Batch 서비스와 관련하여 특정 리소스에 대한 제한이 있습니다. 이러한 제한 대부분은 Azure 구독 또는 계정 수준에서 적용되는 기본 할당량입니다. Batch 워크로드를 설계 및 강화할 때 이 할당량에 주의합니다.
참고 항목
Batch에서 프로덕션 작업을 실행하려고 계획하는 경우, 위 기본값의 할당량 중 두 개 이상을 늘려야 할 수 있습니다. 할당량을 늘리기 위해 무료로 할당량 증가를 요청할 수 있습니다. 자세한 내용은 할당량 증가 요청을 참조하세요.
스토리지
데이터가 지역 간에 백업되도록 Batch 스토리지를 구성해야 합니다. 기본값은 고객 책임입니다. 대부분의 Batch 솔루션은 리소스 파일 및 출력 파일을 저장하기 위해 Azure Storage를 사용합니다. 예를 들어 Batch 태스크(표준 태스크, 시작 태스크, 작업 준비 태스크 및 작업 릴리스 태스크 포함)는 일반적으로 스토리지 계정에 상주하는 리소스 파일을 지정합니다. 스토리지 계정은 처리된 데이터와 생성된 모든 출력 데이터도 저장합니다. 서비스 작업의 지역에서 데이터 손실이 발생할 수 있다는 것을 이해하는 것은 중요한 고려 사항입니다. 데이터를 다시 쓸 수 있는지 읽기 전용인지도 확인해야 합니다.
Batch는 다음 유형의 Azure Storage 계정을 지원합니다.
- 범용 v2(GPv2) 계정
- GPv1(범용 v1) 계정
- Blob Storage 계정(현재 가상 머신 구성에서 풀에 대해 지원됨)
스토리지 계정에 대한 자세한 내용은 Azure Storage 계정 개요를 참조하세요.
Batch 계정을 만들 때 스토리지 계정을 Batch 계정에 연결하거나 나중에 이 단계를 수행할 수 있습니다.
서비스를 사용할 수 있는 각 지역에 대해 별도의 스토리지 계정을 설정하는 경우 ZRS(영역 중복 스토리지) 계정을 사용해야 합니다. 쌍을 이루는 여러 지역에서 동일한 스토리지 계정을 사용하는 경우 GZRS(지역 영역 중복 스토리지) 계정을 사용합니다. 단일 지역을 포함하는 지역의 경우 GZRS를 사용할 수 없으므로 ZRS(영역 중복 스토리지) 계정을 만들어야 합니다.
용량 계획은 스토리지의 또 다른 중요한 고려 사항이며 사전에 해결해야 합니다. 스토리지 계정을 선택할 때 비용 및 성능 요구 사항을 고려해야 합니다. 예를 들어 GPv2 및 Blob Storage 계정 옵션은 GPv1보다 큰 용량 및 확장성 제한을 지원합니다. (스토리지 제한을 늘리려면 Azure 고객 지원팀에 문의하세요.) 이러한 계정 옵션은 스토리지 계정에서 데이터를 읽어 오거나 스토리지 계정에 데이터를 쓰는 다수의 병렬 태스크를 포함하고 있는 Batch 솔루션의 성능을 향상할 수 있습니다.
스토리지 계정이 Batch 계정에 연결되면 autostorage 계정으로 간주됩니다. autostorage 계정은 애플리케이션 패키지 .zip 파일을 저장하는 데 사용되므로 애플리케이션 패키지 기능을 사용하려는 경우에 필요합니다. autostorage 계정은 작업 리소스 파일에도 사용할 수 있습니다. autostorage 계정이 Batch 계정에 이미 연결되어 있으므로 SAS(공유 액세스 서명) URL이 리소스 파일에 액세스할 필요가 없습니다.