영어로 읽기

다음을 통해 공유


환경별 재해 복구 지침

이 문서에서는 지역 재해 발생 시 Fabric 데이터를 복구하기 위한 환경별 지침을 제공합니다.

샘플 시나리오

이 문서의 여러 지침 섹션에서는 설명 및 그림을 제공할 목적으로 다음 샘플 시나리오를 사용합니다. 필요에 따라 이 시나리오를 다시 참조하세요.

작업 영역 W1이 있는 하위 지역 A에 용량 C1이 있다고 가정합니다. 용량 C1에 대한 재해 복구를 설정한 경우 OneLake 데이터가 B 하위 지역의 백업으로 복제됩니다. A 하위 지역에 장애가 발생하면 C1의 Fabric 서비스가 B 하위 지역으로 장애 조치됩니다.

다음 그림에서는 이 시나리오를 보여 줍니다. 왼쪽의 상자에 가동 중단이 발생한 하위 지역이 표시됩니다. 가운데 상자는 장애 조치(failover) 후 데이터의 지속적인 가용성을 나타내며, 오른쪽 상자는 고객이 서비스를 전체 기능으로 복원하기 위한 작업을 수행한 후 완전히 보장된 상황을 보여줍니다.

재해, 장애 조치(failover) 및 전체 복구 시나리오를 보여주는 다이어그램.

다음은 일반적인 복구 계획입니다.

  1. 새 하위 지역에서 새 Fabric 용량 C2를 만듭니다.

  2. C1.W1과 이름이 같은 해당 항목을 포함하여 C2에 새 W2 작업 영역을 만듭니다.

  3. 중단된 C1.W1에서 C2.W2로 데이터를 복사합니다.

  4. 각 구성 요소에 대한 전용 지침에 따라 항목을 전체 함수로 복원합니다.

환경별 복구 계획

다음 섹션에서는 복구 프로세스를 통해 고객을 돕기 위해 각 Fabric 환경에 대한 단계별 가이드를 제공합니다.

데이터 엔지니어링

이 가이드에서는 데이터 엔지니어링 환경에 대한 복구 절차를 안내합니다. 레이크하우스, Notebook 및 Spark 작업 정의를 다룹니다.

Lakehouse

원래 하위 지역의 레이크하우스는 고객이 여전히 사용할 수 없습니다. 레이크하우스를 복구하기 위해 고객은 작업 영역 C2.W2에서 다시 만들 수 있습니다. 레이크하우스를 복구하는 두 가지 방법을 권장합니다.

방법 1: 사용자 지정 스크립트를 사용하여 레이크하우스 델타 테이블 및 파일 복사

고객은 사용자 지정 스칼라 스크립트를 사용하여 레이크하우스를 다시 만들 수 있습니다.

  1. 새로 만든 작업 공간 C2.W2에서 레이크하우스(예: LH1)를 만듭니다.

  2. 작업 영역 C2.W2에서 새 Notebook을 만듭니다.

  3. 원래 레이크하우스에서 테이블과 파일을 복구하려면 abfss와 같은 OneLake 경로가 있는 데이터를 참조하세요(Microsoft OneLake에 연결 참조). Notebook에서 아래 코드 예제(Microsoft Spark 유틸리티 소개 참조)를 사용하여 원래 레이크하우스에서 파일 및 테이블의 ABFS 경로를 가져올 수 있습니다. (C1.W1을 실제 작업 영역 이름으로 바꿉니다.)

    mssparkutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
    
  4. 다음 코드 예제를 사용하여 테이블과 파일을 새로 만든 레이크하우스에 복사합니다.

    1. 델타 테이블의 경우 새 레이크하우스에서 복구하려면 테이블을 한 번에 하나씩 복사해야 합니다. 레이크하우스 파일의 경우 단일 실행으로 모든 기본 폴더와 함께 전체 파일 구조를 복사할 수 있습니다.

    2. 스크립트에 필요한 장애 조치(failover) 타임스탬프는 지원 팀에 문의하세요.

    %%spark
    val source="abfs path to original Lakehouse file or table directory"
    val destination="abfs path to new Lakehouse file or table directory"
    val timestamp= //timestamp provided by Support
    
    mssparkutils.fs.cp(source, destination, true)
    
    val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
        .filter{sf => sf.isFile && sf.modifyTime > timestamp}
    
    for(fileToDelte <- filesToDelete) {
        val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
        println(s"Deleting file $destFileToDelete")
        mssparkutils.fs.rm(destFileToDelete, false)
    }
    
    mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
    
  5. 스크립트를 실행하면 테이블이 새 레이크하우스에 표시됩니다.

방법 2: Azure Storage Explorer를 사용하여 파일 및 테이블 복사

원래 레이크하우스에서 특정 레이크하우스 파일 또는 테이블만 복구하려면 Azure Storage Explorer를 사용합니다. 자세한 단계는 OneLake를 Azure Storage Explorer와 통합을 참조하세요. 큰 데이터 크기의 경우 방법 1을 사용합니다.

참고

위에서 설명한 두 가지 방법은 메타데이터가 OneLake의 데이터와 함께 배치되고 저장되기 때문에 델타 형식 테이블의 메타데이터와 데이터를 모두 복구합니다. Spark DDL(데이터 정의 언어) 스크립트/명령을 사용하여 만든 델타 형식이 아닌 테이블(예: CSV, Parquet 등)의 경우 사용자는 복구를 위해 Spark DDL 스크립트/명령을 유지 관리하고 다시 실행해야 합니다.

Notebook

주 지역의 Notebook은 여전히 고객이 사용할 수 없으며 Notebook의 코드는 보조 지역에 복제되지 않습니다. 새 하위 지역에서 Notebook 코드를 복구하기 위해 Notebook 코드 콘텐츠를 복구하는 두 가지 방법이 있습니다.

방법 1: Git 통합을 사용하는 사용자 관리 중복성(공개 미리 보기)

이 작업을 쉽고 빠르게 수행하는 가장 좋은 방법은 Fabric Git 통합을 사용한 다음 Notebook을 ADO 리포지토리와 동기화하는 것입니다. 서비스가 다른 하위 지역으로 장애 조치된 후 리포지토리를 사용하여 만든 새 작업 영역에서 Notebook을 다시 빌드할 수 있습니다.

  1. Git 통합을 설정하고 ADO 리포지토리와의 연결 및 동기화을 선택합니다.

    ADO 리포지토리를 사용하여 Notebook을 연결하고 동기화하는 방법을 보여주는 스크린샷.

    다음 이미지는 동기화된 Notebook을 보여줍니다.

    ADO 리포지토리와 동기화된 Notebook을 보여주는 스크린샷.

  2. ADO 리포지토리에서 Notebook을 복구합니다.

    1. 새로 만든 작업 영역에서 Azure ADO 리포지토리에 다시 연결합니다.

      ADO 리포지토리에 다시 연결된 Notebook을 보여주는 스크린샷.

    2. 원본 제어 버튼을 선택합니다. 그런 다음, 리포지토리의 관련 분기를 선택합니다. 그런 다음, 모두 업데이트를 선택합니다. 원래 Notebook이 나타납니다.

      분기의 모든 Notebook을 업데이트하는 방법을 보여주는 스크린샷.

      다시 만든 원본 노트를 보여주는 스크린샷.

    3. 원래 Notebook에 기본 레이크하우스가 있는 경우 사용자는 레이크하우스 섹션을 참조하여 레이크하우스를 복구한 다음, 새로 복구된 레이크하우스를 새로 복구된 노트북에 연결할 수 있습니다.

      복구된 레이크하우스를 복구된 Notebook에 연결하는 방법을 보여주는 스크린샷.

    4. Git 통합은 Notebook 리소스 탐색기의 파일, 폴더 또는 Notebook 스냅샷 동기화를 지원하지 않습니다.

      1. 원본 Notebook에 Notebook 리소스 탐색기에 파일이 있는 경우:

        1. 파일 또는 폴더를 로컬 디스크 또는 다른 위치에 저장해야 합니다.

        2. 로컬 디스크 또는 클라우드 드라이브에서 복구된 Notebook으로 파일을 다시 업로드하세요.

      2. 원래 Notebook에 Notebook 스냅샷이 있는 경우 Notebook 스냅샷을 사용자 고유의 버전 제어 시스템 또는 로컬 디스크에 저장합니다.

        Notebook을 실행하여 스냅샷을 저장하는 방법을 보여주는 스크린샷.

        Notebook 스냅샷을 저장하는 방법을 보여주는 스크린샷.

Git 통합에 대한 자세한 내용은 Git 통합 소개를 참조하세요.

방법 2: 코드 콘텐츠를 백업하는 수동 접근 방식

Git 통합 방법을 사용하지 않는 경우 최신 버전의 코드, 리소스 탐색기의 파일 및 Notebook 스냅샷을 Git과 같은 버전 제어 시스템에 저장하고 재해 발생 후 Notebook 콘텐츠를 수동으로 복구할 수 있습니다.

  1. "Notebook 가져오기" 기능을 사용하여 복구할 Notebook 코드를 가져옵니다.

    Notebook 코드를 가져오는 방법을 보여주는 스크린샷.

  2. 가져온 후 원하는 작업 영역(예: "C2.W2")으로 이동하여 액세스합니다.

  3. 원래 Notebook에 기본 레이크하우스가 있는 경우 레이크하우스 섹션을 참조하세요. 그런 다음, 새로 복구된 레이크하우스(원래 기본 레이크하우스와 동일한 콘텐츠 포함)를 새로 복구된 Notebook에 연결합니다.

  4. 원래 Notebook에서 리소스 탐색기에 파일 또는 폴더가 있는 경우 사용자의 버전 제어 시스템에 저장된 파일 또는 폴더를 다시 업로드합니다.

Spark 작업 정의

주 지역의 SJD(Spark 작업 정의)는 고객이 여전히 사용할 수 없으며 Notebook의 기본 정의 파일 및 참조 파일은 OneLake를 통해 보조 지역에 복제됩니다. 새 하위 지역에서 SJD를 복구하려면 아래에 설명된 수동 단계에 따라 SJD를 복구할 수 있습니다. SJD의 실행 내역은 복구되지 않습니다.

Azure Storage Explorer를 사용하여 원래 하위 지역에서 코드를 복사하고 재해 발생 후 레이크하우스 참조를 수동으로 다시 연결하여 SJD 항목을 복구할 수 있습니다.

  1. 새 작업 영역 C2.W2에서 원래 SJD 항목(예: 언어, 환경 등)과 동일한 설정 및 구성으로 새 SJD 항목(예: SJD1)을 만듭니다.

  2. Azure Storage Explorer를 사용하여 Libs, Mains 및 Snapshots를 원래 SJD 항목에서 새 SJD 항목으로 복사합니다.

    원래 Spark 작업 정의에서 새 Spark 작업 정의로 복사하는 방법을 보여주는 스크린샷.

  3. 코드 콘텐츠는 새로 만든 SJD에 표시됩니다. 새로 복구된 레이크하우스 참조를 작업에 수동으로 추가해야 합니다(레이크하우스 복구 단계 참조). 사용자는 원래 명령줄 인수를 수동으로 다시 입력해야 합니다.

    Spark 작업 정의를 복구하기 위한 명령줄 인수를 보여주는 스크린샷.

이제 새로 복구된 SJD를 실행하거나 예약할 수 있습니다.

Azure Storage Explorer에 대한 자세한 내용은 OneLake를 Azure Storage Explorer와 통합을 참조하세요.

데이터 과학

이 가이드에서는 데이터 과학 환경에 대한 복구 절차를 안내합니다. ML 모델 및 실험을 다룹니다.

ML 모델 및 실험

주 지역의 데이터 과학 항목은 여전히 고객이 사용할 수 없으며, ML 모델 및 실험의 콘텐츠 및 메타데이터는 보조 지역에 복제되지 않습니다. 새 하위 지역에서 완전히 복구하려면 버전 제어 시스템(예: Git)에 코드 콘텐츠를 저장하고 재해 발생 후 코드 콘텐츠를 수동으로 다시 실행합니다.

  1. Notebook을 복구합니다. Notebook 복구 단계를 참조하세요.

  2. 구성, 이전에 실행한 메트릭 및 메타데이터는 쌍을 이루는 하위 지역에 복제되지 않습니다. 재해 발생 후 ML 모델 및 실험을 완전히 복구하려면 데이터 과학 코드의 각 버전을 다시 실행해야 합니다.

데이터 웨어하우스

이 가이드에서는 데이터 웨어하우스 환경에 대한 복구 절차를 안내합니다. 웨어하우스를 다룹니다.

웨어하우스

원래 하위 지역의 웨어하우스는 고객이 사용할 수 없습니다. 웨어하우스를 복구하려면 다음 두 단계를 사용합니다.

  1. 원래 웨어하우스에서 복사할 데이터를 위해 작업 공간 C2.W2에 새로운 임시 레이크하우스를 만듭니다.

  2. 웨어하우스 탐색기 및 T-SQL 기능을 활용하여 웨어하우스의 델타 테이블을 채웁니다(Microsoft Fabric에서 데이터 웨어하우징의 테이블 참조).

참고

개발 사례에 따라 웨어하우스 코드(스키마, 테이블, 보기, 저장 프로시저, 함수 정의 및 보안 코드)의 버전을 관리하고 안전한 위치(예: Git)에 저장하는 것이 좋습니다.

레이크하우스 및 T-SQL 코드를 통한 데이터 수집

새로 만든 작업 공간 C2.W2에서 다음을 수행합니다.

  1. C2.W2에 임시 레이크하우스 "LH2"를 만듭니다.

  2. 레이크하우스 복구 단계에 따라 원래 웨어하우스에서 임시 레이크하우스의 델타 테이블을 복구합니다.

  3. C2.W2에서 새 웨어하우스 "WH2"를 만듭니다.

  4. 웨어하우스 탐색기에서 임시 레이크하우스를 연결합니다.

    웨어하우스 복구 중 웨어하우스 탐색기의 스크린샷.

  5. 데이터 가져오기 전에 테이블 정의를 배포하는 방법에 따라 가져오기에 사용되는 실제 T-SQL은 다를 수 있습니다. INSERT INTO, SELECT INTO 또는 CREATE TABLE AS SELECT 접근 방식을 사용하여 레이크하우스에서 웨어하우스 테이블을 복구할 수 있습니다. 이 예제에서는 INSERT INTO 버전을 사용합니다. (아래 코드를 사용하는 경우 샘플을 실제 테이블 및 열 이름으로 바꿉니다.)

    USE WH1
    
    INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
    
    SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
    FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
    GO
    
  6. 마지막으로 Fabric 웨어하우스를 사용하여 애플리케이션의 연결 문자열을 변경합니다.

참고

하위 지역 간 재해 복구 및 완전 자동화된 비즈니스 연속성이 필요한 고객의 경우 두 개의 Fabric 웨어하우스 설정을 별도의 Fabric 하위 지역에 유지하고 두 사이트 모두에서 정기적으로 배포 및 데이터 수집을 수행하여 코드 및 데이터 패리티를 유지하는 것이 좋습니다.

미러된 데이터베이스

주 지역의 미러된 데이터베이스는 고객에게 계속 사용할 수 없으며 설정은 보조 지역에 복제되지 않습니다. 지역 오류가 발생할 경우 복구하려면 다른 지역의 다른 작업 영역에서 미러된 데이터베이스를 다시 만들어야 합니다.

Data Factory

주 지역의 데이터 팩터리 항목은 여전히 고객이 사용할 수 없으며 데이터 파이프라인 또는 데이터 흐름 gen2 항목의 설정 및 구성은 보조 지역에 복제되지 않습니다. 하위 지역에서 오류가 발생할 경우 이러한 항목을 복구하려면 다른 하위 지역의 다른 작업 영역에서 데이터 통합 항목을 다시 만들어야 합니다. 다음 섹션에서 자세한 내용을 설명합니다.

데이터 흐름 Gen2

새 지역에서 데이터 흐름 Gen2 항목을 복구하려면 PQT 파일을 Git과 같은 버전 제어 시스템으로 내보낸 다음, 재해 발생 후 데이터 흐름 Gen2 콘텐츠를 수동으로 복구해야 합니다.

  1. 데이터 흐름 Gen2 항목의 파워 쿼리 편집기의 홈 탭에서 템플릿 내보내기를 선택합니다.

    템플릿 내보내기 옵션이 강조 표시된 파워 쿼리 편집기를 보여주는 스크린샷.

  2. 템플릿 내보내기 대화 상자에서 이 템플릿의 이름(필수) 및 설명(선택 사항)을 입력합니다. 완료하면 확인을 선택합니다.

    템플릿을 내보내는 방법을 보여주는 스크린샷.

  3. 재해가 발생한 후 새 작업 영역 "C2.W2"에 새 데이터 흐름 Gen2 항목을 만듭니다.

  4. 파워 쿼리 편집기의 현재 보기 창에서 파워 쿼리 템플릿에서 가져오기를 선택합니다.

    파워 쿼리 템플릿에서 가져오기가 강조 표시된 현재 보기를 보여주는 스크린샷.

  5. 열기 대화 상자에서 기본 다운로드 폴더로 이동하고 이전 단계에서 저장한 .pqt 파일을 선택합니다. 그런 다음, 열기를 선택합니다.

  6. 그런 다음, 템플릿을 새 데이터 흐름 Gen2 항목으로 가져옵니다.

데이터 파이프라인

고객은 하위 지역 재해 발생 시 데이터 파이프라인에 액세스할 수 없으며 구성은 쌍을 이루는 하위 지역에 복제되지 않습니다. 여러 하위 지역에 걸쳐 여러 작업 영역에서 중요한 데이터 파이프라인을 빌드하는 것이 좋습니다.

실시간 인텔리전스

이 가이드에서는 실시간 인텔리전스 환경에 대한 복구 절차를 안내합니다. KQL 데이터베이스/쿼리 세트 및 Eventstream을 다룹니다.

KQL 데이터베이스/쿼리 세트

KQL 데이터베이스/쿼리 세트 사용자는 하위 지역 수준 재해로부터 보호하기 위해 사전 조치를 취해야 합니다. 다음 접근 방식을 사용하면 하위 지역 수준 재해가 발생한 경우 KQL 데이터베이스 쿼리 세트의 데이터가 보호하고 이에 계속 액세스할 수 있습니다.

KQL 데이터베이스 및 쿼리 세트에 대한 효과적인 재해 복구 솔루션을 보장하려면 다음 단계를 사용합니다.

  1. 독립 KQL 데이터베이스 설정: 전용 Fabric 용량에 대해 둘 이상의 독립된 KQL 데이터베이스/쿼리 세트를 구성합니다. 복원력을 최대화하려면 두 개의 서로 다른 Azure 지역(기본적으로 Azure 쌍을 이루는 하위 지역)에 대해 이를 설정해야 합니다.

  2. 관리 활동 복제: 한 KQL 데이터베이스에서 수행된 모든 관리 작업은 다른 데이터베이스에 미러링되어야 합니다. 이렇게 하면 두 데이터베이스가 모두 동기화 상태로 유지됩니다. 복제할 주요 활동은 다음과 같습니다.

    • 테이블: 테이블 구조 및 스키마 정의가 데이터베이스 전체에서 일관되는지 확인합니다.

    • 매핑: 필요한 매핑을 복제합니다. 데이터 원본과 목적지가 올바르게 정렬되었는지 확인합니다.

    • 정책: 두 데이터베이스에 유사한 데이터 보존, 액세스 및 기타 관련 정책이 있는지 확인합니다.

  3. 인증 및 권한 부여 관리: 각 복제본에서 필요한 권한을 설정합니다. 보안 표준을 유지하면서 필요한 담당자에게 액세스 권한을 부여하여 적절한 권한 부여 수준이 설정되었는지 확인합니다.

  4. 병렬 데이터 수집: 데이터를 여러 하위 지역에서 일관되고 준비된 상태로 유지하려면 데이터를 수집하는 동시에 각 KQL 데이터베이스에 동일한 데이터 세트를 로드합니다.

Eventstream

Eventstream은 노코드 환경을 사용하여 실시간 이벤트를 캡처 및 변환하고 다양한 목적지(예: 레이크하우스, KQL 데이터베이스/쿼리 세트)로 라우팅하기 위한 Fabric 플랫폼의 중앙 집중식 위치입니다. 재해 복구에서 목적지를 지원하는 한 Eventstream에서는 데이터가 손실되지 않습니다. 따라서 고객은 해당 목적지 시스템의 재해 복구 기능을 사용하여 데이터 가용성을 보장해야 합니다.

고객은 다중 사이트 활성/활성 전략의 일환으로 여러 Azure 지역에 동일한 Eventstream 워크로드를 배포하여 지역 중복성을 달성할 수도 있습니다. 다중 사이트 활성/활성 접근 방식을 사용하면 고객은 배포된 모든 하위 지역에서 워크로드에 액세스할 수 있습니다. 이 방법은 재해 복구에 대한 가장 복잡하고 비용이 많이 드는 접근 방식이지만 대부분의 경우 복구 시간을 0에 가깝게 줄일 수 있습니다. 완전 지역 중복을 위해 고객은 다음을 수행할 수 있습니다.

  1. 다른 하위 지역에 데이터 원본의 복제본을 만듭니다.

  2. 해당 하위 지역에 Eventstream 항목을 만듭니다.

  3. 이러한 새 항목을 동일한 데이터 원본에 연결합니다.

  4. 서로 다른 하위 지역의 각 이벤트 스트림에 대해 동일한 대상을 추가합니다.