적용 대상: 
Azure Data Factory Azure Synapse Analytics
팁
기업용 올인원 분석 솔루션인 Microsoft Fabric의 Data Factory를 사용해 보세요. Microsoft Fabric은 데이터 이동부터 데이터 과학, 실시간 분석, 비즈니스 인텔리전스 및 보고에 이르기까지 모든 것을 다룹니다. 무료로 새 평가판을 시작하는 방법을 알아봅니다!
Azure Data Factory는 Microsoft의 클라우드 데이터 통합 및 ETL 서비스입니다. 이 문서에서는 데이터 팩터리의 DataOps에 대한 지침을 제공합니다. CI/CD, Git 또는 DevOps에 대한 완전한 자습서는 아닙니다. 대신 데이터 팩터리 배포 모범 사례, 팩터리 관리 및 거버넌스에 대한 자세한 구현 링크를 참조하여 서비스에서 DataOps를 달성하기 위한 데이터 팩터리 팀의 지침을 찾을 수 있습니다. 이 문서의 끝에는 자습서에 대한 링크가 있는 리소스 섹션이 있습니다.
DataOps란?
DataOps는 데이터 조직이 의사 결정론자에게 더 빠른 가치를 제공하기 위한 협업 데이터 관리를 위해 진행하는 프로세스입니다.
Gartner는 DataOps에 대해 이러한 명확한 정의를 제공합니다.
DataOps는 조직의 데이터 관리자와 데이터 소비자 간의 데이터 흐름에 대한 통신, 통합 및 자동화를 개선하는 데 초점을 맞춘 협업 데이터 관리 사례입니다. DataOps의 목표는 데이터, 데이터 모델 및 관련 아티팩트에서 예측 가능한 전달 및 변경 관리를 만들어 더 빠르게 가치를 제공하는 것입니다. DataOps는 기술을 사용하여 적절한 수준의 거버넌스로 데이터 전달의 설계, 배포 및 관리를 자동화하고 메타데이터를 사용하여 동적 환경에서 데이터의 유용성과 가치를 개선합니다.
Azure Data Factory에서 DataOps를 달성하려면 어떻게 해야 할까요?
Azure Data Factory는 데이터 엔지니어에게 클라우드 규모 데이터 통합 및 ETL 프로젝트를 쉽게 빌드할 수 있는 시각적 기반 데이터 파이프라인 패러다임을 제공합니다. 데이터 팩터리는 GitHub 및 Azure DevOps와 같은 완성도 높은 버전 제어 도구와의 네이티브 통합과 광범위한 Azure 에코시스템을 사용하여 풍부한 협업, 거버넌스 및 아티팩트 관계를 포함하며 DataOps를 용이하게 하는 많은 기본 제공 기능을 제공합니다.
특히 사용자 고유의 GitHub 또는 Azure DevOps 리포지토리를 데이터 팩터리로 가져오면 이 서비스는 커밋, 아티팩트 저장 및 버전 제어와 같은 일반적인 명령에 대한 간단한 기본 제공 UI 옵션을 제공합니다. 또한 이 서비스는 프로덕션 환경의 온전성과 상태를 보호하기 위해 CI/CD 및 코드 체크 인 모범 사례를 제공하는 옵션을 제공합니다.
Azure Data Factory "코드"
Azure Data Factory의 모든 아티팩트(파이프라인, 연결된 서비스, 트리거 등)에서 시각적 UI 통합 이면에는 JSON의 해당하는 "코드" 표현이 있습니다. 이러한 아티팩트는 Azure Resource Manager 템플릿 표준을 준수합니다. 캔버스의 오른쪽 위에 있는 대괄호 아이콘을 클릭하여 코드를 찾을 수 있습니다. 샘플 JSON "코드"는 다음과 같습니다.
라이브 모드 및 Git 버전 제어
파이프라인, 연결된 서비스 및 서비스 내에 저장된 트리거 정의를 비롯한 모든 팩터리에는 단일 데이터 소스(source of truth)가 있습니다. 이 데이터 소스(source of truth)는 파이프라인이 실행하는 항목과 트리거의 동작을 결정하는 항목입니다. 라이브 모드에 있는 경우 게시할 때마다 단일 데이터 소스(source of truth)를 직접 수정합니다. 다음 이미지는 라이브 모드일 때의 모두 게시 단추 모양을 보여 줍니다.
라이브 모드에서는 개발자가 코드 변경의 즉각적인 효과를 볼 수 있으므로 사이드 프로젝트에서 작업하는 단일 사용자에게 편리할 수 있습니다. 그러나 프로덕션 수준 작업 프로젝트에서 작업하는 개발자 팀에게는 권장되지 않습니다. 위험 요인으로는 입력 실수, 실수로 인한 중요 리소스 삭제, 테스트되지 않은 코드 게시 등이 있습니다. 중요 업무용 프로젝트 및 플랫폼에서 작업할 때 Git 리포지토리를 가져오고 데이터 팩터리에서 Git 모드를 사용하여 개발 프로세스를 간소화하는 것이 좋습니다. Git 모드의 버전 제어 및 제어된 체크 인 기능은 터치 라이브 모드와 직접적으로 관련된 대부분의 사고를 방지하는 데 도움이 됩니다.
참고 항목
Git 모드에서는 게시 또는 모두 게시 단추가 저장 또는 모두 저장으로 바뀌고 변경 내용은 라이브 코드베이스를 직접 변경하지 않고 자체 분기에 커밋됩니다.
GitHub 및 Azure DevOps 통합 설정
Azure Data Factory에서는 GitHub 또는 Azure DevOps에 리포지토리를 저장하는 것이 좋습니다. 이 서비스는 두 가지 방법을 모두 완전히 지원하며, 사용할 리포지토리 선택은 개별 조직 표준에 따라 달라집니다. 새 리포지토리를 설정하거나 기존 리포지토리에 연결하는 방법에는 두 가지 방법이 있습니다. 하나는 Azure Portal을 사용하는 것이고 다른 하나는 Azure Data Factory Studio UI에서 만드는 것입니다.
Azure Portal 팩터리 만들기
Azure Portal에서 새 데이터 팩터리를 만들 때 기본 Git 리포지토리는 Azure DevOps입니다. GitHub를 리포지토리로 선택하고 리포지토리 설정을 구성할 수도 있습니다.
Azure Portal에서 리포지토리 유형을 선택하고 리포지토리 및 분기 이름을 입력하여 기본적으로 Git과 통합된 새 팩터리를 만듭니다.
조직에서 Azure Policy에 Git 사용 적용
Azure Data Factory 프로젝트에서 Git을 사용하는 것이 좋습니다. 완전한 CI/CD 프로세스를 구현하지 않더라도 ADF와의 Git 통합을 사용하면 리소스 아티팩트를 자체 샌드박스 환경(Git 분기)에 저장하여 나머지 팩터리 분기와 독립적으로 변경 내용을 테스트할 수 있습니다. Azure Policy를 사용하여 조직 팩터리에서 Git 사용을 적용할 수 있습니다.
Azure Data Factory Studio
데이터 팩터리를 만든 후 Azure Data Factory Studio를 통해 리포지토리에 연결할 수도 있습니다. 관리 탭에 리포지토리 및 리포지토리 설정을 구성하는 옵션이 표시됩니다.
단계별 프로세스를 통해 선택한 리포지토리를 쉽게 구성하고 연결하는 데 도움이 되는 일련의 단계를 안내합니다. 완전히 설정되면 협업을 시작하고 리소스를 리포지토리에 저장할 수 있습니다.
연속 통합 및 지속적인 업데이트(CI/CD)
CI/CD는 개발, 테스트, 스테이징 등 다양한 단계를 거치면서 변경 내용을 검사하고 테스트하는 코드 개발의 패러다임입니다. 각 단계를 통해 검토하고 테스트한 후에는 프로덕션 환경의 라이브 코드베이스에 게시됩니다.
CI(연속 통합)는 개발자가 코드베이스를 변경할 때마다 자동으로 테스트하고 유효성을 검사하는 방법입니다. CD(지속적인 업데이트)는 연속 통합 테스트가 성공하면 변경 내용이 다음 단계에 지속적으로 적용됨을 의미합니다.
앞에서 간략하게 설명한 것처럼 Azure Data Factory의 "코드"는 Azure Resource Manager 템플릿 JSON 형식을 사용합니다. 따라서 CI/CD(연속 통합 및 지속적인 업데이트) 프로세스를 거치는 변경 내용은 JSON Blob에 대한 추가, 삭제 및 편집으로 구성됩니다.
파이프라인은 Azure Data Factory에서 실행됩니다.
Azure Data Factory의 CI/CD에 대해 이야기하기 전에 먼저 서비스가 파이프라인을 실행하는 방법을 논의해야 합니다. 데이터 팩터리는 파이프라인을 실행하기 전에 다음 작업을 수행합니다.
- 파이프라인의 최근에 게시된 정의와 데이터 세트, 연결된 서비스 등과 같은 관련 자산을 끌어옵니다.
- 작업으로 컴파일합니다. 데이터 팩터리에서 최근에 실행한 경우 캐시된 컴파일에서 작업을 검색합니다.
- 파이프라인을 실행합니다.
파이프라인을 실행하면 다음 단계가 진행됩니다.
- 서비스는 파이프라인 정의의 특정 시점 스냅샷을 만듭니다.
- 파이프라인 기간 동안 정의는 변경되지 않습니다.
- 파이프라인이 오랫동안 실행되더라도 파이프라인이 시작된 후 수행된 후속 변경 내용의 영향을 받지 않습니다. 실행 중에 연결된 서비스, 파이프라인 등에 변경 내용을 게시해도 진행 중인 실행에는 영향을 미치지 않습니다.
- 변경 내용을 게시할 때 게시 후 시작된 후속 실행은 업데이트된 정의를 사용합니다.
Azure Data Factory에 게시
게시를 자동화하기 위해 Azure 릴리스 파이프라인을 사용하여 파이프라인을 배포하든, Resource Manager 템플릿의 수동 배포를 통해 파이프라인을 배포하든 관계없이 백 엔드에서 게시는 각 아티팩트의 데이터 세트, 연결된 서비스, 파이프라인 및 트리거에 대한 일련의 만들기/업데이트 작업입니다. 효과는 기본 Rest API 호출을 직접 만드는 경우와 같습니다.
이러한 작업의 몇 가지 사항은 다음과 같습니다.
- 이러한 모든 API 호출은 동기적입니다. 즉, 게시가 성공/실패할 때만 호출이 반환됩니다. 아티팩트의 부분 배포에 대한 상태는 없습니다.
- API 호출은 대체적으로 순차적입니다. 아티팩트의 참조 종속성을 유지하면서 호출을 병렬화하려고 합니다. 배포 순서는 연결된 서비스 -> 데이터 세트/통합 런타임 -> 파이프라인 -> 트리거입니다. 이 순서는 종속 아티팩트가 해당 종속성을 제대로 참조할 수 있도록 합니다. 예를 들어 파이프라인은 데이터 세트에 따라 달라지므로 데이터 팩터리는 데이터 세트 다음에 파이프라인을 배포합니다.
- 연결된 서비스, 데이터 세트 등의 배포는 파이프라인과는 별개입니다. 파이프라인 업데이트 전에 데이터 팩터리가 연결된 서비스를 업데이트하는 경우가 있습니다. 트리거를 중지하는 시점 섹션에서 이 상황에 대해 설명합니다.
- 배포할 경우 팩터리에서 아티팩트가 삭제되지 않습니다. 팩터리를 정리하기 위해 각 아티팩트 유형(파이프라인, 데이터 세트, 연결된 서비스 등)에 대해 삭제 API를 명시적으로 호출해야 합니다. 예를 들어 Azure Data Factory에서 배포 후 샘플 스크립트를 참조하세요.
- 파이프라인, 데이터 세트 또는 연결된 서비스를 사용하지 않더라도 팩터리에 대한 빠른 업데이트 API 호출이 여전히 진행됩니다.
트리거 게시
- 트리거의 상태는 시작됨 또는 중지됨입니다.
- 시작됨 모드에서는 트리거를 변경할 수 없습니다. 변경 내용을 게시하기 전에 트리거를 중지해야 합니다.
- 시작됨 모드에서 트리거에 대해 트리거 만들기 또는 업데이트 API를 호출할 수 있습니다.
- 페이로드가 변경되면 API가 실패합니다.
- 페이로드가 변경되지 않은 상태로 유지되면 API가 성공합니다.
- 이 동작은 트리거를 중지해야 하는 시점에 큰 영향을 미칩니다.
트리거를 중지해야 하는 시점
항상 라이브 트리거가 파이프라인 실행을 시작하도록 하여 프로덕션 데이터 팩터리에 배포하는 경우 "중지해야 하나요?"라는 질문이 발생합니다.
짧은 대답은 다음과 같은 몇 가지 시나리오에서만 트리거 중지를 고려해야 한다는 것입니다.
- 종료 날짜, 빈도 및 파이프라인 연결과 같은 필드를 포함하여 트리거 정의를 업데이트하는 경우 트리거를 중지해야 합니다.
- 라이브 파이프라인에서 참조되는 데이터 세트 또는 연결된 서비스를 업데이트하는 경우 트리거를 중지하는 것이 좋습니다. 예를 들어 SQL Server에 대한 자격 증명을 순환하는 경우가 여기에 해당합니다.
- 연결된 파이프라인이 오류를 throw하고 실패하며, 서버에 부하를 발생시키는 경우 트리거를 중지하도록 선택할 수 있습니다.
트리거 중지와 관련하여 고려해야 할 몇 가지 사항은 다음과 같습니다.
- Azure Data Factory에서 파이프라인 실행 섹션에 설명된 대로 트리거가 파이프라인 실행을 시작할 때 파이프라인, 데이터 세트, 통합 런타임 및 연결된 서비스 정의의 스냅샷을 만듭니다. 변경 내용이 백 엔드에 채워지기 전에 파이프라인이 실행되는 경우 트리거는 이전 버전으로 실행되기 시작합니다. 대부분의 경우에는 괜찮을 것입니다.
- 게시 트리거 섹션에 설명된 대로 트리거가 시작됨 상태이면 업데이트할 수 없습니다. 따라서 트리거 정의에 대한 세부 정보를 변경해야 하는 경우 변경 내용을 게시하기 전에 트리거를 중지합니다.
- Azure Data Factory에 게시 섹션에 설명된 대로 파이프라인이 변경되기 전에 데이터 세트 또는 연결된 서비스에 대한 수정 내용이 게시됩니다. 파이프라인 실행이 올바른 자격 증명을 사용하고 올바른 서버와 통신하도록 하려면 연결된 트리거도 중지하는 것이 좋습니다.
"코드" 변경 준비
끌어오기 요청에 대해 이러한 모범 사례를 따르는 것이 좋습니다.
- 각 개발자는 고유한 개별 분기에서 작업해야 하며, 하루가 끝나면 리포지토리의 기본 분기에 대한 끌어오기 요청을 만들어야 합니다. GitHub 및 DevOps에서 끌어오기 요청에 대한 자습서를 참조하세요.
- 게이트 키퍼가 끌어오기 요청을 승인하고 변경 내용을 기본 분기에 병합하면 CI/CD 프로세스가 시작될 수 있습니다. 환경 전체에서 제안되는 변경 내용 승격 방법에는 자동화 및 수동의 두 가지가 있습니다.
- CI/CD 파이프라인을 시작할 준비가 되면 일반적으로 Azure Pipeline 릴리스를 사용하여 이 작업을 수행하거나 Azure Player의 이 오픈 소스 유틸리티를 사용하여 특정 개별 파이프라인을 배포할 수 있습니다.
변경 내용의 자동화된 배포
자동화된 배포를 지원하려면 Azure Data Factory 유틸리티 npm 패키지를 사용하는 것이 좋습니다. npm 패키지를 사용하면 파이프라인의 모든 리소스에 대한 유효성을 검사하고 사용자에 대한 ARM 템플릿을 생성할 수 있습니다.
Azure Data Factory 유틸리티 npm 패키지를 시작하려면 연속 통합 및 지속적인 업데이트에 대한 자동화된 게시를 참조하세요.
변경 내용 수동 배포
분기를 Git 리포지토리의 기본 협업 분기에 다시 병합한 후 라이브 Azure Data Factory 서비스에 변경 내용을 수동으로 게시할 수 있습니다. 이 서비스는 게시 사용 안 함(ADF Studio) 옵션을 사용하여 비개발 팩터리에서 게시에 대한 UI 컨트롤을 제공합니다.
선택적 배포
선택적 배포는 체리 피킹이라고 하는 GitHub 및 Azure DevOps의 기능을 사용합니다. 이 기능을 사용하면 특정 변경 내용만 배포할 수 있고 다른 변경 내용은 배포할 수 없습니다. 예를 들어 한 개발자가 여러 파이프라인을 변경했지만 오늘 진행하는 배포에서는 하나의 파이프라인에만 변경 내용을 배포하려고 할 수 있습니다.
Azure DevOps 및 GitHub의 자습서에 따라 필요한 파이프라인과 관련된 커밋을 선택합니다. 파이프라인과 연결된 트리거, 연결된 서비스 및 종속성에 대한 관련 변경 내용을 포함하여 모든 변경 내용이 체리 피킹되었는지 확인합니다.
변경 내용을 체리 피킹하고 기본 협업 파이프라인에 병합한 후에는 제안된 변경 내용에 대한 CI/CD 프로세스를 시작할 수 있습니다. 이 문서의 자동화된 테스트 섹션에 설명된 대로 선택적 배포를 위해 외부 프레임워크를 핫픽스, 체리 피킹 또는 활용하는 방법에 대한 추가 정보를 확인합니다.
단위 테스트
단위 테스트는 새 파이프라인을 개발하거나 기존 데이터 팩터리 아티팩트를 편집하는 프로세스의 중요한 부분으로, 코드의 구성 요소를 테스트하는 데 중점을 둡니다. Data Factory를 사용하면 파이프라인 디버그 기능을 사용하여 파이프라인 및 데이터 흐름 아티팩트 수준에서 개별 단위 테스트를 수행할 수 있습니다.
데이터 흐름을 개발할 때는 데이터 미리 보기 기능을 통해 프로덕션에 변경 내용을 배포하기 전에 단위 테스트를 수행하여 각 개별 변환 및 코드 변경에 대한 인사이트를 얻을 수 있습니다.
이 서비스는 Azure Data Factory에서 디버깅 및 단위 테스트를 수행할 때 UI의 파이프라인 활동에 대한 라이브 및 대화형 피드백을 제공합니다.
자동화된 테스트
Azure Data Factory에서 사용할 수 있는 자동화된 테스트에 대해 몇 가지 도구를 사용할 수 있습니다. 이 서비스는 서비스의 개체를 JSON 엔터티로 저장하므로 Visual Studio에서 오픈 소스 .NET 단위 테스트 프레임워크 NUnit을 사용하는 것이 편리할 수 있습니다. 공장에 대한 자동화된 단위 테스트 환경을 설정하는 방법에 대한 자세한 설명을 제공하는 Azure Data Factory에 대한 자동화된 테스트 설정 게시물을 참조하세요. (이 블로그를 사용하도록 허가해 주신 Richard Swinbank에게 특별히 감사드립니다.)
고객은 사전 배포 및 사후 배포 단계, CI/CD 프로세스의 일부로 PowerShell 또는 AZ CLI를 사용하여 TEST 파이프라인을 실행할 수도 있습니다.
데이터 팩터리의 주요 강점은 데이터 세트의 매개 변수화에 있습니다. 이 기능을 사용하면 고객이 서로 다른 데이터 세트로 동일한 파이프라인을 실행하여 새 개발이 모든 원본 및 대상 요구 사항을 충족하는지 확인할 수 있습니다.
Azure Data Factory를 위한 기타 CI/CD 프레임워크
앞에서 설명한 대로 병합, 분기, 비교 및 게시를 비롯한 기본 제공 Git 통합은 기본적으로 Azure Data Factory UI를 통해 사용할 수 있습니다. 그러나 Azure 커뮤니티에서 널리 사용되는 유용한 CI/CD 프레임워크 중에서 유사한 기능의 대체 메커니즘을 제공하는 다른 프레임워크가 있습니다. Azure Data Factory Git 방법론은 ARM 템플릿을 기준으로 하지만, Kamil Nowinski의 ADFTools와 같은 프레임워크는 대신 공장의 개별 JSON 아티팩트를 사용하여 다른 접근 방식을 따릅니다. (서비스가 기본적으로 제공하는 ARM 기반 UI 접근 방식과는 달리) Azure DevOps에 능숙하고 해당 환경에서 작업하는 것을 선호하는 데이터 엔지니어는 이 프레임워크가 부분 배포와 같은 일반적인 시나리오에서 잘 작동한다는 것을 알 수 있습니다. 또한 이 프레임워크는 트리거 상태를 실행하는 환경에 배포할 때 트리거의 처리를 간소화할 수 있습니다.
Azure Data Factory의 데이터 거버넌스
효과적인 DataOps의 중요한 측면은 데이터 거버넌스입니다. 데이터 통합 ETL 도구의 경우 데이터 계보 및 아티팩트 관계를 제공하면 데이터 엔지니어가 다운스트림 변경의 영향을 이해하는 데 중요한 정보를 제공할 수 있습니다. Data Factory는 팩터리 구현을 구성하는 기본 제공 관련 아티팩트 뷰를 제공합니다.
Microsoft Purview와 기본적으로 통합되므로 계보, 영향 분석 및 데이터 카탈로그가 추가로 제공됩니다.
Microsoft Purview는 온-프레미스, 다중 클라우드, SaaS(Software-as-a-Service) 데이터를 관리 및 제어할 수 있게 도와주는 통합 데이터 거버넌스 솔루션을 제공합니다. 이를 통해 자동화된 데이터 검색, 중요한 데이터 분류 및 종단 간 데이터 계보를 사용하여 데이터 환경의 전체적인 최신 맵을 쉽게 만들 수 있습니다. 이러한 기능은 데이터 소비자가 중요하고 신뢰할 수 있는 데이터 관리에 액세스할 수 있도록 합니다.
Purview Data Catalog와 기본적으로 통합되는 데이터 팩터리는 조직의 데이터 자산 전체에서 데이터 통합 파이프라인에 사용할 데이터 자산을 쉽게 검색할 수 있습니다.
Azure Data Factory Studio의 기본 검색 창을 사용하여 Purview 카탈로그에서 데이터 자산을 찾을 수 있습니다.
