Azure 클라우드 서비스(클래식)를 업데이트하는 방법

중요

신규 고객에게는 Cloud Services(클래식)가 사용되지 않으며 모든 고객에 대해 2024년 8월 31일에 사용 중지됩니다. 새 배포에서는 새로운 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 이상 버전이 필요합니다.

경고

가상 머신 크기를 변경하면 로컬 데이터가 소멸됩니다.

업데이트 중 다음과 같은 항목이 지원되지 않습니다.

  • 역할 이름 변경. 제거한 다음 새 이름으로 역할을 추가합니다.
  • 업그레이드 도메인 수 변경
  • 로컬 리소스의 크기 줄이기.

서비스 정의에 로컬 리소스의 크기 줄이기와 같은 다른 업데이트를 하는 경우 대신 VIP 교환 업데이트를 수행해야 합니다. 자세한 내용은 교환 배포를 참조하세요.

업그레이드 진행 방법

서비스에서 모든 역할 또는 단일 역할을 업데이트할 것인지 여부를 결정할 수 있습니다. 두 경우 모두 업그레이드되고 첫 번째 업그레이드 도메인에 속해 있는 각 역할의 모든 인스턴스는 중지, 업그레이드 및 다시 온라인으로 전환됩니다. 다시 온라인 상태가 되면 두 번째 업그레이드 도메인의 인스턴스는 중지, 업그레이드 및 다시 온라인으로 전환됩니다. 클라우드 서비스는 한 번에 하나의 업그레이드를 활성화할 수 있습니다. 업그레이드는 클라우드 서비스의 최신 버전에 대해 항상 수행됩니다.

다음 다이어그램에서는 서비스에서 모든 역할을 업그레이드하는 경우 업그레이드 진행 방법을 보여 줍니다.

Upgrade service

다음 다이어그램에서는 단일 역할만 업그레이드하는 경우 업데이트 진행 방법을 보여 줍니다.

Upgrade role

자동 업데이트 중 Azure 패브릭 컨트롤러는 다음 UD로 이동하는 안전한 시기를 결정하도록 클라우드 서비스의 상태를 주기적으로 평가합니다. 이 상태 평가는 역할별로 수행되며 최신 버전의 인스턴스만 고려합니다(즉, 이미 이동된 UD에서 인스턴스). 각 역할에 대해 최소 수의 역할 인스턴스가 만족스러운 터미널 상태로 수행됐는지 확인합니다.

역할 인스턴스 시작 시간 제한

패브릭 컨트롤러는 각 역할 인스턴스가 시작됨 상태에 도달할 때까지 30분 동안 기다립니다. 시간 제한 기간이 경과하면 패브릭 컨트롤러는 다음 역할 인스턴스로 계속 이동합니다.

클라우드 서비스 업그레이드 동안 드라이브 데이터에 미치는 영향

단일 인스턴스에서 여러 인스턴스로 서비스를 업그레이드하는 경우 업그레이드가 Azure 업그레이드 서비스 방식으로 인해 수행되는 동안 서비스는 중단됩니다. 서비스 수준 계약 보장 서비스 가용성은 두 개 이상의 인스턴스로 배포된 서비스에만 적용됩니다. 다음 목록에서는 각 Azure 서비스 업그레이드 시나리오에 따라 각 드라이브의 데이터에 미치는 영향을 설명합니다.

시나리오 C 드라이브 D 드라이브 E 드라이브
VM 재부팅 유지됨 유지됨 유지됨
포털 재부팅 유지됨 유지됨 제거됨
포털 이미지로 다시 설치 유지됨 제거됨 제거됨
전체 업그레이드 유지됨 유지됨 제거됨
노드 마이그레이션: 제거됨 제거됨 제거됨

위 목록에서 E: 드라이브는 역할의 루트 드라이브를 나타내며 하드 코드되면 안됩니다. 대신 %RoleRoot% 환경 변수를 사용하여 드라이브를 표시합니다.

단일 인스턴스 서비스를 업그레이드할 때 가동 중지 시간을 최소화하려면 스테이징 서버에 새로운 다중 인스턴스 서비스를 배포하고 VIP 교환을 수행합니다.

업데이트 롤백

Azure는 Azure 패브릭 컨트롤러에 의해 초기 업데이트 요청이 수락된 후 서비스에 추가 작업을 시작할 수 있도록 하여 업데이트하는 동안 서비스 관리에 유연성을 제공합니다. 롤백은 배포에서 업데이트(구성 변경) 또는 업그레이드가 진행 중인 상태에서만 수행할 수 있습니다. 업데이트 또는 업그레이드는 아직 새 버전으로 업데이트되지 않은 서비스의 인스턴스가 하나 이상 있는 한 진행 중인 것으로 간주됩니다. 롤백이 허용되는지 여부를 테스트하려면 배포 가져오기클라우드 서비스 속성 가져오기 작업으로 반환되는 RollbackAllowed 플래그의 값이 true로 설정되었는지 확인합니다.

참고

VIP 교체는 실행 중인 전체 서비스 인스턴스를 다른 서비스로 교체하여 업그레이드하기 때문에 진행 중인 업데이트 또는 업그레이드에서만 롤백을 호출하는 것이 의미가 있습니다.

진행 중인 업데이트 롤백에는 배포에 대해 다음과 같은 효과가 있습니다.

  • 이러한 인스턴스는 서비스의 대상 버전을 이미 실행 중이기 때문에 새 버전으로 업데이트 또는 업그레이드되지 않은 모든 역할 인스턴스는 업데이트되거나 업그레이드되지 않습니다.
  • 이미 서비스 패키지(*.cscfg) 파일 또는 서비스 구성(*.cscfg) 파일(또는 두 파일 모두)이 새 버전으로 업데이트 또는 업그레이드된 역할 인스턴스는 업그레이드되기 전 버전의 파일로 되돌아갑니다.

다음과 같은 기능으로 이 기능이 제공됩니다.

  • 아직 새 버전으로 업데이트되지 않은 서비스에 하나 이상의 인스턴스가 있는 한 구성 업데이트(배포 구성 변경을 호출하여 트리거됨) 또는 업그레이드(업그레이드 배포를 호출하여 트리거됨)에서 호출될 수 있는 업데이트 또는 업그레이드 롤백 작업.

  • 배포 가져오기클라우드 서비스 속성 가져오기 작업의 응답 본문의 일부로 반환되는 Locked 요소 및 RollbackAllowed 요소

    1. Locked 요소를 사용하면 지정된 배포에서 변경 작업을 호출할 수 있는 시기를 찾아낼 수 있습니다.
    2. RollbackAllowed 요소를 사용하면 지정된 배포에서 업데이트 또는 업그레이드 롤백 작업을 호출할 수 있는 시기를 찾아낼 수 있습니다.

    롤백을 수행하려면 Locked 및 RollbackAllowed 요소를 모두 확인할 필요가 없습니다. RollbackAllowed가 true로 설정되어 있는지 확인하는 것으로 충분합니다. "x-ms-버전: 2011-10-01" 이상 버전으로 설정된 요청 헤더를 사용하여 해당 메서드가 호출되는 경우 해당 요소는 반환됩니다. 버전 관리 헤더에 대한 자세한 내용은 서비스 관리 버전 관리를 참조하세요.

업데이트 또는 업그레이드의 롤백이 지원되지 않는 경우는 다음과 같습니다.

  • 로컬 리소스 감소 - 업데이트에서 역할에 대한 로컬 리소스를 증가시키는 경우 Azure 플랫폼은 롤백을 허용하지 않습니다.
  • 할당량 제한 - 업데이트가 규모 축소 작업이었던 경우 롤백 작업을 완료할 충분한 컴퓨팅 할당량이 없게 됩니다. 각 Azure 구독에는 해당 구독에 속하는 모든 호스팅된 서비스에서 사용할 수 있는 코어의 최대 수를 지정하는 연결된 할당량이 있습니다. 특정 업데이트의 롤백 수행으로 구독이 할당량을 초과하게 되는 경우 해당 롤백을 사용할 수 없습니다.
  • 경합 상태 - 초기 업데이트가 완료된 경우 롤백할 수 없습니다.

업데이트 롤백이 유용한 경우의 예는 Azure 호스티드 서비스로 주요 전체 업그레이드가 롤아웃되는 속도를 제어하도록 수동 모드에서 업그레이드 배포 작업을 수행하는 경우입니다.

업그레이드를 롤아웃하는 동안 수동 모드에서 배포 업그레이드를 호출하고 업그레이드 도메인을 시작합니다. 어느 시점에서 업그레이드를 모니터링할 때 검사하는 첫 번째 업그레이드 도메인의 일부 역할 인스턴스가 응답하지 않게 되는 경우 배포에서 업데이트 또는 업그레이드 롤백 작업을 호출할 수 있습니다. 이 작업은 업그레이드되지 않은 인스턴스 및 이전 서비스 패키지 및 구성으로 업그레이드된 롤백 인스턴스를 그대로 유지합니다.

진행 중인 배포에 여러 변경 작업 시작

일부 경우에서 진행 중인 배포에 여러 동시 변경 작업을 시작할 수 있습니다. 예를 들어 서비스 업데이트를 수행할 수 있으며 해당 업데이트가 서비스에서 롤아웃되는 동안 업데이트 롤백, 다른 업데이트 적용 또는 배포 삭제와 같은 다른 변경을 수행하려고 합니다. 이러한 작업이 필요한 경우는 서비스 업그레이드가 업그레이드된 역할 인스턴스를 반복적으로 충돌을 일으키는 버그가 있는 코드를 포함 하는 경우입니다. 이 경우 업그레이드된 도메인의 부족한 인스턴스 수가 정상이므로 Azure 패브릭 컨트롤러는 해당 업그레이드 적용 절차를 진행할 수 없습니다. 이러한 상태를 배포 중단이라고 합니다. 업데이트를 롤백하거나 새 업데이트를 실패한 배포의 위쪽에 적용하여 배포 중단을 해결할 수 있습니다

Azure 패브릭 컨트롤러에서 서비스 업데이트 또는 업그레이드에 대한 초기 요청을 받으면 후속 변경 작업을 시작할 수 있습니다. 즉, 다른 변경 작업을 시작할 수 있기 전에 초기 작업이 완료될 때까지 기다릴 필요가 없습니다.

첫 번째 업데이트가 진행 중일 동안 두 번째 업데이트 작업을 시작하는 것은 롤백 작업과 유사하게 수행됩니다. 두 번째 업데이트가 자동 모드에 있는 경우 첫 번째 업그레이드 도메인은 동일한 지점에서 오프라인되는 여러 업그레이드 도메인에서 인스턴스를 이끌도록 즉시 업그레이드됩니다.

변경 작업은 다음과 같습니다. 배포 구성 변경, 배포 업그레이드, 배포 상태 업데이트, 배포 삭제업데이트 또는 업그레이드 롤백.

두 작업 배포 가져오기클라우드 서비스 속성 가져오기는 지정된 배포에서 변경 작업을 호출할 수 있는지 여부를 확인하도록 검사할 수 있는 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개의 작업자 역할 인스턴스를 실행하고 있습니다.

Distribution of Upgrade Domains

참고

Azure는 업그레이드 도메인에 인스턴스가 할당되는 방식을 제어합니다. 어떤 도메인에 어떤 인스턴스를 할당할지를 지정하는 것은 불가능합니다.

다음 단계

Cloud Services를 관리하는 방법
Cloud Services를 모니터링하는 방법
Cloud Services를 구성하는 방법