Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.
| 재:09 | 복구 대상에 맞는 BCDR(구조적, 테스트 및 문서화된 비즈니스 연속성 및 재해 복구) 계획을 구현합니다. 계획은 모든 구성 요소와 시스템 전체를 포함해야 합니다. |
|---|
이 가이드에서는 워크로드에 대한 신뢰할 수 있는 재해 복구 전략을 설계하기 위한 권장 사항을 설명합니다. 고객을 위해 보장한 내부 SLO(서비스 수준 목표) 또는 SLA(서비스 수준 계약)를 충족하려면 강력하고 안정적인 재해 복구 전략이 있어야 합니다. 오류 및 기타 주요 문제가 예상됩니다. 이러한 인시던트에 대처하기 위한 준비는 고객이 귀하의 비즈니스를 얼마나 신뢰할 수 있는지를 결정하며, 안정적으로 서비스를 제공할 수 있는지를 보여줍니다. 재해 복구 전략은 주요 인시던트에 대한 준비의 중추입니다.
정의
| 기간 | 정의 |
|---|---|
| 장애 조치 (페일오버) | 프로덕션 워크로드 트래픽을 사용할 수 없는 지역에서 영향을 받지 않는 지리적 지역으로 자동 및/또는 수동으로 이동하는 작업입니다. |
| 장애 복구 | 장애 조치(failover) 지역의 프로덕션 워크로드 트래픽을 주 지역으로 자동 또는 수동으로 전환하는 일입니다. |
주요 디자인 전략
이 가이드에서는 안정성 계획의 일부로 다음 작업을 이미 수행했다고 가정합니다.
중요 및 중요하지 않은 흐름을 식별 합니다.
흐름에 대한 FMA(오류 모드 분석)를 수행합니다.
안정성 대상을 식별 합니다.
중복성, 크기 조정, 자체 보존 및 자체 복구를 통해 안정성을 위한 디자인
강력한 테스트 전략을 설계합니다.
신뢰할 수 있는 DR(재해 복구) 전략은 신뢰할 수 있는 워크로드 아키텍처를 기반으로 합니다. DR 전략 설계를 시작하기 전에 최적화된 복구에 필요한 부분이 준비되도록 워크로드를 빌드하는 모든 단계에서 안정성을 해결합니다. 이 기반을 통해 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)와 같은 워크로드의 안정성 목표가 현실적이고 달성 가능합니다.
재해 복구 계획 유지 관리
워크로드에 대한 신뢰할 수 있는 DR 전략의 초석은 DR 계획입니다. 계획은 환경이 발전함에 따라 정기적으로 검토 및 업데이트되는 살아있는 문서여야 합니다. 적절한 팀(운영, 기술 리더십 및 비즈니스 이해 관계자)에게 정기적으로 계획을 제시합니다(예: 6개월마다). 비즈니스용 OneDrive와 같은 고가용성 보안 데이터 저장소에 저장합니다.
다음 권장 사항에 따라 DR 계획을 개발합니다.
재해를 구성하는 항목을 명확하게 정의하므로 DR 계획을 활성화해야 합니다.
재해는 대규모 문제입니다. 지역 중단, Microsoft Entra ID 또는 Azure DNS와 같은 서비스 중단 또는 랜섬웨어 공격 또는 DDoS 공격과 같은 심각한 악의적인 공격일 수 있습니다.
운영자가 DR 에스컬레이션을 실수로 호출하지 않도록 단일 리소스의 실패와 같이 재해로 간주되지 않는 오류 모드를 식별합니다. 이러한 오류 모드는 현재 위치에서 문제를 해결하거나 실패한 리소스를 다시 배포하거나 Backup 계획을 활용하여 해결할 수 있습니다.
FMA 문서에서 DR 계획을 수립합니다. DR 계획이 재해로 정의된 중단에 대한 오류 모드 및 완화 전략을 캡처하는지 확인합니다. 환경이 변경되거나 테스트할 때 예기치 않은 동작이 발견되면 정확할 수 있도록 DR 계획과 FMA 문서를 동시에 업데이트합니다.
- 비프로덕션 환경에 대한 DR 계획을 개발하는지 여부는 비즈니스 요구 사항 및 비용 영향에 따라 달라집니다. 예를 들어 시험판 테스트를 위해 특정 고객에게 QA(품질 보증) 환경을 제공하는 경우 해당 환경을 DR 계획에 포함할 수 있습니다.
워크로드 팀 내에서 역할 및 책임을 명확하게 정의하고 조직 내의 모든 관련 외부 역할을 이해합니다. 역할에는 다음이 포함되어야 합니다.
재해를 선언할 책임이 있는 당사자입니다.
사고 종료를 선언할 책임을 지는 주체입니다.
운영 역할.
테스트 및 유효성 검사 역할.
내부 및 외부 통신 역할.
회고 및 근본 원인 분석(RCA) 주도 역할.
워크로드 팀이 따라야 하는 에스컬레이션 경로를 정의하여 복구 상태가 관련자에게 전달되도록 합니다.
구성 요소 수준 복구 절차, 데이터 자산 수준 복구 및 워크로드 전체 복구 프로세스를 캡처합니다. 구성 요소가 최소한의 영향으로 복구되도록 규정된 작업 순서를 포함합니다. 예를 들어 애플리케이션을 복구하기 전에 데이터베이스를 복구하고 확인합니다.
각 구성 요소 수준 복구 절차를 단계별 가이드로 자세히 설명합니다. 가능한 경우 스크린샷을 포함합니다.
팀의 책임과 클라우드 호스팅 공급자의 책임을 정의합니다. 예를 들어 Microsoft는 PaaS(Platform as a Service)를 복원할 책임이 있지만 데이터를 리하일링하고 서비스에 구성을 적용할 책임이 있습니다.
프로시저를 실행하기 위한 필수 구성 요소를 포함합니다. 예를 들어 수집해야 하는 필수 스크립트 또는 자격 증명을 나열합니다.
복구를 시작하기 전에 인시던트 근본 원인을 캡처하고 완화를 수행합니다. 예를 들어 인시던트 원인이 보안 문제인 경우 장애 조치(failover) 환경에서 영향을 받는 시스템을 복구하기 전에 해당 문제를 완화합니다.
워크로드의 중복성 디자인 에 따라 고객이 워크로드를 다시 사용할 수 있도록 하기 전에 중요한 장애 조치(failover) 후 작업을 수행해야 할 수 있습니다. 장애 조치 후 작업에는 DNS 업데이트, 데이터베이스 연결 문자열 업데이트 및 트래픽 라우팅 변경 내용이 포함될 수 있습니다. 복구 절차에 장애 조치(failover) 후의 모든 작업을 반영하십시오.
비고
중복성 설계를 사용하면 주요 인시던트에서 완전히 또는 부분적으로 자동으로 복구할 수 있으므로 계획에 이러한 시나리오에 대한 프로세스 및 절차가 포함되어 있는지 확인합니다. 예를 들어 가용성 영역 또는 지역에 걸쳐 있는 완전 활성-활성 디자인이 있는 경우, 가용성 영역 또는 지역의 중단 후에 자동으로 투명하게 장애 조치를 수행하여, 수행해야 하는 DR 계획의 단계를 최소화할 수 있습니다. 마찬가지로 배포 스탬프를 사용하여 워크로드를 설계한 경우 스탬프가 영역별로 배포되는 경우 부분적인 중단만 발생할 수 있습니다. 이 경우 DR 계획은 영향을 받지 않는 영역 또는 지역에서 스탬프를 복구하는 방법을 다루어야 합니다.
장애 조치(failover) 환경에서 앱을 다시 배포해야 하는 경우 도구를 사용하여 배포 프로세스를 최대한 자동화합니다. 앱 배포를 즉시 시작할 수 있도록 DevOps 파이프라인이 장애 조치(failover) 환경에서 미리 배포되고 구성되었는지 확인합니다. 필요한 경우 수동 승인 게이트가 있는 자동화된 엔드 투 엔드 배포를 사용하여 일관되고 효율적인 배포 프로세스를 보장합니다. 전체 배포 기간은 복구 대상에 맞춰야 합니다.
- 배포 프로세스의 단계에 수동 개입이 필요한 경우 수동 단계를 문서화합니다. 역할과 책임을 명확하게 정의합니다.
가능한 한 많은 절차를 자동화합니다. 스크립트에서 멱등성을 허용하므로 선언적 프로그래밍을 사용합니다. 선언적 프로그래밍을 사용할 수 없는 경우 사용자 지정 코드를 개발하고 실행하는 것을 염두에 두어야 합니다. 재시도 논리 및 회로 차단기 논리를 사용하여 중단된 작업에 중단된 스크립트에서 시간을 낭비하지 않도록 합니다. 이러한 스크립트는 응급 상황에서만 실행하므로 잘못 개발된 스크립트가 더 많은 손상을 입히거나 복구 프로세스를 느리게 하는 것을 원하지 않습니다.
비고
자동화는 위험을 초래합니다. 학습된 운영자는 자동화된 프로세스를 주의 깊게 모니터링하고 프로세스가 문제가 발생하는 경우 개입해야 합니다. 자동화가 오탐에 반응할 위험을 최소화하려면 재해 복구(Disaster Recovery) 훈련을 철저히 수행합니다. 계획의 모든 단계를 테스트합니다. 검색을 시뮬레이션하여 경고를 생성한 다음 전체 복구 절차를 진행합니다.
DR 훈련은 복구 목표 메트릭의 업데이트를 확인하고 관련 정보를 제공해야 합니다. 자동화가 거짓 긍정에 취약하다는 것을 알게 되면 장애 조치(failover) 임계값을 늘려야 할 수 있습니다.
DR 절차와 혼동되지 않도록 DR 계획과 장애 복구 계획을 분리합니다. 장애 복구 계획은 DR 계획의 모든 개발 및 유지 관리 권장 사항을 따라야 하며 동일한 방식으로 구성되어야 합니다. 장애 조치 시 필요했던 수동 단계는 장애 복구 계획에 반영되어야 합니다. 장애 복구는 장애 조치 후 빠르게 이루어질 수도 있고, 며칠 또는 몇 주가 걸릴 수도 있습니다. 장애 복구(failback)를 장애 조치(failover)와 분리된 것으로 간주합니다.
- 장애 복구(failback)의 필요성은 상황에 따라 다릅니다. 성능상의 이유로 지역 간에 트래픽을 라우팅하는 경우, 장애 조치로 인해 발생한 부하를 원래 지역으로 되돌리는 것이 중요합니다. 다른 경우에는 워크로드가 언제든지 있는 프로덕션 환경에 관계없이 완벽하게 작동하도록 설계했을 수 있습니다.
재해 복구 훈련 수행
DR 테스트 사례는 잘 개발된 DR 계획만큼이나 중요합니다. 많은 산업에는 지정된 수의 DR 훈련을 정기적으로 수행해야 하는 규정 준수 프레임워크가 있습니다. 업계에 관계없이 정기적인 DR 훈련이 성공에 가장 중요합니다.
성공적인 DR 훈련을 위해 다음 권장 사항을 따릅니다.
연간 하나 이상의 프로덕션 DR 드릴을 수행합니다. 탁상 모의 훈련 또는 비생산 훈련은 관련 당사자가 자신의 역할과 책임을 잘 알고 있는지 확인하는 데 도움이 됩니다. 이러한 훈련은 또한 운영자가 복구 프로세스를 수행하여 친숙함("근육 메모리")을 구축하는 데 도움이 됩니다. 그러나 운영 연습만이 DR 계획 및 RTO와 RPO 측정치의 유효성을 실제로 테스트합니다. 프로덕션 훈련을 사용하여 구성 요소 및 흐름에 대한 시간 복구 프로세스를 사용하여 워크로드에 대해 정의된 RTO 및 RPO 대상을 달성할 수 있는지 확인합니다. DNS 전파와 같이 제어할 수 없는 함수의 경우 해당 함수를 포함하는 흐름에 대한 RTO 및 RPO 대상이 제어할 수 없는 지연을 고려해야 합니다.
탁상 훈련을 사용하여 숙성된 운영자에 대한 친숙도를 구축할 뿐만 아니라 DR 프로세스 및 절차에 대한 새로운 운영자를 교육합니다. 고위 운영자는 새로운 운영자가 자신의 역할을 수행 할 수 있도록 시간이 걸릴해야하며 개선 기회를 주시해야합니다. 새 연산자가 프로시저의 한 단계로 주저하거나 혼동되는 경우 해당 절차를 검토하여 명확하게 작성되었는지 확인합니다.
고려 사항
프로덕션 환경에서 DR 훈련을 수행하면 예기치 않은 치명적인 오류가 발생할 수 있습니다. 초기 배포 중에 비프로덕션 환경에서 복구 절차를 테스트해야 합니다.
훈련 중에 팀에 가능한 한 많은 유지 관리 시간을 제공합니다. 유지 관리 시간을 계획할 때 테스트 중에 캡처한 복구 메트릭을 필요한 최소 시간으로 사용합니다.
DR 훈련 연습이 성숙해짐에 따라, 병렬로 실행할 수 있는 절차와 순서대로 실행해야 하는 절차를 배우게 됩니다. 드릴 연습 초기에는 모든 프로시저를 순서대로 실행해야 하며 예기치 않은 문제를 처리하기 위해 각 단계에서 추가 시간이 필요하다고 가정합니다.
중요한 흐름 내에서 리소스에 대한 Backup 계획 정의 및 유지 관리
백업은 전체 복구 프로세스에서 중요한 부분입니다. 종종 복구가 필요한 환경의 일부일 뿐입니다. DR 계획은 일반적으로 애플리케이션 또는 지역 전체입니다. 실수로 또는 악의적인 데이터 삭제, 파일 손상, 맬웨어 및 대상 랜섬웨어 공격은 모두 워크로드의 가용성에 영향을 줄 수 있습니다. DR 계획은 효과적인 견고한 백업 계획에 따라 달라지기 때문에 환경의 각 부분에 대해 견고한 백업 계획을 갖는 것은 효과적인 DR 계획을 갖는 것만큼이나 중요합니다. DR 계획과 마찬가지로 백업 계획은 적절한 관리 수준에서 합의하고, 가능한 업데이트를 위해 정기적으로 다시 검토하고, 고가용성 보안 데이터 저장소에 문서화해야 합니다.
워크로드 내의 중요한 경로에 속하는 다양한 Azure 서비스에 대한 적절한 백업 솔루션을 결정합니다.
각 서비스에 필요한 보존 기간을 정의합니다.
하나의 도구가 모든 항목에 대해 작동하지 않을 수 있음을 이해합니다. Azure Backup 도구는 많은 리소스 종류를 포함할 수 있지만 전부는 아닙니다.
경우에 따라 특정 유형의 개체를 복원하는 가장 좋은 옵션은 고가용성 리포지토리의 일부 수준 형식에서 재배포하는 것입니다. (Azure DevOps, GitHub 또는 기타)
데이터 서비스에는 애플리케이션 관련 개체와 다른 요구 사항이 있습니다.
지역 간 복구 기능을 만들기 위해 백업 데이터에 대한 다중 지역 스토리지 전략을 고려해야 합니다.
백업 데이터의 정기 예약된 테스트 복원을 실행하여 서비스가 예상대로 작동하는지 확인합니다.
Azure 지원
많은 Azure 제품에는 기본 제공 장애 조치(failover) 기능이 있습니다. 이러한 기능을 숙지하고 복구 절차에 포함합니다. DR에 대한 엔터프라이즈 데이터 자산 준비에 대한 지침은 Azure 데이터 플랫폼 시리즈용 DR을 참조하세요.
IaaS(서비스로서의 인프라) 시스템의 경우 Azure Site Recovery 를 사용하여 장애 조치(failover) 및 복구를 자동화합니다. 일반적인 PaaS 제품에 대해서는 다음 문서를 참조하세요.
많은 Azure 제품에는 기본 제공 백업 기능이 있습니다. 이러한 기능을 숙지하고 복구 절차에 포함합니다.
IaaS(서비스로서의 인프라) 시스템의 경우 Azure Backup 을 사용하여 VM 및 VM 관련 서비스 및 일부 데이터 서비스의 백업을 용이하게 합니다. 일반적인 제품에 대해서는 다음 문서를 참조하세요.
관련 링크
안정성 검사 목록
전체 권장 사항 집합을 참조하세요.