Azure 클라우드 서비스(클래식)를 업데이트하는 방법
Important
이제 Cloud Services(클래식)는 2024년 9월 1일부터 모든 고객을 대상으로 더 이상 사용되지 않습니다. 기존 실행 중인 배포는 Microsoft에서 중지 및 종료되며, 데이터는 2024년 10월부터 영구적으로 손실됩니다. 새 배포에서는 새로운 Azure Resource Manager 기반 배포 모델인 Azure Cloud Services(추가 지원)를 사용해야 합니다.
역할과 게스트 OS를 포함하여 클라우드 서비스를 업데이트하는 프로세스는 3단계로 진행됩니다. 먼저 새 클라우드 서비스 또는 OS 버전에 대한 이진 및 구성 파일을 업로드해야 합니다. 다음으로 Azure는 새 클라우드 서비스 버전의 요구 사항에 따라 클라우드 서비스에 대한 컴퓨팅 및 네트워크 리소스를 예약합니다. 마지막으로 Azure는 가용성을 유지하면서 새 버전 또는 게스트 OS로 테넌트를 증분 방식으로 업데이트하도록 롤링 업그레이드를 수행합니다. 이 문서에서는 롤링 업그레이드 마지막 단계에 대한 세부 정보를 설명합니다.
Azure 서비스 업데이트
Azure는 업그레이드 도메인(UD)이라는 논리적 그룹으로 역할 인스턴스를 구성합니다. 업그레이드 도메인(UD)은 그룹으로 업데이트되는 역할 인스턴스의 논리적 집합입니다. Azure는 클라우드 서비스를 한 번에 하나의 UD로 업데이트하며 이는 다른 UD의 인스턴스를 계속해서 트래픽을 제공하도록 합니다.
업그레이드 도메인의 기본값은 5입니다. 서비스 정의 파일(.csdef)의 upgradeDomainCount 특성을 포함하여 다른 수의 업그레이드 도메인을 지정할 수 있습니다. upgradeDomainCount 특성에 대한 자세한 내용은 Azure Cloud Services 정의 스키마(.csdef 파일)를 참조하세요.
서비스에서 하나 이상의 역할에 대한 전체 업데이트를 수행하면 Azure는 자신이 속한 업그레이드 도메인에 따라 역할 인스턴스의 집합을 업데이트합니다. Azure는 주어진 업그레이드 도메인 - 중지, 업데이트, 다시 온라인으로 전환 - 으로 모든 인스턴스를 업데이트하고 다음 도메인으로 이동합니다. 현재 업그레이드 도메인에서 실행 중인 인스턴스만 중지하여 Azure는 실행 중인 서비스에 가능한 한 최소한의 영향으로 업데이트를 발생하도록 합니다. 자세한 내용은 이 문서의 뒷부분에 나오는 업데이트 진행 방법 을 참조하세요.
참고 항목
용어 업데이트 및 업그레이드는 Azure 컨텍스트에서 의미가 약간 다르지만 이 문서의 기능 프로세스 및 설명에 대해 같은 의미로 사용될 수 있습니다.
서비스는 해당 역할이 가동 중지 시간 없이 전체 업데이트되도록 적어도 두 개의 역할 인스턴스를 정의해야 합니다. 서비스에 한 역할의 인스턴스가 하나만 있는 경우, 해당 서비스는 기존 업데이트가 완료될 때까지 사용할 수 없습니다.
이 문서에서는 Azure 업데이트에 대한 다음 정보를 다룹니다.
업데이트 중 허용된 서비스 변경 내용
다음 표에서 업데이트 중 서비스에 허용된 변경 내용을 보여 줍니다.
호스팅, 서비스 및 역할에 허용된 변경 사항 | 전체 업데이트 | 스테이징(VIP 교체) | 삭제 및 다시 배포 |
---|---|---|---|
운영 체제 버전 | 예 | 예 | 예 |
.NET 신뢰 수준 | 예 | 예 | 예 |
가상 머신 크기1 | 예2 | 예 | 예 |
로컬 스토리지 설정 | 증가만2 | 예 | 예 |
서비스에서 역할 추가 또는 제거 | 예 | 예 | 예 |
특정 역할의 인스턴스 수 | 예 | 예 | 예 |
서비스에 대한 엔드포인트의 개수 또는 유형 | 예2 | 예 | 예 |
구성 설정의 이름 및 값 | 예 | 예 | 예 |
구성 설정의 값(이름 제외) | 예 | 예 | 예 |
새 인증서 추가 | 예 | 예 | 예 |
기존 인증서 변경 | 예 | 예 | 예 |
새 코드 배포 | 예 | 예 | 예 |
1 크기 변경이 클라우드 서비스에 대해 사용할 수 있는 크기의 일부로 제한되었습니다.
2 Azure SDK 1.5 이상 버전이 필요합니다.
Warning
가상 머신 크기를 변경하면 로컬 데이터가 소멸됩니다.
업데이트 중에는 다음 항목이 지원되지 않습니다.
- 역할 이름 변경. 제거한 다음 새 이름으로 역할을 추가합니다.
- 업그레이드 도메인 수 변경
- 로컬 리소스의 크기 줄이기.
서비스 정의에 로컬 리소스의 크기 줄이기와 같은 다른 업데이트를 하는 경우 대신 VIP 교환 업데이트를 수행해야 합니다. 자세한 내용은 교환 배포를 참조하세요.
업그레이드 진행 방법
서비스에서 모든 역할 또는 단일 역할을 업데이트할 것인지 여부를 결정할 수 있습니다. 두 경우 모두 업그레이드되고 첫 번째 업그레이드 도메인에 속해 있는 각 역할의 모든 인스턴스는 중지, 업그레이드 및 다시 온라인으로 전환됩니다. 다시 온라인 상태가 되면 두 번째 업그레이드 도메인의 인스턴스는 중지, 업그레이드 및 다시 온라인으로 전환됩니다. 클라우드 서비스는 한 번에 하나의 업그레이드를 활성화할 수 있습니다. 업그레이드는 클라우드 서비스의 최신 버전에 대해 항상 수행됩니다.
다음 다이어그램은 서비스의 모든 역할을 업그레이드하는 경우 업그레이드가 어떻게 진행되는지 보여 줍니다.
이 다음 다이어그램은 단일 역할만 업그레이드하는 경우 업데이트가 어떻게 진행되는지 보여 줍니다.
자동 업데이트 중 Azure 패브릭 컨트롤러는 다음 UD로 이동하는 안전한 시기를 결정하도록 클라우드 서비스의 상태를 주기적으로 평가합니다. 이러한 상태 평가는 역할별로 수행되며 최신 버전의 인스턴스(즉, 이미 진행된 UD의 인스턴스)만 고려합니다. 이는 각 역할에 대해 최소한의 역할 인스턴스가 만족스러운 종료 상태에 도달했는지 확인합니다.
역할 인스턴스 시작 시간 제한
Fabric 컨트롤러는 각 역할 인스턴스가 시작됨 상태에 도달할 때까지 30분을 기다립니다. 시간 제한 기간이 경과하면 패브릭 컨트롤러는 다음 역할 인스턴스로 계속 이동합니다.
클라우드 서비스 업그레이드 동안 드라이브 데이터에 미치는 영향
단일 인스턴스에서 여러 인스턴스로 서비스를 업그레이드하는 경우 Azure는 업그레이드가 수행되는 동안 서비스를 중단합니다. 서비스 수준 계약 보장 서비스 가용성은 두 개 이상의 인스턴스로 배포된 서비스에만 적용됩니다. 다음 목록은 각 Azure 서비스 업그레이드 시나리오가 각 드라이브의 데이터에 어떤 영향을 미치는지 설명합니다.
시나리오 | C 드라이브 | D 드라이브 | E 드라이브 |
---|---|---|---|
VM(가상 머신) 다시 부팅 | 유지됨 | 유지됨 | 유지됨 |
포털 재부팅 | 유지됨 | 유지됨 | 제거됨 |
포털 이미지로 다시 설치 | 유지됨 | 제거됨 | 제거됨 |
전체 업그레이드 | 유지됨 | 유지됨 | 제거됨 |
노드 마이그레이션: | 제거됨 | 제거됨 | 제거됨 |
이전 목록에서 E: 드라이브는 역할의 루트 드라이브를 나타내며 하드 코딩되어서는 안 됩니다. 대신 %RoleRoot% 환경 변수를 사용하여 드라이브를 표시합니다.
단일 인스턴스 서비스를 업그레이드할 때 가동 중지 시간을 최소화하려면 스테이징 서버에 새로운 다중 인스턴스 서비스를 배포하고 VIP 교환을 수행합니다.
업데이트 롤백
Azure는 Azure Fabric Controller가 초기 업데이트 요청을 수락한 후에 서비스에서 더 많은 작업을 시작할 수 있도록 하여 업데이트 중에 서비스를 관리하는 데 유연성을 제공합니다. 배포에서 업데이트(구성 변경) 또는 업그레이드가 진행 중 상태일 때 롤백을 수행할 수 있습니다. 해당 서비스의 인스턴스 중 새 버전으로 업데이트되지 않은 인스턴스가 하나라도 있는 경우 업데이트나 업그레이드가 진행 중인 것으로 간주됩니다. 롤백이 허용되는지 테스트하려면 RollbackAllowed 플래그 값이 true로 설정되어 있는지 확인합니다. 배포 가져오기 및 클라우드 서비스 속성 가져오기 작업은 참조를 위해 RollbackAllowed 플래그를 반환합니다.
참고 항목
VIP 교환 업그레이드는 실행 중인 서비스의 전체 인스턴스를 다른 것으로 교체하는 것을 포함하므로 전체 업데이트 또는 업그레이드의 롤백을 호출하는 것이 적합합니다.
진행 중인 업데이트 롤백에는 배포에 대해 다음과 같은 효과가 있습니다.
- 업데이트되지 않거나 새 버전으로 업그레이드되지 않은 역할 인스턴스는 업데이트되거나 업그레이드되지 않습니다. 해당 인스턴스가 이미 서비스의 대상 버전을 실행하고 있기 때문입니다.
- 서비스 패키지(*.cspkg) 파일이나 서비스 구성(*.cscfg) 파일(또는 두 파일 모두)의 새 버전으로 이미 업데이트 또는 업그레이드된 모든 역할 인스턴스는 이러한 파일의 업그레이드 이전 버전으로 되돌려집니다.
다음 기능은 이러한 기능을 제공합니다.
아직 새 버전으로 업데이트되지 않은 상태로 서비스에 하나 이상의 인스턴스가 있는 한 구성 업데이트(배포 구성 변경을 호출하여 트리거됨) 또는 업그레이드(업그레이드 배포를 호출하여 트리거됨)에서 호출될 수 있는 업데이트 또는 업그레이드 롤백 작업.
배포 가져오기 및 클라우드 서비스 속성 가져오기 작업의 응답 본문의 일부로 반환되는 Locked 요소 및 RollbackAllowed 요소
- Locked 요소를 사용하면 지정된 배포에서 변경 작업을 호출할 수 있는 시기를 찾아낼 수 있습니다.
- RollbackAllowed 요소를 사용하면 지정된 배포에서 업데이트 또는 업그레이드 롤백 작업을 호출할 수 있는 시기를 찾아낼 수 있습니다.
롤백을 수행하려면 Locked 및 RollbackAllowed 요소를 모두 확인할 필요가 없습니다. RollbackAllowed가 true로 설정되어 있는지 확인하는 것으로 충분합니다. "x-ms-버전: 2011-10-01" 이상 버전으로 설정된 요청 헤더를 사용하여 해당 메서드가 호출되는 경우 해당 요소는 반환됩니다. 버전 관리 헤더에 대한 자세한 내용은 클래식 배포 모델의 버전 관리를 참조하세요.
업데이트나 업그레이드 롤백이 지원되지 않는 몇 가지 상황은 다음과 같습니다.
- 로컬 리소스 감소 - 업데이트에서 역할에 대한 로컬 리소스를 증가시키는 경우 Azure 플랫폼은 롤백을 허용하지 않습니다.
- 할당량 제한 - 업데이트가 규모 축소 작업이었던 경우 롤백 작업을 완료할 충분한 컴퓨팅 할당량이 없게 됩니다. 각 Azure 구독에는 할당량이 연결되어 있습니다. 할당량은 해당 구독에 속한 모든 호스트된 서비스가 사용할 수 있는 최대 코어 수를 지정합니다. 특정 업데이트를 롤백하면 구독 할당량을 초과하게 되므로 롤백은 사용하도록 설정되지 않습니다.
- 경합 상태 - 초기 업데이트가 완료되면 롤백이 불가능합니다.
업데이트 롤백이 유용한 예로는 수동 모드에서 업그레이드 배포 작업을 사용하여 Azure에서 호스트된 서비스에 대한 주요 현재 위치 업그레이드가 롤아웃되는 속도를 제어하는 경우가 있습니다.
업그레이드를 롤아웃하는 동안 수동 모드에서 배포 업그레이드를 호출하고 업그레이드 도메인을 시작합니다. 업그레이드를 모니터링하는 동안 첫 번째 업그레이드 도메인의 일부 역할 인스턴스가 응답하지 않는 경우 배포에서 업데이트 또는 업그레이드 롤백 작업을 호출할 수 있습니다. 이 작업을 수행하면 업그레이드되지 않은 인스턴스는 그대로 두고 업그레이드된 인스턴스를 이전 서비스 패키지 및 구성으로 롤백합니다.
진행 중인 배포에 여러 변경 작업 시작
일부 경우에서 진행 중인 배포에 여러 동시 변경 작업을 시작할 수 있습니다. 예를 들어, 서비스 업데이트를 수행하고 업데이트가 서비스 전체에 적용되는 동안 업데이트를 롤백하거나, 다른 업데이트를 적용하거나, 배포를 삭제하는 등 일부 변경 작업을 수행하려는 경우가 있습니다. 이러한 시나리오가 발생할 수 있는 사례 중 하나는 서비스 업그레이드에 버그가 있는 코드가 포함되어 있고, 이로 인해 업그레이드된 역할 인스턴스가 반복적으로 충돌하는 경우입니다. 이 경우 업그레이드된 도메인의 부족한 인스턴스 수가 정상이므로 Azure 패브릭 컨트롤러는 해당 업그레이드 적용 절차를 진행할 수 없습니다. 이 상태를 배포 중단이라고 합니다. 업데이트를 롤백하거나 새 업데이트를 실패한 배포의 위쪽에 적용하여 배포 중단을 해결할 수 있습니다
Azure Fabric Controller가 서비스를 업데이트하거나 업그레이드하기 위한 최초 요청을 받으면 후속 변형 작업을 시작할 수 있습니다. 즉, 다른 변경 작업을 시작할 수 있기 전에 초기 작업이 완료될 때까지 기다릴 필요가 없습니다.
첫 번째 업데이트가 진행 중인 동안 두 번째 업데이트 작업을 시작하는 것은 롤백 작업과 비슷하게 진행됩니다. 두 번째 업데이트가 자동 모드인 경우, 첫 번째 업그레이드 도메인이 즉시 업그레이드되므로 여러 업그레이드 도메인의 인스턴스가 동시에 오프라인이 될 수 있습니다.
변경 작업은 다음과 같습니다. 배포 구성 변경, 배포 업그레이드, 배포 상태 업데이트, 배포 삭제 및 업데이트 또는 업그레이드 롤백.
배포 가져오기 및 클라우드 서비스 속성 가져오기라는 두 가지 작업은 잠금 플래그를 반환합니다. Locked 플래그를 검사하여 지정된 배포에서 변형 작업을 호출할 수 있는지 확인할 수 있습니다.
Locked 플래그를 반환하는 이러한 메서드의 버전을 호출하려면 요청 헤더를 "x-ms-버전: 2011-10-01" 이상으로 설정해야 합니다. 버전 관리 헤더에 대한 자세한 내용은 클래식 배포 모델의 버전 관리를 참조하세요.
업그레이드 도메인 간 역할의 배포
Azure는 서비스 정의(.csdef) 파일의 일부로 구성될 수 있는 업그레이드 도메인의 수에 대해 역할의 인스턴스를 균등하게 배포합니다. 업그레이드 도메인의 최대값은 20이며 기본값은 5입니다. 서비스 정의 파일을 수정하는 방법에 대한 자세한 내용은 Azure 서비스 정의 스키마(.csdef 파일)를 참조하세요.
예를 들어 역할에 10개의 인스턴스가 있는 경우 기본적으로 각 업그레이드 도메인에는 두 개의 인스턴스가 포함됩니다. 역할에 14개의 인스턴스가 있는 경우 4개의 업그레이드 도메인은 3개의 인스턴스를 포함하고 5번째 도메인은 2개의 인스턴스를 포함합니다.
업그레이드 도메인은 0부터 시작하는 인덱스로 식별됩니다. 첫 번째 업그레이드 도메인의 ID가 0이면 두 번째 업그레이드 도메인은 ID가 1입니다.
다음 다이어그램은 서비스에서 두 개의 업그레이드 도메인을 정의할 때 두 개의 역할이 포함된 서비스의 역할이 어떻게 분산되는지 보여 줍니다. 서비스는 8개의 웹 역할 인스턴스 및 9개의 작업자 역할 인스턴스를 실행하고 있습니다.
참고 항목
Azure는 업그레이드 도메인에 인스턴스가 할당되는 방식을 제어합니다. 어떤 도메인에 어떤 인스턴스를 할당할지를 지정하는 것은 불가능합니다.
다음 단계
Cloud Services를 관리하는 방법
Cloud Service를 모니터링하는 방법
Cloud Services를 구성하는 방법