데이터베이스 지역에서 복제를 사용하여 다중 테넌트 SaaS 애플리케이션 재해 복구

적용 대상:Azure SQL Database

이 자습서에서는 테넌트별 데이터베이스 모델을 사용하여 구현된 다중 테넌트 SaaS 애플리케이션에 대한 전체 재해 복구 시나리오를 살펴봅니다. 중단으로부터 앱을 보호하기 위해 지역 복제를 사용하여 대체 복구 리전에서 카탈로그 및 테넌트 데이터베이스에 대한 복제본(replica)을 만듭니다. 작동 중단이 발생할 경우 이러한 복제본으로 신속하게 장애 조치(failover)하여 정상적인 비즈니스 작업을 재개합니다. 장애 조치(failover) 시 원래 리전의 데이터베이스는 복구 리전에 있는 데이터베이스의 보조 복제본(replica)이 됩니다. 이러한 복제본(replica)이 다시 온라인 상태가 되면 복구 리전의 데이터베이스 상태를 자동으로 파악합니다. 중단이 해결되면 원래 프로덕션 리전의 데이터베이스로 장애를 복구합니다.

이 자습서에서는 장애 조치(failover) 워크플로와 장애 복구(failback) 워크플로를 모두 살펴봅니다. 이 문서에서 배울 내용은 다음과 같습니다.

• 테넌트 카탈로그로의 탄력적 풀 및 데이터베이스 구성 정보 동기화
• 애플리케이션, 서버 및 풀로 구성된 대체 리전에서 복구 환경 설정
• 지역에서 복제를 사용하여 카탈로그 및 테넌트 데이터베이스를 복구 리전으로 복제
• 애플리케이션 및 카탈로그와 테넌트 데이터베이스를 복구 지역으로 장애 조치(Failover)
• 나중에 애플리케이션, 카탈로그 및 테넌트 데이터베이스를 원래 지역으로 다시 장애 복구(Failback)
• 각 테넌트 데이터베이스가 장애 조치(failover)되어 각 테넌트 데이터베이스의 기본 위치를 추적하도록 카탈로그를 업데이트합니다.
• 대기 시간을 줄이기 위해 애플리케이션 및 주 테넌트 데이터베이스가 항상 동일한 Azure 리전에 공동 배치되어 있는지 확인합니다.

이 자습서를 시작하기 전에 다음 필수 구성 요소가 완료되었는지 확인합니다.

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

지역 복제 복구 패턴 소개

DR(재해 복구)은 규정 준수 이유 또는 비즈니스 연속성 등 많은 애플리케이션에서 중요한 고려 사항입니다. 서비스 중단 시간이 길어지면 잘 준비된 DR 계획으로 비즈니스 중단을 최소화할 수 있습니다. 지역 복제를 사용하면 짧은 시간에 장애 조치(failover)할 수 있는 복구 리전의 데이터베이스 복제본(replica)을 유지 보수하며 가장 낮은 RPO 및 RTO를 제공합니다.

지역 복제 기반 DR 계획은 다음과 같은 세 가지 개별 부분으로 구성됩니다.

• 설정 - 복구 환경 유지 보수 및 기본 테넌트
• 복구 - 작동 중단 발생 시 앱 및 데이터베이스를 복구 환경으로 장애 조치(Failover)
• 송환 - 애플리케이션이 확인되면 앱 및 데이터베이스를 다시 원래 지역으로 장애 조치(Failover)

모든 부분을 신중히 고려해야 하며 대규모로 운영하는 경우에는 특히 신중해야 합니다. 전반적으로 이 계획은 다음과 같은 몇 가지 목표를 달성해야 합니다.

• 설정
  • 복구 리전에서 미러 이미지 환경을 설정하고 유지 보수. 이 복구 환경에서 탄력적 풀을 만들고 데이터베이스를 복제하면 복구 지역의 용량이 보존됩니다. 이 환경을 유지 보수하는 것은 프로비전될 때 새 테넌트 데이터베이스를 복제하는 것을 포함합니다.
• 복구
  • 일일 비용을 최소화하기 위해 규모가 축소된 복구 환경을 사용하는 경우 풀 및 데이터베이스를 강화하여 복구 지역의 전체 운영 용량을 확보해야 합니다.
  • 가능한 한 빨리 복구 리전에서 새 테넌트 프로비저닝 사용
  • 우선 순위에 따라 테넌트를 복원할 수 있도록 최적화합니다.
  • 실용적인 경우 병렬로 단계를 수행하여 가능한 한 빨리 테넌트를 온라인 상태로 유지하기 위해 최적화
  • 실패, 다시 시작 가능 및 idempotent에 대한 복원력 유지
  • 원래 지역이 다시 온라인 상태가 되면 프로세스를 도중에 취소할 수 있어야 합니다.
• 송환
  • 테넌트에 최소한의 영향만 미치고, 데이터 손실을 발생하지 않고, 테넌트당 오프라인 기간을 최소화하면서 복구 지역의 데이터베이스를 원래 지역의 복제본으로 장애 조치(Failover)합니다.

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

• 필요한 모든 용량을 가능한 한 빨리 예약하기 위한 Azure Resource Manager 템플릿 Azure Resource Manager 템플릿은 복구 지역의 프로덕션 서버 및 탄력적 풀의 미러 이미지를 프로비전하는 데 사용됩니다.
• 지역에서 복제 - 모든 데이터베이스에 대해 비동기적으로 복제된 읽기 전용 보조 데이터베이스를 만듭니다. 중단 시 복구 리전의 복제본(replica)에 장애 조치(failover)합니다. 중단이 해결되면 데이터 손실 없이 원래 리전의 데이터베이스로 장애를 복구합니다.
• 비동기 - 많은 수의 데이터베이스에 대한 장애 조치(Failover) 시간을 최소화하기 위해 테넌트 우선 순위에 따라 장애 조치(Failover) 작업이 전송됩니다.
• 분할된 관리 복구 기능 - 복구 및 송환하는 동안 카탈로그의 데이터베이스 항목을 변경합니다. 이러한 기능을 통해 앱은 다시 구성하지 않고도 위치에 관계없이 테넌트 데이터베이스에 연결할 수 있습니다.
• SQL Server DNS 에일리어스, 앱이 작동하는 리전에 관계없이 새 테넌트에 원활하게 프로비저닝하기 DNS 에일리어스는 카탈로그 동기화 프로세스가 리전에 관계없이 활성 카탈로그에 연결할 수 있도록 하는 데도 사용됩니다.

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

Important

모든 Wingtip Tickets 관리 스크립트와 마찬가지로 DR 스크립트는 샘플 품질이며 프로덕션에서 사용할 수 없습니다.

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

자습서 개요

이 자습서에서는 먼저 지역에서 복제를 사용하여 Wingtip Tickets 애플리케이션 및 해당 데이터베이스의 복제본(replica)을 다른 리전에 만듭니다. 그런 다음, 이 지역으로 장애 조치(Failover)하여 작동 중단에서 복구하는 과정을 시뮬레이트합니다. 완료되면 애플리케이션이 복구 리전에서 완벽하게 작동합니다.

나중에, 별도의 송환 단계에서 복구 지역의 카탈로그 및 테넌트 데이터베이스를 원래 지역으로 장애 조치(Failover)합니다. 애플리케이션 및 데이터베이스는 송환 기간 내내 계속 사용할 수 있습니다. 완료되면 애플리케이션은 원래 지역에서 완벽하게 작동합니다.

참고 항목

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

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

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

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

   • 페이지 아래쪽으로 스크롤하여 바닥글의 카탈로그 서버 이름과 위치를 확인합니다. 위치는 앱을 배포한 리전입니다. 팁: 마우스 커서를 위치 위로 올리면 디스플레이가 확대됩니다.

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

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

3. Azure Portal에서 앱이 배포된 리소스 그룹을 엽니다.

   • 서버가 배포되는 리전을 확인합니다.

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

이 작업에서는 서버, 탄력적 풀 및 데이터베이스의 구성을 테넌트 카탈로그로 동기화하는 프로세스를 시작합니다. 이 프로세스는 정보를 카탈로그에 최신 상태로 유지합니다. 또한 원래 지역에 있든, 복구 지역에 있든 관계없이 활성 카탈로그가 프로세스에서 사용됩니다. 구성 정보는 복구 환경이 원래 환경과 일치하도록 복구 프로세스의 일부로 사용되며, 나중에 송환 중에 원래 리전이 복구 환경에서 변경된 내용과 일치하도록 보장합니다. 카탈로그는 테넌트 리소스의 복구 상태를 추적하는 데도 사용됩니다.

Important

편의상, 이러한 자습서에서는 동기화 프로세스 및 다른 장기 실행 복구/송환 프로세스가 클라이언트 사용자 로그인에서 실행되는 로컬 PowerShell 작업 또는 세션으로 구현됩니다. 로그인할 때 발급된 인증 토큰은 몇 시간 후에 만료되어 작업이 실패합니다. 프로덕션 시나리오에서 장기 실행 프로세스는 서비스 주체에서 실행되는 어떤 종류의 신뢰할 수 있는 Azure 서비스로 구현되어야 합니다. Azure PowerShell을 사용하여 인증서로 서비스 주체 만들기를 참조하세요.

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

2. PowerShell ISE에서 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 스크립트를 열고 설정합니다.

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

3. F5 키를 눌러 동기화 스크립트를 실행합니다. 테넌트 리소스의 구성을 동기화하기 위해 열린 새 PowerShell 세션

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

참고 항목

동기화 프로세스는 DNS 별칭을 통해 카탈로그에 연결합니다. 이 별칭은 복원 및 송환 중에 활성 카탈로그를 가리키도록 수정됩니다. 동기화 프로세스는 복구 리전에서 변경된 데이터베이스 또는 풀 구성 변경 내용으로 카탈로그를 최신 상태로 유지합니다. 송환 중에 이러한 변경 내용은 원래 리전의 해당 리소스에 적용됩니다.

복구 리전에서 보조 데이터베이스 복제본(replica) 만들기

이 작업에서는 중복된 앱 인스턴스를 배포하고, 카탈로그 및 모든 테넌트 데이터베이스를 복구 지역에 복제하는 프로세스를 시작합니다.

참고 항목

이 자습서에서는 Wingtip Tickets 샘플 애플리케이션에 지역에서 보제 보호를 추가합니다. 지역에서 복제를 사용하는 애플리케이션의 프로덕션 시나리오에서 각 테넌트는 처음부터 지역에서 복제 데이터베이스로 프로비전됩니다. Azure SQL Database를 사용하여 항상 사용 가능한 서비스 디자인을 참조하세요.

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

   • $DemoScenario = 2, 미러 이미지 복구 환경 만들기 및 카탈로그 및 테넌트 데이터베이스 복제

2. F5 키를 눌러 스크립트를 실행합니다. 복제본(replica)을 만들기 위해 새 PowerShell 세션이 열립니다.

일반 애플리케이션 상태 검토

이 시점에서 애플리케이션은 원래 리전에서 정상적으로 실행되며 이제 지역에서 복제가 보호됩니다. 읽기 전용 보조 복제본(replica)은 모든 데이터베이스의 복구 리전에 존재합니다.

1. Azure Portal에서 리소스 그룹을 살펴보고 리소스 그룹이 복구 리전에서 -recovery 접미사를 사용하여 만들어졌음을 확인합니다.

2. 복구 리소스 그룹에서 리소스를 탐색합니다.

3. tenants1-dpt-<user>-recovery 서버에서 Contoso Concert Hall 데이터베이스를 클릭합니다. 왼쪽의 지역에서 복제를 클릭합니다.

   

Azure 지역 맵에서 원래 리전의 주 리전과 복구 리전의 보조 리전 간 지역에서서 복제 연결에 유의하세요.

애플리케이션을 복구 리전으로 장애 조치(failover)

지역에서 복제 복구 프로세스 개요

복구 스크립트는 다음 작업을 수행합니다.

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

2. 복구 리전에서 카탈로그 데이터베이스의 강제 장애 조치(failover)를 사용하여 주 데이터베이스로 만들고 activecatalog 별칭을 업데이트하여 복구 카탈로그 서버를 가리킵니다.

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

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

5. 원래 지역의 해당 구성을 미러링하도록 복구 지역에 있는 모든 탄력적 풀 및 복제된 단일 데이터베이스의 구성을 업데이트합니다. (이 작업은 비용 절감을 위해 정상적인 작업 중에 풀 또는 복제 데이터베이스가 축소된 경우에만 필요합니다.)

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

7. 우선 순위에 따라 데이터베이스 장애 조치(failover)를 강제하기 위해 요청 배치를 제출합니다.

   • 배치는 데이터베이스가 모든 풀에서 병렬로 장애 조치(failover)되도록 구성됩니다.
   • 장애 조치 요청은 비동기 작업을 사용하여 제출되므로 신속하게 제출되고 여러 요청을 동시에 처리할 수 있습니다.

   참고 항목

   중단 시나리오에서 원래 리전의 주 데이터베이스는 오프라인 상태입니다. 보조 데이터베이스의 강제 장애 조치(failover)는 대기 중인 잔여 트랜잭션을 적용하지 않고 주 복제본에 대한 연결을 끊습니다. 이 자습서와 같은 DR 드릴 시나리오에서 장애 조치(failover) 시 업데이트 작업이 있는 경우 데이터가 손실될 수 있습니다. 나중에 송환을 수행하는 동안, 복구 지역의 데이터베이스를 원래 지역으로 다시 장애 조치(Failover)할 경우 데이터 손실을 방지하기 위해 일반 장애 조치(Failover)가 사용됩니다.

8. 서비스를 모니터링하여 데이터베이스가 장애 조치된 시기를 결정합니다. 테넌트 데이터베이스가 장애 조치되면 테넌트 데이터베이스의 복구 상태를 기록하고 테넌트를 온라인 상태로 표시하도록 카탈로그를 업데이트합니다.

   • 테넌트 데이터베이스는 카탈로그에서 온라인으로 표시되는 즉시 애플리케이션에서 액세스할 수 있습니다.
   • 테넌트 데이터베이스의 행 변환 값 합계는 카탈로그에 저장됩니다. 이 값은 지문 역할을 하여 송환 프로세스에서 데이터베이스가 복구 리전에서 업데이트되었는지 확인할 수 있습니다.

스크립트를 실행하여 복구 리전으로 장애 조치(failover)

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

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

   • $DemoScenario = 3, 복제본(replica) 장애 조치(failover)를 통해 앱을 복구 리전으로 복원

2. F5 키를 눌러 스크립트를 실행합니다.

   • 스크립트가 새 PowerShell 창에서 열리고 병렬로 실행되는 일련의 PowerShell 작업을 시작합니다. 이러한 작업은 테넌트 데이터베이스를 복구 지역으로 장애 조치(failover)합니다.
   • 복구 지역은 애플리케이션을 배포한 Azure 지역과 연결된 쌍을 이루는 지역입니다. 자세한 내용은 Azure 쌍을 이루는 지역을 참조하세요.

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

참고 항목

복구 작업 코드를 살펴보려면 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\RecoveryJobs 폴더에서 PowerShell 스크립트를 검토합니다.

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

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

1. 카탈로그 데이터베이스가 복구되면 즉시 웹 브라우저에서 Wingtip Tickets 이벤트 허브를 새로 고칩니다.

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

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

     참고 항목

     복구할 데이터베이스가 거의 없으면 복구가 완료되기 전에 브라우저를 새로 고칠 수 없으므로 오프라인 상태인 동안 테넌트가 표시되지 않을 수 있습니다.

     

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

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

모든 기존 테넌트 데이터베이스가 장애 조치(failover)되기 전에도 복구 리전에서 새 테넌트를 프로비전할 수 있습니다.

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

   • $DemoScenario = 4 - 복구 지역에 새 테넌트를 프로비전합니다.

2. F5 키를 눌러 스크립트를 실행하고 새 테넌트에 프로비전합니다.

3. 완료되면 Hawthorn Hall 이벤트 페이지가 브라우저에서 열립니다. 바닥글에서 Hawthorn Hall 데이터베이스가 복구 지역에서 프로비전된다는 것을 알 수 있습니다.

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

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

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

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

1. PowerShell 콘솔 창 디스플레이에 표시되면 모든 테넌트가 복구되었음이 표시되면 이벤트 허브를 새로 고칩니다. 새 테넌트인 Hawthorn Hall을 포함하여 모든 테넌트가 온라인으로 표시됩니다.

   

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

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

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

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

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

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

     

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

5. 리소스 그룹으로 다시 이동한 후 tenants1-dpt-<user>-recovery 서버에서 Contoso Concert Hall 데이터베이스를 클릭합니다. 왼쪽의 지역에서 복제를 클릭합니다.

   

테넌트 데이터 변경

이 작업에서는 테넌트 데이터베이스 중 하나를 업데이트합니다.

1. 브라우저에서 Contoso Concert Hall의 이벤트 목록을 찾고 마지막 이벤트 이름을 적어 둡니다.
2. PowerShell ISE의 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 스크립트에서 다음 값을 설정합니다.
   • $DemoScenario = 5 복구 리전의 테넌트에서 이벤트를 삭제합니다.
3. F5 키를 눌러 스크립트를 실행합니다.
4. Contoso Concert Hall 이벤트 페이지(http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall - substitute <user>를 배포의 사용자 값으로 바꿈)를 새로 고치고 마지막 이벤트가 삭제된 것을 확인합니다.

애플리케이션을 원래 프로덕션 지역으로 송환

이 작업은 애플리케이션을 원래 지역으로 송환합니다. 실제 시나리오에서는 중단이 해결되면 송환을 시작합니다.

송환 프로세스 개요

송환 프로세스:

1. 미해결 또는 실행 중인 데이터베이스 복원 요청을 취소합니다.
2. 원래 리전에서 테넌트의 서버를 가리키도록 newtenant 별칭을 업데이트합니다. 이 별칭을 변경하면 모든 새 테넌트의 데이터베이스가 원래 리전에 즉시 프로비전 되도록 합니다.
3. 변경된 테넌트 데이터를 원래 리전으로 시드
4. 우선 순위에 따라 테넌트 데이터베이스를 장애 조치(fails over)합니다.

장애 조치(failover)는 데이터베이스를 원래 리전으로 효과적으로 이동시킵니다. 데이터베이스가 장애 조치되면 열려 있는 연결이 삭제되고 몇 초 동안 데이터베이스를 사용할 수 없습니다. 애플리케이션을 다시 연결하려면 재시도 논리를 사용하여 작성해야 합니다. 짧은 연결 해제가 자주 발견되지 않지만, 업무 시간 외에 데이터베이스를 송환하도록 선택할 수 있습니다.

송환 스크립트 실행

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

1. PowerShell ISE의 ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 스크립트

2. 카탈로그 동기화 프로세스가 PowerShell 인스턴스에서 계속 실행 중인지 확인합니다. 필요한 경우 다음을 설정하여 다시 시작합니다.

   • $DemoScenario = 1, 카탈로그로의 테넌트 서버, 풀 및 데이터베이스 구성 정보 동기화를 시작합니다.
   • F5 키를 눌러 스크립트를 실행합니다.

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

   • $DemoScenario = 6, 앱을 원래 리전으로 송환
   • F5 키를 눌러 새 PowerShell 창에서 복구 스크립트를 실행합니다. 송환에는 몇 분 정도 걸리며 PowerShell 창에서 모니터링할 수 있습니다.

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

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

5. 송환이 완료되면 이벤트 허브를 새로 고치고 Hawthorn Hall에 대한 이벤트 페이지를 엽니다. 이 데이터베이스는 원래 리전으로 송환되었습니다.

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

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

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

다음 단계

이 자습서에서는 다음 방법에 대해 알아보았습니다.

• 테넌트 카탈로그로의 탄력적 풀 및 데이터베이스 구성 정보 동기화
• 애플리케이션, 서버 및 풀로 구성된 대체 리전에서 복구 환경 설정
• 지역에서 복제를 사용하여 카탈로그 및 테넌트 데이터베이스를 복구 리전으로 복제
• 애플리케이션 및 카탈로그와 테넌트 데이터베이스를 복구 지역으로 장애 조치(Failover)
• 중단 해결 후 애플리케이션, 카탈로그 및 테넌트 데이터베이스를 원래 리전으로 다시 장애 복구(Failback)

비즈니스 연속성 개요 설명서에서 비즈니스 연속성을 활성화하기 위해 Azure SQL Database에서 제공하는 기술에 대해 자세히 알아볼 수 있습니다.

추가 리소스

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