Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.
| 재:09 | 복구 대상에 맞는 구조적, 테스트 및 문서화된 DR(재해 복구) 계획을 구현합니다. 계획은 모든 구성 요소와 시스템 전체를 포함해야 합니다. |
|---|
재해는 워크로드 및 운영 팀의 신중한 계획 및 사전 준비가 필요한 중요한 인시던트입니다.
이 문서에서는 장애 조치(failover) 및 복구를 위한 복원력 있는 워크로드 디자인, 데이터 무결성 및 명확하게 정의된 목표를 강조하여 재해 복구를 위한 주요 전략을 간략하게 설명합니다. 단계별 절차보다는 DR의 목적과 지침 원칙에 중점을 둡니다. 단계별 프로세스 및 플레이북을 비롯한 자세한 구현 지침은 함께 제공되는 문서인 다중 지역 배포에 대한 재해 복구 계획 개발 문서를 참조하세요.
정의
| 기간 | 정의 |
|---|---|
| 활성-수동 냉 대기 | DR 배포 패턴이란 보조 지역에 최소 또는 전혀 실행 중인 인프라가 없고, 재해가 발생하여 '장애 조치(failover)' 동안 전체 배포가 필요할 경우를 나타냅니다. |
| 활성-수동 웜 대기 | 보조 지역에 일부 인프라가 미리 배포되고 용량이 감소하여 콜드 대기보다 더 빠른 장애 조치(failover)를 가능하게 하는 DR 배포 패턴입니다. |
| 백업 | 손실, 손상 또는 재해가 발생할 경우 데이터 복구를 사용하도록 기본 시스템과 별도로 저장된 데이터 복사본 |
| 비즈니스 중요도 | 비즈니스 운영에 대한 중요도에 따라 워크로드 또는 구성 요소의 분류로, 복구 우선 순위 및 투자 수준에 영향을 줍니다. |
| DR 활성화 조건 | 재해를 선언하고 복구 절차를 트리거할 시기를 결정하는 미리 정의된 임계값 및 조건입니다. |
| DR 드릴 | 재해 복구 절차를 테스트하고 제어된 조건에서 복구 기능의 유효성을 검사하기 위한 계획된 연습입니다. |
| 장애 복구 | 장애 조치(failover) 지역의 프로덕션 워크로드 트래픽을 주 지역으로 자동 또는 수동으로 전환하는 일입니다. |
| 장애 조치 (페일오버) | 프로덕션 워크로드 트래픽을 사용할 수 없는 지역에서 영향을 받지 않는 지리적 지역으로 자동 및/또는 수동으로 이동하는 작업입니다. |
| 지정 시간 복구 | 데이터를 특정 시점으로 복원하는 기능으로, 일반적으로 데이터 손상 또는 실수로 인한 변경으로부터 복구하는 데 사용됩니다. |
| RPO(복구 지점 목표) | 시간 단위로 측정된 최대 허용 가능한 데이터 손실 양으로, 재해 발생 시 비즈니스에서 손실될 수 있는 데이터의 양을 정의합니다. |
| RTO(복구 시간 목표) | 재해가 발생한 후 비즈니스 운영을 복원하는 데 허용되는 최대 시간입니다. |
| 동기 복제 | 변경 내용이 여러 위치에 동시에 기록되는 데이터 복제를 통해 데이터가 손실되지 않지만 대기 시간이 더 짧아질 수 있습니다. |
| 비동기 복제 | 변경 내용이 기본 위치에 먼저 기록된 다음 보조 위치에 복사되는 데이터 복제를 통해 일부 데이터 손실이 발생하지만 대기 시간이 짧아집니다. |
| 전쟁방 | 재해 복구 작업 중에 핵심 담당자가 조정하는 중앙 집중식 위치 또는 통신 채널입니다. |
비즈니스 영향별 우선 순위 지정
중요 업무용, 중요 비즈니스용, 비즈니스 운영 등 조직에서 정의한 중요 계층별로 워크로드를 분류합니다. 각 계층은 고유한 수준의 투자, 복원력 및 복구 시퀀싱을 보증한다는 것을 인식합니다. 워크로드에 다양한 중요도가 있는 여러 흐름 또는 구성 요소가 포함된 경우 이벤트 중 모호성을 방지하기 위해 각각에 대한 복구 방법을 문서화합니다.
이러한 중요 계층은 적절한 복구 목표에 영향을 줍니다. 중요도가 높은 구성 요소는 더 빠른 복구와 더 빈번한 데이터 보호가 필요하지만, 중요도가 낮은 구성 요소는 복원 속도가 느려질 수 있습니다. 이러한 요구 사항에서 복구 기대치를 비즈니스 가치와 직접 일치시키는 명확한 RTO 및 RPO 목표를 도출 합니다.
재해 임계값 정의
팀과 비즈니스 이해 관계자가 재해로 간주되는 항목과 그렇지 않은 사항을 정확히 이해해야 합니다. 전략은 전체 재해, 주요 중단 및 신속하게 해결할 수 있는 작은 문제를 구분해야 합니다. 실패하는 구성 요소에만 기반하지 마세요. 대신 문제가 사용자와 비즈니스 전체에 미치는 영향을 고려합니다.
사소한 인시던트가 실제 DR 상황과 분리되는 임계값을 정의한 후 상태 모델에 빌드합니다. 이러한 방식으로 모니터링은 조기 경고 징후를 발견할 수 있으며 적절한 복구 프로세스가 트리거됩니다.
통신 프로토콜 설정
명확한 통신이 없으면 가장 잘 설계된 재해 복구 계획조차도 무너질 수 있습니다. 의사 결정을 내리는 사람, 정보를 받는 사람 및 DR 이벤트 중에 정보가 흐르는 방식을 정의하는 명확한 통신 전략을 구축합니다.
먼저 워크로드 팀 내의 역할 및 책임과 관련된 외부 그룹을 간략하게 설명합니다. 여기에는 재해 선언, 인시던트 닫기, 작업 작업 실행, 테스트 및 유효성 검사 수행, 내부 및 외부 통신 관리, 선행 회고 또는 근본 원인 분석을 위한 소유자가 포함되어야 합니다.
단계별 지침을 제공하고, 모든 필수 구성 요소(예: 스크립트, 자격 증명 및 구성)를 나열하고, 팀과 클라우드 공급자 간의 책임을 정의합니다. 복구가 반복 실패를 방지하기 전에 근본 원인 문제가 해결되었는지 확인합니다.
적절한 사람들이 신속하게 조정할 수 있도록 부서간 업무용 전쟁실을 설정하고, 팀이 압박을 받고 즉흥적으로 대응하지 않도록 커뮤니케이션 채널과 메시지 템플릿을 미리 준비합니다.
워크로드 팀이 따라야 하는 에스컬레이션 경로를 정의하여 복구 상태가 관련자에게 전달되도록 합니다.
복구 인식 아키텍처 디자인
재해 복구 프로세스는 워크로드가 디자인되는 방식을 반영해야 하며, 반대로 복구 요구 사항은 처음부터 아키텍처 결정에 영향을 주어야 합니다. 시스템을 디자인할 때 재해 발생 시 복구하려는 방법을 고려하고 복구 요구 사항을 지원하는 패턴(예: 활성-수동 콜드 대기 또는 활성-수동 웜 대기)을 선택합니다.
데이터 복구의 경우 RPO 대상을 기반으로 하는 복제 전략을 사용합니다. 예를 들어 우선 순위가 높은 데이터에 대한 가용성 영역 간에 동기식으로, 우선 순위가 낮은 지역 간에 비동기적입니다. 일관성 모델이 복구를 지원하고, 빈번한 전체 백업 및 지정 시간 복구를 구현하고, 데이터 저장소 간의 종속성을 고려하며, 복구 중에 무결성 검사를 자동화합니다.
비고
워크로드를 설계할 때 포함 및 격리를 활용하여 개별 구성 요소의 부분 장애 조치를 허용합니다. 이렇게 하면 복잡성, 비용 및 RTO가 감소하고 전체 재해를 선언하지 않고 부분 가용성을 유지할 수 있습니다. 부분 장애 조치(failover)를 개별적으로 테스트하고, 트리거해야 할 시점을 문서화합니다.
인프라 및 복구 절차 준비
보조 지역을 미리 준비합니다. 다음과 같이 인시던트가 발생할 때 팀이 준비되도록 검사 목록을 작성합니다.
- 컴퓨팅 계층: 웜 활성/수동 워크로드의 경우, 신속한 장애 조치를 지원하기 위해 최소한의 컴퓨팅 리소스를 미리 배치합니다.
- 네트워크 인프라: VNet, 서브넷, 경로, 방화벽 및 보안 그룹을 포함하여 토폴로지 복제하고 모든 구성을 확인합니다.
- ID 및 액세스 관리: 계정 설정, RBAC 권한 및 정책을 복제하여 프로덕션과 동일한 보안 기준을 보장합니다.
- 모니터링: 가시성을 위해 구성된 경고 및 대시보드를 사용하여 모니터링 인프라를 배포합니다.
복구 프로세스를 계층화합니다. 구성 요소 수준, 데이터 자산 수준 및 워크로드 수준의 구조 프로시저입니다. 영향을 최소화하기 위한 적절한 시퀀스를 정의합니다. 예를 들어 데이터베이스에 의존하는 애플리케이션 앞에 데이터베이스를 복원합니다. 비즈니스 영향에 따라 범위를 정의합니다. 고객의 영향과 비용을 고려하여 어떤 환경, 프로덕션 및 필요한 경우 비프로덕션에 DR 적용 범위가 필요한지 결정합니다.
장애 복구(페일백) 전략과 장애 조치(페일오버)를 별도로 유지합니다.
위험: 장애 복구(failback)의 필요성은 상황에 따라 달라집니다. 예를 들어 성능을 위해 지역 간에 트래픽이 다시 라우팅된 경우 원래 지역으로 복원하는 것이 중요합니다. 다른 경우에는 어떤 환경이 활성 상태인지에 관계없이 워크로드가 완전히 작동할 수 있습니다. 장애 복구(failback)가 장애 조치(failover)와 분리된 고유하고 잘 정의된 프로세스로 처리되지 않는 경우 팀은 혼동을 일으켜 불완전한 복원 또는 장기간 가동 중지 시간을 야기할 수 있습니다.
이러한 위험을 완화하려면 장애 조치(failback) 계획을 만들고, 장애 조치(failover)의 수동 단계를 미러링하는 것을 포함하여 DR 계획과 동일한 원칙을 사용하여 장애 복구 계획을 빌드하고 유지 관리합니다. 장애 복구는 즉시 또는 며칠 또는 몇 주 동안 발생할 수 있지만 별도의 프로세스로 처리합니다.
장애 조치 후 작업을 위한 계획 수립 DNS 업데이트, 트래픽 라우팅 및 연결 문자열 조정과 같은 장애 조치(failover) 후 필요한 모든 작업을 캡처하여 워크로드를 완전히 다시 온라인 상태로 전환합니다.
강력한 백업 전략 구현
각 Azure 서비스에 맞게 조정된 백업 솔루션을 선택하고, 보존 기간을 정의하고, 모든 것을 다루는 단일 도구가 없음을 인식합니다. 지역 간 복구를 위해 다중 지역 스토리지를 고려하고 일부 리소스의 경우 고가용성 리포지토리에서 재배포를 사용합니다. 정기적으로 복원을 테스트하여 백업의 유효성을 검사하고 계획을 정기적으로 검토 및 업데이트하여 안전하게 저장하고 관련 팀에서 액세스할 수 있도록 합니다.
정기적으로 연습하기
DR 계획은 현실적인 조건에서 유효성을 검사할 때만 의미가 있습니다. 에지 케이스를 비롯한 여러 시나리오를 테스트하고, 예약된 훈련을 서프라이즈 게임 데이와 결합하여 시스템과 팀이 압력을 받고 어떻게 대응하는지 확인합니다.
DR 계획에는 모의 연습, 비프로덕션 환경에서 사전 점검 및 실제 환경 수준의 연습에 대한 절차와 타임테이블이 포함됩니다. 탁상 훈련은 팀이 역할을 연습하고, 친숙함을 구축하고, 새 멤버를 학습시키는 데 도움이 되며, 프로덕션 훈련은 계획이 실제 조건에서 RTO 및 RPO 목표를 충족하는지 확인하는 유일한 방법입니다. DNS 전파와 같은 제어 외부 프로세스의 경우 복구 시간을 평가할 때 잠재적인 지연의 유효성을 검사합니다.
전체 DR 상태를 개선하기 위해 테스트 결과를 입력으로 처리하는 프로세스를 마련합니다. 예를 들어 새 연산자가 주저하는 경우 해당 절차를 검토하여 명확하게 작성되었는지 확인합니다.
전체 재해 복구(Disaster Recovery) 훈련과 별도로, 전체 및 구성 요소 수준 RTO와 RPO를 각각 테스트하고 검증합니다. 대상을 달성할 수 있도록 지역 간 데이터 이동 또는 콜드 스토리지에서 복원과 같은 시나리오를 포함합니다.
계획을 최신 상태로 유지하고 실행 가능
DR 계획을 살아있는 문서로 처리합니다. 환경이 변화함에 따라 계획이 진화해야 하며 모든 관련 팀, 운영, 기술 리더십 및 비즈니스 이해 관계자와 정기적으로 검토해야 하며, 이상적으로는 6개월마다 검토해야 합니다.
재해 발생 시 시스템이 동작하는 방식과 대응 방법을 캡처하여 DR 계획을 FMA 설명서에 맞게 유지합니다. 테스트, 모니터링 또는 실제 인시던트 등 새로운 실패 사례를 발견할 때 계획을 업데이트하여 포함할 수 있습니다. 환경이 변경되거나 테스트가 예기치 않은 동작을 발견할 때마다 DR 계획 및 FMA 설명서가 모두 업데이트되는지 확인합니다.
시간이 지남에 따라 프로시저를 구체화합니다. DR 사례 초기에는 각 프로시저가 순서대로 실행되어야 하며 예기치 않은 문제에 대한 추가 시간을 허용해야 한다고 가정합니다. DR 사례가 완성되면 병렬로 안전하게 실행할 수 있는 단계를 식별합니다. 정제는 아키텍처 변경 사항도 반영해야 합니다. 워크로드 아키텍처가 변경되면 DR 계획을 업데이트하여 활성화 조건 또는 복구 프로세스에 대한 조정을 명확하게 정의합니다.
현실적인 복구 시간을 계획합니다. 훈련을 예약할 때 복구 단계에 필요한 최소 시간으로 테스트 메트릭을 사용합니다.
중단 시 접근성 보장
재해 복구는 계획과 실행하는 데 필요한 도구가 모두 모든 오류 조건에서 사용 가능한 상태로 유지되는 경우에만 성공합니다.
재해 복구 설명서, 스크립트 및 복구 구성 요소를 고가용성 보안 위치에 저장하여 지역 가동 중단 시에도 계속 액세스할 수 있도록 합니다. 계획, 자격 증명, 인증서 및 스크립트를 비롯한 모든 DR 자산을 보호하고 지역 간에 복제합니다. 최악의 경우 오프라인 또는 인쇄된 복사본을 유지 관리합니다. 필요한 경우 즉시 실행할 준비가 되도록 모든 지역에서 CI/CD 파이프라인을 미리 배포합니다.
복구 프로시저를 안전하게 자동화
가능한 경우 장애 조치(failover) 환경에서 배포 및 복구 절차를 자동화하여 RTO 대상을 충족하는지 확인합니다. 안정성을 위해 선언적이고 아이템포턴트한 스크립트를 사용하며, 사용자 지정 코드에는 재시도 및 회로 차단기 로직 같은 안전 장치를 구축합니다. 필요한 경우에만 수동 승인 게이트가 있는 자동화된 엔드 투 엔드 프로세스를 사용하여 배포를 즉시 시작할 수 있도록 DevOps 파이프라인을 미리 배포하고 구성합니다. 배포 타임라인이 복구 대상과 일치하는지 확인합니다.
속도와 컨트롤의 균형을 맞추기 위해 필요한 경우 수동 승인을 적용합니다. 수동 단계가 필요한 경우 명확하게 문서화하고 역할 및 책임을 정의합니다.
Azure 지원
많은 Azure 제품에는 기본 제공 장애 조치(failover) 기능이 있습니다. 이러한 기능을 숙지하고 복구 절차에 포함합니다. DR에 대한 엔터프라이즈 데이터 자산 준비에 대한 지침은 Azure 데이터 플랫폼 시리즈용 DR을 참조하세요.
IaaS(서비스로서의 인프라) 시스템의 경우 Azure Site Recovery 를 사용하여 장애 조치(failover) 및 복구를 자동화합니다. 일반적인 PaaS 제품에 대해서는 다음 문서를 참조하세요.
- Azure 앱 서비스
- Azure Container Apps
- Azure Kubernetes Service
- Azure SQL 데이터베이스
- Azure Event Hubs
- Azure Managed Redis
많은 Azure 제품에는 기본 제공 백업 기능이 있습니다. 이러한 기능을 숙지하고 복구 절차에 포함합니다.
IaaS(서비스로서의 인프라) 시스템의 경우 Azure Backup 을 사용하여 VM 및 VM 관련 서비스 및 일부 데이터 서비스의 백업을 용이하게 합니다. 일반적인 제품에 대해서는 다음 문서를 참조하세요.
- Azure 앱 서비스
- Azure Kubernetes Service
- Azure SQL 데이터베이스
- Azure Files
관련 링크
안정성 검사 목록
전체 권장 사항 집합을 참조하세요.