재해 복구 전략 설계를 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:09 복구 대상에 맞는 BCDR(구조적, 테스트 및 문서화된 비즈니스 연속성 및 재해 복구) 계획을 구현합니다. 계획은 모든 구성 요소와 시스템 전체를 포함해야 합니다.

이 가이드에서는 워크로드에 대한 신뢰할 수 있는 재해 복구 전략을 설계하기 위한 권장 사항을 설명합니다. 고객을 위해 보장한 내부 SLO(서비스 수준 목표) 또는 SLA(서비스 수준 계약)를 충족하려면 강력하고 신뢰할 수 있는 재해 복구 전략이 있어야 합니다. 오류 및 기타 주요 문제가 예상됩니다. 이러한 인시던트에 대처하기 위한 준비는 고객이 비즈니스를 신뢰할 수 있는 양을 결정하여 이를 위해 안정적으로 제공할 수 있습니다. 재해 복구 전략은 주요 인시던트에 대한 준비의 중추입니다.

정의

용어 정의
장애 조치 프로덕션 워크로드 트래픽을 사용할 수 없는 지역에서 영향을 받지 않는 지리적 지역으로 자동화 및/또는 수동으로 이동하는 것입니다.
장애 복구 장애 조치(failover) 지역에서 주 지역으로 프로덕션 워크로드 트래픽의 자동화된 및/또는 수동 이동입니다.

주요 디자인 전략

이 가이드에서는 안정성 계획의 일부로 이미 다음 작업을 수행했다고 가정합니다.

신뢰할 수 있는 DR(재해 복구) 전략은 신뢰할 수 있는 워크로드 아키텍처를 기반으로 합니다. DR 전략 설계를 시작하기 전에 최적화된 복구에 필요한 부분이 있는지 확인하기 위해 워크로드를 빌드하는 모든 단계에서 안정성을 해결합니다. 이 기반은 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)와 같은 워크로드의 안정성 목표가 현실적이고 달성 가능하도록 보장합니다.

재해 복구 계획 유지 관리

워크로드에 대한 신뢰할 수 있는 DR 전략의 초석은 DR 계획입니다. 계획은 환경이 발전함에 따라 정기적으로 검토 및 업데이트되는 살아있는 문서여야 합니다. 적절한 팀(운영, 기술 리더십 및 비즈니스 이해 관계자)에게 정기적으로 계획을 제시합니다(예: 6개월마다). 비즈니스용 OneDrive 같은 고가용성 보안 데이터 저장소에 저장합니다.

다음 권장 사항에 따라 DR 계획을 개발합니다.

  • 재해를 구성하는 항목을 명확하게 정의하므로 DR 계획을 활성화해야 합니다.

    • 재해는 대규모 문제입니다. 지역 가동 중단, Microsoft Entra ID 또는 Azure DNS와 같은 서비스 중단 또는 랜섬웨어 공격 또는 DDoS 공격과 같은 심각한 악의적인 공격일 수 있습니다.

    • 운영자가 DR 에스컬레이션을 실수로 호출하지 않도록 단일 리소스의 실패와 같이 재해로 간주되지 않는 실패 모드를 식별합니다.

  • FMA 설명서에서 DR 계획을 빌드합니다. DR 계획이 재해로 정의된 중단에 대한 오류 모드 및 완화 전략을 캡처하는지 확인합니다. 환경이 변경되거나 테스트 시 예기치 않은 동작이 발견되면 정확해지도록 DR 계획과 FMA 문서를 모두 병렬로 업데이트합니다.

    • 비프로덕션 환경에 대한 DR 계획을 개발하는지 여부는 비즈니스 요구 사항 및 비용 영향에 따라 달라집니다. 예를 들어 시험판 테스트를 위해 특정 고객에게 QA(품질 보증) 환경을 제공하는 경우 해당 환경을 DR 계획에 포함할 수 있습니다.

  • 워크로드 팀 내에서 역할 및 책임을 명확하게 정의하고 organization 내의 관련 외부 역할을 이해합니다. 역할에는 다음이 포함되어야 합니다.

    • 재해를 선언할 책임이 있는 당사자입니다.

    • 인시던트 폐쇄를 선언할 책임이 있는 당사자입니다.

    • 작업 역할.

    • 테스트 및 유효성 검사 역할.

    • 내부 및 외부 통신 역할.

    • 회고 및 RCA(근본 원인 분석) 리드 역할.

  • 워크로드 팀이 따라야 하는 에스컬레이션 경로를 정의하여 복구 상태 관련자에게 전달되도록 합니다.

  • 구성 요소 수준 복구 절차, 데이터 자산 수준 복구 및 워크로드 전체 복구 프로세스를 캡처합니다. 구성 요소가 최소한의 영향으로 복구되도록 지정된 작업 순서를 포함합니다. 예를 들어 애플리케이션을 복구하기 전에 데이터베이스를 복구하고 검사.

    • 각 구성 요소 수준 복구 프로시저를 단계별 가이드로 자세히 설명합니다. 가능한 경우 스크린샷을 포함합니다.

    • 팀의 책임과 클라우드 호스팅 공급자의 책임을 정의합니다. 예를 들어 Microsoft는 PaaS(Platform as a Service)를 복원할 책임이 있지만 데이터를 리하일레이션하고 서비스에 구성을 적용할 책임이 있습니다.

    • 프로시저를 실행하기 위한 필수 구성 요소를 포함합니다. 예를 들어 수집해야 하는 필수 스크립트 또는 자격 증명을 나열합니다.

    • 인시던트 근본 원인을 캡처하고 복구를 시작하기 전에 완화를 수행합니다. 예를 들어 인시던트 원인이 보안 문제인 경우 장애 조치(failover) 환경에서 영향을 받는 시스템을 복구하기 전에 해당 문제를 완화합니다.

  • 워크로드의 중복성 디자인 에 따라 고객이 워크로드를 다시 사용할 수 있도록 하기 전에 중요한 장애 조치(failover) 후 작업을 수행해야 할 수 있습니다. 장애 조치 후 작업에는 DNS 업데이트, 데이터베이스 연결 문자열 업데이트 및 트래픽 라우팅 변경 내용이 포함될 수 있습니다. 복구 절차에서 장애 조치(failover) 후 작업을 모두 캡처합니다.

    참고

    중복 설계를 사용하면 주요 인시던트에서 완전히 또는 부분적으로 자동으로 복구할 수 있으므로 계획에 이러한 시나리오에 대한 프로세스와 절차가 포함되어 있어야 합니다. 예를 들어 가용성 영역 또는 지역에 걸쳐 있는 완전 활성-활성 디자인이 있는 경우 가용성 영역 또는 지역 중단 후 자동으로 투명하게 장애 조치(failover)하고 수행해야 하는 DR 계획의 단계를 최소화할 수 있습니다. 마찬가지로 배포 스탬프를 사용하여 워크로드를 설계한 경우 스탬프가 영역별로 배포되는 경우 부분적인 중단만 발생할 수 있습니다. 이 경우 DR 계획은 영향을 받지 않는 영역 또는 지역에서 스탬프를 복구하는 방법을 다루어야 합니다.

  • 장애 조치(failover) 환경에서 앱을 다시 배포해야 하는 경우 도구를 사용하여 배포 프로세스를 최대한 자동화합니다. 앱 배포를 즉시 시작할 수 있도록 DevOps 파이프라인이 장애 조치(failover) 환경에서 미리 배포되고 구성되었는지 확인합니다. 필요한 경우 수동 승인 게이트와 함께 자동화된 엔드 투 엔드 배포를 사용하여 일관되고 효율적인 배포 프로세스를 보장합니다. 전체 배포 기간은 복구 대상에 맞춰야 합니다.

    • 배포 프로세스의 단계에 수동 개입이 필요한 경우 수동 단계를 문서화합니다. 역할과 책임을 명확하게 정의합니다.

  • 가능한 한 많은 절차를 자동화합니다. 스크립트에서 선언적 프로그래밍은 멱등성을 허용하므로 사용합니다. 선언적 프로그래밍을 사용할 수 없는 경우 사용자 지정 코드를 개발하고 실행하는 것을 염두에 두어야 합니다. 다시 시도 논리 및 회로 차단기 논리를 사용하여 중단된 작업에 중단된 스크립트에서 시간을 낭비하지 않도록 합니다. 이러한 스크립트는 응급 상황에서만 실행하므로 잘못 개발된 스크립트가 더 많은 손상을 입히거나 복구 프로세스를 늦추는 것을 원하지 않습니다.

    참고

    자동화는 위험을 초래합니다. 학습된 운영자는 자동화된 프로세스를 주의 깊게 모니터링하고 프로세스가 문제가 발생하는 경우 개입해야 합니다. 자동화가 가양성 에 반응할 위험을 최소화하려면 DR 드릴을 철저히 수행합니다. 계획의 모든 단계를 테스트합니다. 검색을 시뮬레이션하여 경고를 생성한 다음 전체 복구 절차를 진행합니다.

    DR 드릴은 복구 대상 메트릭에 대한 업데이트의 유효성을 검사하거나 알려야 합니다. 자동화가 가양성 에 취약하다는 것을 알게 되면 장애 조치(failover) 임계값을 늘려야 할 수 있습니다.

  • DR 절차와의 잠재적인 혼동을 방지하기 위해 DR 계획과 장애 복구 계획을 분리합니다. 장애 복구 계획은 DR 계획의 모든 개발 및 유지 관리 권장 사항을 따라야 하며 동일한 방식으로 구성되어야 합니다. 장애 조치(failover)에 필요한 모든 수동 단계는 장애 복구 계획에서 미러링되어야 합니다. 장애 복구(failback)는 장애 조치(failover) 후 빠르게 발생하거나 며칠 또는 몇 주가 걸릴 수 있습니다. 장애 복구(failback)를 장애 조치(failover)와 별도로 고려합니다.

    • 장애 복구(failback)의 필요성은 상황입니다. 성능상의 이유로 지역 간에 트래픽을 라우팅하는 경우 장애 조치(failover) 지역에서 원래 부하를 장애 복구하는 것이 중요합니다. 다른 경우에는 워크로드가 어떤 프로덕션 환경에 있는지 언제든지 완벽하게 작동하도록 설계했을 수 있습니다.

재해 복구 훈련 수행

DR 테스트 사례는 잘 개발된 DR 계획만큼 중요합니다. 많은 산업에는 지정된 수의 DR 훈련을 정기적으로 수행해야 하는 규정 준수 프레임워크가 있습니다. 업계에 관계없이 정기적인 DR 훈련이 성공에 가장 중요합니다.

성공적인 DR 훈련을 위해 다음 권장 사항을 따릅니다.

  • 연간 하나 이상의 프로덕션 DR 드릴을 수행합니다. 테이블톱(드라이 런) 훈련 또는 비프로덕션 훈련은 관련 당사자가 자신의 역할과 책임을 잘 알고 있는지 확인하는 데 도움이 됩니다. 이러한 훈련은 또한 운영자가 복구 프로세스를 수행하여 친숙함("근육 메모리")을 구축하는 데 도움이 됩니다. 그러나 프로덕션 드릴만 DR 계획 및 RTO 및 RPO 메트릭의 유효성을 실제로 테스트합니다. 프로덕션 드릴을 사용하여 구성 요소 및 흐름에 대한 시간 복구 프로세스를 사용하여 워크로드에 대해 정의된 RTO 및 RPO 목표를 달성할 수 있도록 합니다. DNS 전파와 같이 제어할 수 없는 함수의 경우 해당 함수를 포함하는 흐름에 대한 RTO 및 RPO 대상이 제어할 수 없는 지연을 고려해야 합니다.

  • 탁상 드릴을 사용하여 숙성된 운영자에 대한 친숙함을 구축할 뿐만 아니라 DR 프로세스 및 절차에 대한 새로운 운영자를 교육합니다. 선임 운영자는 새 운영자가 자신의 역할을 수행할 수 있도록 하는 데 시간이 걸리며 개선 기회를 위해 watch 합니다. 새 연산자가 프로시저의 단계를 주저하거나 혼동하는 경우 해당 절차를 검토하여 명확하게 작성되었는지 확인합니다.

고려 사항

  • 프로덕션에서 DR 훈련을 수행하면 예기치 않은 치명적인 오류가 발생할 수 있습니다. 초기 배포 중에 비프로덕션 환경에서 복구 절차를 테스트해야 합니다.

  • 훈련 중에 팀에 가능한 한 많은 유지 관리 시간을 제공합니다. 유지 관리 시간을 계획할 때 테스트 중에 캡처한 복구 메트릭을 필요한 최소 시간으로 사용합니다.

  • DR 드릴 사례가 완성되면 병렬로 실행할 수 있는 절차와 순서대로 실행해야 하는 절차를 알아봅니다. 드릴 연습 초기에는 모든 프로시저를 순서대로 실행해야 하며 예기치 않은 문제를 처리하기 위해 각 단계에서 추가 시간이 필요하다고 가정합니다.

Azure 촉진

많은 Azure 제품에는 기본 제공 장애 조치(failover) 기능이 있습니다. 이러한 기능을 숙지하고 복구 절차에 포함합니다.

IaaS(서비스로서의 인프라) 시스템의 경우 Azure Site Recovery 사용하여 장애 조치(failover) 및 복구를 자동화합니다. 일반적인 PaaS 제품은 다음 문서를 참조하세요.

예제

DR에 대한 엔터프라이즈 데이터 자산 준비에 대한 지침은 Azure 데이터 플랫폼용 DR 시리즈를 참조하세요.

안정성 검사 목록

전체 권장 사항 집합을 참조하세요.

안정성 검사 목록