Azure SQL Database 탄력적 풀을 사용하는 애플리케이션 재해 복구 전략

적용 대상: Azure SQL Database

Azure SQL Database는 재해 발생 시 애플리케이션의 비즈니스 연속성을 위해 몇 가지 기능을 제공합니다. 탄력적 풀 및 단일 데이터베이스는 동일한 종류의 DR(재해 복구) 기능을 지원합니다. 이 문서에서는 Azure SQL Database 비즈니스 연속성 기능을 활용하는 탄력적 풀에 대한 몇 가지 DR 전략을 설명합니다.

이 문서에서는 다음과 같은 canonical SaaS ISV 애플리케이션 패턴을 사용합니다.

최신 클라우드 기반 웹 애플리케이션은 최종 사용자마다 하나의 데이터베이스를 프로비저닝합니다. ISV에는 많은 고객이 있으므로 테넌트 데이터베이스라고 하는 많은 데이터베이스를 사용합니다. 일반적으로 테넌트 데이터베이스에는 예측할 수 없는 활동 패턴이 있으므로 ISV는 데이터베이스 비용을 확장된 기간 동안 잘 예측할 수 있도록 탄력적 풀을 사용합니다. 또한 탄력적 풀은 사용자 활동이 급증하는 경우 성능 관리를 단순화합니다. 테넌트 데이터베이스 외에도 애플리케이션은 여러 데이터베이스를 사용하여 사용자 프로필, 보안, 사용 패턴 수집 등을 관리합니다. 개별 테넌트의 가용성은 애플리케이션의 전체 가용성에 영향을 주지 않습니다. 하지만 관리 데이터베이스의 성능과 가용성은 애플리케이션의 기능에 중요하며 관리 데이터베이스가 오프라인 상태이면 전체 애플리케이션도 오프라인 상태입니다.

이 문서에서는 비용에 민감한 시작 애플리케이션에서 엄격한 가용성 요구 사항이 포함된 애플리케이션에 걸친 시나리오를 다루는 DR 전략을 설명합니다.

참고

프리미엄 또는 중요 비즈니스용 데이터베이스 및 탄력적 풀을 사용하는 경우, 영역 중복 배포 구성으로 변환하여 지역 중단 시 탄력적으로 복원할 수 있습니다. 영역 중복 데이터베이스를 참조하세요.

시나리오 1. 비용에 민감한 시작

스타트업 사업체이며 비용에 매우 민감합니다. 애플리케이션의 배포 및 관리를 단순화하려면 개별 고객을 위해 제한된 SLA를 보유할 수 있습니다. 하지만 애플리케이션 전체가 오프라인이 되는 것은 절대 원하지 않습니다.

단순성 요구 사항을 충족하려면 모든 테넌트 데이터베이스를 선택한 Azure 지역에서 하나의 탄력적 풀로 배포하고 관리 데이터베이스를 지역 복제된 단일 데이터베이스로 배포합니다. 테넌트의 재해 복구를 위해 추가 비용 없이 제공되는 지역 복원을 사용합니다. 관리 데이터베이스의 가용성을 보장하려면 장애 조치(failover) 그룹을 사용하여 다른 지역으로 지역 복제합니다(1단계). 이 시나리오에서 재해 복구를 구성하는 지속적인 비용은 보조 데이터베이스의 총 비용과 같습니다. 이 구성은 다음 다이어그램에 나와 있습니다.

주 지역에서 중단이 발생한 경우 애플리케이션을 온라인 상태로 복구하는 단계는 다음 다이어그램에 설명되어 있습니다.

• 장애 조치 그룹에서 DR 지역으로의 관리 데이터베이스 장애 조치를 자동으로 시작합니다. 애플리케이션이 새 주 데이터베이스에 자동으로 다시 연결되며, 모든 새 계정과 테넌트 데이터베이스가 DR 지역에 만들어집니다. 기존 고객은 자신의 데이터를 임시로 사용할 수 없음을 확인하게 됩니다.
• 원래 풀과 동일한 구성으로 탄력적 풀을 만듭니다(2).
• 지역 복원을 사용하여 테넌트 데이터베이스의 복사본을 만듭니다(3). 최종 사용자 연결로 개별 복원 트리거를 고려하거나 다른 애플리케이션 특정 우선 순위 체계를 사용할 수 있습니다.

이때 애플리케이션은 DR 영역에서 다시 온라인 상태이지만 일부 고객은 데이터에 액세스할 때 지연을 경험하게 됩니다.

일시적인 중단인 경우 DR 지역에서 모든 데이터베이스 복원이 완료되기 전에 Azure에서 주 지역이 복구될 수 있습니다. 이 경우에 주 지역으로 애플리케이션을 다시 이동하도록 오케스트레이션합니다. 이 프로세스는 다음 다이어그램에 설명된 단계를 수행합니다.

• 미해결된 모든 지역 복원 요청을 취소합니다.
• 관리 데이터베이스를 주 지역으로 장애 조치합니다(5). 지역의 복구 후에 이전 주 데이터베이스는 자동으로 보조 데이터베이스가 됩니다. 이제 역할을 다시 전환합니다.
• 주 지역을 다시 가리키도록 애플리케이션의 연결 문자열을 변경합니다. 이제 모든 새 계정 및 테넌트 데이터베이스가 주 지역에 생성됩니다. 일부 기존 고객은 자신의 데이터를 임시로 사용할 수 없음을 확인하게 됩니다.
• DR 풀에서 모든 데이터베이스를 읽기 전용으로 설정하여 DR 지역에서 수정할 수 없도록 합니다(6).
• 복구 이후에 변경된 DR 풀에 있는 각 데이터베이스에 대해 기본 풀에 있는 해당 데이터베이스의 이름을 변경하거나 삭제합니다(7).
• DR 풀에서 기본 풀로 업데이트된 데이터베이스를 복사합니다(8).
• DR 풀을 삭제합니다(9).

이때 애플리케이션은 기본 풀에서 모든 테넌트 데이터베이스를 사용할 수 있는 주 지역에서 온라인 상태가 됩니다.

이점

이 전략의 주요 장점 은 데이터 계층 중복성을 위해 지속적으로 발생하는 비용이 낮은 것입니다. Azure SQL Database는 추가 비용 없이 애플리케이션을 다시 생성하지 않고 데이터베이스를 자동으로 백업합니다. 탄력적 데이터베이스를 복원한 경우에만 비용이 발생합니다.

장단점

단점은 모든 테넌트 데이터베이스를 전체 복구하는 데 상당한 시간이 소요된다는 것입니다. 소요되는 시간은 DR 지역에서 시작할 총 복원 수와 테넌트 데이터베이스의 전체 크기에 따라 달라집니다. 일부 테넌트의 복원을 다른 복원보다 우선하더라도 기존 고객 데이터베이스에 전체 영향을 최소화하기 위해 서비스가 조정하고 제한하므로 동일한 지역에서 시작된 모든 다른 복원과 경쟁하게 됩니다. 또한 DR 지역에 새 탄력적 풀이 생성될 때까지는 테넌트 데이터베이스의 복구를 시작할 수 없습니다.

시나리오 2. 계층화된 서비스를 포함하는 완성도 높은 애플리케이션

계층화된 서비스 제품 및 평가판 고객/유료 고객을 위한 다양한 SLA를 포함하는 완성도 높은 SaaS 애플리케이션입니다. 평가판 고객을 위해 가능한 비용을 절감해야 합니다. 평가판 고객은 중단 시간이 있을 수 있지만 중단 시간이 발생할 가능성을 줄이고 싶습니다. 유료 고객의 경우 중단 시간이 있을 경우 고객이 이탈할 위험이 있습니다. 따라서 유료 고객이 항상 데이터에 액세스할 수 있도록 하고 싶습니다.

이 시나리오를 지원하려면 별도의 탄력적 풀에 배치하여 평가판 테넌트와 유료 테넌트를 분리합니다. 평가판 고객의 경우 테넌트당 eDTU 또는 vCore 수가 더 낮고 복구 시간이 더 긴 하위 수준의 SLA가 적용됩니다. 유료 고객은 테넌트당 eDTU 또는 vCore 수가 더 높고 상위 수준의 SLA가 적용된 풀을 사용하게 됩니다. 가장 짧은 복구 시간을 보장하기 위해 유료 고객의 테넌트 데이터베이스는 지역 복제됩니다. 이 구성은 다음 다이어그램에 나와 있습니다.

첫 번째 시나리오와 마찬가지로 관리 데이터베이스는 매우 활동적이므로 이 경우 단일 지역 복제 데이터베이스를 사용합니다(1). 이렇게 하면 새 고객 구독, 프로필 업데이트 및 기타 관리 작업에 대한 성능을 예측할 수 있습니다. 주 관리 데이터베이스가 있는 지역이 주 지역이 되며 보조 관리 데이터베이스가 있는 지역이 DR 지역이 됩니다.

유료 고객의 테넌트 데이터베이스는 주 지역에 프로비저닝된 유료 풀에 활성 데이터베이스를 포함하게 됩니다. DR 지역에서 동일한 이름으로 보조 풀을 프로비전합니다. 각 테넌트는 보조 풀로 지역 복제됩니다(2). 이렇게 하면 장애 조치를 사용하여 모든 테넌트 데이터베이스를 신속하게 복구할 수 있습니다.

주 지역에서 중단이 발생한 경우 애플리케이션을 온라인 상태로 복구하는 단계는 다음 다이어그램에 설명되어 있습니다.

• 관리 데이터베이스를 DR 지역으로 즉시 장애 조치합니다(3).
• DR 지역을 가리키도록 애플리케이션의 연결 문자열을 변경합니다. 이제 모든 새 계정 및 테넌트 데이터베이스가 DR 지역에 생성됩니다. 기존 평가판 고객은 자신의 데이터를 임시로 사용할 수 없음을 확인하게 됩니다.
• 유료 테넌트의 데이터베이스를 DR 지역의 풀로 장애 조치하여 가용성을 즉시 복원합니다(4). 장애 조치는 신속한 메타데이터 수준 변경이므로 최종 사용자 연결에 의해 필요 시 개별 장애 조치를 트리거하는 최적화를 고려합니다.
• 보조 데이터베이스에는 보조인 동안 변경 로그를 처리할 용량만 필요하므로 보조 풀의 eDTU 크기 또는 vCore 수 값이 기본 풀보다 작은 경우 모든 테넌트의 전체 워크로드를 수용할 수 있도록 풀 용량을 즉시 늘립니다(5).
• DR 지역에 동일한 이름 및 구성으로 평가판 고객의 데이터베이스에 대해 새 탄력적 풀을 만듭니다(6).
• 평가판 고객의 풀을 만든 후 지역 복원을 사용하여 개별 평가판 테넌트 데이터베이스를 새 풀로 복원합니다(7). 최종 사용자 연결로 개별 복원 트리거를 고려하거나 다른 애플리케이션 특정 우선 순위 체계를 사용합니다.

이때 DR 지역에서 애플리케이션이 다시 온라인 상태입니다. 모든 유료 고객은 자신의 데이터에 액세스할 수 있으나 평가판 고객은 데이터에 액세스할 때 지연을 경험하게 됩니다.

DR 지역에서 애플리케이션을 복원한 후 Azure에 의해 주 지역이 복구된 경우 해당 지역에서 애플리케이션을 계속 실행하거나 주 지역으로 장애 복구하도록 결정할 수 있습니다. 장애 조치 프로세스가 완료되기 전에 주 지역이 복구된 경우 바로 장애 복구를 고려합니다. 이 장애 복구에는 다음 다이어그램에 표시된 단계를 거칩니다.

• 미해결된 모든 지역 복원 요청을 취소합니다.
• 관리 데이터베이스를 장애 조치합니다(8). 지역의 복구 후 이전 주 데이터베이스는 자동으로 보조 데이터베이스가 됩니다. 이제 다시 주 항목이 됩니다.
• 유료 테넌트 데이터베이스를 장애 조치합니다(9). 마찬가지로 지역의 복구 후 이전 주 데이터베이스는 자동으로 보조 데이터베이스가 됩니다. 이제 다시 주 데이터베이스가 됩니다.
• DR 지역에서 변경된 복원된 평가판 데이터베이스를 읽기 전용으로 설정합니다(10).
• 복구 이후에 변경된 평가판 고객 DR 풀에 있는 각 데이터베이스에 대해 평가판 고객 기본 풀에 있는 해당 데이터베이스의 이름을 변경하거나 삭제합니다(11).
• DR 풀에서 기본 풀로 업데이트된 데이터베이스를 복사합니다(12).
• DR 풀을 삭제합니다(13).

참고

장애 조치 작업은 비동기입니다. 복구 시간을 최소화하기 위해 적어도 20개의 데이터베이스 배치에서 테넌트 데이터베이스의 장애 조치 명령을 실행하는 것이 중요합니다.

이점

이 전략의 주요 장점 은 유료 고객에게 가장 높은 SLA를 제공한다는 점입니다. 또한 평가판 DR 풀이 만들어지는 즉시 새 평가판이 차단 해제되도록 보장합니다.

장단점

단점은 이러한 설정이 유료 고객을 위한 보조 DR 풀의 비용으로 테넌트 데이터베이스의 총 비용을 증가시킨다는 것입니다. 또한 보조 풀 크기가 다른 경우 유료 고객은 장애 조치 후에 DR 지역에서 풀 업그레이드가 완료될 때까지 성능 저하를 경험하게 됩니다.

시나리오 3. 계층화된 서비스를 포함하는 지리적으로 분산된 애플리케이션

계층화된 서비스 제품을 포함한 완성도 높은 SaaS 애플리케이션이 있습니다. 일시적인 중단이라도 고객 불만족으로 이어질 수 있으므로 유료 고객에게 매우 파격적인 SLA를 제공하고 중단이 발생할 때 미치는 위험을 최소화하고 싶습니다. 유료 고객은 자신의 데이터에 항상 액세스할 수 있어야 한다는 것이 중요합니다. 평가판은 무료이며 평가판 사용 기간에는 SLA가 제공되지 않습니다.

이 시나리오를 지원하려면 세 개의 별도의 탄력적 풀을 사용합니다. 유료 고객의 테넌트 데이터베이스를 포함하기 위해 높은 데이터베이스당 eDTU 또는 vCore 수가 있는 동일한 크기의 풀 두 개를 서로 다른 두 지역에 프로비전합니다. 평가판 테넌트를 포함하는 세 번째 풀은 낮은 데이터베이스당 eDTU 또는 vCore 수를 포함하고 두 지역 중 하나에 프로비전할 수 있습니다.

중단 중에 가장 짧은 복구 시간을 보장하기 위해 유료 고객의 테넌트 데이터베이스를 두 지역 각각에서 주 데이터베이스의 50%로 지역 복제합니다. 마찬가지로 각 지역은 보조 데이터베이스의 50%를 포함합니다. 이러한 방식에서 지역이 오프라인 상태이면 유료 고객 데이터베이스의 50%만 영향을 받고 장애 조치해야 합니다. 다른 데이터베이스는 그대로 유지됩니다. 이 구성은 다음 다이어그램에서 설명됩니다.

이전 시나리오와 마찬가지로 관리 데이터베이스는 매우 활동적이므로 단일 지역 복제 데이터베이스로 구성합니다(1). 이렇게 하면 새 고객 구독, 프로필 업데이트 및 기타 관리 작업의 성능을 예측할 수 있습니다. 지역 A는 관리 데이터베이스에 대한 주 지역이고 지역 B는 관리 데이터베이스의 복구에 사용됩니다.

유료 고객의 테넌트 데이터베이스도 지역 복제되지만 주 데이터베이스 및 보조 데이터베이스는 지역 A 및 지역 B로 분할됩니다(2). 이러한 방식에서 중단으로 영향을 받는 테넌트 주 데이터베이스는 다른 지역으로 장애 조치될 수 있으며 사용 가능하게 됩니다. 테넌트 데이터베이스의 나머지 절반은 전혀 영향을 받지 않습니다.

다음 다이어그램은 지역 A에서 중단이 발생할 경우 수행할 복구 단계를 보여 줍니다.

• 관리 데이터베이스를 지역 B로 즉시 장애 조치합니다(3).
• 지역 B에서 관리 데이터베이스를 가리키도록 애플리케이션의 연결 문자열을 변경합니다. 새 계정 및 테넌트 데이터베이스가 지역 B에 생성되고 기존 테넌트 데이터베이스도 이 지역에서 찾을 수 있도록 관리 데이터베이스를 수정합니다. 기존 평가판 고객은 자신의 데이터를 임시로 사용할 수 없음을 확인하게 됩니다.
• 유료 테넌트의 데이터베이스를 지역 B의 풀 2로 장애 조치하여 가용성을 즉시 복원합니다(4). 장애 조치는 신속한 메타데이터 수준 변경이므로 최종 사용자 연결에 의해 필요 시 개별 장애 조치를 트리거하도록 최적화를 고려할 수 있습니다.
• 이제 풀 2는 주 데이터베이스만 포함하고 있으므로 풀의 총 워크로드가 증가하고 eDTU 크기 또는 vCore 수를 즉시 늘릴 수 있습니다(5).
• 지역 B에 동일한 이름 및 구성으로 평가판 고객의 데이터베이스에 대해 새 탄력적 풀을 만듭니다(6).
• 풀을 만든 후 지역 복원을 사용하여 개별 평가판 테넌트 데이터베이스를 풀로 복원합니다(7). 최종 사용자 연결로 개별 복원 트리거를 고려하거나 다른 애플리케이션 특정 우선 순위 체계를 사용할 수 있습니다.

참고

장애 조치 작업은 비동기입니다. 복구 시간을 최소화하기 위해 적어도 20개의 데이터베이스 배치에서 테넌트 데이터베이스의 장애 조치 명령을 실행하는 것이 중요합니다.

이때 애플리케이션은 지역 B에서 다시 온라인 상태입니다. 모든 유료 고객은 자신의 데이터에 액세스할 수 있으나 평가판 고객은 데이터에 액세스할 때 지연을 경험하게 됩니다.

지역 A를 복구할 때 평가판 고객에 대해 지역 B를 사용할지 지역 A에서 평가판 고객 풀을 사용하도록 장애 복구할지 결정해야 합니다. 한 가지 조건은 복구 이후 수정된 평가판 테넌트 데이터베이스의 비율(%)일 수 있습니다. 결정에 관계 없이 두 개의 풀 사이 유료 테넌트는 균형을 재조정해야 합니다. 다음 다이어그램은 평가판 테넌트 데이터베이스가 A 영역으로 장애 복구할 때의 프로세스를 보여 줍니다.

• 평가판 DR 풀에 대해 미해결된 모든 지역 복원 요청을 취소합니다.
• 관리 데이터베이스를 장애 조치합니다(8). 지역의 복구 후 이전 주 데이터베이스는 자동으로 보조 데이터베이스가 되었습니다. 이제 다시 주 항목이 됩니다.
• 풀 1로 장애 복구할 유료 테넌트 데이터베이스를 선택하고 보조 데이터베이스로 장애 조치를 시작합니다(9). 지역의 복구 후 풀 1에 있는 모든 데이터베이스는 자동으로 보조 데이터베이스가 됩니다. 이제 그 중 50%가 다시 주 데이터베이스가 됩니다.
• 풀 2의 크기를 원래 eDTU 또는 vCore 수로 줄입니다(10).
• 지역 B의 모든 복원된 평가판 데이터베이스를 읽기 전용으로 설정합니다(11).
• 복구 이후에 변경된 평가판 DR 풀에 있는 각 데이터베이스에 대해 평가판 기본 풀에 있는 해당 데이터베이스의 이름을 변경하거나 삭제합니다(12).
• DR 풀에서 기본 풀로 업데이트된 데이터베이스를 복사합니다(13).
• DR 풀을 삭제합니다(14).

이점

이 전략의 주요 장점 은 다음과 같습니다.

• 중단이 테넌트 데이터베이스의 50% 미만에만 영향을 줄 수 있도록 하므로 유료 고객에게 가장 파격적인 SLA를 지원합니다.
• 복구 중에 평가판 DR 풀이 만들어지는 즉시 새 평가판이 차단 해제되도록 보장합니다.
• 따라서 풀 1과 풀 2에서 보조 데이터베이스 중 50%가 주 데이터베이스보다 덜 활성화되도록 보장되므로 풀 용량을 더욱 효율적으로 사용할 수 있습니다.

장단점

주요 단점 은 다음과 같습니다.

• 관리 데이터베이스에 대한 CRUD 작업에서 지역 A에 연결된 최종 사용자에 대한 대기 시간이 지역 B에 연결된 최종 사용자보다 낮습니다. 작업이 주 관리 데이터베이스에 대해 실행되기 때문입니다.
• 따라서 관리 데이터베이스에 대해 보다 복잡한 설계가 필요합니다. 예를 들어 각 테넌트 레코드는 장애 조치 및 장애 복구 중에 변경해야 하는 위치 태그를 포함합니다.
• 유료 고객은 지역 B에서 풀 업그레이드가 완료될 때까지 평소보다 성능 저하를 경험할 수 있습니다.

요약

이 문서는 SaaS ISV 다중 테넌트 애플리케이션에서 사용하는 데이터베이스 계층에 대한 재해 복구 전략에 중점을 둡니다. 비즈니스 모델, 고객에게 제공할 SLA, 예산 제약 조건 등의 애플리케이션 요구 사항에 따라 전략을 선택합니다. 각 전략의 혜택 및 장단점이 간략하게 설명되어 있으므로 정확하고 합리적인 의사 결정을 내릴 수 있습니다. 또한 특정 애플리케이션은 다른 Azure 구성 요소를 포함할 가능성이 높습니다. 따라서 해당 비즈니스 연속성 지침을 검토하고 데이터베이스 계층의 복구를 오케스트레이션합니다. Azure에서 데이터베이스 애플리케이션 복구를 관리하는 방법에 대해 자세히 알아보려면 재해 복구를 위한 클라우드 솔루션 설계를 참조하세요.

다음 단계

• Azure SQL Database 자동화 백업에 대한 자세한 내용은 Azure SQL Database 자동화 백업을 참조하세요.
• 비즈니스 연속성의 개요 및 시나리오를 보려면 비즈니스 연속성 개요를 참조하세요.
• 복구를 위해 자동화된 백업을 사용하는 방법을 알아보려면 서비스에서 시작한 백업에서 데이터베이스 복원을 참조하세요.
• 빠른 복구 옵션에 대해 알아보려면 활성 지역 복제 및 장애 조치(failover) 그룹을 참조하세요.
• 보관을 위해 자동화된 백업을 사용하는 방법을 알아보려면 데이터베이스 복사를 참조하세요.