다음을 통해 공유

Azure SQL Database를 사용하여 전역적으로 사용 가능 서비스 디자인

  • 아티클

적용 대상: Azure SQL Database

Azure SQL Database에서 클라우드 서비스를 빌드하고 배포하는 경우 활성 지역 복제 또는 자동 장애 조치(Failover) 그룹을 사용하여 지역 오류 및 심각한 서비스 중단에 대한 복원 기능을 제공합니다. 동일한 기능을 사용하여 데이터에 로컬로 액세스하도록 최적화된 전역 분산 애플리케이션을 만들 수 있습니다. 이 문서에서는 일반적인 애플리케이션 패턴에 초점을 맞추고 각 옵션의 이점 및 장단점을 설명합니다.

참고

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

시나리오 1: 두 Azure 지역을 사용하여 가동 중지 시간을 최소화하고 비즈니스 연속성 유지

이 시나리오에서는 애플리케이션에 다음과 같은 특징이 있습니다.

  • 애플리케이션이 한 Azure 지역에서 활성
  • 모든 데이터베이스 세션에서 데이터에 대한 읽기 및 쓰기 액세스(RW) 필요
  • 대기 시간 및 트래픽 비용을 줄이도록 웹 계층 및 데이터 계층 배치
  • 근본적으로 가동 중단 시간은 데이터 손실보다 이러한 애플리케이션에 더 높은 비즈니스 위험이 있음

이 경우 애플리케이션 배포 토폴로지는 모든 애플리케이션 구성 요소를 함께 장애 조치(failover)해야 할 때 지역 재해를 처리하기 위해 최적화됩니다. 아래 다이어그램은 이 토폴로지를 보여줍니다. 지리적 중복 구성을 위해 애플리케이션의 리소스는 A와 B 지역에 배포되어 있습니다. 그러나 지역 B의 리소스는 지역 A가 실패할 때까지 사용되지 않습니다. 데이터베이스 연결, 복제 및 장애 조치를 관리하기 위해 두 지역 간에 장애 조치 그룹이 구성됩니다. 두 지역의 웹 서비스는 읽기-쓰기 수신기 <failover-group-name>.database.windows.net(1)을 통해 데이터베이스에 액세스하도록 구성되었습니다. Azure Traffic Manager는 우선 순위 라우팅 메서드(2)를 사용하도록 설정됩니다.

참고

Azure Traffic Manager는 이 문서 전체에서 설명을 위한 용도로만 사용됩니다. 우선 순위 라우팅 메서드를 지원하는 모든 부하 분산 솔루션을 사용할 수 있습니다.

다음 다이어그램은 작동 중단 전의 이 구성을 보여 줍니다.

시나리오 1. 중단 전 구성

주 지역에서 가동 중단된 후 SQL Database는 주 데이터베이스에 액세스할 수 없음을 감지하여 자동 장애 조치(failover) 정책(1)의 매개 변수를 기반으로 하여 보조 지역으로 장애 조치(failover)를 트리거합니다. 애플리케이션 SLA에 따라 가동 중단 감지와 장애 조치 자체 사이의 시간을 구성할 수 있습니다. 장애 조치(failover) 그룹이 데이터베이스 장애 조치(failover)를 트리거하기 전에 Azure Traffic Manager가 엔드포인트 장애 조치(failover)를 시작할 수 있습니다. 이 경우 웹 애플리케이션은 즉시 데이터베이스에 다시 연결할 수 없습니다. 그러나 데이터베이스 장애 조치가 완료되는 즉시 자동으로 다시 연결합니다. 실패 지역이 복원되고 온라인으로 돌아오면 기존의 기본 항목이 자동으로 새로운 보조로 연결됩니다. 아래 다이어그램은 장애 조치 후의 구성을 나타냅니다.

참고

장애 조치 후 커밋된 모든 트랜잭션은 재연결 중 손실됩니다. 장애 조치 완료 후 지역 B의 애플리케이션을 다시 연결하고 사용자 요청 처리를 다시 시작할 수 있습니다. 이제 웹 애플리케이션과 주 데이터베이스는 모두 지역 B이며 공동 배치된 상태로 유지됩니다.

시나리오 1. 장애 조치(failover) 후 구성

영역 B에서 중단이 발생할 경우 주 및 보조 데이터베이스 간 복제 프로세스가 일시 중지되나 둘 사이의 연결은 그대로 유지됩니다(1). Traffic Manager가 지역 B와의 연결이 끊어졌음을 감지하고 엔드포인트 웹앱 2를 성능 저하됨(2)으로 표시합니다. 이 경우 애플리케이션 성능에는 영향이 없으나 데이터베이스가 노출되므로, 이후 지역 A도 실패한다면 데이터 손실 위험이 더 높아집니다.

참고

재해 복구의 경우 애플리케이션 배포를 두 지역으로 제한하여 구성하는 것이 좋습니다. 대부분의 경우 Azure 지역이 두 개뿐이기 때문입니다. 이 구성은 두 영역에서 동시에 발생하는 치명적인 오류로부터 애플리케이션을 보호하지 않습니다. 이러한 발생 가능성이 없는 실패 시 지리적 복원 작업을 사용하여 세 번째 지역에서 데이터베이스를 복구할 수 있습니다. 자세한 내용은 Azure SQL 데이터베이스 재해 복구 가이드를 참조하세요.

작동 중단이 완화되면 보조 데이터베이스가 주 데이터베이스와 자동으로 다시 동기화됩니다. 동기화 중에는 주 데이터베이스의 성능에 영향이 있을 수 있습니다. 특정한 영향은 장애 조치 후 새로운 주 데이터베이스가 확보하게 되는 데이터의 크기에 따라 결정됩니다.

참고

중단이 완화되면 Traffic Manager는 지역 A의 애플리케이션에 대한 연결을 우선 순위가 더 높은 엔드포인트로 라우팅하기 시작합니다. 한 동안 지역 B에서 기본 설정을 유지하려는 경우 Trafic Manager 프로필에서 우선 순위 테이블을 적절하게 변경해야 합니다.

다음 다이어그램은 보조 지역의 작동 중단을 보여 줍니다.

시나리오 1. 보조 지역에서 중단 후 구성

이 설계 패턴의 주요 장점 은 다음과 같습니다.

  • 동일한 웹 애플리케이션은 모든 지역 관련 구성 및 장애 조치(failover) 관리를 위한 추가 논리 없이 두 지역 모두에 배포됩니다.
  • 웹 애플리케이션과 데이터베이스가 항상 동일한 위치에 배치되므로 애플리케이션의 성능은 장애 조치의 영향을 받지 않습니다.

지역 B의 애플리케이션 리소스가 대부분의 시간 동안 덜 사용되는 것이 적정 수준입니다.

시나리오 2: 최고 수준의 데이터 보존과 비즈니스 연속을 위한 Azure 지역

이 옵션은 다음 특성을 가진 애플리케이션에 가장 적합합니다.

  • 어떤 경우든 데이터 손실은 비즈니스에 큰 위험이 됩니다. 치명적인 실패에 의한 가동 중단의 경우 데이터베이스 장애 조치는 최후의 수단으로만 사용할 수 있습니다.
  • 애플리케이션에서 작업의 읽기 전용 및 읽기-쓰기 모드를 지원하며, 일정 기간 동안 "읽기 전용 모드"에서 작동할 수 있습니다.

이 패턴에서 읽기-쓰기 연결에 대한 시간 제한 오류가 발생하기 시작하면 애플리케이션이 읽기 전용 모드로 전환됩니다. 웹 애플리케이션은 두 지역 모두에 배포되며, 읽기-쓰기 수신기 엔드포인트에 대한 연결과 읽기 전용 수신기 엔드포인트(1)에 대한 다른 연결을 포함합니다. Traffic Manager 프로필은 우선 순위 라우팅을 사용해야 합니다. 각 지역의 애플리케이션 엔드포인트에 대해 엔드포인트 모니터링을 활성화해야 합니다(2).

다음 다이어그램은 작동 중단 전의 이 구성을 보여 줍니다.

시나리오 2. 중단 전 구성

Traffic Manager가 지역 A에 대한 연결 장애를 감지하면 사용자 트래픽을 지역 B의 애플리케이션 인스턴스로 자동 전환합니다. 이 패턴을 사용하면 데이터 손실이 있는 유예 기간을 충분히 높은 값(예: 24시간)으로 설정하는 것이 중요합니다. 이 시간 내에 가동 중단이 완화되면 데이터 손실이 방지됩니다. 지역 B의 웹 애플리케이션이 활성화되면 읽기-쓰기 작업이 실패하기 시작합니다. 이 시점에서 읽기 전용 모드로 전환해야 합니다(1). 이 모드에서는 요청이 자동으로 보조 데이터베이스로 라우팅됩니다. 치명적인 오류로 중단된 경우 대개는 유예 기간 동안 완화될 수 없습니다. 만료되면 장애 조치 그룹이 장애 조치를 트리거합니다. 이후 읽기-쓰기 수신기를 사용할 수 있게 되고 이 수신기에 대한 연결 실패가 중지됩니다(2). 다음 다이어그램에서는 복구 과정의 두 단계를 보여 줍니다.

참고

주 지역의 가동 중단이 유예 기간 내에 완화되면 Traffic Manager에서 주 지역의 연결 복원을 검색하고 사용자 트래픽을 지역 A의 애플리케이션 인스턴스로 다시 전환합니다. 이전 다이어그램에서 본 것처럼 해당 애플리케이션 인스턴스는 지역 A의 주 데이터베이스를 사용하여 읽기-쓰기 모드에서 다시 시작되어 작동합니다.

시나리오 2. 재해 복구 단계

지역 B에서 중단이 발생한 경우 Traffic Manager가 지역 B의 엔드포인트 웹 앱 2 실패를 감지하고 성능 저하되었다고 표시합니다(1). 그 동안 장애 조치 그룹이 읽기 전용 수신기를 지역 A로 전환합니다(2). 이 중단은 최종 사용자 환경에 영향을 미치지 않으나 중단 기간 중 주 데이터베이스가 노출됩니다. 다음 다이어그램은 보조 지역에서의 실패를 보여 줍니다.

시나리오 2. 보조 지역의 중단

가동 중단이 완화되면 보조 데이터베이스는 즉시 주 데이터베이스와 동기화되고, 읽기 전용 수신기는 지역 B의 보조 데이터베이스로 다시 전환됩니다. 동기화하는 동안 동기화해야 하는 데이터의 양에 따라 주 데이터베이스의 동기화 성능에 약간 영향을 줄 수 있습니다.

이 디자인 패턴에는 다음과 같은 여러 장점이 있습니다.

  • 임시 작동 중단 동안 데이터 손실 방지
  • 가동 중지 시간은 Traffic Manager가 구성 가능한 연결 실패를 얼마나 빨리 감지하는지에 따라 달라집니다.

애플리케이션은 읽기 전용 모드에서 작동할 수 있어야 하는 것이 적정 수준입니다.

무중단 업무 방식 계획: 클라우드 재해 복구에 대한 애플리케이션 디자인 선택

특정 클라우드 재해 복구 전략은 애플리케이션의 요구 사항을 최상으로 충족하도록 이러한 디자인 패턴을 결합하거나 확장할 수 있습니다. 앞에서 설명한 대로 선택한 전략은 고객 및 애플리케이션 배포 토폴로지에 제공하려는 SLA에 따라 달라집니다. 결정에 도움을 주기 위해 다음 테이블에서는 복구 지점 목표(RPO) 및 예상 복구 시간(ERT)에 따라 선택 항목을 비교합니다.

패턴 RPO ERT
배치된 데이터베이스 액세스로 재해 복구에 대한 활성-수동 배포 읽기-쓰기 권한 < 5초 장애 감지 시간 + DNS TTL
애플리케이션 부하 분산에 대한 활성-활성 배포 읽기-쓰기 권한 < 5초 장애 감지 시간 + DNS TTL
데이터 보존에 대한 활성-수동 배포 읽기 전용 액세스 < 5초 읽기 전용 액세스 = 0
읽기-쓰기 액세스 = 0 읽기-쓰기 액세스 = 장애 감지 시간 + 데이터 손실이 있는 유예 기간

다음 단계