Azure SQL Database의 안정성

Azure SQL 데이터베이스는 사용자 개입 없이 업그레이드, 패치, 백업, 모니터링 등 대부분 데이터베이스 관리 기능을 처리하는 완전 관리형 플랫폼 서비스(PaaS) 데이터베이스 엔진입니다.

Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.

이 문서에서는 일시적인 오류, 가용성 영역 중단 및 지역 중단을 포함하여 다양한 잠재적인 중단 및 문제에 대해 Azure SQL Database를 복원력 있게 만드는 방법을 설명합니다. 또한 백업을 사용하여 다른 유형의 문제에서 복구하는 방법, 서비스 유지 관리를 처리하는 방법 및 Azure SLA(SQL Database 서비스 수준 계약)에 대한 몇 가지 주요 정보를 강조 표시합니다.

프로덕션 배포 권장 사항

솔루션의 안정성 요구 사항을 지원하기 위해 Azure SQL Database를 배포하는 방법과 안정성이 아키텍처의 다른 측면에 어떤 영향을 미치는지 알아보려면 Azure Well-Architected Framework에서 Azure SQL Database에 대한 아키텍처 모범 사례를 참조하세요.

안정성 아키텍처 개요

SQL Database는 모든 적용 가능한 패치를 포함하여 Windows 운영 체제의 최신 안정적인 SQL Server 데이터베이스 엔진에서 실행됩니다.

SQL Database는 기본적으로 주 지역의 단일 데이터 센터에 세 개의 데이터 사본을 저장하여 중복도를 달성합니다. 이 방식은 소규모 네트워크 장애 또는 정전과 같은 국지적인 장애가 발생하는 경우와 다음과 같은 이벤트 중에 데이터를 보호합니다.

• 짧은 가동 중지 시간을 초래하는 고객이 수행한 관리 작업

• 서비스 유지 관리 작업

• 데이터 센터에 다음 구성 요소가 있는 경우 발생하는 문제 및 데이터 센터 중단:

  • 서비스에 전원을 공급하는 컴퓨터가 실행되는 랙

  • SQL Database 엔진을 실행하는 VM(가상 머신)을 호스팅하는 실제 컴퓨터

• SQL Database 엔진의 다른 문제

• 기타 계획되지 않은 지역적 중단 가능성.

SQL Database는 Azure Service Fabric을 사용하여 데이터베이스 복제를 관리합니다.

중복도는 SQL Database의 다양한 서비스 계층에 따라 서로 다른 방식으로 구현됩니다. 자세한 내용은 중복도를 통한 가용성 - SQL Database를 참조하세요.

일시적인 오류에 대한 복원력

일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.

모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.

SQL Database는 패치, 백업, Windows, SQL Database 엔진 업그레이드와 같은 중요한 서비스 작업을 자동으로 처리합니다. 또한 기본 하드웨어, 소프트웨어 또는 네트워크 오류와 같은 계획되지 않은 이벤트를 자동으로 처리합니다. SQL Database는 심각한 장애로부터 신속하게 복구하도록 설계되어 데이터를 항상 사용할 수 있습니다. 대부분의 사용자는 업그레이드가 지속적으로 수행된다는 사실을 알지 못합니다.

데이터베이스에 패치가 적용되거나 장애 조치(failover)가 수행될 때 애플리케이션에서 다시 시도 논리를 사용하면 가동 중지로 인해 중단이 발생하지 않습니다.

애플리케이션 오류 복원력 테스트의 지침에 따라 임시 오류에 대한 애플리케이션의 복원력을 테스트할 수 있습니다.

가용성 영역 오류에 대한 복원력

가용성 영역은 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.

다른 서비스 계층에 대한 가용성 영역 지원에 대한 정보를 보려면 이 페이지의 시작 부분에서 적절한 서비스 계층을 선택해야 합니다.

요구 사항

지역 전체 오류에 대한 복원력

이 섹션에서는 SQL Database의 다중 지역 복제에 사용할 수 있는 서로 관련되지만 별도의 두 가지 기능에 대해 간략하게 설명합니다.

• 활성 지역 복제 는 단일 데이터베이스를 동기화된 보조 데이터베이스에 복제합니다.

• 장애 조치(failover) 그룹은 활성 지역 복제를 기반으로 빌드되며, 데이터베이스 그룹에 대한 장애 조치(failover) 기능을 제공합니다.

활성 지리적 복제

활성 지역 복제는 단일 주 데이터베이스에 대해 모든 지역에서 지속적으로 동기화되고 읽기 가능한 보조 데이터베이스(지역 보조 또는 지역 복제본이라고도 함)를 만듭니다. 활성 지역 복제를 통해 동일한 지역에 보조 데이터베이스를 만들 수 있지만, 이 구성은 지역 중단에 대한 보호 기능을 제공하지 않습니다. 활성 지역 복제를 사용하여 지역 중복성을 달성하는 경우 다른 지역에서 주 데이터베이스에 대한 보조 데이터베이스를 찾습니다.

요구 사항

활성 지역 복제를 사용하는 경우 다음 요구 사항을 고려합니다.

• 지역 지원:활성 지역 복제 는 모든 Azure 지역에서 사용하도록 설정할 수 있으며 Azure 지역 쌍을 사용할 필요가 없습니다.

  팁 (조언)

  SQL Database는 Azure가 쌍을 이루는 지역에 동시에 업데이트를 배포하지 않으려고 노력하는 안전한 배포 사례를 따릅니다. 쌍이 아닌 지역을 사용하도록 활성 지역 복제를 구성하는 경우 각 지역의 서버에 대해 다른 유지 관리 기간을 설정합니다. 이러한 방식은 두 지역 모두에서 동시에 발생하는 유지 관리로 인해 연결 문제가 발생할 가능성을 줄이는 데 도움이 됩니다.

• 구성: 기본 및 지역 보조는 모두 동일한 서비스 계층을 가져야 하며 컴퓨팅 계층, 컴퓨팅 크기 및 백업 스토리지 중복성이 동일해야 합니다.

• 방화벽: 주 복제본과 지역 보조 복제본 모두 동일한 IP 주소 방화벽 규칙을 가져야 합니다.

• Azure 구독: 활성 지역 복제는 여러 Azure 구독의 데이터베이스에 대해 지원됩니다.

고려 사항

• 활성 지역 복제는 단일 데이터베이스에 대한 장애 조치를 제공하기 위해 설계되었습니다. 여러 데이터베이스를 장애 조치(failover)해야 하는 경우 장애 조치(failover) 그룹을 대신 사용하는 것이 좋습니다.

• 지역 복제는 비동기적이므로 장애 조치(failover)가 발생하면 데이터가 손실될 수 있습니다. 장애 조치(failover) 중 비동기 복제로 인한 데이터 손실을 제거해야 하는 경우 마지막으로 커밋된 트랜잭션이 전송되어 보조 데이터베이스의 트랜잭션 로그에 저장될 때까지 호출 스레드를 차단하도록 애플리케이션을 구성합니다. 이 방식은 사용자 지정 개발이 필요하고 애플리케이션의 성능을 저하합니다. 자세한 내용은 중요한 데이터의 손실 방지를 참조하세요.

• 제한 사항 및 고려 사항에 대한 자세한 내용은 활성 지역 복제를 참조하세요.

비용

보조 데이터베이스는 별도의 데이터베이스로 청구됩니다.

다중 지역 지원 구성

• 활성 지역 복제 사용: Azure Portal에서 활성 지역 복제를 사용하는 방법에 대한 자세한 내용은 SQL Database에 대한 활성 지역 복제 구성 또는 활성 지역 복제를 참조하세요.

  활성 지역 복제를 사용하도록 설정한 후 초기 시드 단계에는 시간이 걸릴 수 있습니다.

• 활성 지역 복제 사용 안 함: 데이터베이스에서 활성 지역 복제를 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 보조 데이터베이스 제거를 참조하세요.

모든 지역이 정상인 경우의 동작

이 섹션에서는 데이터베이스가 활성 지역 복제를 사용하도록 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.

• 지역 간 트래픽 라우팅: 주 데이터베이스에 읽기-쓰기 요청을 보내도록 애플리케이션을 구성해야 합니다. 선택적으로 읽기 전용 요청을 보조 데이터베이스로 보낼 수 있으며, 이를 통해 주 데이터베이스에 대한 읽기 전용 워크로드의 영향을 줄이는 데 도움이 됩니다.

• 지역 간 데이터 복제: 주 데이터베이스와 보조 데이터베이스 간의 복제는 비동기식으로 발생합니다. 즉, 주 데이터베이스에 변경 내용이 적용되는 순간과 보조 데이터베이스에 복제되는 순간 사이에 지연이 발생할 수 있습니다.

  장애 조치(failover)를 수행할 때 데이터 손실 가능성을 처리하는 방법을 결정합니다.

지역 오류 중 동작

이 섹션에서는 데이터베이스가 활성 지역 복제를 사용하도록 구성되고 주 지역에서 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

• 검색 및 응답: 데이터베이스 또는 지역의 중단을 검색하고 장애 조치(failover)를 트리거하는 것은 모두 사용자의 책임입니다.

• 알림: 지역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Service Health 를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.

• 활성 요청: 장애 조치(failover) 중 활성 요청은 종료되며 다시 시도해야 합니다.

• 예상 데이터 손실: 주 데이터베이스를 사용할 수 있는 경우 선택적으로 데이터 손실 없이 장애 조치(failover)를 수행할 수 있습니다. 장애 조치 프로세스는 역할을 전환하기 전에 주 데이터베이스와 보조 데이터베이스 간에 데이터를 동기화합니다.

  주 데이터베이스를 사용할 수 없는 경우 강제 장애 조치(failover)를 수행해야 할 수 있으며, 이로 인해 데이터가 손실될 수 있습니다. 복제 지연을 모니터링하여 데이터 손실의 양을 예측할 수 있습니다. 자세한 내용은 메트릭 및 경고를 사용하여 SQL Database 모니터링을 참조하세요.

• 예상 가동 중지 시간: 일반적으로 장애 조치(failover) 중 최대 60초의 가동 중지 시간이 발생합니다. 애플리케이션이 짧은 가동 중지 시간에서 복구할 수 있도록 임시 오류를 처리하는지 확인합니다. 또한, 새로운 주 데이터베이스에 연결하기 위해 애플리케이션을 다시 구성하는 속도도 발생하는 가동 중지 시간에 영향을 미칩니다.

• 트래픽 경로 변경: 새 주 데이터베이스에 요청을 보내도록 애플리케이션을 다시 구성할 책임이 있습니다. 장애 조치가 투명하게 이루어져야 한다면, 장애 조치 그룹을 사용하는 것이 좋습니다.

지역 복구

주 지역이 복구된 후에는 다른 장애 조치(failover)를 수행하여 주 지역으로 수동으로 장애 복구를 수행할 수 있습니다.

지역 오류 테스트

언제든지 수동 장애 조치를 트리거하여 지역 중단을 시뮬레이션할 수 있습니다. 데이터 손실 없는 장애 조치(failover)나 강제 장애 조치를 트리거할 수 있습니다.

장애 조치 그룹

Failover 그룹은 활성 지역 복제를 기반으로 구축됩니다. 장애 조치(failover) 그룹을 사용하면 다음 작업을 수행할 수 있습니다.

• Azure 지역의 모든 조합에 걸쳐 단일 논리 서버에서 데이터베이스 집합을 복제합니다.

• 그룹으로 데이터베이스에서 장애 조치(failover)를 수행합니다.

• 기본 노드에 자동으로 연결을 유도하는 연결 엔드포인트를 사용합니다.

요구 사항

• 지역 지원: 장애 조치(failover) 그룹은 모든 Azure 지역에서 만들 수 있으며 Azure 지역 쌍을 사용할 필요가 없습니다.

  팁 (조언)

  쌍이 아닌 지역으로 장애 조치(failover) 그룹을 구성하는 경우 각 지역의 서버에 대해 서로 다른 유지 관리 기간을 설정하는 것이 좋습니다. 이러한 방식은 두 지역 모두에서 동시에 발생하는 유지 관리로 인해 연결 문제가 발생할 가능성을 줄이는 데 도움이 됩니다.

• 구성: 장애 조치(failover) 그룹의 보조 데이터베이스는 주 데이터베이스와 동일한 서비스 계층, 컴퓨팅 계층, 컴퓨팅 크기, IP 주소 방화벽 규칙 및 백업 스토리지 중복성을 가져야 합니다.

고려 사항

• 가능한 데이터 손실: 지역 복제는 비동기이므로 장애 조치(failover)가 발생할 때 데이터가 손실될 수 있습니다. 장애 조치(failover) 중 비동기 복제로 인한 데이터 손실을 제거해야 하는 경우 마지막으로 커밋된 트랜잭션이 전송되어 보조 데이터베이스의 트랜잭션 로그에 기록될 때까지 호출 스레드를 차단하도록 애플리케이션을 구성할 수 있습니다. 이 방식에는 사용자 지정 개발이 필요하며, 애플리케이션의 성능이 저하됩니다. 자세한 내용은 중요한 데이터의 손실 방지를 참조하세요.

• 제한 사항 및 고려 사항에 대한 자세한 내용은 장애 조치(failover) 그룹을 참조하세요.

비용

보조 데이터베이스는 별도의 데이터베이스로 청구됩니다.

다중 지역 지원 구성

• 장애 조치(failover) 그룹 사용: 논리 서버에서 장애 조치(failover) 그룹을 구성합니다. 논리 서버의 모든 데이터베이스를 장애 조치(failover) 그룹에 추가하거나 추가할 데이터베이스의 하위 집합을 선택할 수 있습니다.

  장애 조치(failover) 그룹을 만들 때 장애 조치(failover) 정책을 선택합니다. 이 정책은 중단을 검색하고 장애 조치(failover)를 수행하는 담당자를 지정합니다. 권장되는 고객 관리 장애 조치(failover) 또는 Microsoft 관리 장애 조치(failover)를 구성할 수 있습니다.

  중요합니다

  Microsoft에서 시작하는 장애 조치(failover)는 상당한 지연이 발생한 후에 발생할 가능성이 높으며 최선의 활동을 기준으로 수행됩니다. 데이터베이스 장애 조치(failover)는 다른 Azure 서비스의 장애 조치(failover)와 다른 시간에 발생할 수 있습니다. 자세한 내용은 SQL Database에 대한 장애 조치(failover) 그룹 구성을 참조하세요.

  장애 조치(failover) 그룹을 구성한 후 초기 시드 단계에는 시간이 다소 걸릴 수 있습니다.

• 장애 조치(failover) 그룹 사용 안 함: 장애 조치(failover) 그룹에서 개별 데이터베이스를 제거하거나, 전체 장애 조치(failover) 그룹을 제거하거나, 데이터베이스를 다른 장애 조치(failover) 그룹으로 이동할 수 있습니다.

모든 지역이 정상인 경우의 동작

이 섹션에서는 데이터베이스가 장애 조치(failover) 그룹 내에서 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.

• 지역 간 트래픽 라우팅: 읽기-쓰기 및 읽기 전용 워크로드의 경우 장애 조치(failover) 그룹은 애플리케이션을 연결할 수 있는 두 개의 수신기 엔드포인트를 제공합니다. 장애 조치(failover) 그룹 수신기 엔드포인트를 사용하여 장애 조치 중 가동 중지 시간을 최소화합니다. 일반적인 작업 중에는 다음과 같은 라우팅 동작이 발생합니다.

  • 읽기-쓰기 수신기 엔드포인트는 모든 요청을 주 데이터베이스로 라우팅합니다.

  • 읽기 전용 수신기 엔드포인트는 모든 요청을 읽을 수 있는 보조 데이터베이스로 라우팅합니다.

• 지역 간 데이터 복제: 주 데이터베이스와 보조 데이터베이스 간의 지역 복제는 비동기식으로 발생합니다. 이러한 대기 시간은 변경 내용이 주 데이터베이스에 적용되는 시점과 보조 데이터베이스에 복제되는 시점 사이에 대기 시간이 발생할 수 있음을 의미합니다.

  장애 조치(failover)를 수행할 때 데이터 손실 가능성을 처리하는 방법을 결정합니다.

지역 오류 중 동작

이 섹션에서는 데이터베이스가 장애 조치(failover) 그룹 내에서 구성되고 주 지역에서 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

• 검색 및 응답은 사용하는 장애 조치(failover) 정책에 따라 달라집니다.

  • 고객이 시작한 장애 조치(failover): 데이터베이스 또는 지역의 중단을 검색하고 장애 조치를 트리거하는 것은 고객의 책임입니다.

  • Microsoft에서 시작한 장애 조치(failover): Microsoft는 영향을 받는 지역의 모든 장애 조치(failover) 그룹에 대해 장애 조치(failover)를 트리거합니다. Microsoft에서는 이러한 형식의 장애 조치(failover)를 예외적인 상황에서만 수행할 것으로 예상합니다. 대부분의 솔루션에서는 Microsoft에서 관리하는 장애 조치(failover)에 의존하지 마세요. 자세한 내용은 장애 조치(failover) 정책 - Microsoft 관리를 참조하세요.

• 알림: 지역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Service Health 를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.

• 활성 요청: 장애 조치(failover) 중 활성 요청은 종료되며 다시 시도해야 합니다.

• 예상되는 데이터 손실: 데이터 손실은 사용하는 장애 조치(failover) 정책에 따라 달라집니다.

  • 고객이 시작한 장애 조치(failover): 주 데이터베이스를 사용할 수 있는 경우 선택적으로 데이터 손실 없이 장애 조치(failover)를 수행할 수 있습니다. 장애 조치 프로세스는 역할을 전환하기 전에 주 데이터베이스와 보조 데이터베이스 간에 데이터를 동기화합니다.

    주 데이터베이스를 사용할 수 없는 경우 강제 장애 조치(failover)를 수행해야 할 수 있으며, 이로 인해 데이터가 손실될 수 있습니다. 복제 지연을 모니터링하여 데이터 손실의 양을 예측할 수 있습니다. 자세한 내용은 메트릭 및 경고를 사용하여 SQL Database 모니터링을 참조하세요.

  • Microsoft에서 시작하는 장애 조치(failover): Microsoft에서 관리하는 장애 조치는 예외적인 상황에서만 트리거됩니다. Microsoft에서 관리하는 페일오버는 강제 페일오버이므로 일부 데이터 손실이 예상됩니다. 발생할 수 있는 데이터 손실의 양을 제어할 수 없습니다.

• 예상 가동 중지 시간: 가동 중지 시간은 사용하는 장애 조치(failover) 정책에 따라 달라집니다.

  • 고객이 시작한 장애 조치(failover): 일반적으로 장애 조치 중에 최대 60초의 가동 중지 시간이 발생합니다. 애플리케이션이 짧은 가동 중지 시간에서 복구할 수 있도록 임시 오류를 처리하는지 확인합니다.

  • Microsoft에서 시작하는 장애 조치(failover): Microsoft에서 장애 조치를 시작하기 전에 기다려야 하는 시간을 결정하는 유예 기간을 지정할 수 있습니다. 최소 유예 기간은 1시간입니다. 하지만 Microsoft의 응답 시간은 적어도 몇 시간이 걸릴 가능성이 높습니다.

• 트래픽 경로 전환: 장애 조치(failover) 중에 SQL Database는 읽기-쓰기 및 읽기 전용 수신기 엔드포인트를 업데이트하여 필요에 따라 새로운 주 데이터베이스 및 보조 데이터베이스로 트래픽을 전달합니다.

  새로운 보조 데이터베이스(이전의 주 데이터베이스)를 사용할 수 없는 경우 읽기 전용 수신기 엔드포인트는 새로운 보조 데이터베이스를 사용할 수 있을 때까지 연결할 수 없습니다.

지역 복구

필요한 경우 주 지역으로 복구하는 것은 사용자의 책임입니다. 고객 관리 장애 조치(failover)를 수행하여 주 지역으로 수동으로 장애 복구를 수행할 수 있습니다.

Microsoft에서 원래 장애 조치(failover)를 시작한 경우에도 사용자가 선택하는 경우 이전 지역으로 장애 조치(failover)를 수행해야 합니다.

지역 오류 테스트

언제든지 수동 장애 조치를 트리거하여 지역 중단을 시뮬레이션할 수 있습니다. 데이터 손실 없는 장애 조치(failover)나 강제 장애 조치를 트리거할 수 있습니다.

백업 및 복원

데이터 손실을 비롯한 다양한 위험으로부터 보호하기 위해 데이터베이스의 백업을 수행합니다. 실수로 인한 데이터 손실, 손상 또는 기타 문제를 복구하기 위해 백업을 복원할 수 있습니다. 백업은 영역 중복, 활성 지역 복제 또는 장애 조치(failover) 그룹과 다르며 목적도 다릅니다. 자세한 내용은 중복성, 복제 및 백업을 참조하세요.

SQL Database는 데이터베이스의 자동 백업을 제공합니다. 백업에서 복원해야 하는 경우 데이터 손실량에 영향을 줄 수 있는 백업 빈도에 대한 자세한 내용은 SQL Database의 자동 백업을 참조하세요.

백업 스토리지

자동 백업을 LRS 또는 ZRS에 저장할 수 있습니다. 쌍을 이루는 지역을 사용하는 경우 지역 중복 스토리지를 사용하여 자동화된 백업을 쌍을 이루는 지역에 복제하도록 선택할 수 있습니다. 이 기능을 사용하면 백업을 지정된 쌍 지역으로 지리적 복원할 수 있습니다. 자세한 내용은 SQL Database의 자동 백업을 참조하세요.

페어링되지 않은 지역을 사용하거나 쌍을 이루는 지역이 아닌 다른 지역에 백업을 복제해야 하는 경우 데이터베이스를 내보내고 내보낸 파일을 blob 개체 복제를 사용하여 다른 지역의 스토리지 계정으로 복제하는 스토리지 계정에 저장하는 것이 좋습니다. 자세한 내용은 데이터베이스 내보내기를 참조하세요.

서비스 유지 관리에 대한 복원력

SQL Database가 데이터베이스와 탄력적 풀에 대한 유지 관리를 수행하는 경우 보조 복제본을 사용하도록 데이터베이스를 자동으로 장애 조치(failover)할 수 있습니다. 장애 조치(failover)가 발생하면 클라이언트 애플리케이션에서 잠시 연결이 끊어질 수 있습니다. 클라이언트 애플리케이션은 일시적인 오류에 대한 복원력을 높이기 위해 지침을 따라야 합니다.

SQL Database를 사용하면 일반적으로 서비스 업그레이드 및 기타 유지 관리 작업에 사용되는 유지 관리 기간을 지정할 수 있습니다. 유지 관리 기간을 구성하면 업무 시간 동안 자동 장애 조치(failover)와 같은 부작용을 최소화하는 데 도움이 됩니다. 계획된 유지 관리에 대한 사전 알림을 받을 수도 있습니다.

플랫폼은 SQL Database에 대한 연결을 처리하는 데 사용되는 게이트웨이를 자동으로 유지 관리합니다. 업그레이드 또는 유지 관리 작업으로 인해 클라이언트가 다시 시도할 수 있는 짧은 연결 중단이 발생할 수도 있습니다.

자세한 내용은 SQL Database의 유지 관리 기간을 참조하세요.

서비스 수준 약정

Azure 서비스의 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 해당 가용성 예상 결과치를 달성하기 위해 솔루션이 충족해야 하는 조건을 설명합니다. 자세한 내용은 온라인 서비스 SLA를 참조하세요.

SQL Database의 SLA(서비스 수준 계약)는 서비스의 예상 가용성과 활성 지역 복제의 예상 복구 지점 및 복구 시간을 설명합니다.

영역 중복 데이터베이스 또는 탄력적 풀을 배포하고 지원되는 서비스 계층을 사용하는 경우 가동 시간 SLA가 더 높습니다.

관련 콘텐츠

• SQL Database를 통한 비즈니스 연속성 개요
• 고가용성 및 재해 복구 체크리스트 - SQL Database
• Azure의 안정성