SQL Database 활성 지역 복제를 사용하여 클라우드 애플리케이션의 롤링 업그레이드 관리

적용 대상: Azure SQL Database

Azure SQL Database의 활성 지역 복제를 사용하여 클라우드 애플리케이션의 롤링 업그레이드를 사용하도록 설정하는 방법을 알아봅니다. 업그레이드는 중단 작업이므로 무중단 업무 방식 계획 및 설계의 일부여야 합니다. 이 문서에서는 업그레이드 프로세스를 오케스트레이션하는 두 가지 방법을 살펴보고 각 옵션의 장점과 단점에 대해 설명합니다. 이 문서에서는 해당 데이터 계층으로 단일 데이터베이스에 연결된 웹 사이트로 구성된 애플리케이션을 사용합니다. 우리의 목표는 사용자 경험에 큰 영향을 주지 않고 애플리케이션의 버전 1(V1)을 버전 2(V2)로 업그레이드하는 것입니다.

업그레이드 옵션을 평가할 때는 다음 요소를 고려합니다.

• 업그레이드 중에 애플리케이션 기능이 제한되거나 성능이 저하되는 기간 등 애플리케이션 가용성에 미칠 수 있는 영향.
• 업그레이드에 실패하는 경우 다시 롤백하는 기능
• 업그레이드 중에 관련 없는 치명적인 오류가 발생하는 경우 애플리케이션의 취약성
• 총 달러 비용. 여기에는 업그레이드 프로세스에서 사용되는 임시 구성 요소의 추가 데이터베이스 중복 및 증분 비용이 포함됩니다.

재해 복구를 위해 데이터베이스 백업을 사용하는 애플리케이션 업그레이드

애플리케이션이 자동 데이터베이스 백업을 사용하고 재해 복구에 지역 복원을 사용하는 경우 단일 Azure 지역에 배포됩니다. 사용자 중단을 최소화하려면 업그레이드와 관련된 모든 애플리케이션 구성 요소를 사용하여 해당 지역에 스테이징 환경을 만듭니다. 첫 번째 다이어그램은 업그레이드 프로세스 전의 운영 환경을 보여줍니다. 엔드포인트 contoso.azurewebsites.net은 웹앱의 프로덕션 환경을 나타냅니다. 업그레이드를 롤백할 수 있으려면, 데이터베이스의 완전히 동기화된 복사본으로 스테이징 환경을 만들어야 합니다. 업그레이드를 위한 스테이징 환경을 만들려면 다음 단계를 따릅니다.

1. 동일한 Azure 지역에 보조 데이터베이스를 만듭니다. 보조 데이터베이스를 모니터링하여 시드 프로세스가 완료되었는지 확인합니다(1).
2. 웹앱에 대한 새 환경을 만들고 이를 '스테이징'이라고 합니다. 이 환경은 Azure DNS에 URL contoso-staging.azurewebsites.net으로 등록됩니다(2).

참고 항목

이러한 준비 단계는 전체 액세스 모드에서 작동할 수 있는 프로덕션 환경에는 영향을 주지 않습니다.

준비 단계가 완료되면 애플리케이션이 실제 업그레이드할 준비가 된 것입니다. 다음 다이어그램은 업그레이드 프로세스와 관련된 단계를 보여줍니다.

1. 주 데이터베이스를 읽기 전용 모드로 설정합니다(3). 이 모드는 업그레이드 동안 웹앱(V1)의 프로덕션 환경을 읽기 전용으로 유지하여 V1 및 V2 데이터베이스 인스턴스 간에 데이터베이스가 확산되지 않습니다.
2. 계획된 종료 모드를 사용하여 보조 데이터베이스의 연결을 끊습니다(4). 이 작업으로 주 데이터베이스의 완전히 동기화된 독립적인 복사본이 생성됩니다. 이 데이터베이스는 업그레이드됩니다.
3. 보조 데이터베이스를 읽기-쓰기 모드로 설하고 업그레이드 스크립트를 실행합니다(5).

업그레이드가 성공적으로 완료되면 이제 사용자를 업그레이드된 애플리케이션 복사본으로 전환할 준비가 되었으며, 이것이 프로덕션 환경이 됩니다. 전환 과정에는 다음 다이어그램에 설명된 대로 몇 가지 단계가 더 포함됩니다.

1. 웹앱의 프로덕션 환경과 스테이징 환경 간 전환 작업을 활성화합니다(6). 이 작업은 두 환경의 URL을 전환합니다. 이제 contoso.azurewebsites.net은 웹 사이트 및 데이터베이스(프로덕션 환경)의 V2 버전를 가리킵니다.
2. 전환 후에 스테이징 복사본이 된 V1 버전이 더 이상 필요하지 않으면 스테이징 환경을 서비스 해제할 수 있습니다(7).

업그레이드 스크립트의 오류 등으로 인해 업그레이드 프로세스가 실패하면 스테이징 환경은 손상된 것으로 간주됩니다. 애플리케이션을 업그레이드 전 상태로 롤백하려면 프로덕션 환경의 애플리케이션을 모든 권한으로 되돌리면 됩니다. 다음 다이어그램은 회귀 단계를 보여줍니다.

1. 데이터베이스 복사본을 읽기-쓰기 모드로 설정합니다(8). 이 작업은 프로덕션 복사본의 전체 V1 기능을 복원합니다.
2. 근본 원인 분석을 수행하고 스테이징 환경을 해제합니다(9).

이 시점에서 애플리케이션은 완벽하게 작동하며 업그레이드 단계를 반복할 수 있습니다.

참고 항목

아직 전환 작업을 수행하지 않았으므로 롤백에서 DNS를 변경할 필요가 없습니다.

이 옵션의 주요 이점은 일련의 간단한 단계를 따라 단일 지역에서 애플리케이션을 업그레이드할 수 있다는 것입니다. 업그레이드의 달러 비용은 상대적으로 낮습니다.

하지만 업그레이드 중에 치명적인 오류가 발생하는 경우 업그레이드 전 상태로 복구할 때 다른 지역에 애플리케이션이 다시 배포되며 지역 복원을 사용하여 백업에서 데이터베이스가 복원된다는 주요 단점이 있습니다. 이 과정에서 상당한 가동 중지 시간이 발생합니다.

재해 복구에 대해 데이터베이스 지역에서 복제를 사용하는 애플리케이션 업그레이드

애플리케이션이 무중단 업무 방식을 위해 활성 지역 복제 또는 장애 조치 그룹을 사용하는 경우 애플리케이션은 두 개 이상의 서로 다른 지역에 배포됩니다. 주 지역에는 활성 상태의 주 데이터베이스가 있고 백업 지역에는 읽기 전용 보조 데이터베이스가 있습니다. 이 문서의 시작 부분에 언급된 요소와 함께, 업그레이드 프로세스에는 다음 요소도 보장해야 합니다.

• 업그레이드 프로세스 중에 애플리케이션은 항상 치명적인 오류로부터 보호되어야 합니다.
• 애플리케이션의 지역 중복 구성 요소는 활성화된 구성 요소와 함께 병렬로 업그레이드되어야 합니다.

이러한 목표를 달성하기 위해 Web Apps 환경을 사용하는 동시에 활성 엔드포인트와 백업 엔드포인트가 하나씩 포함된 장애 조치(failover) 프로필을 사용하는 ATM(Azure Traffic Manager)을 활용하게 됩니다. 다음 다이어그램에서는 업그레이드 프로세스 전의 운영 환경을 보여 줍니다. 웹 사이트 contoso-1.azurewebsites.net 및 contoso-dr.azurewebsites.net은 전체 지리적 중복성을 가진 애플리케이션의 프로덕션 환경을 나타냅니다. 프로덕션 환경에는 다음 구성 요소가 포함됩니다.

• 주 지역에 있는 웹앱 contoso-1.azurewebsites.net의 프로덕션 환경(1)
• 주 지역의 주 데이터베이스(2)
• 백업 지역에 있는 웹앱의 대기 인스턴스(3)
• 백업 지역의 지역에서 복제된 보조 데이터베이스(4)
• 온라인 엔드포인트 contoso-1.azurewebsites.net 및 오프라인 엔드포인트 contoso-dr.azurewebsites.net이 포함된 Azure Traffic Manager 성능 프로필

업그레이드를 롤백할 수 있도록 하려면 애플리케이션의 완전히 동기화된 복사본이 있는 스테이징 환경을 만들어야 합니다. 업그레이드 프로세스 중에 치명적인 오류가 발생하는 경우 애플리케이션이 빠르게 복구되도록 해야 하므로 스테이징 환경도 지역 중복 환경으로 만들어야 합니다. 업그레이드를 위한 스테이징 환경을 만들려면 다음 단계가 필요합니다.

1. 주 지역에 웹앱의 스테이징 환경을 배포합니다(6).
2. 주 Azure 지역에 보조 데이터베이스를 만듭니다(7). 웹앱의 스테이징 환경을 구성하여 연결합니다.
3. 주 지역의 보조 데이터베이스를 복제하여 백업 지역에 또다른 지역 중복 보조 데이터베이스를 만듭니다 (이 메서드를 연결된 지역에서 복제라고 합니다.)(8).
4. 백업 지역에 웹앱 인스턴스의 스테이징 환경을 배포하고(9) (8)에서 만든 지역 중복 보조 데이터베이스를 연결하도록 구성합니다.

참고 항목

이러한 준비 단계는 프로덕션 환경의 애플리케이션에 영향을 주지 않습니다. 읽기-쓰기 모드에서 정상적으로 작동합니다.

준비 단계가 완료되면 스테이징 환경이 업그레이드할 준비가 된 것입니다. 다음 다이어그램은 이러한 업그레이드 단계를 보여줍니다.

1. 프로덕션 환경의 주 데이터베이스를 읽기 전용 모드로 설정합니다(10). 이 모드에서는 업그레이드 중에 프로덕션 데이터베이스(V1)가 변경되지 않으므로 V1 및 V2 데이터베이스 인스턴스 간에 데이터베이스가 확산되지 않습니다.

-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY

2. 보조의 연결을 끊어 지역에서 복제를 종료합니다(11). 이 작업으로 프로덕션 데이터베이스의 완전히 동기화된 독립 복사본이 생성됩니다. 이 데이터베이스는 업그레이드됩니다. 다음 예제에서는 Transact-SQL을 사용하지만 PowerShell도 사용할 수 있습니다.

-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]

3. contoso-1-staging.azurewebsites.net, contoso-dr-staging.azurewebsites.net, 스테이징 주 데이터베이스에 대해 업그레이드 스크립트를 실행합니다(12). 데이터베이스 변경 내용이 스테이징 보조 데이터베이스에 자동으로 복제됩니다.

업그레이드가 성공적으로 완료되면 이제 사용자를 V2 버전 애플리케이션으로 전환할 준비가 되었습니다. 다음 다이어그램은 관련 단계를 보여줍니다.

1. 주 지역(13)과 백업 지역(14)에서 웹앱의 프로덕션 및 스테이징 환경 간 전환 작업을 활성화합니다. 이제 애플리케이션 V2 버전이 프로덕션 환경이 되고, 백업 지역에는 중복 복사본이 생성됩니다.
2. V1 애플리케이션(15 및 16)이 더 이상 필요하지 않은 경우 스테이징 환경을 해제할 수 있습니다.

업그레이드 스크립트의 오류 등으로 인해 업그레이드 프로세스가 실패하면 스테이징 환경이 일관되지 않은 상태인 것으로 간주됩니다. 애플리케이션을 업그레이드 전 상태로 롤백하려면 프로덕션 환경의 애플리케이션 V1을 사용하도록 되돌립니다. 다음 다이어그램에 필요한 단계가 나와 있습니다.

1. 프로덕션 환경의 주 데이터베이스 복사본을 읽기-쓰기 모드로 설정합니다(17). 이 작업은 프로덕션 환경의 전체 V1 기능을 복원합니다.
2. 근본 원인 분석을 수행하고 스테이징 환경을 복구하거나 제거합니다(18 및 19).

이 시점에서 애플리케이션은 완벽하게 작동하며 업그레이드 단계를 반복할 수 있습니다.

참고 항목

전환 작업을 수행하지 않았으므로 롤백에서 DNS를 변경할 필요가 없습니다.

이 옵션의 주요 이점은 업그레이드하는 동안 무중단 업무 방식을 손상시키지 않고 애플리케이션과 해당 지역 중복 복사본을 동시에 업그레이드할 수 있다는 것입니다.

주 단점은 각 애플리케이션 구성 요소의 이중 중복이 필요하므로 더 높은 달러 비용이 발생한다는 것입니다. 또한 워크플로가 더 복잡합니다.

요약

이 문서에서 설명하는 두 가지 업그레이드 방법은 복잡성과 달러 비용에서 차이가 있지만 둘 다 사용자가 읽기 전용 작업으로 제한되는 기간을 최소화하는 데 중점을 둡니다. 해당 시간은 업그레이드 스크립트의 기간에 의해 직접적으로 정의됩니다. 이는 데이터베이스 크기, 선택한 서비스 계층, 웹 사이트 구성 또는 쉽게 제어할 수 없는 기타 요인에 따라 달라지지 않습니다. 모든 준비 단계가 업그레이드 단계와 분리되어 있고 프로덕션 애플리케이션에 영향을 주지 않습니다. 업그레이드 중에 사용자 환경을 결정하는 핵심 요소 중 하나는 업그레이드 스크립트의 효율성입니다. 따라서 이러한 환경을 개선하는 가장 좋은 방법은 업그레이드 스크립트를 최대한 효율적으로 만드는 데 집중하는 것입니다.

관련 콘텐츠

• 무중단 업무 방식 개요.
• 활성 지역 복제를 사용하여 읽기 가능한 보조 데이터베이스 만들기.
• 장애 조치 그룹을 통해 여러 데이터베이스의 투명하고 조정된 장애 조치 사용.
• Azure App Service에서 스테이징 환경 설정
• Azure Traffic Manager 프로필 관리.