재해 복구 지침 - Azure SQL Database
적용 대상: 
Azure SQL Database
Azure SQL Database는 항상 사용할 수 있어야 하는 중요 업무용 애플리케이션을 비롯한 다양한 애플리케이션을 지원하기 위해 99.99% 이상의 업계 최고 고가용성 보장을 제공합니다. Azure SQL 데이터베이스에는 지역 중단이 발생할 경우 빠른 재해 복구를 수행하는 턴키 비즈니스 연속성 기능도 탑재되어 있습니다. 이 문서는 애플리케이션 배포 전에 검토할 중요한 정보를 포함합니다.
고가용성을 제공하기 위해 지속적으로 노력하고 있지만 Azure SQL Database 서비스가 데이터베이스 사용을 불가능하게 만들어 중단을 초래하고 애플리케이션에 영향을 미치는 경우가 있습니다. 서비스 모니터링에서 광범위한 연결 오류, 오류 또는 성능 문제를 일으키는 문제를 감지하면 서비스가 자동으로 중단을 선언하여 사용자에게 정보를 제공합니다.
서비스 중단
Azure SQL Database 서비스 중단 시 다음 위치에서 중단과 관련된 추가 세부 정보를 확인할 수 있습니다.
Azure Portal 배너
구독이 영향을 받는 것으로 식별되면 Azure Portal 알림에 서비스 문제에 대한 중단 경고가 나타납니다.
도움말 + 지원 또는 지원 + 문제 해결
도움말 + 지원 또는 지원 + 문제 해결에서 지원 티켓을 만들 때 리소스에 영향을 미치는 모든 문제에 대한 정보가 제공됩니다. 자세한 정보 및 영향의 요약을 보려면 중단 세부 정보 보기를 선택합니다. 새 지원 요청 페이지에도 경고가 나타납니다.
서비스 상태
Azure Portal의 서비스 상태 페이지에는 전 세계 Azure 데이터 센터 상태에 대한 정보가 포함되어 있습니다. Azure Portal의 검색 창에서 "서비스 상태"를 검색한 다음 활성 이벤트 범주에서 서비스 문제를 확인합니다. 도움말 메뉴 아래 리소스의 리소스 상태 페이지에서 개별 리소스의 상태를 볼 수도 있습니다. 서비스 상태 페이지의 샘플 스크린샷은 다음과 같습니다. 동남 아시아의 활성 서비스 문제에 대한 정보를 포함합니다.
이메일 알림
경고를 설정한 경우 서비스 중단이 구독 및 리소스에 영향을 줄 때
azure-noreply@microsoft.com에서 이메일 알림을 전송합니다. 이메일 본문은 일반적으로 "Azure 구독 서비스 문제가 활동 로그 경고를 ... 트리거했습니다..."로 시작합니다. 서비스 상태 경고에 대한 자세한 내용은 Azure Portal로 Azure 서비스 알림에서 활동 로그 경고 받기를 참조하세요.가용성 메트릭
Azure Portal에서 Azure SQL Database 가용성 메트릭에 대한 경고를 모니터링하고 구성할 수 있습니다.
중단 시 재해 복구 시작 시점
애플리케이션 리소스에 영향을 미치는 서비스 중단이 발생하는 경우 다음 작업 과정을 고려합니다.
Azure 팀은 최대한 빠르게 서비스 가용성을 복원하기 위해 열심히 작업하지만 근본 원인에 따라 몇 시간이 걸릴 수 있습니다. 애플리케이션이 긴 가동 중지 시간을 허용할 수 있는 경우 복구가 완료될 때까지 기다리면 됩니다. 이 경우에 사용자의 조치가 필요하지 않습니다. 도움말 메뉴 아래 리소스의 리소스 상태 페이지에서 개별 리소스의 상태를 확인합니다. 업데이트 및 중단에 대한 최신 정보는 리소스 상태 페이지를 참조하세요. 지역 복구 후에 애플리케이션의 가용성이 복원됩니다.
다른 Azure 지역으로 복구하려면 애플리케이션 연결 문자열을 변경하거나 DNS 리디렉션을 사용해야 할 수 있으며, 이로 인해 데이터가 영구적으로 손실될 수 있습니다. 따라서 중단 기간이 애플리케이션의 RTO(복구 시간 목표)에 근접할 때만 재해 복구를 수행해야 합니다. 애플리케이션을 프로덕션에 배포하면 애플리케이션 상태를 정기적으로 모니터링하고 애플리케이션 계층에서 데이터베이스로의 장기적인 연결 장애가 발생할 때만 복구를 보장하는지 확인해야 합니다. 가동 중지 시간 및 가능한 비즈니스 책임에 대한 애플리케이션 허용 범위에 따라 서비스가 복구될 때까지 기다리거나 직접 재해 복구를 시작할 수 있습니다.
중단 복구 지침
지역의 Azure SQL Database 중단을 오랜 시간 완화하지 않았으며 애플리케이션의 SLA(서비스 수준 계약)에 영향을 주는 경우 다음 단계를 고려합니다.
지역에서 복제한 보조 서버로 장애 조치(데이터 손실 없음)
활성 지역 복제 또는 장애 조치 그룹을 사용하는 경우 주 데이터베이스 및 보조 데이터베이스 리소스 상태가 Azure Portal에서 온라인인지 확인합니다. 온라인이라면 주 데이터베이스와 보조 데이터베이스 모두의 데이터 평면이 정상입니다. Azure Portal, T-SQL, PowerShell 또는 Azure CLI를 사용하여 보조 지역에 대한 활성 지역 복제 또는 장애 조치 그룹의 장애 조치를 시작합니다.
참고 항목
장애 조치를 수행하려면 역할을 전환하기 전에 전체 데이터 동기화가 필요하며 데이터 손실이 발생하지 않습니다. 서비스 중단 유형에 따라 데이터 손실이 없는 장애 조치가 성공한다는 보장은 없지만 첫 번째 복구 옵션으로 시도할 가치가 있습니다.
장애 조치를 시작하려면 다음 링크를 사용합니다.
| 기술 | 메서드 | 단계 |
|---|---|---|
| 활성 지역 복제 | PowerShell | PowerShell을 통해 지역 복제 보조로 장애 조치 |
| T-SQL | T-SQL을 통해 지역 복제 보조로 장애 조치 | |
| 장애 조치(failover) 그룹 | Azure CLI | Azure CLI를 통해 보조 서버로 장애 조치 |
| Azure Portal | Azure Portal을 통해 보조 서버로 장애 조치 | |
| PowerShell | PowerShell을 통해 보조 서버로 장애 조치 |
지역에서 복제한 보조 서버로 강제 장애 조치(잠재적인 데이터 손실)
장애 조치가 정상적으로 완료되지 않고 오류가 발생하거나 주 데이터베이스 상태가 온라인이 아닌 경우 보조 지역에 대한 잠재적인 데이터 손실을 동반하는 강제 장애 조치를 신중하게 고려합니다.
강제 장애 조치를 시작하려면 다음 링크를 사용합니다.
| 기술 | 메서드 | 단계 |
|---|---|---|
| 활성 지역 복제 | Azure CLI | Azure CLI를 통해 지역 복제 보조로 강제 장애 조치 |
| Azure Portal | Azure Portal을 통해 지역 복제 보조로 강제 장애 조치 | |
| PowerShell | PowerShell을 통해 지역 복제 보조로 강제 장애 조치 | |
| T-SQL | T-SQL을 통해 지역 복제 보조로 강제 장애 조치 | |
| 장애 조치(failover) 그룹 | Azure Portal | Azure Portal을 통해 보조 서버로 강제 장애 조치를 수행하지만 강제 장애 조치를 선택합니다. |
| Azure CLI | Azure CLI를 통해 보조 서버로 강제 장애 조치를 수행하지만 --allow-data-loss를 사용합니다 |
|
| PowerShell | PowerShell을 통해 보조 서버로 강제 장애 조치를 수행하지만 -AllowDataLoss를 사용합니다 |
지역 복원
활성 지역 복제 또는 장애 조치(failover) 그룹을 사용하도록 설정하지 않은 경우 마지막 수단으로 지역 복원을 사용하여 중단에서 복구할 수 있습니다. 지역 복원은 지역 복제된 백업을 원본으로 사용합니다. 가장 최근에 지역 복제된 백업의 Azure 지역에 있는 논리 서버에 데이터베이스를 복원할 수 있습니다. 지리적 복원은 가동 중단으로 인해 데이터베이스 또는 전체 지역에 액세스할 수 없는 경우에도 요청할 수 있습니다.
Azure CLI, Azure Portal, PowerShell 또는 REST API를 통한 지역 복원에 대한 자세한 내용은 Azure SQL Database의 지역 복원을 참조하세요.
복구 후 데이터베이스 구성
지역 장애 조치(failover) 또는 지역 복원을 사용하여 중단으로부터 복구하는 경우 일반적인 애플리케이션 함수를 다시 시작할 수 있도록 새 데이터베이스에 대한 연결이 올바르게 구성되었는지 확인해야 합니다. 복구된 데이터베이스 프로덕션을 준비하는 작업의 검사 목록입니다.
Important
재해 복구 전략의 정기적인 훈련을 수행하여 애플리케이션 허용 범위 및 복구 절차의 모든 운영 측면을 확인하는 것이 좋습니다. 애플리케이션 인프라의 다른 계층에는 재구성이 필요할 수 있습니다. 복원력 있는 아키텍처 단계에 대한 자세한 내용은 Azure SQL Database 고가용성 및 재해 복구 체크리스트를 검토하세요.
연결 문자열 업데이트
- 활성 지역 복제 또는 지역 복원을 사용하는 경우 일반적인 애플리케이션 함수를 다시 시작할 수 있도록 새 데이터베이스에 대한 연결이 제대로 구성되었는지 확인해야 합니다. 복구된 데이터베이스가 다른 서버에 상주하기 때문에 해당 서버를 가리키도록 애플리케이션의 연결 문자열을 업데이트해야 합니다. 연결 문자열을 변경하는 방법에 대한 자세한 내용은 연결 라이브러리에 대한 적절한 개발 언어를 참조하세요.
- 장애 조치(failover) 그룹을 사용하여 중단으로부터 복구하고 애플리케이션 연결 문자열에서 읽기/쓰기 및 읽기 전용 수신기를 사용하는 경우 새 주 항목으로 연결이 자동 지정되므로 추가 작업이 필요하지 않습니다.
방화벽 규칙 구성
보조 서버 및 데이터베이스에서 구성된 방화벽 규칙이 주 서버 및 주 데이터베이스에서 구성된 방화벽 규칙과 일치하는지 확인해야 합니다. 자세한 내용은 방법: 방화벽 설정 구성을 참조하세요.
로그인 및 데이터베이스 사용자 구성
새로운 주 서버의 master 데이터베이스에 있어야 하는 로그인을 만들고 이러한 로그인이 master 데이터베이스에서 적절한 권한을 가지고 있는지 확인합니다(있는 경우). 자세한 내용은 재해 복구 후 보안을 참조하세요.
원격 분석 경고 설정
기존 경고 규칙 설정을 업데이트하여 새로운 주 데이터베이스와 다른 서버에 매핑해야 합니다. 데이터베이스 경고 규칙에 대한 자세한 내용은 경고 알림 수신 및 서비스 상태 추적을 참조하세요.
감사 사용
주 서버에서 감사를 구성한 경우 보조 서버에서도 동일하게 만듭니다. 자세한 내용은 감사를 참조하세요.
관련 콘텐츠
자세한 내용은 다음을 검토하세요.
- 연속성 시나리오.
- 자동화된 백업
- 서비스에서 시작한 백업에서 데이터베이스를 복원합니다.
- 빠른 복구 옵션에 대해 알아보려면 활성 지역 복제 및 장애 조치(failover) 그룹을 참조하세요.
- 재해 복구 참고 자료 및 고가용성 및 재해 복구 체크리스트를 참조하세요.