재해 복구

Azure Databricks와 같은 클라우드 네이티브 데이터 분석 플랫폼에는 명확한 재해 복구 패턴이 있는 것이 중요합니다. 데이터 팀은 허리케인이나 지진과 같은 지역 재해 또는 기타 원본으로 인한 지역 서비스 차원의 클라우드 서비스 공급자 중단이 드문 경우에도 Azure Databricks 플랫폼을 사용할 수 있어야 합니다.

Azure Databricks는 업스트림 데이터 수집 서비스(일괄 처리/스트리밍), ADLS gen2(2023년 3월 6일 이전에 만든 작업 영역의 경우, Azure Blob Storage), 비즈니스 인텔리전스 앱과 같은 다운스트림 도구 및 서비스, 오케스트레이션 도구와 같은 클라우드 네이티브 스토리지를 비롯한 많은 서비스를 포함하는 전체 데이터 에코시스템의 핵심 부분입니다. 일부 사용 사례는 지역 서비스 전체 중단에 특히 중요할 수 있습니다.

이 문서에서는 Databricks 플랫폼에 대한 성공적인 상호 재해 복구 솔루션에 대한 개념 및 모범 사례를 설명합니다.

지역 내 고가용성 보장

이 항목의 나머지 부분에는 지역 간 재해 복구 구현에 중점을 두지만 Azure Databricks가 단일 지역 내에서 제공하는 고가용성 보장을 이해하는 것이 중요합니다. 지역 내 고가용성 보장은 다음 구성 요소를 다룹니다.

Azure Databricks 컨트롤 플레인의 가용성

• 대부분의 컨트롤 플레인 서비스는 Kubernetes 클러스터에서 실행되며 특정 AZ에서 손실된 VM을 자동으로 처리합니다.
• 작업 영역 데이터는 Premium Storage가 있는 데이터베이스에 저장되며 지역 전체에 복제본(replica). 데이터베이스(단일 서버)의 스토리지는 다른 AZs 또는 지역에 복제본(replica) 없습니다. 영역 중단이 데이터베이스 스토리지에 영향을 주는 경우 백업에서 새 인스턴스를 가져와서 데이터베이스를 복구합니다.
• DBR 이미지를 제공하는 데 사용되는 스토리지 계정도 지역 내에서 중복되며, 모든 지역에는 주 복제본이 다운되었을 때 사용되는 보조 스토리지 계정이 있습니다. Azure Databricks 지역을 참조 하세요.
• 일반적으로 가용성 영역이 복구된 후 15분 이내에 컨트롤 플레인 기능을 복원해야 합니다.

컴퓨팅 평면의 가용성

• 작업 영역 가용성은 위에서 설명한 대로 컨트롤 플레인의 가용성에 따라 달라집니다.
• DBFS 루트의 스토리지 계정이 ZRS 또는 GZRS(기본값: GRS)로 구성된 경우 DBFS 루트의 데이터는 영향을 받지 않습니다.
• 클러스터에 대한 노드는 Azure 컴퓨팅 공급자의 노드를 요청하여 다른 가용성 영역에서 가져옵니다(요청을 수행하기 위해 재기본ing 영역에 충분한 용량이 있다고 가정). 노드가 손실되면 클러스터 관리자는 Azure 컴퓨팅 공급자로부터 교체 노드를 요청하여 사용 가능한 AZ에서 노드를 가져옵니다. 유일한 예외는 드라이버 노드가 손실된 경우입니다. 이 경우 작업 또는 클러스터 관리자가 다시 시작합니다.

재해 복구 개요

재해 복구에는 자연 재해 또는 인적 재해가 발생한 후 중요한 기술 인프라 및 시스템의 복구 또는 지속을 가능하게 하는 일련의 정책, 도구 및 절차가 포함됩니다. Azure와 같은 대규모 클라우드 서비스는 많은 고객에게 서비스를 제공하며 단일 장애에 대한 기본 제공 보호 기능을 갖추고 있습니다. 예를 들어, 지역은 단일 전력 손실이 지역을 종료되지 않도록 보장하기 위해 서로 다른 전원에 연결된 건물 그룹입니다. 그러나 클라우드 지역 장애가 발생할 수 있으며 중단 정도와 조직에 미치는 영향은 다양할 수 있습니다.

재해 복구 계획을 구현하기 전에 DR(재해 복구)과 HA(고가용성)의 차이점을 이해하는 것이 중요합니다.

고가용성은 시스템의 복원력 특성입니다. 고가용성은 일반적으로 일관된 가동 시간 또는 가동 시간 비율로 정의되는 최소 수준의 운영 성능을 보장합니다. 고가용성은 기본 시스템의 기능으로 설계하여 내부(기본 시스템과 동일한 지역)에서 구현됩니다. 예를 들어 Azure와 같은 클라우드 서비스에는 ADLS gen2와 같은 고가용성 서비스가 있습니다(2023년 3월 6일 이전에 만든 작업 영역의 경우 Azure Blob Storage). 고가용성은 Azure Databricks 고객의 상당한 명시적 준비가 필요하지 않습니다.

대조적으로, 재해 복구 계획에는 특정 조직이 중요한 시스템에 대한 대규모 지역 중단을 처리하는 데 적합한 결정과 솔루션이 필요합니다. 이 문서에서는 Azure Databricks를 사용한 재해 복구 계획에 대한 일반적인 재해 복구 용어, 일반적인 솔루션 및 몇 가지 모범 사례를 설명합니다.

용어

지역 용어

이 문서에서는 지역에 대해 다음 정의를 사용합니다.

• 주 지역: 사용자가 일상적인 대화형 및 자동화된 데이터 분석 워크로드를 실행하는 지리적 지역입니다.

• 보조 지역: IT 팀이 주 지역의 중단 중에 일시적으로 데이터 분석 워크로드를 이동하는 지리적 지역입니다.

• 영역 중복 스토리지: Azure에는 비동기 스토리지 복제 프로세스를 사용하는 영구 스토리지를 위한 지역 간 영역 중복 스토리지가 있습니다.

  Important

  재해 복구 프로세스의 경우 Databricks는 Azure Databricks가 Azure 구독의 각 작업 영역에 대해 만드는 ADLS gen2(2023년 3월 6일 이전에 만든 작업 영역의 경우, Azure Blob Storage)와 같은 데이터의 지역 간 중복을 위해 지역 중복 스토리지를 사용하지 않는 것이 좋습니다. 일반적으로 Delta 테이블에는 딥 클론을 사용하고 다른 데이터 서식에서 가능하면 데이터를 Delta 형식으로 변환하여 딥 클론을 사용하도록 합니다.

배포 상태 용어

이 문서에서는 배포 상태에 대한 다음 정의를 사용합니다.

• 활성 배포: 사용자는 Azure Databricks 작업 영역의 활성 배포에 연결하고 워크로드를 실행할 수 있습니다. 작업은 Azure Databricks 스케줄러 또는 기타 메커니즘을 사용하여 주기적으로 예약됩니다. 이 배포에서도 데이터 스트림을 실행할 수 있습니다. 일부 문서에서는 활성 배포를 핫 배포라고 할 수 있습니다.

• 수동 배포: 수동 배포에서는 프로세스가 실행되지 않습니다. IT 팀은 수동 배포에 코드, 구성 및 기타 Azure Databricks 개체를 배포하는 자동화된 절차를 설정할 수 있습니다. 현재 활성 배포가 중단된 경우에만 배포가 활성화됩니다. 일부 문서에서는 수동 배포를 콜드 배포라고 할 수 있습니다.

  Important

  프로젝트는 선택적으로 다른 지역에 여러 수동 배포를 포함하여 지역 중단을 해결하기 위한 추가 옵션을 제공할 수 있습니다.

일반적으로 팀은 능동-수동 재해 복구 전략에서 한 번에 하나의 활성 배포만 수행합니다. 두 개의 동시 활성 배포가 있는 능동-능동이라는 덜 일반적인 재해 복구 솔루션 전략이 있습니다.

재해 복구 산업 용어

팀에 대해 이해하고 정의해야 하는 두 가지 중요한 업계 용어가 있습니다.

• 복구 지점 목표: RPO(복구 지점 목표)는 주요 인시던트로 인해 IT 서비스에서 데이터(트랜잭션)가 손실될 수 있는 최대 대상 기간입니다. Azure Databricks 배포는 기본 고객 데이터를 저장하지 않습니다. 이는 ADLS gen2(2023년 3월 6일 이전에 만든 작업 영역의 경우, Azure Blob Storage) 또는 사용자가 제어하는 다른 데이터 원본과 같은 별도의 시스템에 저장됩니다. Azure Databricks 컨트롤 플레인은 작업 및 Notebooks와 같은 일부 개체를 부분적으로 또는 전체적으로 저장합니다. Azure Databricks의 경우 RPO는 작업 및 Notebook 변경 내용과 같은 개체가 손실될 수 있는 최대 대상 기간으로 정의됩니다. 또한 ADLS gen2(2023년 3월 6일 이전에 만든 작업 영역, Azure Blob Storage) 또는 사용자가 제어하는 다른 데이터 원본에서 사용자 고유의 고객 데이터에 대한 RPO를 정의할 책임이 있습니다.

• 복구 시간 대상: RTO(복구 시간 대상)는 재해 이후 업무 프로세스를 복원해야 하는 대상 기간과 서비스 수준입니다.

  

재해 복구 및 데이터 손상

재해 복구 솔루션은 데이터 손상을 완화하지 않습니다. 주 지역의 손상된 데이터는 주 지역에서 보조 지역으로 복제되고 두 지역 모두에서 손상됩니다. 이러한 종류의 실패를 완화하는 다른 방법이 있습니다(예: Delta 시간 이동).

일반적인 복구 워크플로

Azure Databricks 재해 복구 시나리오는 일반적으로 다음과 같은 방식으로 수행됩니다.

1. 주 지역에서 사용하는 중요한 서비스에 장애가 발생했습니다. Azure Databricks 배포에 영향을 주는 데이터 원본 서비스 또는 네트워크일 수 있습니다.

2. 클라우드 공급자와 상황을 조사합니다.

3. 회사가 주 지역에서 문제가 수정될 때까지 기다릴 수 없다고 판단되면 보조 지역으로의 장애 조치(failover)가 필요하다고 결정할 수 있습니다.

4. 동일한 문제가 보조 지역에도 영향을 미치지 않는지 확인합니다.

5. 보조 지역으로 장애 조치(failover)합니다.

   1. 작업 영역에서 모든 작업을 중지합니다. 사용자는 워크로드를 중지합니다. 사용자 또는 관리자는 가능하면 최근 변경 내용을 백업하도록 지시합니다. 작업 중단으로 인해 아직 실패하지 않은 경우 작업이 종료됩니다.
   2. 보조 지역에서 복구 절차를 시작합니다. 복구 절차는 보조 지역에 대한 연결 및 네트워크 트래픽의 라우팅 및 이름 바꾸기를 업데이트합니다.
   3. 테스트 후 보조 지역이 작동 가능하다고 선언합니다. 이제 프로덕션 워크로드를 다시 시작할 수 있습니다. 사용자는 현재 활성화된 배포에 로그인할 수 있습니다. 예약되거나 지연된 작업을 다시 트리거할 수 있습니다.

   Azure Databricks 컨텍스트의 자세한 단계는 테스트 장애 조치(failover)를 참조하세요.

6. 특정 시점에서 주 지역의 문제가 완화되며 이때 사용자는 이 사실을 확인합니다.

7. 주 지역으로 복원(장애 복구)합니다.

   1. 보조 지역에서 모든 작업을 중지합니다.
   2. 주 지역에서 복구 절차를 시작합니다. 복구 절차는 주 지역으로 다시 연결 및 네트워크 트래픽의 라우팅 및 이름 바꾸기를 처리합니다.
   3. 필요에 따라 데이터를 주 지역으로 다시 복제합니다. 복잡성을 줄이려면 복제해야 하는 데이터의 양을 최소화합니다. 예를 들어 보조 배포에서 실행할 때 일부 작업이 읽기 전용인 경우 해당 데이터를 주 지역의 기본 배포로 다시 복제할 필요가 없습니다. 그러나 실행해야 하는 프로덕션 작업이 하나 있을 수 있으며 주 지역으로 다시 데이터 복제가 필요할 수 있습니다.
   4. 주 지역에서 배포를 테스트합니다.
   5. 주 지역이 작동 가능하고 활성 배포임을 선언합니다. 프로덕션 워크로드를 다시 시작합니다.

   주 지역으로 복원하는 방법에 대한 자세한 내용은 테스트 복원(장애 복구)을 참조하세요.

Important

이 단계에서 일부 데이터 손실이 발생할 수 있습니다. 조직은 허용 가능한 데이터 손실의 양과 이 손실을 완화하기 위해 할 수 있는 일을 정의해야 합니다.

1단계: 비즈니스 요구 사항 이해

첫 번째 단계는 비즈니스 요구 사항을 정의하고 이해하는 것입니다. 중요한 데이터 서비스와 예상 RPO 및 RTO를 정의합니다.

각 시스템의 실제 허용 오차를 조사하고 재해 복구 장애 조치(failover) 및 장애 복구는 비용이 많이 들고 다른 위험을 수반할 수 있음을 기억합니다. 다른 위험에는 데이터 손상, 잘못된 스토리지 위치에 쓰는 경우 복제되는 데이터, 잘못된 위치에 로그인하고 변경하는 사용자가 포함될 수 있습니다.

비즈니스에 영향을 미치는 모든 Azure Databricks 통합 지점을 매핑합니다.

• 재해 복구 솔루션이 대화형 프로세스, 자동화된 프로세스 또는 둘 다를 수용해야 하나요?
• 어떤 데이터 서비스를 사용하나요? 일부는 온-프레미스일 수 있습니다.
• 입력 데이터는 어떻게 클라우드에 도달하나요?
• 누가 이 데이터를 소비하나요? 다운스트림으로 소비하는 프로세스는 무엇인가요?
• 재해 복구 변경 내용을 인식해야 하는 타사 통합이 있나요?

재해 복구 계획을 지원할 수 있는 도구 또는 커뮤니케이션 전략을 결정합니다.

• 네트워크 구성을 빠르게 수정하기 위해 어떤 도구를 사용하려고 하나요?
• 구성을 미리 정의하고 자연스럽고 유지 관리 가능한 방식으로 재해 복구 솔루션을 수용하도록 모듈식으로 만들 수 있나요?
• 내부 팀과 타사(통합, 다운스트림 소비자)에게 재해 복구 장애 조치(failover) 및 장애 복구 변경 내용을 알리는 커뮤니케이션 도구 및 채널은 무엇인가요? 그리고 그들의 승인을 어떻게 확인할 것인가요?
• 어떤 도구나 특별한 지원이 필요하나요?
• 완전한 복구가 이루어질 때까지 어떤 서비스가 종료되나요?

2단계: 비즈니스 요구 사항을 충족하는 프로세스 선택

솔루션은 컨트롤 플레인, 컴퓨팅 평면 및 데이터 원본 모두에서 올바른 데이터를 복제본(replica). 재해 복구를 위한 중복 작업 영역은 다른 지역의 다른 컨트롤 플레인에 매핑되어야 합니다. 스크립트 기반 솔루션(동기화 도구 또는 CI/CD 워크플로)을 사용하여 주기적으로 데이터를 동기화 상태로 유지해야 합니다. Databricks 런타임 작업자와 같이 컴퓨팅 평면 네트워크 자체 내에서 데이터를 동기화할 필요가 없습니다.

VNet 삽입 기능(일부 구독 및 배포 유형에서 사용할 수 없음)을 사용하는 경우 Terraform과 같은 템플릿 기반 도구를 사용하여 두 지역 모두에서 이러한 네트워크를 일관되게 배포할 수 있습니다.

또한 데이터 원본이 필요에 따라 여러 지역에 복제되는지 확인해야 합니다.

일반적인 모범 사례

성공적인 재해 복구 계획을 위한 일반적인 모범 사례는 다음과 같습니다.

1. 비즈니스에 중요하고 재해 복구에서 실행해야 하는 프로세스를 이해합니다.

2. 관련된 서비스, 처리 중인 데이터, 데이터 흐름 및 저장 위치를 명확하게 식별

3. 서비스와 데이터를 최대한 격리합니다. 예를 들어 재해 복구를 위한 데이터를 위한 특수 클라우드 스토리지 컨테이너를 만들거나 재해 중에 필요한 Azure Databricks 개체를 별도의 작업 영역으로 이동합니다.

4. Databricks 컨트롤 플레인에 저장되지 않은 다른 개체에 대한 기본 배포와 보조 배포 간의 무결성을 유지하는 것은 사용자의 책임입니다.

   Warning

   작업 영역에 대한 DBFS 루트 액세스에 사용되는 루트 ADLS gen2(2023년 3월 6일 이전에 만든 작업 영역의 경우, Azure Blob Storage)에 데이터를 저장하지 않는 것이 좋습니다. 해당 DBFS 루트 스토리지는 프로덕션 고객 데이터에 대해 지원되지 않습니다. 또한 Databricks는 라이브러리, 구성 파일 또는 init 스크립트를 이 위치에 저장하지 않는 것이 좋습니다.

5. 데이터 원본의 경우 가능한 경우 복제 및 중복을 위한 네이티브 Azure 도구를 사용하여 재해 복구 지역에 데이터를 복제하는 것이 좋습니다.

복구 솔루션 전략 선택

일반적인 재해 복구 솔루션에는 두 개(또는 그 이상)의 작업 영역이 포함됩니다. 선택할 수 있는 몇 가지 전략이 있습니다. 중단의 잠재적 기간(몇 시간 또는 심지어 하루), 작업 영역이 완전히 작동하도록 하기 위한 활동, 주 지역으로 복원(장애 조치(failover))하기 위한 활동을 고려합니다.

능동-수동 솔루션 전략

능동-수동 솔루션이 가장 일반적이고 가장 쉬운 솔루션이며 이러한 유형의 솔루션이 이 문서의 초점입니다. 능동-수동 솔루션은 능동 배포에서 수동 배포로 데이터 및 개체 변경 내용을 동기화합니다. 원하는 경우 여러 지역에 수동 배포를 여러 개 가질 수 있지만 이 문서에서는 단일 수동 배포 방법에 중점을 둡니다. 재해 복구 이벤트 중에 보조 지역의 수동 배포가 능동 배포가 됩니다.

이 전략에는 두 가지 주요 변형이 있습니다.

• 통합(엔터프라이즈) 솔루션: 전체 조직을 지원하는 정확히 하나의 능동 및 수동 배포 집합입니다.
• 부서 또는 프로젝트별 솔루션: 각 부서 또는 프로젝트 도메인은 별도의 재해 복구 솔루션을 유지 관리합니다. 일부 조직에서는 부서 간에 재해 복구 세부 정보를 분리하고 각 팀의 고유한 요구 사항에 따라 각 팀에 대해 서로 다른 기본 및 보조 지역을 사용하려고 합니다.

읽기 전용 사용 사례에 수동 배포를 사용하는 것과 같은 다른 변형이 있습니다. 읽기 전용 워크로드(예: 사용자 쿼리)가 있는 경우 데이터 또는 Notebooks 또는 작업과 같은 Azure Databricks 개체를 수정하지 않으면 언제든지 수동 솔루션에서 실행할 수 있습니다.

능동-능동 솔루션

능동-능동 솔루션에서는 두 지역의 모든 데이터 프로세스를 항상 병렬로 실행합니다. 운영 팀은 작업과 같은 데이터 프로세스가 두 지역 모두에서 성공적으로 완료된 경우에만 완료로 표시되도록 해야 합니다. 개체는 프로덕션에서 변경할 수 없으며 개발/스테이징에서 프로덕션에 이르기까지 엄격한 CI/CD 프로모션을 따라야 합니다.

능동-능동 솔루션은 가장 복잡한 전략이며 작업이 두 지역 모두에서 실행되기 때문에 추가 재정 비용이 발생합니다.

능동-수동 전략과 마찬가지로 이를 통합 조직 솔루션으로 또는 부서별로 구현할 수 있습니다.

워크플로에 따라 모든 작업 영역에 대해 보조 시스템에 동등한 작업 영역이 필요하지 않을 수 있습니다. 예를 들어 개발 또는 스테이징 작업 영역에는 복제본이 필요하지 않을 수 있습니다. 잘 설계된 개발 파이프라인을 사용하면 필요한 경우 이러한 작업 영역을 쉽게 재구성할 수 있습니다.

도구 선택

기본 및 보조 지역의 작업 영역 간에 데이터를 최대한 유사하게 유지하기 위한 도구에는 두 가지 주요 방법이 있습니다.

• 기본에서 보조로 복사하는 동기화 클라이언트: 동기화 클라이언트는 프로덕션 데이터와 자산을 주 지역에서 보조 지역으로 푸시합니다. 일반적으로 일정에 따라 실행됩니다.
• 병렬 배포를 위한 CI/CD 도구: 프로덕션 코드 및 자산의 경우 프로덕션 시스템의 변경사항을 두 지역에 동시에 푸시하는 CI/CD 도구를 사용합니다. 예를 들어 스테이징/개발에서 프로덕션으로 코드와 자산을 푸시할 때 CI/CD 시스템은 두 지역에서 동시에 사용할 수 있도록 합니다. 핵심 아이디어는 Azure Databricks 작업 영역의 모든 아티팩트를 코드로서의 인프라로 처리하는 것입니다. 대부분의 아티팩트는 기본 및 보조 작업 영역 모두에 공동 배포할 수 있지만 일부 아티팩트는 재해 복구 이벤트가 일어난 후에만 배포해야 할 수 있습니다. 도구는 Automation 스크립트, 샘플 및 프로토타입을 참조하세요.

다음 다이어그램은 이 두 가지 방법을 대조합니다.

필요에 따라 방법을 결합할 수 있습니다. 예를 들어 Notebook 소스 코드에는 CI/CD를 사용하지만 풀 및 액세스 제어와 같은 구성에는 동기화를 사용합니다.

다음 표에서는 각 도구 옵션으로 다양한 유형의 데이터를 처리하는 방법을 설명합니다.

설명	CI/CD 도구로 처리하는 방법	동기화 도구로 처리하는 방법
소스 코드: 패키지 라이브러리용 Notebook 원본 내보내기 및 소스 코드	기본 및 보조 모두에 공동 배포합니다.	소스 코드를 기본에서 보조로 동기화합니다.
사용자 및 그룹	Git에서 구성으로 메타데이터를 관리합니다. 또는 두 작업 영역에 동일한 IdP(ID 공급자)를 사용합니다. 기본 및 보조 배포에 사용자 및 그룹 데이터를 공동 배포합니다.	두 지역 모두에 대해 SCIM 또는 기타 자동화를 사용합니다. 수동 만들기는 권장되지 않지만 사용하는 경우 두 가지 모두에 대해 동시에 수행해야 합니다. 수동 설정을 사용하는 경우 예약된 자동화 프로세스를 만들어 두 배포 간에 사용자 및 그룹 목록을 비교합니다.
풀 구성	Git에서 템플릿이 될 수 있습니다. 기본 및 보조에 공동 배포합니다. 그러나 보조의 min_idle_instances는 재해 복구 이벤트까지 0이어야 합니다.	API 또는 CLI를 사용하여 보조 작업 영역에 동기화할 때 min_idle_instances로 만들어진 풀.
작업 구성	Git에서 템플릿이 될 수 있습니다. 기본 배포의 경우 작업 정의를 있는 그대로 배포합니다. 보조 배포의 경우 작업을 배포하고 동시성을 0으로 설정합니다. 이렇게 하면 이 배포에서 작업이 사용하지 않도록 설정되고 추가 실행이 방지됩니다. 보조 배포가 활성화된 후 동시성 값을 변경합니다.	어떤 이유로 인해 작업이 기존 <interactive> 클러스터에서 실행되는 경우 동기화 클라이언트는 보조 작업 영역의 해당 cluster_id에 매핑해야 합니다.
ACL(액세스 제어 목록)	Git에서 템플릿이 될 수 있습니다. Notebooks, 폴더 및 클러스터의 기본 및 보조 배포에 공동 배포합니다. 그러나 재해 복구 이벤트가 발생할 때까지 작업에 대한 데이터를 보유합니다.	권한 API는 클러스터, 작업, 풀, Notebook 및 폴더에 대한 액세스 제어를 설정할 수 있습니다. 동기화 클라이언트는 보조 작업 영역의 각 개체에 대한 해당 개체 ID에 매핑해야 합니다. Databricks는 액세스 제어를 복제하기 전에 이러한 개체를 동기화하면서 기본 작업 영역에서 보조 작업 영역으로 개체 ID 맵을 만드는 것이 좋습니다.
라이브러리	소스 코드 및 클러스터/작업 템플릿에 포함합니다.	중앙 집중식 리포지토리, DBFS 또는 클라우드 스토리지(탑재 가능)에서 사용자 지정 라이브러리를 동기화합니다.
클러스터 초기화 스크립트	원하는 경우 소스 코드에 포함합니다.	더 간단한 동기화를 위해 공통 폴더 또는 가능한 경우 작은 폴더 집합의 기본 작업 영역에 init 스크립트를 저장합니다.
탑재 지점	Notebook 기반 작업 또는 명령 API를 통해서만 만들어진 경우 소스 코드에 포함합니다.	ADF(Azure Data Factory) 작업으로 실행할 수 있는 작업을 사용합니다. 작업 영역이 다른 지역에 있는 경우 스토리지 엔드포인트가 변경될 수 있습니다. 이는 데이터 재해 복구 전략에도 크게 좌우됩니다.
테이블 메타데이터	Notebook 기반 작업 또는 명령 API를 통해서만 만들어진 경우 소스 코드와 함께 포함합니다. 이는 내부 Azure Databricks 메타스토어 또는 외부 구성된 메타스토어 모두에 적용됩니다.	Spark Catalog API를 사용하여 메타스토어 간의 메타데이터 정의를 비교하거나 Notebook 또는 스크립트를 통해 테이블 만들기 표시를 사용합니다. 기본 스토리지에 대한 테이블은 지역 기반일 수 있으며 메타스토어 인스턴스마다 다릅니다.
비밀	명령 API를 통해서만 만들어진 경우 소스 코드에 포함합니다. 일부 비밀 콘텐츠는 기본 콘텐츠와 보조 콘텐츠 간에 변경해야 할 수도 있습니다.	비밀은 API를 통해 두 작업 영역 모두에서 만들어집니다. 일부 비밀 콘텐츠는 기본 콘텐츠와 보조 콘텐츠 간에 변경해야 할 수도 있습니다.
클러스터 구성	Git에서 템플릿이 될 수 있습니다. 기본 및 보조 배포에 공동 배포하지만 보조 배포에 있는 배포는 재해 복구 이벤트가 있을 때까지 종료해야 합니다.	클러스터는 API 또는 CLI를 사용하여 보조 작업 영역에 동기화된 후 만들어집니다. 자동 종료 설정에 따라 원하는 경우 명시적으로 종료할 수 있습니다.
Notebook, 작업 및 폴더 권한	Git에서 템플릿이 될 수 있습니다. 기본 및 보조 배포에 공동 배포합니다.	권한 API를 사용하여 복제합니다.

지역 및 여러 보조 작업 영역 선택

재해 복구 트리거를 완전히 제어해야 합니다. 언제든지 또는 어떤 이유로든 이를 트리거하기로 결정할 수 있습니다. 운영 장애 복구(일반 프로덕션) 모드를 다시 시작하기 전에 재해 복구 안정화에 대한 책임을 져야 합니다. 일반적으로 이는 프로덕션 및 재해 복구 요구 사항을 제공하기 위해 여러 Azure Databricks 작업 영역을 만들고 보조 장애 조치(failover) 지역을 선택해야 함을 의미합니다.

Azure에서 제품 및 VM 유형 가용성은 물론 데이터 복제를 확인합니다.

3단계: 작업 영역 준비 및 일회성 복사 수행

작업 영역이 이미 프로덕션에 있는 경우 일반적으로 일회성 복사 작업을 실행하여 수동 배포를 활성 배포와 동기화합니다. 이 일회성 복사는 다음을 처리합니다.

• 데이터 복제: 클라우드 복제 솔루션 또는 Delta 딥 클론 작업을 사용하여 복제합니다.
• 토큰 생성: 토큰 생성을 사용하여 복제 및 향후 워크로드를 자동화합니다.
• 작업 영역 복제: 4단계: 데이터 원본 준비에 설명된 메서드를 사용하여 작업 영역 복제를 사용합니다.
• 작업 영역 유효성 검사: - 작업 영역과 프로세스가 성공적으로 실행되고 예상 결과를 제공할 수 있는지 테스트합니다.

초기 1회 복사 작업 후에는 후속 복사 및 동기화 작업이 더 빨라지고 도구의 모든 로깅은 변경 내용과 변경 시기에 대한 로그이기도 합니다.

4단계: 데이터 원본 준비

Azure Databricks는 일괄 처리 또는 데이터 스트림을 사용하여 다양한 데이터 원본을 처리할 수 있습니다.

데이터 원본에서 일괄 처리

데이터가 일괄 처리될 때 일반적으로 쉽게 복제하거나 다른 지역으로 전달할 수 있는 데이터 원본에 상주합니다.

예를 들어, 데이터는 정기적으로 클라우드 스토리지 위치에 업로드될 수 있습니다. 보조 지역의 재해 복구 모드에서 파일이 보조 지역 스토리지에 업로드되는지 확인해야 합니다. 워크로드는 보조 지역 스토리지를 읽고 보조 지역 스토리지에 써야 합니다.

데이터 스트림

데이터 스트림을 처리하는 것은 더 큰 과제입니다. 스트리밍 데이터는 다양한 원본에서 수집되고 처리되어 스트리밍 솔루션으로 보낼 수 있습니다.

• Kafka와 같은 메시지 큐
• 데이터베이스 변경 데이터 캡처 스트림
• 파일 기반 연속 처리
• 한 번 트리거라고도 하는 파일 기반 예약 처리

이러한 모든 경우에 재해 복구 모드를 처리하고 보조 지역에서 보조 배포를 사용하도록 데이터 원본을 구성해야 합니다.

스트림 작성기는 처리된 데이터에 대한 정보가 있는 검사점을 저장합니다. 이 검사점에는 스트림을 성공적으로 다시 시작하기 위해 새 위치로 수정해야 하는 데이터 위치(일반적으로 클라우드 스토리지)가 포함될 수 있습니다. 예를 들어 검사점 아래의 source 하위 폴더는 파일 기반 클라우드 폴더를 저장할 수 있습니다.

이 검사점은 적시에 복제되어야 합니다. 새로운 클라우드 복제 솔루션과의 검사점 간격 동기화를 고려합니다.

검사점 업데이트는 작성자의 함수이므로 데이터 스트림 수집 또는 처리 및 다른 스트리밍 원본에 저장하는 데 적용됩니다.

스트리밍 워크로드의 경우 마지막 실패 지점에서 워크로드 다시 시작을 위해 보조 지역으로 복제할 수 있도록 검사점이 고객 관리 스토리지에 구성되어 있는지 확인합니다. 기본 프로세스와 병렬로 보조 스트리밍 프로세스를 실행하도록 선택할 수도 있습니다.

5단계: 솔루션 구현 및 테스트

정기적으로 재해 복구 설정을 테스트하여 올바르게 작동하는지 확인합니다. 필요할 때 사용할 수 없다면 재해 복구 솔루션을 유지 관리하는 것은 가치가 없습니다. 일부 회사는 몇 달에 한 번씩 지역을 전환합니다. 정기적인 일정에 따라 지역을 전환하는 것은 가정과 프로세스를 테스트하고 복구 요구 사항을 충족하는지 확인합니다. 이는 또한 조직이 비상 사태에 대한 정책과 절차를 잘 알고 있는지 확인합니다.

Important

실제 상황에서 재해 복구 솔루션을 정기적으로 테스트합니다.

개체 또는 템플릿이 누락되었고 여전히 기본 작업 영역에 저장된 정보에 의존해야 하는 경우 이러한 장애물을 제거하거나 보조 시스템에 이 정보를 복제하거나 다른 방법으로 사용할 수 있도록 계획을 수정합니다.

일반적으로 프로세스 및 구성에 필요한 조직 변경 내용을 테스트합니다. 재해 복구 계획은 배포 파이프라인에 영향을 미치므로 팀이 동기화 상태를 유지해야 하는 항목을 아는 것이 중요합니다. 재해 복구 작업 영역을 설정한 후에는 인프라(수동 또는 코드), 작업, Notebook, 라이브러리 및 기타 작업 영역 개체를 보조 지역에서 사용할 수 있는지 확인해야 합니다.

표준 작업 프로세스 및 구성 파이프라인을 확장하여 모든 작업 영역에 변경 내용을 배포하는 방법에 대해 팀과 상의합니다. 모든 작업 영역에서 사용자 ID를 관리합니다. 새 작업 영역에 대한 작업 자동화 및 모니터링과 같은 도구를 구성하는 것을 잊지 마세요.

구성 도구에 대한 변경 계획 및 테스트:

• 수집: 데이터 원본이 있는 위치와 해당 원본에서 데이터를 가져오는 위치를 이해합니다. 가능한 경우 원본을 매개 변수화하고 보조 배포 및 보조 지역 작업을 위한 별도의 구성 템플릿이 있는지 확인합니다. 장애 조치(failover) 계획을 준비하고 모든 가정을 테스트합니다.
• 실행 변경 내용: 작업 또는 기타 작업을 트리거하는 스케줄러가 있는 경우 보조 배포 또는 해당 데이터 원본과 함께 작동하는 별도의 스케줄러를 구성해야 할 수 있습니다. 장애 조치(failover) 계획을 준비하고 모든 가정을 테스트합니다.
• 대화형 연결: REST API, CLI 도구 또는 JDBC/ODBC와 같은 기타 서비스 사용에 대한 지역적 중단이 구성, 인증 및 네트워크 연결에 어떤 영향을 미칠 수 있는지 고려합니다. 장애 조치(failover) 계획을 준비하고 모든 가정을 테스트합니다.
• Automation 변경: 모든 자동화 도구에 대해 장애 조치(failover) 계획을 준비하고 모든 가정을 테스트합니다.
• 출력: 출력 데이터 또는 로그를 생성하는 모든 도구의 경우 장애 조치(failover) 계획을 준비하고 모든 가정을 테스트합니다.

장애 조치(failover) 테스트

재해 복구는 다양한 시나리오에서 트리거될 수 있습니다. 예기치 않은 중단으로 인해 발생할 수 있습니다. 클라우드 네트워크, 클라우드 스토리지 또는 다른 핵심 서비스를 포함한 일부 핵심 기능이 다운될 수 있습니다. 시스템을 정상적으로 종료할 수 있는 액세스 권한이 없으며 복구를 시도해야 합니다. 그러나 프로세스는 시스템 종료 또는 계획된 중단 또는 두 지역 간의 활성 배포를 주기적으로 전환하여 트리거될 수 있습니다.

장애 조치(failover)를 테스트할 때 시스템에 연결하고 종료 프로세스를 실행합니다. 모든 작업이 완료되고 클러스터가 종료되었는지 확인합니다.

동기화 클라이언트(또는 CI/CD 도구)는 관련 Azure Databricks 개체 및 리소스를 보조 작업 영역에 복제할 수 있습니다. 보조 작업 영역을 활성화하기 위해 프로세스에 다음 중 일부 또는 전체가 포함될 수 있습니다.

1. 테스트를 실행하여 플랫폼이 최신 상태인지 확인합니다.
2. 실패한 서비스가 온라인으로 반환되는 경우 주 지역에서 새 데이터 처리를 시작하지 않도록 주 지역에서 풀 및 클러스터를 사용하지 않도록 설정합니다.
3. 복구 프로세스:
   1. 가장 최근에 동기화된 데이터의 날짜를 확인합니다. 재해 복구 업계 용어를 참조하세요. 이 단계의 세부 정보는 데이터를 동기화하는 방법과 고유한 비즈니스 요구 사항에 따라 다릅니다.
   2. 데이터 원본을 안정화하고 모두 사용 가능한지 확인합니다. Azure Cloud SQL과 같은 모든 외부 데이터 원본과 Delta Lake, Parquet 또는 기타 파일을 포함합니다.
   3. 스트리밍 복구 지점을 찾습니다. 거기에서 다시 시작하도록 프로세스를 설정하고 잠재적인 중복을 식별하고 제거할 준비가 된 프로세스를 준비합니다(Delta Lake는 이를 더 쉽게 만듭니다).
   4. 데이터 흐름 프로세스를 완료하고 사용자에게 알립니다.
4. 관련 풀을 시작합니다(또는 min_idle_instances를 관련 숫자로 늘림).
5. 관련 클러스터를 시작합니다(종료되지 않은 경우).
6. 작업의 동시 실행을 변경하고 관련 작업을 실행합니다. 일회성 실행 또는 주기적 실행일 수 있습니다.
7. Azure Databricks 작업 영역에 대해 URL 또는 도메인 이름을 사용하는 외부 도구의 경우 새 컨트롤 플레인을 설명하도록 구성을 업데이트합니다. 예를 들어 REST API 및 JDBC/ODBC 연결에 대한 업데이트 URL입니다. Azure Databricks 웹 애플리케이션의 고객 대면 URL은 컨트롤 플레인이 변경되면 변경되므로 조직의 사용자에게 새 URL을 알립니다.

테스트 복원(장애 복구)

장애 복구는 제어하기 쉽고 유지 관리 기간에 수행할 수 있습니다. 이 계획에는 다음 중 일부 또는 전부가 포함될 수 있습니다.

1. 주 지역이 복원되었는지 확인합니다.
2. 새 데이터 처리를 시작하지 않도록 보조 지역에서 풀 및 클러스터를 사용하지 않도록 설정합니다.
3. 보조 작업 영역에서 새 자산이나 수정된 자산을 다시 기본 배포로 동기화합니다. 장애 조치(failover) 스크립트의 디자인에 따라 동일한 스크립트를 실행하여 보조(재해 복구) 지역에서 기본(프로덕션) 지역으로 개체를 동기화할 수 있습니다.
4. 모든 새 데이터 업데이트를 기본 배포와 다시 동기화합니다. 로그 및 Delta 테이블의 감사 내역을 사용하여 데이터 손실이 없도록 보장할 수 있습니다.
5. 재해 복구 지역의 모든 워크로드를 종료합니다.
6. 작업 및 사용자 URL을 주 지역으로 변경합니다.
7. 테스트를 실행하여 플랫폼이 최신 상태인지 확인합니다.
8. 관련 풀을 시작합니다(또는 min_idle_instances를 관련 숫자로 늘림).
9. 관련 클러스터를 시작합니다(종료되지 않은 경우).
10. 작업의 동시 실행을 변경하고 관련 작업을 실행합니다. 일회성 실행 또는 주기적 실행일 수 있습니다.
11. 필요에 따라 향후 재해 복구를 위해 보조 지역을 다시 설정합니다.

Automation 스크립트, 샘플 및 프로토타입

재해 복구 프로젝트를 위해 고려할 Automation 스크립트:

• Databricks에서는 Databricks Terraform 공급자를 사용하여 고유한 동기화 프로세스를 개발할 것을 권장합니다.
• 샘플 및 프로토타입 스크립트는 Databricks Workspace 마이그레이션 도구도 참조하세요. Azure Databricks 개체 외에도 관련 Azure Data Factory 파이프라인을 복제하여 보조 작업 영역에 매핑된 연결된 서비스를 참조하도록 합니다.
• DBSync(Databricks Sync) 프로젝트는 Databricks 작업 영역을 백업, 복원 및 동기화하는 개체 동기화 도구입니다.