Azure 데이터 플랫폼용 DR - 권장 사항

학습 내용

1. 관련된 모든 당사자가 HA(고가용성)와 DR(재해 복구)의 차이를 이해하도록 합니다. 일반적인 문제는 두 개념을 혼동하고 관련 솔루션과 일치하지 않는 것입니다.
2. RPO(복구 지점 목표) 및 RTO(복구 시간 목표)를 정의하기 위한 다음 측면과 관련하여 비즈니스 이해 관계자와 논의합니다.
   1. 일반적으로 복구 속도가 빨라질수록 비용이 높아집니다.
   2. 이러한 이벤트의 관련 가능성을 언급하면서 보호하려는 인시던트 유형 예를 들어 서버가 다운되는 확률은 지역 전체의 모든 데이터 센터에 영향을 주는 자연 재해보다 높습니다.
   3. 사용할 수 없는 시스템은 비즈니스에 어떤 영향을 미치나요?
   4. 앞으로 진행되는 솔루션에 대한 OPEX(운영 비용) 예산입니다.
3. 최종 사용자가 허용할 수 있는 성능 저하된 서비스 옵션을 고려합니다. 여기에는 다음이 포함될 수 있습니다.
   1. 가장 최신 데이터가 없는 경우에도 여전히 시각화 대시보드에 액세스할 수 있습니다. 즉, 수집 파이프라인이 작동하지 않는 경우 최종 사용자는 여전히 해당 데이터에 액세스할 수 있습니다.
   2. 읽기 액세스 권한이 있지만 쓰기 권한이 없습니다.
4. 대상 RTO 및 RPO 메트릭은 구현하도록 선택한 재해 복구 전략을 정의할 수 있습니다.
   1. 활성/활성.
   2. 활성/수동.
   3. 재해에 대한 활성/재배포
   4. 고유한 복합 SLO(서비스 수준 목표)를 고려하여 허용되는 가동 중지 시간을 고려합니다.
5. 다음과 같이 시스템의 가용성에 영향을 줄 수 있는 모든 구성 요소를 이해해야 합니다.
   1. ID 관리.
   2. 네트워킹 토폴로지.
   3. 비밀/키 관리.
   4. 데이터 원본.
   5. Automation/작업 스케줄러.
   6. 원본 리포지토리 및 배포 파이프라인(GitHub, Azure DevOps).
6. 조기 중단 감지는 RTO 및 RPO 값을 크게 줄이는 방법이기도 합니다. 다음은 다루어야 할 몇 가지 측면입니다.
   1. 중단이란 무엇이며 중단에 대한 Microsoft의 정의에 매핑되는 방법을 정의합니다. Microsoft 정의는 제품 또는 서비스 수준의 Azure SLA(서비스 수준 계약) 페이지에서 사용할 수 있습니다.
   2. 책임 있는 팀이 해당 메트릭 및 경고를 적시에 검토하는 효율적인 모니터링 및 경고 시스템은 목표를 달성하는 데 도움이 됩니다.
7. 구독 디자인과 관련하여 재해 복구를 위한 추가 인프라를 원래 구독에 저장할 수 있습니다. Azure Data Lake Storage Gen2 또는 Azure Data Factory와 같은 PaaS(platform as a Service) 서비스에는 일반적으로 원래 구독에 포함된 상태를 유지하면서 다른 지역의 보조 인스턴스로 장애 조치(failover)를 허용하는 네이티브 기능이 있습니다. 일부 고객은 비용 목적으로 DR 시나리오에서만 사용되는 리소스에 대한 전용 리소스 그룹을 사용하는 것을 고려할 수 있습니다.
   1. 구독 제한은 이 접근 방식의 제약 조건으로 작용할 수 있습니다.
   2. 다른 제약 조건에는 DR 리소스 그룹이 평상시(BAU) 워크플로에 사용되지 않도록 디자인 복잡성 및 관리 제어가 포함될 수 있습니다.
8. 솔루션의 중요도 및 종속성을 기반으로 DR 워크플로를 디자인합니다. 예를 들어 데이터 웨어하우스가 가동되고 실행되기 전에 Azure Analysis Services 인스턴스를 다시 빌드하지 마세요. 오류가 트리거되기 때문에 프로세스의 뒷부분에서 개발 랩을 떠나 핵심 엔터프라이즈 솔루션을 먼저 복구합니다.
9. 솔루션 간에 병렬 처리할 수 있는 복구 작업을 식별하여 총 RTO를 줄입니다.
10. 솔루션 내에서 Azure Data Factory가 사용되는 경우 범위에 자체 호스팅 통합 런타임을 포함해야 합니다. Azure Site Recovery 는 이러한 머신에 이상적입니다.
11. 수동 작업은 특히 압박을 받을 때 사람의 오류를 방지하기 위해 최대한 자동화해야 합니다. 다음을 수행하는 것이 좋습니다.
    1. Bicep, ARM 템플릿 또는 PowerShell 스크립트를 통해 리소스 프로비저닝을 채택합니다.
    2. 소스 코드 및 리소스 구성의 버전 관리 채택
    3. 클릭 작업 대신 CI/CD 릴리스 파이프라인을 사용합니다.
12. 장애 조치(failover) 계획이 있으므로 주 인스턴스로 대체하기 위한 절차를 고려해야 합니다.
13. 명확한 지표 및 메트릭을 정의하여 장애 조치(failover)가 성공했으며 솔루션이 실행 중인지 또는 상황이 정상으로 돌아왔는지(기본 기능이라고도 함) 유효성을 검사합니다.
14. 장애 조치(failover) 후 또는 성능 저하된 서비스를 허용하는지 여부를 SLA(서비스 수준 계약)가 동일하게 유지할지 결정합니다.
    1. 이 결정은 지원되는 비즈니스 서비스 프로세스에 따라 크게 달라집니다. 예를 들어 회의실 예약 시스템의 장애 조치(failover)는 핵심 운영 시스템과 크게 다릅니다.
15. RTO/RPO 정의는 인프라 수준이 아닌 특정 사용자 시나리오를 기반으로 해야 합니다. 이렇게 하면 중단 또는 재해가 발생한 경우 먼저 복구해야 하는 프로세스 및 구성 요소에 대한 세분성이 제공됩니다.
16. 장애 조치(failover)를 진행하기 전에 대상 지역에 용량 검사를 포함해야 합니다. 큰 재해가 발생하는 경우 많은 고객이 동시에 동일한 쌍을 이루는 지역으로 장애 조치(failover)를 시도하므로 리소스 프로비전이 지연되거나 경합이 발생할 수 있습니다.
    1. 이러한 위험을 허용할 수 없는 경우 활성/활성 또는 활성/수동 DR 전략을 고려해야 합니다.
17. 복구 프로세스 및 작업 소유자를 문서화하기 위해 재해 복구 계획을 만들고 유지 관리해야 합니다. 또한 사용자가 휴가 중일 수 있으므로 보조 연락처를 포함해야 합니다.
18. 정기적인 재해 복구 훈련을 수행하여 DR 계획 워크플로의 유효성을 검사하고, 필요한 RTO/RPO를 충족하고, 책임 있는 팀을 교육해야 합니다.
    1. 또한 데이터 및 구성 백업을 정기적으로 테스트하여 복구 활동을 지원하기 위해 "목적에 맞는"지 확인해야 합니다.
19. 네트워킹, ID 및 리소스 프로비저닝을 담당하는 팀과의 초기 협업을 통해 가장 최적의 솔루션에 대한 계약을 체결할 수 있습니다.
    1. 사용자 및 트래픽을 기본 사이트에서 보조 사이트로 리디렉션하는 방법입니다. DNS 리디렉션 또는 Azure Traffic Manager와 같은 특정 도구의 사용과 같은 개념을 평가할 수 있습니다.
    2. 시기적절하고 안전한 방식으로 보조 사이트에 대한 액세스 및 권한을 제공하는 방법입니다.
20. 재해가 발생하면 관련된 많은 당사자 간의 효과적인 통신이 계획의 효율적이고 신속한 실행의 핵심입니다. Teams에는 다음이 포함될 수 있습니다.
    1. 의사 결정자.
    2. 인시던트 대응 팀.
    3. 영향을 받는 내부 사용자 및 팀.
    4. 외부 팀.
21. 적절한 시기에 다양한 리소스를 오케스트레이션하면 재해 복구 계획 실행의 효율성이 보장됩니다.

고려 사항

안티패턴

• 이 문서 시리즈 복사/붙여넣기 이 문서 시리즈는 Azure 특정 DR 프로세스에 대한 다음 수준의 세부 정보를 찾는 고객에게 지침을 제공하기 위한 것입니다. 따라서 단일 고객별 Azure 구현이 아닌 일반 Microsoft IP 및 참조 아키텍처를 기반으로 합니다.

제공된 세부 정보는 견고한 기본 이해를 지원하는 데 도움이 되지만, 고객은 "목적에 맞는" DR 전략 및 프로세스를 얻기 전에 고유한 특정 컨텍스트, 구현 및 요구 사항을 적용해야 합니다.

• DR을 기술 전용 프로세스로 처리 비즈니스 관련자는 DR에 대한 요구 사항을 정의하고 서비스 복구를 확인하는 데 필요한 비즈니스 유효성 검사 단계를 완료하는 데 중요한 역할을 합니다. 비즈니스 관련자가 모든 DR 활동에 참여하도록 보장하면 "목적에 적합"하고 비즈니스 가치를 나타내며 실행 가능한 DR 프로세스를 제공합니다.

• 개별 고객의 다양한 구성 요소 및 서비스 사용과 마찬가지로 DR 플랜 "설정 및 잊기"는 Azure가 지속적으로 진화하고 있습니다. "목적에 맞는" DR 프로세스는 그들과 함께 진화해야 합니다. SDLC(소프트웨어 개발 수명 주기) 프로세스 또는 정기적인 검토를 통해 고객은 DR 계획을 정기적으로 다시 확인해야 합니다. 목표는 서비스 복구 플랜의 유효성을 확인하고 구성 요소, 서비스 또는 솔루션의 델타가 고려되었는지 확인하는 것입니다.

• 종이 기반 평가 DR 이벤트의 종단 간 시뮬레이션은 최신 데이터 에코 시스템에서 어려울 수 있지만 영향을 받는 구성 요소 전체에서 완전한 시뮬레이션에 최대한 근접하기 위해 노력해야 합니다. 정기적으로 예약된 훈련은 조직에서 DR 계획을 자신 있게 실행하는 데 필요한 "근육 메모리"를 빌드합니다.

• Microsoft에 의존하여 Microsoft Azure 서비스 내에서 모든 작업을 수행하는 데는 사용되는 클라우드 서비스 계층에 의해 고정된 명확한 책임 분할이 있습니다. 전체 SaaS(Software as a Service) 스택 이 사용되더라도 고객은 Azure 서비스와 상호 작용하는 데 사용되는 디바이스와 함께 계정, ID 및 데이터가 정확하고 최신 상태인지 확인하는 책임을 계속 유지합니다.

이벤트 범위 및 전략

재해 이벤트 범위

이벤트별로 영향 범위가 다르므로 응답이 다릅니다. 다음 다이어그램에서는 재해 이벤트에 대해 이를 보여 줍니다.

재해 전략 옵션

재해 복구 전략에는 다음과 같은 네 가지 상위 수준 옵션이 있습니다.

• Microsoft 대기 - 이름에서 알 수 있듯이 Microsoft가 영향을 받는 지역에서 서비스를 완전히 복구할 때까지 솔루션이 오프라인 상태입니다. 복구되면 고객이 솔루션의 유효성을 검사한 다음 서비스 복구를 위해 최신 상태로 유지됩니다.
• 재해 에 대한 다시 배포 - 솔루션은 재해 후 처음부터 사용 가능한 지역에 수동으로 다시 배포됩니다.
• 웜 스페어(활성/수동): 보조 호스티드 솔루션은 다른 지역에 만들어지고 구성 요소는 최소 용량을 보장하도록 배포되지만 프로덕션 트래픽을 받지는 않습니다. 대체 지역의 보조 서비스는 DR 이벤트가 발생할 때까지 더 낮은 성능 수준에서 "꺼져" 실행될 수 있습니다.
• 핫 스페어(활성/활성) - 솔루션은 여러 지역의 활성/활성 설정에서 호스트됩니다. 보조 호스팅 솔루션은 더 큰 시스템의 일부로 데이터를 수신, 처리 및 제공합니다.

DR 전략 영향

높은 수준의 서비스 복원력으로 인한 운영 비용이 DR 전략의 KDD(주요 디자인 결정)를 지배하는 경우가 많습니다. 다른 중요한 고려 사항이 있습니다.

이 작업 예제의 DR 시나리오는 Contoso Data Platform을 호스트하는 주 지역에 직접적인 영향을 주는 완전한 Azure 지역 중단입니다. 이 중단 시나리오에서 4가지 상위 수준 DR 전략에 대한 상대적 영향:

분류 키

• RTO(복구 시간 목표): 재해 이벤트에서 플랫폼 서비스 복구로 예상되는 경과 시간입니다.
• 실행 복잡성: 조직에서 복구 활동을 실행하는 복잡성입니다.
• 구현할 복잡성: 조직이 DR 전략을 구현하는 복잡성입니다.
• 고객에게 미치는 영향: DR 전략에서 데이터 플랫폼 서비스의 고객에게 직접적인 영향을 미칩니다.
• 위의 OPEX 비용: 추가 구성 요소 및 지원하는 데 필요한 추가 리소스에 대한 Azure에 대한 월별 청구 증가와 같은 이 전략을 구현할 때 예상되는 추가 비용입니다.

다음 단계

시나리오와 관련된 권장 사항에 대해 알아보았으므로 이제 이 시나리오를 배포하는 방법을 알아볼 수 있습니다.

관련 참고 자료

• Azure Data Platform용 DR - 개요
• Azure Data Platform용 DR - 아키텍처
• Azure 데이터 플랫폼용 DR - 시나리오 세부 정보
• Azure 데이터 플랫폼용 DR - 요약