Azure Data Explorer 비즈니스 연속성 및 재해 복구를 통해 중단이 발생하는 상황에서도 비즈니스를 계속 운영할 수 있습니다. 이 문서에서는 복구 가능성 요구 사항(RPO 및 RTO), 필요한 노력 및 비용에 따라 여러 재해 복구 구성을 자세히 설명합니다.
일부 유형의 사용자 오류에 대한 가용성 영역 지원, 백업 및 보호를 포함하여 Azure Data Explorer 사용할 수 있는 안정성 옵션에 대한 자세한 내용은
재해 복구 구성
RTO(복구 시간 목표)는 중단으로부터 복구하는 시간을 나타냅니다. 예를 들어 2시간의 RTO는 애플리케이션이 중단된 후 2시간 이내에 가동 및 실행되어야 함을 의미합니다. RPO(복구 지점 목표)는 중단 중에 해당 기간 동안 손실된 데이터 양이 허용 가능한 임계값을 초과하기 전에 경과할 수 있는 시간 간격을 나타냅니다. 예를 들어 RPO가 24시간이고 애플리케이션에 15년 전부터 시작된 데이터가 있는 경우 여전히 합의된 RPO의 매개 변수 내에 있습니다.
수집, 처리 및 큐레이션 프로세스는 재해 복구를 계획할 때 사전에 주의를 기울여 설계해야 합니다. 수집은 다양한 원본에서 Azure Data Explorer 통합된 데이터를 나타냅니다. 처리는 변환 및 유사한 활동을 의미합니다. 큐레이션은 구체화된 뷰, 데이터 레이크로 내보내기 등을 의미합니다.
다음은 널리 사용되는 재해 복구 구성입니다.
활성-활성-활성 구성
이 구성을 Always-On이라고도 합니다. 중단에 대한 허용 오차가 없는 중요한 애플리케이션 배포의 경우 Azure 쌍을 이루는 지역에서 여러 Azure Data Explorer 클러스터를 사용해야 합니다. 모든 클러스터에 대한 수집, 처리 및 큐레이션을 병렬로 설정합니다. 클러스터 SKU는 지역 간에 동일해야 합니다. Azure는 데이터 센터 리전 쌍을 통해 업데이트를 순차적으로 배포합니다. Azure 지역 중단으로 인해 애플리케이션이 중단되지 않습니다. 약간의 대기 시간 또는 성능 저하가 발생할 수 있습니다.
| Configuration | RPO | RTO | 노력 | 비용 |
|---|---|---|---|---|
| Active-Active-Active-n | 0시간 | 0시간 | 낮음 | 가장 높음 |
활성-활성 구성
이 구성은 active-active-active 구성 동일하지만 두 개의 Azure 쌍을 이루는 지역만 포함합니다. 이중 수집, 처리 및 큐레이션을 구성합니다. 사용자는 가장 가까운 지역으로 라우팅됩니다. 클러스터 SKU는 지역 간에 동일해야 합니다.
| Configuration | RPO | RTO | 노력 | 비용 |
|---|---|---|---|---|
| 활성-활성 | 0시간 | 0시간 | 낮음 | 높음 |
활성-상시 대기 구성
활성-핫 구성은 이중 수집, 처리 및 큐레이션의 활성-활성 구성과 비슷합니다. 대기 클러스터는 수집, 프로세스 및 큐레이션을 위해 온라인 상태이지만 쿼리할 수 없습니다. 대기 클러스터는 주 클러스터와 동일한 SKU에 있을 필요가 없습니다. SKU 및 규모가 작을 수 있으므로 성능이 저하될 수 있습니다. 재해 시나리오에서 사용자는 대기 클러스터로 리디렉션되며, 필요에 따라 확장하여 성능을 높일 수 있습니다.
| Configuration | RPO | RTO | 노력 | 비용 |
|---|---|---|---|---|
| 활성-상시 대기 | 0시간 | 낮음 | 중간 | 중간 |
주문형 데이터 복구 구성
이 솔루션은 가장 적은 복구 가능성(가장 높은 RPO 및 RTO)을 제공하며, 가장 낮은 비용 및 가장 높은 노력을 제공합니다. 이 구성에는 데이터 복구 클러스터가 없습니다. 큐레이팅된 데이터를 GRS(지역 중복 스토리지)가 구성된 스토리지 계정으로 지속적으로 내보내도록 구성합니다(원시 및 중간 데이터도 필요한 경우 제외). 재해 복구 시나리오가 있는 경우 데이터 복구 클러스터가 회전합니다. 이 시점에서 DDL, 구성, 정책 및 프로세스가 적용됩니다. 수집 속성 kustoCreationTime 을 사용하여 스토리지에서 데이터를 수집하여 기본값인 수집 시간을 시스템 시간으로 재정의합니다.
| Configuration | RPO | RTO | 노력 | 비용 |
|---|---|---|---|---|
| 주문형 데이터 복구 클러스터 | 가장 높음 | 가장 높음 | 가장 높음 | 가장 낮음 |
재해 복구 구성 옵션 요약
| Configuration | 복구 | RPO | RTO | 노력 | 비용 |
|---|---|---|---|---|---|
| Active-Active-Active-n | 가장 높음 | 0시간 | 0시간 | 낮음 | 가장 높음 |
| 활성-활성 | 높음 | 0시간 | 0시간 | 낮음 | 높음 |
| 활성-상시 대기 | 중간 | 0시간 | 낮음 | 중간 | 중간 |
| 주문형 데이터 복구 클러스터 | 가장 낮음 | 가장 높음 | 가장 높음 | 가장 높음 | 가장 낮음 |
모범 사례
선택한 재해 복구 구성에 관계없이 다음 모범 사례를 따릅니다.
- 모든 데이터베이스 개체, 정책 및 구성은 릴리스 자동화 도구에서 클러스터로 릴리스될 수 있도록 원본 제어에서 유지해야 합니다. 자세한 내용은 Azure Data Explorer 대한
Azure DevOps 지원을 참조하세요. - 데이터 관점에서 모든 클러스터가 동기화되도록 유효성 검사 루틴을 설계, 개발 및 구현합니다. Azure Data Explorer는 크로스 클러스터 조인을 지원합니다. 테이블 전체의 간단한 개수 또는 행이 유효성을 검사하는 데 도움이 될 수 있습니다.
- 릴리스 절차는 클러스터 미러링을 보장하는 거버넌스 확인 및 균형을 포함해야 합니다.
- 클러스터를 처음부터 빌드하기 위해 수행하는 작업을 완전히 이해해야 합니다.
- 배포 단위의 검사 목록을 만듭니다. 목록은 요구 사항에 고유하지만 배포 스크립트, 수집 연결, BI 도구 및 기타 중요한 구성을 포함해야 합니다.