고가용성 및 재해 복구 구성
SQL Server에서 재해 복구 및 고가용성 솔루션을 구성하는 주요 부분은 Azure Virtual Machine에서 실행되는 SQL Server에서도 동일하게 유지됩니다. 고가용성 솔루션은 오류로 인해 커밋된 데이터가 손실되지 않고, 워크로드가 유지 관리 작업의 영향을 받지 않고, 데이터베이스가 소프트웨어 아키텍처의 단일 실패 지점이 되지 않도록 보장하도록 설계되었습니다.
대부분의 Azure SQL 서비스 계층은 로컬 중복성부터 영역 중복 모델까지 다양한 고가용성 옵션을 제공합니다.
다음으로 Azure PaaS 제품의 재해 복구 및 고가용성을 위한 특정 솔루션을 살펴보겠습니다.
지속적인 백업
Azure SQL Database는 데이터베이스의 정기적이고 지속적인 백업을 보장하며, 이 백업은 RA-GRS(읽기 액세스 지역 중복 스토리지)에 복제됩니다.
주간 전체 백업, 12~24시간 간격의 차등 백업, 5~10분 간격의 트랜잭션 로그 백업은 자동화된 백업 전략의 일부입니다. 확장된 백업 가용성(최대 10년)을 위해 단일 데이터베이스와 풀링된 데이터베이스 모두에 대해 LTR(장기 보존)을 구성할 수 있습니다.
LTR(장기 보존)
Azure는 일반적인 한도 이상으로 설정할 수 있는 보존 정책을 제공하며, 이는 장기 보존이 필요한 시나리오에 유용합니다. 최대 10년 동안 보존 정책을 설정할 수 있으며 이 옵션은 기본적으로 사용하지 않도록 설정되어 있습니다.
이미지는 Azure Portal에서 장기 보존 정책을 설정하는 방법을 보여 줍니다. 데이터베이스를 선택하면 기본 설정을 변경할 수 있는 패널이 화면 오른쪽에 나타납니다.
장기 보존에 대한 자세한 내용은 장기 보존 - Azure SQL Database 및 Azure SQL Managed Instance를 참조하세요.
지역 복원
SQL Database 및 SQL Managed Instance에 대한 백업은 기본적으로 지역 중복됩니다. 이를 통해 데이터베이스를 다른 지역으로 쉽게 복원할 수 있으며, 이는 덜 엄격한 재해 복구 시나리오에 유용한 기능입니다.
백업 스토리지는 일반 데이터베이스 파일 스토리지와는 별도로 청구됩니다. 그러나 SQL Database를 프로비저닝할 때 추가 비용 없이 데이터베이스에 대해 데이터 계층의 최대 크기가 선택된 상태로 백업 스토리지가 만들어집니다.
지역 복원 작업의 기간은 데이터베이스 크기, 복원 작업에 관련된 트랜잭션 로그 수, 대상 지역에서 처리되는 동시 복원 요청의 양을 비롯한 여러 기본 구성 요소의 영향을 받을 수 있습니다.
PITR(특정 시점 복원)
정의된 보존 기간에 따라 데이터베이스를 특정 시점으로 복원할 수 있지만 PITR은 백업이 시작된 동일한 서버에서 데이터베이스를 복원하는 경우에만 지원됩니다. Azure Portal, Azure PowerShell, Azure CLI 또는 REST API를 사용하여 SQL Database를 복원할 수 있습니다.
활성 지리적 복제
Azure SQL Database의 가용성을 높이는 한 가지 방법은 활성 지역 복제를 사용하는 것입니다. 활성 지역 복제는 비동기적으로 최신 상태로 유지되는 보조 데이터베이스 복제본을 다른 지역에 만듭니다.
이 복제본은 SQL Server의 AlwaysOn 가용성 그룹과 유사하게 읽을 수 있습니다. 표면적으로 Azure는 가용성 그룹을 사용하여 이 기능을 유지 관리하므로 일부 용어가 유사합니다.
활성 지역 복제는 고객이 주요 재해 시 주 데이터베이스를 보조 지역으로 장애 조치(failover)할 때 이를 프로그래밍 방식으로 또는 수동으로 수행할 수 있도록 함으로써 비즈니스 연속성을 제공합니다.
참고 항목
Azure SQL Managed Instance는 활성 지역 복제를 지원하지 않습니다. 대신 이 단원의 뒷부분에서 살펴볼 항목인 자동 장애 조치(failover) 그룹을 사용해야 합니다.
지역 복제 관계와 관련된 모든 데이터베이스는 동일한 서비스 계층을 가져야 합니다. 또한 과도한 쓰기 워크로드로 인한 복제 성능 문제를 방지하려면 기본 복제본과 동일한 컴퓨팅 크기로 보조 복제본을 구성하는 것이 좋습니다.
데이터베이스 블레이드에 액세스하고 데이터 관리 섹션에서 복제본을 선택한 다음 + 복제본 만들기를 선택하여 Azure SQL Database에 대한 지역 복제를 수동으로 구성할 수 있습니다.
보조 복제본이 설정되면 수동으로 장애 조치(failover)를 시작할 수 있는 옵션이 제공됩니다. 이 프로세스에서는 역할이 역전됩니다. 즉, 보조 복제본이 기본 복제본의 역할을 맡고 원래 기본 복제본이 보조 복제본이 됩니다.
구독 간 지역 복제
특정 시나리오에서는 주 데이터베이스와 다른 구독에 보조 복제본을 구성해야 할 수도 있습니다. 여기에서 구독 간 지역 복제 기능이 작동합니다.
참고 항목
구독 간 지역 복제는 프로그래밍 방식으로만 사용할 수 있습니다.
구독 간 지역 복제를 구성하는 데 필요한 단계에 관한 자세한 내용은 구독 간 지역 복제를 참조하세요.
자동 장애 조치 그룹
자동 장애 조치(failover) 그룹은 Azure SQL Database와 Azure SQL Managed Instance 모두에서 지원되는 고가용성 기능입니다. 자동 장애 조치(failover) 그룹을 사용하면 데이터베이스가 다른 지역에 복제되는 방식과 장애 조치(failover)가 발생하는 방식을 관리할 수 있습니다. 자동 장애 조치(failover) 그룹에 할당된 이름은 *.database.windows.net 도메인 내에서 고유해야 합니다.
자동 장애 조치(failover) 그룹에는 여러 데이터베이스가 포함될 수 있습니다. 기본 및 보조 데이터베이스 크기는 모두 동일합니다.
자동 장애 조치(failover) 그룹은 AG와 유사한 기능인 수신기를 제공하는데, 수신기는 읽기/쓰기 작업과 읽기 전용 작업을 모두 허용합니다. 수신기에는 두 가지 형식이 있습니다. 하나는 읽기-쓰기용이고 다른 하나는 읽기 전용 트래픽용입니다. 장애 조치(failover)에서 내부적으로 DNS가 업데이트되므로 클라이언트가 추상화된 수신기 이름을 가리킬 수 있으며 다른 것은 알 필요가 없습니다. 읽기/쓰기 복사본을 포함하는 데이터베이스 서버는 주 서버이고, 주 서버에서 트랜잭션을 수신하는 서버는 보조 서버입니다.
자동 장애 조치(failover) 그룹에는 두 가지 정책이 있습니다.
| 정책 유형 | 설명 |
|---|---|
| 자동 | 오류가 검색되면 시스템은 기본적으로 자동으로 장애 조치(failover)를 트리거합니다. 그러나 필요한 경우 자동 장애 조치(failover)를 사용하지 않도록 설정할 수 있습니다. |
| 읽기 전용 | 장애 조치(failover) 중에 엔진은 기본적으로 읽기 전용 수신기를 사용하지 않도록 설정하여 보조 수신기가 다운될 때 새 기본 수신기의 성능을 유지합니다. 그러나 장애 조치(failover) 후 두 가지 형식의 트래픽을 모두 허용하도록 이 동작을 변경할 수 있습니다. |
장애 조치(failover)는 자동 장애 조치(failover)가 사용하도록 설정된 경우에도 수동으로 시작할 수 있는 프로세스입니다. 그러나 장애 조치(failover) 형식은 데이터 손실 발생 여부에 영향을 미칠 수 있습니다. 예를 들어, 계획되지 않은 장애 조치(failover)가 강제로 수행되고 보조 데이터베이스가 기본 데이터베이스와 완전히 동기화되지 않은 경우 데이터 손실이 발생할 수 있습니다.
GracePeriodWithDataLossHours는 Azure가 장애 조치(failover)를 시작하기 전에 대기하는 기간을 결정하며 기본값은 1시간으로 설정됩니다. RPO(복구 지점 목표)가 엄격하고 데이터 손실이 옵션이 아닌 경우 이 값을 더 높게 설정할 수 있습니다. 이는 Azure가 장애 조치(failover)를 시작하기 전에 더 오래 기다린다는 의미이지만 보조 데이터베이스가 기본 데이터베이스와 완전히 동기화하는 데 더 많은 시간을 제공하므로 잠재적으로 데이터 손실을 줄일 수 있습니다.
참고 항목
보조 데이터베이스는 시드라는 프로세스를 통해 자동으로 만들어지며 데이터베이스 크기에 따라 시간이 걸릴 수 있습니다. 따라서 네트워크 속도와 같은 요소를 고려하여 미리 계획을 세우는 것이 중요합니다.
Azure SQL Database의 고가용성 및 재해 복구에 대해 자세히 알아보려면 Azure SQL Database 고가용성 및 재해 복구 검사 목록을 참조하세요.