Azure SQL Database의 비즈니스 연속성 개요

적용 대상: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database 및 SQL Managed Instance의 비즈니스 연속성 은 비즈니스에서 특히 컴퓨팅 인프라에 대 한 중단을 계속 진행할 수 있도록 하는 메커니즘, 정책 및 절차를 의미 합니다. 대부분의 경우 SQL Database 및 SQL Managed Instance는 클라우드 환경에서 발생할 수 있는 중단 이벤트를 처리 하 고 응용 프로그램 및 비즈니스 프로세스를 계속 실행 합니다. 그러나 SQL Database에서 처리할 수 없는 중단 이벤트는 다음과 같이 자동으로 발생 합니다.

  • 사용자가 실수로 테이블 행을 삭제하거나 업데이트했습니다.
  • 악의적인 공격자가 데이터를 삭제하거나 데이터베이스를 삭제하는 데 성공했습니다.
  • 지진은 정전 및 일시적으로 사용 하지 않도록 설정 된 데이터 센터를 발생 시켰습니다.

이 개요에서는 비즈니스 연속성 및 재해 복구를 위해 SQL Database 및 SQL Managed Instance 제공 하는 기능에 대해 설명 합니다. 데이터 손실을 유발하거나 데이터베이스 및 애플리케이션을 사용할 수 없게 만들 수 있는 중단 이벤트에서의 복구와 관련된 옵션, 권장 사항 및 자습서에 대해 알아봅니다. 사용자 또는 애플리케이션 오류가 데이터 무결성에 영향을 주거나, Azure 지역에 가동 중단이 발생하거나, 애플리케이션에 유지 관리가 필요할 때 수행할 작업을 알아봅니다.

비즈니스 연속성을 제공하는 데 사용할 수 있는 SQL Database 기능

데이터베이스 관점에서 다음 네 가지 주요 잠재적 중단 시나리오가 있습니다.

  • 로컬 하드웨어 또는 소프트웨어 오류 - 디스크 드라이브 오류와 같이 데이터베이스 노드에 영향을 미칩니다.
  • 데이터 손상 또는 삭제 - 일반적으로 애플리케이션 버그 또는 사람의 실수로 인해 발생합니다. 이러한 오류는 응용 프로그램에 따라 달라 지 며 일반적으로 데이터베이스 서비스에서 검색할 수 없습니다.
  • 데이터 센터 중단 - 아마도 자연 재해로 인해 발생했을 수 있습니다. 이 시나리오에는 대체 데이터 센터로의 애플리케이션 장애 조치가 포함된 일부 수준의 지리적 중복성이 필요합니다.
  • 업그레이드 또는 유지 관리 오류, 계획 된 인프라 유지 관리 또는 업그레이드 중에 발생 하는 예기치 않은 문제는 이전 데이터베이스 상태로의 신속한 롤백이 필요할 수 있습니다.

로컬 하드웨어 및 소프트웨어 오류를 완화 하기 위해 SQL Database에는 고가용성 아키텍처가포함 되어 있으며,이는 최대 99.995%의 가용성 SLA를 통해 이러한 오류를 자동으로 복구할 수 있도록 보장 합니다.

데이터 손실 로부터 비즈니스를 보호 하기 위해 SQL Database 및 SQL Managed Instance는 매주 전체 데이터베이스 백업, 12 시간 마다 차등 데이터베이스 백업 및 5-10 분 마다 트랜잭션 로그 백업을 자동으로 만듭니다. 백업은 모든 서비스 계층에 대해 최소 7 일 동안 GRS 저장소에 저장 됩니다. 지정 시간 복원에 대 한 기본 지원 구성 가능한 백업 보존 기간을 제외한 모든 서비스 계층은 최대 35 일입니다.

또한 SQL Database 및 SQL Managed Instance는 계획 되지 않은 여러 시나리오를 완화 하는 데 사용할 수 있는 여러 비즈니스 연속성 기능을 제공 합니다.

  • temporal 테이블을 사용하면 특정 시점의 행 버전을 복원할 수 있습니다.
  • 자동 백업 및 지정 시간 복원 기능을 사용 하면 전체 데이터베이스를 구성 된 보존 기간 (최대 35 일) 내에 특정 시점으로 복원할 수 있습니다.
  • 삭제 된 데이터베이스는 서버가 삭제 되지 않은 경우 삭제 된 시점으로 복원할 수 있습니다.
  • 장기 백업 보존을 사용하면 백업을 최대 10년 동안 유지할 수 있습니다. 이는 SQL Managed Instance에 대해 제한 된 공개 미리 보기 상태입니다.
  • 활성 지역 복제 를 사용 하면 데이터 센터 가동 중단 또는 응용 프로그램 업그레이드 시 읽기 가능한 복제본을 만들고 모든 복제본으로 수동으로 장애 조치 (failover) 할 수 있습니다.
  • 자동 장애 조치 (failover) 그룹 을 사용 하면 데이터 센터 중단이 발생 한 경우 응용 프로그램이 자동으로 복구 됩니다.

동일한 Azure 지역 내에서 데이터베이스 복구

자동 데이터베이스 백업을 사용 하 여 과거의 특정 시점으로 데이터베이스를 복원할 수 있습니다. 이러한 방식으로 사용자 오류로 인 한 데이터 손상을 복구할 수 있습니다. 지정 시간 복원을 사용 하면 손상 이벤트 이전의 데이터 상태를 나타내는 동일한 서버에 새 데이터베이스를 만들 수 있습니다. 대부분의 데이터베이스의 경우 복원 작업은 12 시간 이내에 수행 됩니다. 매우 크거나 매우 활성 상태인 데이터베이스를 복구 하는 데 시간이 오래 걸릴 수 있습니다. 복구 시간에 대한 자세한 내용은 데이터베이스 복구 시간을 참조하세요.

PITR (지정 시간 복원)에 대해 지원 되는 최대 백업 보존 기간이 응용 프로그램에 대해 충분 하지 않은 경우 데이터베이스에 대해 LTR (장기 보존) 정책을 구성 하 여 확장할 수 있습니다. 자세한 내용은 장기 백업 보존을 참조하세요.

장애 조치 (failover) 그룹과 지역에서 복제 비교

자동 장애 조치 그룹지역에서 복제 의 배포 및 사용을 간소화 하 고 다음 표에 설명 된 대로 추가 기능을 추가 합니다.

지역에서 복제 장애 조치(failover) 그룹
자동 장애 조치(Failover) 아니요
여러 데이터베이스를 동시에 장애 조치(failover) 아니요
사용자가 장애 조치(failover) 후에 연결 문자열을 업데이트해야 함 아니요
SQL Managed Instance 지원 아니요
주 복제본과 동일한 지역에 있을 수 있음 아니요
여러 복제본 아니요
읽기 확장 지원

기존 서버에 데이터베이스 복구

드문 경우 지만 Azure 데이터 센터에서 가동 중단이 발생할 수 있습니다. 가동 중단이 발생하면 몇 분 내지 몇 시간 동안 지속될 수 있는 업무 중단이 발생합니다.

  • 한 가지 옵션은 데이터 센터 중단이 발생 했을 때 데이터베이스가 다시 온라인 상태가 될 때까지 대기 하는 것입니다. 이러한 방법은 데이터베이스의 오프라인 유지가 가능한 애플리케이션에 적합합니다. 예를 들어 지속적으로 작업할 필요가 없는 개발 프로젝트 또는 무료 평가판이 있습니다. 데이터 센터의 작동이 중단 되 면 중단이 얼마나 지속 될 지 알 수 없으므로이 옵션은 잠시 동안 데이터베이스가 필요 하지 않은 경우에만 작동 합니다.
  • 또 다른 옵션은 지역 중복 데이터베이스 백업(지역 복원)을 사용하여 모든 Azure 지역의 모든 서버에서 데이터베이스를 복원하는 것입니다. 지리적 복원은 지역 중복 백업을 해당 원본으로 사용하고 가동 중단으로 인해 데이터베이스 또는 데이터 센터에 액세스할 수 없는 경우에도 데이터베이스를 복구하는 데 사용될 수 있습니다.
  • 마지막으로, 활성 지역 복제 를 사용 하 여 지리적 보조를 구성 했거나 데이터베이스 또는 데이터베이스에 대해 자동 장애 조치 (failover) 그룹 을 구성한 경우 중단에서 신속 하 게 복구할 수 있습니다. 이러한 기술의 선택에 따라 수동 또는 자동 장애 조치(failover)를 사용할 수 있습니다. 장애 조치(failover) 자체는 몇 초밖에 걸리지 않지만 서비스에서 장애 조치(failover)를 활성화하려면 최소 1시간이 걸립니다. 가동 중단 규모가 장애 조치(failover)를 수행하기에 적합한지를 확인해야 하기 때문입니다. 또한 비동기 복제의 특성상 장애 조치(failover)로 인해 데이터가 약간 손실될 수도 있습니다.

비즈니스 연속성 계획을 개발할 때는 중단 이벤트가 발생한 후 애플리케이션이 완전히 복구되기까지 허용되는 최대 시간을 이해해야 합니다. 응용 프로그램을 완전히 복구 하는 데 필요한 시간을 RTO (복구 시간 목표) 라고 합니다. 또한 계획 되지 않은 중단 이벤트에서 복구할 때 응용 프로그램이 손실을 허용할 수 있는 최신 데이터 업데이트 (시간 간격)의 최대 기간을 이해 해야 합니다. 잠재적 데이터 손실은 RPO (복구 지점 목표) 라고 합니다.

복구 방법 마다 다른 수준의 RPO 및 RTO를 제공 합니다. 특정 복구 방법을 선택 하거나 방법 조합을 사용 하 여 전체 응용 프로그램 복구를 달성할 수 있습니다. 다음 표에서는 각 복구 옵션의 RPO 및 RTO를 비교 합니다. 자동 장애 조치 그룹은 지역에서 복제의 배포 및 사용을 간소화 하 고 다음 표에 설명 된 대로 추가 기능을 추가 합니다.

복구 방법 RTO RPO
지리적으로 복제된 백업에서 지역 복원 12 h 1 h
자동 장애 조치 그룹 1 h 5 s
수동 데이터베이스 장애 조치 (failover) 30 초 5 s

참고

수동 데이터베이스 장애 조치 (failover)계획 되지 않은 모드를 사용 하 여 단일 데이터베이스를 지역에서 복제 된 보조 복제본으로 장애 조치 (failover) 자동 장애 조치(failover) RTO 및 RPO 세부 정보는 이 문서 앞부분의 표를 참조하세요.

애플리케이션이 다음 조건에 맞는 경우 자동 장애 조치(failover) 그룹을 사용합니다.

  • 중요 업무용입니다.
  • 12시간 이상의 가동 중지 시간을 허용하지 않는 SLA(서비스 수준 약정)가 있습니다.
  • 가동 중지는 재무적 책임을 유발할 수 있습니다.
  • 데이터 변경률이 높고 1시간에 해당하는 데이터 손실은 허용할 수 없는 수준입니다.
  • 활성 지역 복제를 사용할 때 발생하는 추가적인 비용이 잠재적인 재무적 책임과 연계된 비즈니스 손실보다 낮습니다.

응용 프로그램 요구 사항에 따라 데이터베이스 백업 및 활성 지역 복제의 조합을 사용 하도록 선택할 수 있습니다. 이러한 비즈니스 연속성 기능을 사용 하는 독립 실행형 데이터베이스 및 탄력적 풀에 대 한 디자인 고려 사항에 대 한 자세한 내용은 클라우드 재해 복구를 위한 응용 프로그램 디자인탄력적 풀 재해 복구 전략을 참조 하세요.

다음 섹션에서는 데이터베이스 백업 또는 활성 지역 복제를 사용하는 복구 단계를 대략적으로 설명합니다. 계획 요구 사항, 복구 후 단계 및 가동 중단을 시뮬레이션 하 여 재해 복구 훈련을 수행 하는 방법에 대 한 자세한 단계는 중단에서 SQL Database 데이터베이스 복구를 참조 하세요.

가동 중단에 대비

어떤 비즈니스 연속성 기능을 사용하든 관계없이 다음 작업을 수행해야 합니다.

  • 서버 수준 IP 방화벽 규칙, 로그인 및 master 데이터베이스 수준 사용 권한을 포함한 대상 서버를 식별하고 준비합니다.
  • 클라이언트 및 클라이언트 애플리케이션을 새 서버로 리디렉션하는 방법을 결정합니다.
  • 감사 설정 및 경고와 같은 다른 종속성을 문서화합니다.

적절한 준비 없이 장애 조치나 데이터베이스 복구 이후에 애플리케이션을 온라인 상태로 전환하면 추가 시간이 소요되고, 바쁜 업무 중 문제 해결이 필요할 수도 있어 비효율적입니다.

지역에서 복제된 보조 데이터베이스로 장애 조치

활성 지역 복제 또는 자동 장애 조치 (failover) 그룹을 복구 메커니즘으로 사용 하는 경우 자동 장애 조치 (failover) 정책을 구성 하거나 수동 계획 되지 않은 장애 조치 (failover)를 사용할 수 있습니다. 일단 장애 조치가 시작되면 보조 데이터베이스는 새로운 주 데이터베이스로 승격되며, 새 트랜잭션을 기록하고 쿼리에 응답할 준비를 갖춥니다. 이때 최소한의 데이터 손실이 있을 수 있으나 아직 복제되지 않습니다. 장애 조치(failover) 프로세스 디자인에 대한 자세한 내용은 클라우드 재해 복구를 위해 애플리케이션 디자인을 참조하세요.

참고

데이터 센터가 다시 온라인 상태가 되 면 이전 주 데이터베이스는 새 주 데이터베이스에 자동으로 다시 연결 되 고 보조 데이터베이스가 됩니다. 주 데이터베이스를 다시 원래 지역으로 재배치해야 할 경우 계획된 장애 조치를 수동으로 시작할 수 있습니다(장애 복구).

지역 복원 수행

지역 중복 스토리지(기본적으로 사용)와 함께 자동화된 백업을 사용하는 경우 지역 복원을 사용하여 데이터베이스를 복구할 수 있습니다. 일반적으로 복구는 12시간 이내에 수행됩니다. 이때 마지막 로그 백업의 실행 및 복제를 기준으로 최대 1시간의 데이터 손실이 있을 수 있습니다. 복구가 완료될 때까지 데이터베이스는 어떤 트랜잭션도 기록할 수 없으며 쿼리에 응답할 수 없습니다. 지역 복원은 데이터베이스를 마지막으로 사용할 수 있는 시점으로만 복원합니다.

참고

응용 프로그램을 복구 된 데이터베이스로 전환 하기 전에 데이터 센터가 다시 온라인 상태가 되 면 복구를 취소할 수 있습니다.

사후 장애 조치(failover)/복구 작업 수행

복구 메커니즘에서 복구한 후에는 사용자 및 애플리케이션이 다시 실행되기 전에 다음과 같은 추가 작업을 수행해야 합니다.

  • 클라이언트와 클라이언트 응용 프로그램을 새 서버와 복원 된 데이터베이스로 리디렉션합니다.
  • 사용자가 연결할 수 있는 또는 데이터베이스 수준 방화벽을 사용하여 적절한 규칙을 설정할 수 있는 적절한 서버 수준 IP 방화벽 규칙이 적용되고 있는지 확인합니다.
  • 적절 한 로그인 및 master 데이터베이스 수준 사용 권한이 있는지 확인 합니다 (또는 포함 된 사용자사용).
  • 감사를 적절 하 게 구성 합니다.
  • 적절 한 경고를 구성 합니다.

참고

장애 조치 (failover) 그룹을 사용 하 고 읽기/쓰기 수신기를 사용 하 여 데이터베이스에 연결 하는 경우 장애 조치 (failover) 후 리디렉션이 응용 프로그램에 자동으로 투명 하 게 발생 합니다.

최소 가동 중단으로 애플리케이션 업그레이드

애플리케이션 업그레이드와 같은 계획된 유지 관리로 인해 애플리케이션을 오프라인 상태로 전환해야 하는 경우도 있습니다. 애플리케이션 업그레이드 관리에서는 활성 지역 복제를 사용하여 클라우드 애플리케이션의 롤링 업그레이드를 사용하도록 설정함으로써 업그레이드 기간에 가동 중지 시간을 최소화하고 오류가 발생한 경우 복구 경로를 제공하는 방법을 설명합니다.

다음 단계

단일 데이터베이스 및 탄력적 풀에 대 한 응용 프로그램 디자인 고려 사항에 대 한 자세한 내용은 클라우드 재해 복구를 위한 응용 프로그램 디자인탄력적 풀 재해 복구 전략을 참조 하세요.