지역 복원을 사용하여 데이터베이스 백업에서 다중 테넌트 SaaS 애플리케이션 복구

적용 대상: Azure SQL Database

이 자습서에서는 테넌트별 데이터베이스 모델을 사용하여 구현된 다중 테넌트 SaaS 애플리케이션에 대한 전체 재해 복구 시나리오를 살펴봅니다. 지역 복원을 사용하여 카탈로그 및 테넌트 데이터베이스를 자동으로 유지 관리되는 지역 중복 백업에서 대체 복구 지역으로 복구합니다. 가동 중단이 해결되면 지역 복제를 사용하여 변경된 데이터베이스를 원래 지역으로 송환합니다.

지역 복원은 Auzre SQL Database에 대한 가장 저렴한 재해 복구 솔루션입니다. 그러나 지역 중복 백업에서 복원하면 최대 1시간의 데이터 손실이 발생할 수 있습니다. 각 데이터베이스의 크기에 따라 상당한 시간이 걸릴 수 있습니다.

이 자습서에서는 복원 및 송환 워크플로를 모두 살펴봅니다. 다음 방법에 대해 설명합니다.

이 자습서를 시작하기 전에 다음 필수 구성 요소를 완료해야 합니다.

• Wingtip Tickets SaaS Database Per Tenant 앱 배포 5분 안에 배포를 마치려면 Wingtip 티켓 SaaS 테넌트별 데이터베이스 애플리케이션 배포 및 살펴보기를 참조하세요.
• Azure PowerShell을 설치합니다. 자세한 내용은 Azure PowerShell 시작을 참조하세요.

지역 복원 복구 패턴 소개

DR(재해 복구)은 규정 준수 이유 또는 비즈니스 연속성 등 많은 애플리케이션에서 중요한 고려 사항입니다. 서비스 중단 시간이 길어지면 잘 준비된 DR 계획으로 비즈니스 중단을 최소화할 수 있습니다. 지역 복원을 기반으로 하는 DR 계획은 다음과 같은 몇 가지 목표를 달성해야 합니다.

• 선택한 복구 지역에서 필요한 모든 용량을 최대한 빨리 예약하여 테넌트 데이터베이스를 복원하는 데 사용할 수 있도록 합니다.
• 원래 풀 및 데이터베이스 구성을 반영하는 미러 이미지 복구 환경을 설정합니다.
• 원래 리전이 다시 온라인 상태가 되면 복구 프로세스를 도중에 취소할 수 있어야 합니다.
• 새 테넌트 온보딩이 가능한 한 빨리 다시 시작될 수 있도록 테넌트 프로비저닝을 신속하게 사용하도록 설정합니다.
• 우선 순위에 따라 테넌트를 복원할 수 있도록 최적화합니다.
• 실행 시 병렬로 단계를 수행하여 가능한 한 빨리 테넌트를 온라인 상태로 유지하기 위해 최적화
• 실패, 다시 시작 가능 및 idempotent에 대한 복원력 유지
• 중단이 해결될 때 테넌트에 미치는 영향을 최소화하면서 데이터베이스를 원래 리전으로 송환합니다.

이 자습서에서는 Azure SQL Database 및 Azure 플랫폼의 기능을 사용하여 이러한 어려움을 해결합니다.

• 필요한 모든 용량을 가능한 한 빨리 예약하기 위한 Azure Resource Manager 템플릿 Azure Resource Manager 템플릿은 복구 지역의 원래 서버 및 탄력적 풀의 미러 이미지를 프로비전하는 데 사용됩니다. 새 테넌트를 프로비전하기 위해 별도의 서버와 풀도 만들어집니다.
• EDCL(탄력적 데이터베이스 클라이언트 라이브러리) - 테넌트 데이터베이스 카탈로그를 만들고 유지 관리합니다. 확장 카탈로그에는 주기적으로 새로 고쳐진 풀 및 데이터베이스 구성 정보가 포함됩니다.
• EDCL의 분할된 관리 복구 기능 - 복구 및 송환하는 동안 카탈로그의 데이터베이스 위치 항목을 유지 보수합니다.
• 지역 복원을 사용하여 카탈로그 및 테넌트 데이터베이스를 자동으로 유지 관리되는 지역 중복 백업에서 복구합니다.
• 테넌트 우선 순위 순서로 전송되는 비동기 복원 작업은 시스템에서 각 풀에 대해 큐에 대기하고 풀이 오버로드되지 않도록 일괄 처리됩니다. 필요한 경우 실행 전이나 실행 중에 이러한 작업을 취소할 수 있습니다.
• 지역에서 복제 시, 가동 중단이 해결되면 데이터베이스를 원래 리전으로 송환합니다. 지역 복제를 사용하면 데이터 손실이 없고 테넌트에 미치는 영향을 최소화할 수 있습니다.
• SQL 서버 DNS 별칭은 카탈로그 동기화 프로세스가 리전에 관계없이 활성 카탈로그에 연결할 수 있도록 하는 데도 사용됩니다.

재해 복구 스크립트 가져오기

이 자습서에서 사용된 DR 스크립트는 Wingtip Tickets SaaS 테넌트당 데이터베이스 GitHub 리포지토리에서 사용 가능합니다. Wingtip Tickets 관리 스크립트를 다운로드하고 차단을 해제하는 단계는 일반 지침을 확인합니다.

애플리케이션의 정상 상태 검토

복구 프로세스를 시작하기 전에 애플리케이션의 정상 상태를 검토합니다.

1. 웹 브라우저에서 Wingtip Tickets 이벤트 허브(http://events.wingtip-dpt.<user>.trafficmanager.net <user>를 사용자 배포의 사용자 값으로 바꿈)를 엽니다.

   페이지 아래쪽으로 스크롤하여 바닥글의 카탈로그 서버 이름과 위치를 확인합니다. 위치는 앱을 배포한 리전입니다.

   팁

   마우스 커서를 위치 위로 올리면 디스플레이가 확대됩니다.

   

2. Contoso Concert Hall 테넌트를 선택하고 해당 이벤트 페이지를 엽니다.

   바닥글에서 테넌트 서버 이름을 확인합니다. 위치는 카탈로그 서버의 위치와 동일합니다.

   

3. Azure Portal에서 앱이 배포된 리소스 그룹을 열어 검토합니다.

   앱 서비스 구성 요소와 SQL Database가 배포된 리소스와 지역을 확인합니다.

카탈로그로 테넌트 구성 동기화

이 작업에서는 서버, 탄력적 풀 및 데이터베이스의 구성을 테넌트 카탈로그로 동기화하는 프로세스를 시작합니다. 이 정보는 나중에 복구 지역에서 미러 이미지 환경을 구성하는 데 사용됩니다.

1. PowerShell ISE에서 ...\Learning Modules\UserConfig.psm1 파일을 엽니다. 앱을 배포할 때 사용되는 값과 10번째 줄, 11번째 줄의 <resourcegroup> 및 <user>를 바꿉니다. 파일을 저장합니다.

2. PowerShell ISE에서 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 스크립트를 엽니다.

   이 자습서에서는 이 PowerShell 스크립트에서 각 시나리오를 실행하므로 이 파일을 열어 둡니다.

3. 다음과 같이 설정합니다.

   $DemoScenario = 1: 테넌트 서버를 동기화하는 백그라운드 작업 시작 및 구성 정보를 카탈로그로 풀

4. 동기화 스크립트를 실행하려면 F5를 선택하세요.

   이 정보는 나중에 복구 리전에서 서버, 풀 및 데이터베이스의 미러 이미지를 만드는 데 사용됩니다.

   

PowerShell 창을 백그라운드에서 실행 상태로 두고 자습서의 나머지 부분을 계속 진행합니다.

지역 복원 복구 프로세스 개요

지역 복원 복구 프로세스는 애플리케이션을 배포하고 백업에서 복구 리전으로 데이터베이스를 복원합니다.

복구 프로세스는 다음을 수행합니다.

1. 원래 리전의 웹앱에 대한 Azure Traffic Manager 엔드포인트를 사용하지 않도록 설정합니다. 엔드포인트를 사용하지 않도록 설정하면 복구 중에 원래 리전이 온라인 상태가 되어도 사용자가 잘못된 상태로 앱에 연결하는 것을 방지합니다.

2. 복구 지역의 복구 카탈로그 서버를 프로비전하고, 카탈로그 데이터베이스를 지리적으로 복원하며, activecatalog 별칭이 복원된 카탈로그 서버를 가리키도록 업데이트합니다. 카탈로그 별칭을 변경하면 카탈로그 동기화 프로세스가 항상 활성 카탈로그와 동기화됩니다.

3. 복구 카탈로그에 있는 기존의 모든 테넌트를 오프라인으로 표시하여 복원되기 전에 테넌트 데이터베이스에 액세스하지 못하도록 방지합니다.

4. 복구 리전에서 앱 인스턴스를 프로비전하고 해당 리전에서 복원된 카탈로그를 사용하도록 구성합니다. 대기 시간을 최소화하기 위해 샘플 앱은 항상 동일한 지역의 테넌트 데이터베이스에 연결되도록 설계되었습니다.

5. 새 테넌트가 프로비전되는 서버 및 탄력적 풀을 프로비전합니다. 이러한 리소스를 만들면 새 테넌트 프로비전이 기존 테넌트의 복구를 방해하지 않습니다.

6. 복구 지역에서 새 테넌트 데이터베이스에 대한 서버를 가리키도록 새 테넌트 별칭을 업데이트합니다. 이 별칭을 변경하면 모든 새 테넌트의 데이터베이스가 복구 지역에 프로비전됩니다.

7. 테넌트 데이터베이스를 복원하기 위해 복구 리전에 서버 및 탄력적 풀을 프로비전합니다. 이러한 서버 및 풀은 원래 리전의 구성에 대한 미러 이미지입니다. 풀이 미리 프로비전되면 모든 데이터베이스를 복원하는 데 필요한 용량을 예약합니다.

   한 리전의 가동 중단으로 쌍을 이루는 리전에서 사용할 수 있는 리소스에 상당한 부담이 발생할 수 있습니다. DR에 지역 복원을 사용하는 경우 리소스를 빠르게 예약하는 것이 좋습니다. 특정 리전에서 애플리케이션을 복구하는 것이 중요한 경우 지역에서 복제를 고려합니다.

8. 복구 리전의 웹앱에 대해 Traffic Manager 엔드포인트를 사용하도록 설정합니다. 이 엔드포인트를 사용하도록 설정하면 애플리케이션이 새 테넌트를 프로비전할 수 있습니다. 이 단계에서 기존 테넌트는 여전히 오프라인 상태입니다.

9. 우선 순위에 따라 데이터베이스 복구 요청 배치를 제출합니다.

   • 배치는 데이터베이스가 모든 풀에서 병렬로 복구되도록 구성됩니다.

   • 복원 요청은 비동기적으로 제출되므로 신속하게 제출되고 각 풀에서 실행을 위해 큐에 대기됩니다.

   • 복원 요청은 모든 풀에서 병렬로 처리되기 때문에 중요한 테넌트를 여러 풀에 배포하는 것이 좋습니다.

10. 서비스를 모니터링하여 데이터베이스가 복원되는 시기를 확인합니다. 테넌트 데이터베이스가 복원된 후에는 카탈로그에서 온라인으로 표시되고 테넌트 데이터베이스에 대한 rowversion 합계가 기록됩니다.

    • 테넌트 데이터베이스는 카탈로그에서 온라인으로 표시되는 즉시 애플리케이션에서 액세스할 수 있습니다.

    • 테넌트 데이터베이스의 행 변환 값 합계는 카탈로그에 저장됩니다. 이 합계는 지문 역할을 하여 송환 프로세스에서 데이터베이스가 복구 지역에서 업데이트되었는지 확인할 수 있습니다.

복구 스크립트 실행

이제 애플리케이션이 배포되고 복구 스크립트를 실행하는 지역에 가동 중단이 있다고 가정해 보겠습니다.

1. PowerShell ISE의 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 스크립트에서 다음 값을 설정합니다.

   $DemoScenario = 2: 지역 중복 백업에서 복원하여 앱을 복구 리전으로 복구합니다.

2. 스크립트를 실행하려면 F5를 선택합니다.

   • 스크립트가 새 PowerShell 창에서 열리고 병렬로 실행되는 일련의 PowerShell 작업을 시작합니다. 이러한 작업은 서버, 풀 및 데이터베이스를 복구 리전으로 복원합니다.

   • 복구 지역은 애플리케이션을 배포한 Azure 지역과 연결된 쌍을 이루는 지역입니다. 자세한 내용은 Azure 쌍을 이루는 지역을 참조하세요.

3. PowerShell 창에서 복구 프로세스의 상태를 모니터링합니다.

   

복구하는 동안 애플리케이션 상태 검토

Traffic Manager에서 애플리케이션 엔드포인트를 사용하지 않도록 설정되면 해당 애플리케이션을 사용할 수 없습니다. 카탈로그가 복원되고 모든 테넌트가 오프라인으로 표시됩니다. 그런 다음, 복구 지역의 애플리케이션 엔드포인트가 활성화되고 애플리케이션이 다시 온라인 상태가 됩니다. 애플리케이션을 사용할 수 있지만 테넌트는 데이터베이스가 복구될 때까지 이벤트 허브에서 오프라인으로 표시됩니다. 오프라인 테넌트 데이터베이스를 처리하도록 애플리케이션을 디자인하는 것이 중요합니다.

• 카탈로그 데이터베이스가 복구되었으나 테넌트가 온라인이 되기 전이라면, 웹 브라우저에서 Wingtip Tickets 이벤트 허브를 새로 고칩니다.

  • 이제 바닥글에서 카탈로그 서버 이름이 -recovery 접미사를 갖고 있고 복구 지역에 있음을 확인할 수 있습니다.

  • 아직 복원되지 않은 테넌트는 오프라인으로 표시되고 선택할 수 없습니다.

    

  • 테넌트가 오프라인 상태인 동안 테넌트의 이벤트 페이지를 직접 열면 해당 페이지에 '테넌트 오프라인' 알림이 표시됩니다. 예를 들어 Contoso Concert Hall이 오프라인인 경우 http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall을 열어 봅니다.

    

복구 리전에 새 테넌트를 프로비전합니다.

테넌트 데이터베이스가복원되기 전에도 복구 리전에서 새 테넌트를 프로비전할 수 있습니다. 복구 지역에 프로비전된 새 테넌트 데이터베이스는 나중에 복구된 데이터베이스와 함께 송환됩니다.

1. PowerShell ISE의 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 스크립트에서 다음 속성을 설정합니다.

   $DemoScenario = 3 - 복구 리전에 새 테넌트를 프로비전합니다.

2. 스크립트를 실행하려면 F5를 선택합니다.

3. 프로비전이 완료되면 Hawthorn Hall 이벤트 페이지가 브라우저에서 열립니다.

   Hawthorn Hall 데이터베이스는 복구 리전에 있다는 점을 주지하세요.

   

4. 브라우저에서 Wingtip Tickets 이벤트 허브 페이지를 새로 고쳐 Hawthorn Hall이 포함되어 있는지 확인합니다.

   다른 테넌트가 복원될 때까지 기다리지 않고 Hawthorn Hall을 프로비전한 경우 다른 테넌트는 여전히 오프라인 상태일 수 있습니다.

애플리케이션의 복구 상태 검토

복구 프로세스가 완료되면 애플리케이션과 모든 테넌트가 복구 리전에서 완벽하게 작동합니다.

1. PowerShell 콘솔 창 디스플레이에 표시된 후 모든 테넌트가 복구되었음이 표시되면 이벤트 허브를 새로 고칩니다.

   새 테넌트인 Hawthorn Hall을 포함한 모든 테넌트가 온라인으로 표시됩니다.

   

2. Contoso Concert Hall을 클릭하고 해당 이벤트 페이지를 엽니다.

   이제 바닥글에서 데이터베이스가 복구 리전 내 복구 서버에 위치함을 확인할 수 있습니다.

   

3. Azure Portal에서 리소스 그룹 목록을 여세요.

   배포한 리소스 그룹과 복구 리소스 그룹에 -recovery 접미사가 있는지 확인합니다. 복구 리소스 그룹에는 복구 프로세스 중에 생성된 모든 리소스와 가동 중단 중에 생성된 새 리소스가 포함됩니다.

4. 복구 리소스 그룹을 열고 다음 항목을 확인합니다.

   • -recovery 접미사가 있는 카탈로그 및 tenants1 서버의 복구 버전입니다. 이러한 서버의 복원된 카탈로그 및 테넌트 데이터베이스에는 모두 원래 리전에서 사용되는 이름이 있습니다.

   • tenants2-dpt-<user>-recovery SQL 서버 이 서버는 가동 중단 중에 새 테넌트 프로비전에 사용됩니다.

   • 이벤트 앱의 복구 인스턴스인 events-wingtip-dpt-<recoveryregion>-<user>라는 이름의 App Service.

     

5. tenants2-dpt-<user>-recovery SQL 서버를 엽니다. hawthornhall 데이터베이스와 Pool1 탄력적 풀이 포함되어 있음을 확인합니다. hawthornhall 데이터베이스는 Pool1 탄력적 풀의 탄력적 데이터베이스로 구성됩니다.

테넌트 데이터 변경

이 작업에서는 복원된 테넌트 데이터베이스 중 하나를 업데이트합니다. 송환 프로세스는 원래 리전으로 변경된 복원된 데이터베이스를 복사합니다.

1. 브라우저에서 Contoso Concert Hall에 대한 이벤트 목록을 찾고, 이벤트를 스크롤하여 마지막 이벤트인 Seriously Strauss를 적어둡니다.

2. PowerShell ISE의 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 스크립트에서 다음 값을 설정합니다.

   $DemoScenario = 4: 복구 지역의 테넌트에서 이벤트를 삭제합니다.

3. 스크립트를 실행하려면 F5을 선택합니다.

4. Contoso Concert Hall 이벤트 페이지(http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall)를 새로 고치고, Seriously Strauss 이벤트가 누락되어 있는지 확인합니다.

자습서의 이 포인트에서 현재 복구 리전에서 실행 중인 애플리케이션을 복구했습니다. 복구 지역에 새 테넌트를 프로비전하고 복원된 테넌트 중 하나의 데이터를 수정했습니다.

송환 프로세스 개요

송환 프로세스는 중단이 해결된 후 애플리케이션 및 해당 데이터베이스를 원래 리전으로 되돌립니다.

프로세스는 다음과 같습니다.

1. 진행 중인 복원 작업을 중지하고 미해결 또는 진행 중인 데이터베이스 복원 요청을 취소합니다.

2. 중단 이후 변경되지 않은 원래 리전 테넌트 데이터베이스에서 다시 활성화합니다. 이러한 데이터베이스에는 아직 복구되지 않은 데이터베이스와 복구되었지만 나중에 변경되지 않은 데이터베이스가 포함됩니다. 다시 활성화된 데이터베이스는 테넌트에서 마지막으로 액세스한 것과 정확히 같습니다.

3. 원래 리전의 새 테넌트 서버 및 탄력적 풀의 미러 이미지를 프로비전합니다. 이 작업이 완료되면 새 테넌트 별칭이 이 서버를 가리키도록 업데이트됩니다. 별칭을 업데이트하면 복구 리전 대신 원래 리전에서 새 테넌트 온보딩이 발생합니다.

4. 지역에서 복제를 사용하여 카탈로그를 복구 리전에서 원래 리전으로 이동합니다.

5. 원래 리전에서 풀 구성을 업데이트 중단하면 복구 리전에서 변경된 내용과 일치하게 됩니다.

6. 가동 중단 중에 만든 새 데이터베이스를 호스트하는 데 필요한 서버 및 풀을 만듭니다.

7. 지역에서 복제를 사용하여 복원 후 업데이트된 복원된 테넌트 데이터베이스와 가동 중단 중에 프로비전된 모든 새 테넌트 데이터베이스를 송환합니다.

8. 복원 프로세스 중에 복구 지역에서 만든 리소스를 정리합니다.

송환해야 하는 테넌트 데이터베이스 수를 제한하기 위해 1~3단계는 즉시 수행됩니다.

4단계는 가동 중단 중에 복구 지역의 카탈로그가 수정된 경우에만 수행됩니다. 새 테넌트가 만들어지거나 복구 리전에서 데이터베이스 또는 풀 구성이 변경된 경우 카탈로그가 업데이트됩니다.

7단계에서는 테넌트에 중단을 최소화하고 데이터가 손실되지 않도록 하는 것이 중요합니다. 이 목표를 달성하기 위해 프로세스는 지역에서 복제를 사용합니다.

각 데이터베이스가 지역에서 복제하기 전 원래 리전의 해당 데이터베이스가 삭제됩니다. 그런 다음, 복구 지역의 데이터베이스가 지리적으로 복제되어 원래 지역에 보조 복제본을 만듭니다. 복제 작업이 완료되면 테넌트는 카탈로그에서 오프라인으로 표시되어 복구 리전의 데이터베이스에 대한 모든 연결을 끊습니다. 그런 다음 데이터베이스가 장애 조치(failover)되어 보류 중인 트랜잭션이 보조 데이터베이스에서 처리되므로 데이터가 손실되지 않습니다.

장애 조치 시 데이터베이스 역할이 취소됩니다. 원래 리전의 보조 데이터베이스는 기본 읽기-쓰기 데이터베이스가 되고 복구 리전의 데이터베이스는 읽기 전용 보조 데이터베이스가 됩니다. 카탈로그의 테넌트 항목은 원래 지역의 데이터베이스를 참조하도록 업데이트되고 테넌트는 온라인으로 표시됩니다. 이 시점에서 데이터베이스의 송환이 완료됩니다.

연결이 끊어지면 자동으로 다시 연결되도록 애플리케이션을 다시 시도 논리로 작성해야 합니다. 카탈로그를 사용하여 재연결을 조정하는 경우 원래 리전의 송환된 데이터베이스에 연결합니다. 짧은 연결 해제가 자주 발견되지 않지만, 업무 시간 외에서 데이터베이스를 송환하도록 선택할 수 있습니다.

데이터베이스가 송환되면 복구 리전의 보조 데이터베이스를 삭제할 수 있습니다. 그러면 원래 지역의 데이터베이스에서 DR을 보호하기 위해 지역 복원을 다시 사용합니다.

8단계에서는 복구 서버 및 풀을 포함한 복구 리전의 리소스가 삭제됩니다.

송환 스크립트 실행

중단이 해결되고 송환 스크립트를 실행했다고 가정해 보겠습니다.

자습서를 수행한 경우 스크립트는 변경되지 않았으므로 Fabrikam Jazz Club 및 Dogwood Dojo를 원래 지역에서 즉시 다시 활성화합니다. 그런 다음, 새 테넌트인 Hawthorn Hall을 송환하고, Contoso Concert Hall이 수정되었기 때문에 이 Contoso Concert Hall도 송환합니다. 스크립트는 또한 호손 홀이 프로비전될 때 업데이트된 카탈로그를 송환합니다.

1. PowerShell ISE에서 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 스크립트에서, PowerShell 인스턴스에서 Catalog Sync 프로세스가 여전히 실행 중인지 확인합니다.. 필요한 경우 다음을 설정하여 다시 시작합니다.

   $DemoScenario = 1: 카탈로그로의 테넌트 서버, 풀 및 데이터베이스 구성 정보 동기화를 시작합니다.

   스크립트를 실행하려면 F5를 선택합니다.

2. 그런 다음, 송환 프로세스를 시작하려면 다음을 설정합니다.

   $DemoScenario = 5: 앱을 원래 리전으로 송환

   F5 키를 눌러 새 PowerShell 창에서 복구 스크립트를 실행합니다. 송환에는 몇 분 정도 걸리며 PowerShell 창에서 모니터링할 수 있습니다.

3. 스크립트가 실행되는 동안 이벤트 허브 페이지(http://events.wingtip-dpt.<user>.trafficmanager.net)를 새로 고칩니다.

   모든 테넌트는 온라인 상태가 되며 이 프로세스 전체에서 액세스할 수 있습니다.

4. Fabrikam Jazz Club을 선택하여 엽니다. 이 테넌트를 수정하지 않은 경우 바닥글에서 서버가 이미 원래 서버로 되돌아갔는지 확인합니다.

5. Contoso Concert Hall 이벤트 페이지를 열거나 새로 고칩니다. 처음에는 데이터베이스가 여전히 -recovery 서버에 있는지 바닥글에서 확인합니다.

6. 송환 프로세스가 완료되면 Contoso Concert Hall 이벤트 페이지를 새로 고치고, 이제 데이터베이스가 원래 지역에 있는지 확인합니다.

7. 이벤트 허브를 다시 새로 고치고 Hawthorn Hall을 엽니다. 해당 데이터베이스는 원래 리전에도 있습니다.

송환 후 복구 리전 리소스 정리

송환이 완료되면 복구 지역의 리소스를 안전하게 삭제할 수 있습니다.

복원 프로세스는 복구 리소스 그룹에 모든 복구 리소스를 만듭니다. 정리 프로세스는 이 리소스 그룹을 삭제하고, 카탈로그에서 리소스에 대한 모든 참조를 제거합니다.

1. PowerShell ISE의 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 스크립트에서 설정합니다.

   $DemoScenario = 6: 복구 리전에서 사용되지 않는 리소스를 삭제합니다.

2. 스크립트를 실행하려면 F5를 선택합니다.

스크립트가 정리되면 애플리케이션이 시작된 위치로 돌아갑니다. 이 포인트에서 스크립트를 다시 실행하거나 다른 자습서를 사용해 볼 수 있습니다.

애플리케이션 및 데이터베이스가 공동으로 배치되도록 애플리케이션 디자인

애플리케이션은 항상 테넌트 데이터베이스와 동일한 지역에 있는 인스턴스에서 연결되도록 설계되었습니다. 이 디자인은 애플리케이션과 데이터베이스 간의 대기 시간을 줄입니다. 이 최적화에서는 앱-데이터베이스 상호 작용이 사용자-앱 상호 작용보다 더 많이 수행된다고 가정합니다.

테넌트 데이터베이스는 송환 중에 일정 시간 동안 복구 및 원래 리전에 분산될 수 있습니다. 각 데이터베이스에 대해 앱은 테넌트 서버 이름에 대한 DNS 조회를 수행하여 데이터베이스가 있는 리전을 조회합니다. 서버 이름은 별칭입니다. 별칭이 지정된 서버 이름에는 리전 이름이 포함됩니다. 애플리케이션이 데이터베이스와 동일한 리전에 있지 않으면 서버와 동일한 지역의 인스턴스로 리디렉션됩니다. 데이터베이스와 동일한 리전의 인스턴스로 리디렉션하면 앱과 데이터베이스 간의 대기 시간이 최소화됩니다.

다음 단계

이 자습서에서는 다음 작업 방법을 알아보았습니다.

데이터베이스 지역에서 복제를 사용하여 다중 테넌트 SaaS 애플리케이션에 대한 재해 복구 자습서를 시도하여 지역에서 복제를 사용하여 대규모 다중 테넌트 애플리케이션을 복구하는 데 필요한 시간을 크게 줄이는 방법을 알아봅니다.

추가 리소스

Wingtip SaaS 애플리케이션을 빌드하는 또 다른 자습서