고객 활동 필요
사전 인시던트
Azure 서비스의 경우
- Azure Portal의 Azure Service Health에 대해 잘 알고 있어야 합니다. 이 페이지는 인시던트 중에 "원스톱 상점"으로 작동합니다.
- Azure 인시던트가 발생할 때 자동으로 알림을 생성하도록 구성할 수 있는 Service Health 경고를 사용하는 것이 좋습니다.
Power BI의 경우
- Microsoft 365 관리 센터의 Service Health에 대해 잘 알고 있어야 합니다. 이 페이지는 인시던트 중에 "원스톱 상점"으로 작동합니다.
- Microsoft 365 관리 모바일 앱을 사용하여 자동 서비스 인시던트 경고 알림을 받는 것이 좋습니다.
인시던트 중
Azure 서비스의 경우
- Azure 관리 포털 내의 Azure Service Health 는 최신 업데이트를 제공합니다.
- Service Health에 액세스하는 데 문제가 있는 경우 Azure 상태 페이지를 참조 하세요.
- 상태 페이지에 액세스하는 데 문제가 있는 경우 X(이전의 Twitter)로 이동합니다 @AzureSupport .
- 영향/문제가 인시던트와 일치하지 않거나 완화 후에 유지되는 경우 지원에 문의하여 서비스 지원 티켓을 제기합니다.
Power BI의 경우
- Microsoft 365 관리 센터 내의 Service Health 페이지에서 최신 업데이트를 제공합니다.
- Service Health에 액세스하는 데 문제가 있는 경우 Microsoft 365 상태 페이지를 참조하세요.
- 영향/문제가 인시던트와 일치하지 않거나 완화 후 문제가 지속되는 경우 서비스 지원 티켓을 발생시켜야 합니다.
Microsoft 복구 후
이 세부 정보는 아래 섹션을 참조하세요.
인시던트 후
Azure Services의 경우
- Microsoft는 검토를 위해 Azure Portal - Service Health에 PIR을 게시합니다.
Power BI의 경우
- Microsoft는 검토를 위해 Microsoft 365 관리 - Service Health에 PIR을 게시합니다.
Microsoft 프로세스 대기
"Microsoft 대기" 프로세스는 Microsoft가 영향을 받는 주 지역의 모든 구성 요소 및 서비스를 복구하기만을 기다리고 있습니다. 복구되면 데이터 플랫폼의 바인딩을 엔터프라이즈 공유 또는 기타 서비스, 데이터 세트 날짜에 대한 유효성을 검사한 다음 시스템을 현재 날짜까지 가져오는 프로세스를 실행합니다.
이 프로세스가 완료되면 기술 및 비즈니스 실무 전문가(SME) 유효성 검사를 완료하여 관련자가 서비스 복구에 대한 승인을 받을 수 있습니다.
재해 시 재배포
"재해에 대한 재배포" 전략의 경우 다음과 같은 고급 프로세스 흐름을 설명할 수 있습니다.
Contoso의 엔터프라이즈 공유 서비스 및 원본 시스템 복구
- 이 단계는 데이터 플랫폼의 복구를 위한 필수 구성 요소입니다.
- 이 단계는 엔터프라이즈 공유 서비스 및 운영 원본 시스템을 담당하는 다양한 Contoso 운영 지원 그룹에서 완료됩니다.
Azure 서비스 복구 Azure Services는 Azure 클라우드 제품을 만드는 애플리케이션 및 서비스를 참조하며, 배포를 위해 보조 지역 내에서 사용할 수 있습니다.
Azure 서비스는 Azure 클라우드를 제공하는 애플리케이션 및 서비스를 참조하며, 배포를 위해 보조 지역 내에서 사용할 수 있습니다.
- 이 단계는 데이터 플랫폼 복구의 필수 구성 요소입니다.
- 이 단계는 Microsoft 및 기타 PaaS(Platform as a Service)/SaaS(Software as a Service) 파트너가 완료합니다.
데이터 플랫폼 기반 복구
- 이 단계는 플랫폼 복구 작업의 진입점입니다.
- 재배포 전략의 경우 필요한 각 구성 요소/서비스가 조달되어 보조 지역에 배포됩니다.
- 또한 이 프로세스에는 엔터프라이즈 공유 서비스에 대한 바인딩, 액세스/인증에 대한 연결 보장 및 로그 오프로드가 작동하는지 확인하는 동시에 업스트림 및 다운스트림 프로세스에 대한 연결을 보장하는 등의 작업도 포함되어야 합니다.
- 데이터/처리를 확인해야 합니다. 예를 들어 복구된 플랫폼의 타임스탬프 유효성 검사입니다.
- 데이터 무결성에 대한 질문이 있는 경우 플랫폼을 최신 상태로 만들기 위해 새 처리를 실행하기 전에 시간을 더 롤백하기로 결정할 수 있습니다.
- 프로세스에 대한 우선 순위 순서(비즈니스 영향 기반)를 사용하면 복구를 오케스트레이션하는 데 도움이 됩니다.
- 이 단계는 비즈니스 사용자가 서비스와 직접 상호 작용하지 않는 한 기술 유효성 검사에 의해 종료되어야 합니다. 직접 액세스가 있는 경우 비즈니스 유효성 검사 단계가 필요합니다.
- 유효성 검사가 완료되면 개별 솔루션 팀에 전달하여 자체 DR(재해 복구) 복구 프로세스를 시작합니다.
- 이 인계에는 데이터 및 프로세스의 현재 타임스탬프에 대한 확인이 포함되어야 합니다.
- 핵심 엔터프라이즈 데이터 프로세스가 실행될 경우 개별 솔루션은 인바운드/아웃바운드 흐름과 같이 이를 인식해야 합니다.
플랫폼에서 호스트하는 개별 솔루션 복구
- 각 개별 솔루션에는 자체 DR Runbook이 있어야 합니다. Runbook에는 적어도 서비스 복구가 완료되었는지 테스트하고 확인할 지명된 비즈니스 관련자가 포함되어야 합니다.
- 리소스 경합 또는 우선 순위에 따라 주요 솔루션/워크로드가 임시 랩보다 핵심 엔터프라이즈 프로세스인 다른 솔루션/워크로드보다 우선 순위가 지정될 수 있습니다.
- 유효성 검사 단계가 완료되면 DR 복구 프로세스를 시작하기 위해 다운스트림 솔루션으로의 인계가 수행됩니다.
다운스트림 독립 시스템으로 전달
- 종속 서비스가 복구되면 E2E DR 복구 프로세스가 완료됩니다.
참고 항목
이론적으로는 E2E DR 프로세스를 완전히 자동화할 수 있지만, E2E 프로세스를 처리하는 데 필요한 SDLC 활동 비용과 이벤트의 위험을 고려할 가능성은 거의 없습니다.
주 지역으로 대체 대체는 데이터 플랫폼 서비스 및 해당 데이터를 BAU에 사용할 수 있게 되면 주 지역으로 다시 이동하는 프로세스입니다.
원본 시스템 및 다양한 데이터 프로세스의 특성에 따라 데이터 플랫폼의 대체는 데이터 에코 시스템의 다른 부분과 독립적으로 수행할 수 있습니다.
고객은 적절한 결정을 내리기 위해 자체 데이터 플랫폼의 종속성(업스트림 및 다운스트림 모두)을 검토하는 것이 좋습니다. 다음 섹션에서는 데이터 플랫폼의 독립적인 복구를 가정합니다.
- 기본 지역에서 모든 필수 구성 요소/서비스를 사용할 수 있게 되면 고객은 Microsoft 복구의 유효성을 검사하기 위한 스모크 테스트를 완료합니다.
- 구성 요소/서비스 구성의 유효성이 검사됩니다. 델타는 소스 제어에서 재배포를 통해 해결됩니다.
- 주 지역의 시스템 날짜는 상태 저장 구성 요소 간에 설정됩니다. 설정된 날짜와 보조 지역의 날짜/타임스탬프 사이의 델타는 해당 시점부터 데이터 수집 프로세스를 다시 검사하거나 재생하여 해결해야 합니다.
- 비즈니스 및 기술 관련자 모두의 승인을 받아 대체 창이 선택됩니다. 이상적으로는 시스템 작업 및 처리에서 소강 상태일 때 발생합니다.
- 대체 중에는 시스템이 전환되기 전에 주 지역이 보조 지역과 동기화됩니다.
- 병렬 실행 기간이 지나면 보조 지역이 시스템에서 오프라인으로 전환됩니다.
- 선택한 DR 전략에 따라 보조 지역의 구성 요소가 삭제되거나 제거됩니다.
웜 스페어 프로세스
"웜 스페어" 전략의 경우 상위 수준 프로세스 흐름은 "재해에 대한 재배포"의 흐름과 밀접하게 일치합니다. 주요 차이점은 해당 구성 요소가 보조 지역에서 이미 조달되었다는 점입니다. 이러한 전략은 해당 지역에서 자체 DR을 완료하려는 다른 조직에서의 리소스 경합의 위험을 제거합니다.
핫 스페어 프로세스
"핫 스페어" 전략은 보조 시스템이 기본 시스템과 함께 실행됨에 따라 재해 이벤트에도 불구하고 PaaS 및 IaaS(Infrastructure as a Service) 시스템을 포함한 플랫폼 서비스가 유지됨을 의미합니다. "웜 스페어" 전략과 마찬가지로 이 전략은 해당 지역에서 자체 DR을 완료하려는 다른 조직에서 리소스 경합의 위험을 제거합니다.
핫 스페어 고객은 주 지역의 구성 요소/서비스의 Microsoft 복구를 모니터링합니다. 완료되면 고객은 주 지역 시스템의 유효성을 검사하고 주 지역으로 대체를 완료합니다. 이 프로세스는 DR 장애 조치(failover) 프로세스와 유사하게 됩니다. 즉, 사용 가능한 코드베이스 및 데이터를 확인하고 필요에 따라 다시 배포합니다.
참고
여기에서는 시스템 메타데이터가 두 지역 간에 일관성을 유지할 수 있도록 특별히 유의해야 합니다.
- 주 지역으로 대체가 완료되면 시스템 부하 분산 장치를 업데이트하여 주 지역을 시스템 토폴로지로 다시 가져올 수 있습니다. 사용 가능한 경우 카나리아 릴리스 접근 방식을 통해 시스템의 주 지역을 증분 방식으로 전환할 수 있습니다.
DR 계획 구조
효과적인 DR 계획은 Azure 기술 리소스에서 실행할 수 있는 서비스 복구를 위한 단계별 가이드를 제공합니다. 따라서 다음은 DR 계획에 대해 제안된 MVP 구조를 나열합니다.
- 프로세스 요구 사항
- DR을 시작하고 필요에 따라 복구에 대한 주요 결정을 내리는 데 필요한 올바른 권한 부여와 같은 고객 DR 프로세스별 세부 정보(예: "완료 정의"포함), 서비스 지원 DR 티켓 참조 및 전쟁실 세부 정보.
- DR 리드 및 실행기 백업 등의 리소스 확인 모든 리소스는 주 연락처 및 보조 연락처, 에스컬레이션 경로 및 휴가 일정으로 문서화되어야 합니다. 중요한 DR 상황에서는 명단 시스템을 고려해야 할 수 있습니다.
- DR 실행기, DR 백업 및 에스컬레이션 지점에 대한 랩톱, 전원 팩 또는 백업 전원, 네트워크 연결 및 휴대폰 세부 정보입니다.
- 프로세스 요구 사항이 충족되지 않는 경우 따라야 할 프로세스입니다.
- 연락처 목록
- DR 리더십 및 지원 그룹.
- 기술 복구를 위해 테스트/검토 주기를 완료할 비즈니스 중소기업.
- 서비스 복구 승인자를 포함하여 영향을 받는 비즈니스 소유자
- 영향을 받는 기술 소유자(기술 복구 승인자 포함)
- 플랫폼에서 호스팅하는 주요 솔루션을 포함하여 영향을 받는 모든 영역에서 중소기업을 지원합니다.
- 영향을 받는 다운스트림 시스템 – 운영 지원.
- 업스트림 원본 시스템 – 운영 지원.
- 엔터프라이즈 공유 서비스 연락처 예를 들어 액세스 및 인증 지원, 보안 모니터링 및 게이트웨이 지원
- 클라우드 공급자에 대한 지원 연락처를 포함하여 외부 또는 타사 공급업체.
- 아키텍처 디자인
- E2E(엔드 엔드) 시나리오 세부 정보를 설명하고 관련된 모든 지원 설명서를 첨부합니다.
- 종속성
- 모든 구성 요소의 관계 및 종속성을 나열합니다.
- DR 필수 구성 요소
- 필요에 따라 업스트림 원본 시스템을 사용할 수 있는지 확인합니다.
- 스택 전체에서 상승된 액세스 권한이 DR 실행기 리소스에 부여되었습니다.
- Azure 서비스는 필요에 따라 사용할 수 있습니다.
- 필수 구성 요소가 충족되지 않은 경우 따라야 할 프로세스입니다.
- 기술 복구 - 단계별 지침
- 순서를 실행합니다.
- 단계 설명입니다.
- 단계 필수 구성 요소입니다.
- URL을 포함하여 각 불연속 작업에 대한 자세한 프로세스 단계입니다.
- 필요한 증거를 포함한 유효성 검사 지침입니다.
- 사태를 포함하여 각 단계를 완료하는 데 필요한 시간입니다.
- 단계가 실패할 경우 수행할 프로세스입니다.
- 오류 또는 SME 지원의 경우 에스컬레이션 지점입니다.
- 기술 복구 - 필수 구성 요소 게시
- 주요 구성 요소에서 시스템의 현재 날짜 타임스탬프를 확인합니다.
- DR 시스템 URL 및 IP를 확인합니다.
- 시스템 액세스 확인 및 유효성 검사 및 승인을 완료하는 비즈니스 중소기업을 포함하여 비즈니스 관련자 검토 프로세스를 준비합니다.
- 비즈니스 관련자 검토 및 승인
- 비즈니스 리소스 연락처 세부 정보입니다.
- 위의 기술 복구에 따른 비즈니스 유효성 검사 단계입니다.
- 비즈니스 승인자가 복구에 서명하는 데 필요한 증거 내역입니다.
- 복구 후 필수 구성 요소
- 운영 지원으로 인계하여 데이터를 실행하여 시스템을 최신 상태로 유지합니다.
- DR 시스템의 날짜 및 연결 세부 정보를 확인하는 다운스트림 프로세스 및 솔루션을 인계합니다.
- DR 리드로 복구 프로세스가 완료되었는지 확인합니다. 증명 정보 추적 및 완료된 Runbook을 확인합니다.
- DR 팀에서 상승된 액세스 권한을 제거할 수 있음을 보안 팀에 알립니다.
설명선
- 각 단계 프로세스의 시스템 스크린샷을 포함하는 것이 좋습니다. 이러한 스크린샷은 시스템 중소기업에 대한 종속성을 해결하여 작업을 완료하는 데 도움이 됩니다.
- 빠르게 진화하는 클라우드 서비스를 따라가기 위해 DR 계획은 Azure 및 해당 서비스에 대한 현재 지식을 갖춘 리소스에서 정기적으로 다시 검토, 테스트 및 실행해야 합니다.
- 기술 복구 단계에서는 조직에 구성 요소 및 솔루션의 우선순위를 반영해야 합니다. 예를 들어 핵심 엔터프라이즈 데이터 흐름은 임시 데이터 분석 랩 전에 복구됩니다.
- Key Vault와 같은 기본 구성 요소 또는 서비스가 복구되면 기술 복구 단계는 워크플로의 순서(일반적으로 왼쪽에서 오른쪽으로)를 따라야 합니다. 이 전략을 통해 업스트림 종속성을 사용할 수 있고 구성 요소를 적절하게 테스트할 수 있습니다.
- 단계별 계획이 완료되면 대체 작업의 총 시간을 확보해야 합니다. 이 합계가 합의된 RTO(복구 시간 목표)를 초과하면 다음과 같은 몇 가지 옵션을 사용할 수 있습니다.
- 선택한 복구 프로세스를 자동화합니다(가능한 경우).
- 선택한 복구 단계를 병렬로 실행할 기회를 찾습니다(가능한 경우). 그러나 이러한 전략에는 추가 DR 실행기 리소스가 필요할 수 있습니다.
- 주요 구성 요소를 PaaS와 같은 더 높은 수준의 서비스 계층으로 업그레이드합니다. 여기서 Microsoft는 서비스 복구 활동에 대해 더 큰 책임을 집니다.
- 관련자와 RTO를 확장합니다.
DR 테스트
Azure 클라우드 서비스 제공 사항의 특성으로 인해 모든 DR 테스트 시나리오에 대한 제약 조건이 발생합니다. 따라서 해당 지침은 보조 지역에서 사용할 수 있는 것처럼 데이터 플랫폼 구성 요소를 사용하여 DR 구독을 설정하는 것입니다.
이 기준부터 DR 계획 Runbook을 선택적으로 실행하여 배포 및 유효성 검사를 수행할 수 있는 서비스 및 구성 요소에 특히 주의할 수 있습니다. 이 프로세스에는 계획에 따라 기술 및 비즈니스 유효성 검사 확인을 사용하도록 설정하는 큐레이팅된 테스트 데이터 세트가 필요합니다.
DR 계획은 최신 상태인지 확인할 뿐만 아니라 장애 조치(failover) 및 복구 활동을 수행하는 팀을 위한 "머슬 메모리"를 구축하기 위해 정기적으로 테스트해야 합니다.
- 또한 데이터 및 구성 백업을 정기적으로 테스트하여 복구 활동을 지원하기 위해 "목적에 맞는"지 확인해야 합니다.
DR 테스트 중에 집중해야 할 주요 영역은 규범적 단계가 여전히 정확하고 예상 타이밍이 여전히 관련성이 있는지 확인하는 것입니다.
- 지침에 코드가 아닌 포털 화면이 반영되면 클라우드의 변경 주기로 인해 적어도 12개월마다 지침의 유효성을 검사해야 합니다.
이는 완전히 자동화된 DR 프로세스를 갖기 위한 포부이지만 이벤트의 희귀성으로 인해 전체 자동화가 불가능할 수 있습니다. 따라서 플랫폼을 제공하는 데 사용되는 코드(IaC)로 DSC(Desired State Configuration) 인프라를 사용하여 복구 기준을 설정한 다음, 새 프로젝트가 기준에 따라 빌드될 때 향상하는 것이 좋습니다.
- 구성 요소 및 서비스가 확장되면 시간이 지남에 따라 NFR을 적용해야 하며, DR에 대한 적용 범위를 제공하기 위해 프로덕션 배포 파이프라인을 리팩터링해야 합니다.
Runbook 타이밍이 RTO를 초과하는 경우 다음과 같은 몇 가지 옵션이 있습니다.
- 관련자와 RTO를 확장합니다.
- 자동화, 병렬로 작업 실행 또는 더 높은 클라우드 서버 계층으로 마이그레이션을 통해 복구 작업에 필요한 시간을 낮춥니다.
Azure Chaos Studio
Azure Chaos Studio 는 Azure 애플리케이션에 오류를 주입하여 복원력을 향상시키기 위한 관리형 서비스입니다. Chaos Studio를 사용하면 실험을 통해 안전하고 제어된 방식으로 Azure 리소스에 대한 오류 주입을 오케스트레이션할 수 있습니다. 현재 지원되는 오류 유형에 대한 설명은 제품 설명서를 참조하세요.
Chaos Studio의 현재 반복은 Azure 구성 요소 및 서비스의 하위 집합 만 포함합니다. 더 많은 오류 라이브러리가 추가될 때까지 Chaos Studio는 전체 시스템 DR 테스트가 아닌 격리된 복원력 테스트에 권장되는 방법입니다.
Chaos Studio에 대한 자세한 내용은 Azure Chaos Studio 설명서에서 찾을 수 있습니다.
Azure Site Recovery
IaaS 구성 요소의 경우 Azure Site Recovery는 지원되는 VM 또는 물리적 서버에서 실행되는 대부분의 워크로드를 보호합니다.
다음과 같은 강력한 지침이 있습니다.
관련 참고 자료
- 복원력 및 가용성 설계
- 비즈니스 연속성 및 재해 복구
- Azure 애플리케이션의 백업 및 재해 복구
- Azure의 복원력
- SLA(서비스 수준 계약) 요약
- 실패를 예측하는 5가지 모범 사례
다음 단계
이제 시나리오를 배포하는 방법을 알아보았으므로 Azure 데이터 플랫폼 시리즈용 DR의 요약을 읽을 수 있습니다.