Azure에서 클라우드 기반 분석을 확장

확장 가능한 데이터 플랫폼은 데이터의 급속한 증가를 수용하는 데 매우 중요합니다. 전 세계에서 1초마다 방대한 양의 데이터가 생성됩니다. 사용 가능한 데이터의 양은 향후 몇 년 동안 기하급수적으로 증가할 것으로 예상됩니다. 데이터 생성 속도가 증가함에 따라 데이터 이동 속도도 증가합니다.

데이터 양에 관계없이 사용자는 빠른 쿼리 응답을 요구합니다. 그들은 결과를 위해 시간이 아닌 몇 분을 기다릴 것으로 예상합니다. 이 문서에서는 Azure 클라우드 규모 분석 솔루션의 크기를 조정하고 속도에 대한 사용자 요구를 계속 충족하는 방법을 설명합니다.

소개

많은 기업에는 대규모 데이터 플랫폼 모놀리스가 있습니다. 이러한 모놀리식은 단일 Azure Data Lake Gen2 계정 및 경우에 따라 단일 스토리지 컨테이너를 중심으로 빌드됩니다. 단일 Azure 구독은 종종 모든 데이터 플랫폼 관련 작업에 사용됩니다. 대부분의 아키텍처 플랫폼에는 구독 수준 크기 조정이 결여되어 있어, 사용자가 Azure 구독 또는 서비스 수준 제한에 부딪히게 될 경우 지속적인 Azure 도입에 걸림돌이 될 수 있습니다. 일부 제약 조건은 완화된 제한이지만, 이러한 제한에 도달하게 되면 데이터 플랫폼에 상당한 부정적인 영향을 줄 수 있습니다.

데이터 플랫폼을 구성할 때 조직의 구조를 고려합니다. 팀의 데이터 소유권 및 기능적 책임에 유의하세요. 조직에서 팀에게 대량의 자율성 및 분산 소유권을 제공하는 경우 데이터 메시 아키텍처를 사용하는 것이 가장 좋습니다.

수집, 정리, 집계 및 봉사와 같은 다양한 솔루션 작업을 서로 다른 팀이 담당하는 상황을 방지합니다. 여러 팀에 의존하면 큰 속도 저하를 초래할 수 있습니다. 예를 들어 서비스 계층의 데이터 소비자가 새 데이터 자산을 온보딩하거나 특정 데이터 자산에 대한 기능 변경을 구현해야 하는 경우 다단계 프로세스를 거쳐야 합니다. 이 예제의 단계는 다음과 같습니다.

1. 데이터 소비자는 데이터 파이프라인 단계를 담당하는 모든 팀에 티켓을 제출합니다.
2. 계층이 상호 연결되므로 팀은 동기화된 상태로 함께 작업해야 합니다. 새 서비스에는 데이터 정리 계층을 변경해야 하므로 데이터 집계 계층이 변경되어 서비스 계층이 변경됩니다. 변경 내용은 모든 파이프라인 단계에 영향을 줄 수 있습니다.
3. 팀들은 전 과정의 수명 주기에 대한 개요가 없기 때문에 처리 변화의 잠재적 영향을 파악하기 어렵습니다. 기존 소비자 및 파이프라인에 미치는 영향을 최소화하는 잘 정의된 릴리스 계획을 설계하려면 함께 작업해야 합니다. 이 종속성 관리는 관리 오버헤드를 증가합니다.
4. 일반적으로 팀은 데이터 소비자가 요청한 데이터 자산에 대한 분야 전문가가 아닙니다. 새 데이터 세트 기능 또는 매개 변수 값을 이해하려면 전문가와 상의해야 합니다.
5. 모든 변경 내용이 구현되면 데이터 소비자에게 새 데이터 자산을 사용할 준비가 되었다는 알림이 표시됩니다.

각 대규모 조직에는 수천 명의 데이터 소비자가 있습니다. 중앙 집중식 팀이 사업부에 병목 현상을 일으키기 때문에 설명한 것과 같은 복잡한 프로세스는 대규모 아키텍처에서의 속도를 심각하게 감소시킵니다. 그 결과 혁신이 줄어들고 효율성이 제한됩니다. 잠재적으로 사업부는 서비스를 종료하고 대신 자체 데이터 플랫폼을 빌드하도록 결정할 수 있습니다.

크기 조정 방법

클라우드 규모 분석은 다음 두 가지 핵심 개념을 사용하여 크기 조정 문제를 해결합니다.

• 크기 조정을 위한 데이터 랜딩 존
• 데이터 소유권의 분산화를 가능하게 하기 위한 데이터 제품 및 데이터 통합을 통해 확장성을 지원합니다.

단일 데이터 랜딩 존 또는 여러 데이터 랜딩 존을 배포할 수 있습니다. 데이터 랜딩 존을 사용하면 데이터 관리 랜딩 존에 연결하여 데이터를 검색하고 관리할 수 있습니다. 각 데이터 관리 랜딩 존은 단일 Azure 구독 내에 있습니다.

구독은 Azure의 관리, 청구 및 규모 단위입니다. 대규모 Azure 채택 계획에서 중요한 역할을 합니다.

데이터 랜딩 존을 사용하여 크기 조정

클라우드 규모 분석의 중심 개념은 Microsoft Purview, Azure Databricks를 사용하는 경우의 Azure Databricks Unity 카탈로그, 데이터 관리 랜딩 존, 그리고 데이터 랜딩 존입니다. 각각 별도의 Azure 구독에 배치해야 합니다. 이를 분리하면 의무를 명확하게 구분하고, 최소 권한 원칙을 따르고, 앞에서 언급한 구독 규모 문제를 부분적으로 해결할 수 있습니다. 최소한의 클라우드 규모 분석 설정에는 단일 데이터 랜딩 존과 단일 데이터 관리 랜딩 존이 포함됩니다.

그러나 대규모 데이터 플랫폼 배포에는 최소한의 설정만으로는 충분하지 않습니다. 기업은 대규모 플랫폼을 구축하고 시간이 지남에 따라 데이터 및 분석 노력을 일관되고 효율적으로 확장하기 위해 투자합니다. 구독 수준 제한을 극복하기 위해 클라우드 규모 분석은 Azure 랜딩 존설명한 대로 구독을 크기 조정 단위로 사용합니다. 이 기술을 사용하면 아키텍처에 더 많은 데이터 랜딩 존을 추가하여 데이터 플랫폼 공간을 늘릴 수 있습니다. 또한 이 기술을 채택하면 각 데이터 랜딩 존에 3개의 데이터 레이크가 포함되어 있기 때문에 전체 조직에 사용되는 하나의 Azure Data Lake Gen2 문제가 해결됩니다. 여러 도메인의 프로젝트 및 활동을 둘 이상의 Azure 구독에 분산하여 확장성을 높일 수 있습니다.

클라우드 규모 분석 아키텍처를 구현하기 전에 조직에 필요한 데이터 랜딩 존 수를 결정합니다. 올바른 솔루션을 선택하면 효과적이고 효율적인 데이터 플랫폼의 기반이 형성됩니다.

필요한 데이터 랜딩 존의 수는 특히 다음과 같은 여러 요인에 따라 달라집니다.

• 조직 조정(예: 자체 데이터 랜딩 존이 필요한 사업부 수)
• 운영상의 고려 사항에는 조직에서 운영 리소스를 정렬하고 사업부 특정 리소스를 조정하는 방법이 포함됩니다.

올바른 데이터 랜딩 존 모델을 사용하면 데이터 제품 및 데이터 자산을 한 랜딩 존에서 다른 랜딩 존으로 이동하려는 향후 노력이 최소화됩니다. 또한 향후 빅 데이터 및 분석 활동을 효과적이고 일관되게 확장하는 데 도움이 됩니다.

배포할 데이터 랜딩 존 수를 결정할 때 다음 요소를 고려합니다.

데이터 메시 아키텍처를 구현하는 경우 데이터 랜딩 존 및 데이터 도메인을 배포하는 방법을 결정할 때 다음 요소를 고려합니다.

구독에 대한 클라우드 채택 프레임워크 지침에서 더 많은 고려 사항을 찾을 수 있습니다.

많은 조직에서는 엔터프라이즈 데이터 플랫폼의 효율적인 크기 조정을 원합니다. 사업부는 고유한 요구 사항을 충족하기 위해 자체 데이터 솔루션 및 애플리케이션을 빌드할 수 있어야 합니다. 이 기능을 제공하는 것은 많은 기존 데이터 플랫폼이 확장성 및 탈중앙화 소유권 개념을 기반으로 구축되지 않기 때문에 어려울 수 있습니다. 이러한 단점은 이러한 데이터 플랫폼의 아키텍처, 팀 구조 및 ops 모델에서 명확하게 확인할 수 있습니다.

데이터 랜딩 존은 조직 내에서 데이터 고립 현상을 만들지 않습니다. 클라우드 규모 분석에 권장되는 네트워크 설정을 사용하면 랜딩 존 간에 안전하고 현재 위치의 데이터 공유가 가능하므로 데이터 도메인 및 사업부 간에 혁신이 가능합니다. 자세한 내용은 네트워크 아키텍처 고려 사항을 참조하세요.

ID 계층도 마찬가지입니다. 단일 Microsoft Entra 테넌트를 사용하는 경우 ID에 여러 데이터 랜딩 존의 데이터 자산에 대한 액세스 권한을 부여할 수 있습니다. 사용자 및 ID 권한 부여 프로세스에 대한 자세한 내용은 데이터 액세스 관리참조하세요.

클라우드 규모 분석은 공통 아키텍처를 사용하여 일관된 거버넌스를 옹호합니다. 아키텍처는 기준 기능 및 정책을 정의합니다. 모든 데이터 랜딩 존은 동일한 감사 및 제어를 준수합니다. 팀은 데이터 파이프라인을 만들고, 원본을 수집하고, 보고서 및 대시보드와 같은 데이터 제품을 만들 수 있습니다. 팀은 필요에 따라 Spark/SQL 분석을 수행할 수도 있습니다. 정책의 기능에 서비스를 추가하여 데이터 랜딩 존 기능을 보강할 수 있습니다. 예를 들어 팀은 비즈니스 요구 사항을 해결하기 위해 타사 그래프 엔진을 추가할 수 있습니다.

클라우드 규모 분석은 중앙 카탈로그 및 분류에 중점을 두어 데이터를 보호하고 다양한 그룹이 데이터 제품을 검색할 수 있도록 합니다.

클라우드 규모 분석 아키텍처와 데이터 랜딩 존의 개념을 통해 조직은 시간이 지남에 따라 데이터 플랫폼의 크기를 쉽게 늘릴 수 있습니다. 단계적 접근 방식에서 더 많은 데이터 랜딩 존을 추가할 수 있습니다. 고객은 처음에는 여러 랜딩 존을 가질 필요가 없습니다. 이 아키텍처를 채택할 때는 몇 가지 데이터 랜딩 존 및 해당 영역에 포함된 데이터 제품의 우선 순위를 지정합니다. 적절한 우선 순위를 지정하면 클라우드 규모 분석 배포의 성공을 보장하는 데 도움이 됩니다.

데이터 애플리케이션을 사용하여 크기 조정

각 랜딩 존 내에서 조직은 데이터 애플리케이션을 사용하여 크기를 조정할 수 있습니다. 데이터 애플리케이션은 다른 데이터 애플리케이션에서 사용할 수 있도록 읽기 최적화 데이터 제품을 제공하는 기능을 캡슐화하는 데이터 아키텍처의 단위 또는 구성 요소입니다. Azure에서 데이터 애플리케이션은 기능 간 팀이 데이터 솔루션 및 워크로드를 구현할 수 있도록 하는 리소스 그룹 형태의 환경입니다. 관련 팀은 수집, 정리, 집계 및 서비스 작업을 포함하는 데이터 솔루션의 종단 간 수명 주기를 처리합니다.

클라우드 규모 분석은 앞에서 설명한 데이터 통합 및 책임 문제를 해결합니다. 참조 디자인은 테이블 수집 및 원본 시스템 통합에 대한 모놀리식 기능 책임 대신 데이터 도메인에 의해 구동되는 분산 아키텍처를 제공합니다. 부서간 업무 팀은 데이터 범위에 대한 엔드 투 엔드 기능 책임 및 소유권을 담당합니다.

중앙 집중식 기술 스택과 데이터 처리 워크플로의 모든 작업을 담당하는 팀이 있는 대신, 여러 자율적인 기능 간 데이터 통합 팀에 엔드 투 엔드 책임을 분산할 수 있습니다. 각 팀은 도메인 또는 하위 도메인 기능을 소유하며 데이터 소비자가 요구하는 대로 데이터 세트를 제공하는 것이 좋습니다.

이러한 아키텍처 차이로 인해 데이터 플랫폼의 속도가 향상됩니다. 데이터 소비자는 더 이상 중앙 집중식 팀 집합에 의존하거나 요청된 변경 내용의 우선 순위를 정하기 위해 싸울 필요가 없습니다. 소규모 팀이 엔드 투 엔드 통합 워크플로의 소유권을 맡을수록 데이터 공급자와 데이터 소비자 간의 피드백 루프가 짧아집니다. 이 방법을 사용하면 우선 순위가 더 빨라지고 개발 주기가 빨라지고 개발 프로세스가 더 민첩해집니다. 부서간 데이터 통합 팀이 엔드 투 엔드 기술 스택과 변경의 의미를 완전히 인식하므로 팀은 더 이상 프로세스와 릴리스 계획을 동기화할 필요가 없습니다. 소프트웨어 엔지니어링 사례를 사용하여 단위 및 통합 테스트를 실행하여 소비자에게 미치는 전반적인 영향을 최소화할 수 있습니다.

이상적으로는 데이터 통합 시스템을 소유하는 팀도 원본 시스템을 소유합니다. 이 팀은 원본 시스템에서 작업하는 데이터 엔지니어, 데이터 세트에 대한 실무 전문가(SME), 클라우드 엔지니어 및 데이터 제품 소유자로 구성되어야 합니다. 이러한 종류의 부서간 업무 팀을 구축하면 외부 팀과의 통신 양이 줄어들고 인프라에서 실제 데이터 파이프라인으로 전체 스택을 개발하는 동안 필수적입니다.

데이터 플랫폼의 기반은 원본 시스템에서 통합된 데이터 세트입니다. 이러한 데이터 세트를 사용하면 데이터 제품 팀이 비즈니스 팩트 테이블에서 혁신하고 의사 결정 및 비즈니스 프로세스를 개선할 수 있습니다. 데이터 통합 팀과 데이터 제품 팀은 소비자에게 SLA를 제공하고 모든 계약이 충족되는지 확인해야 합니다. 제공된 SLA는 데이터 품질, 타임라인, 오류 비율, 가동 시간 및 기타 작업과 관련이 있을 수 있습니다.

요약

클라우드 규모 분석 아키텍처의 크기 조정 메커니즘을 사용하면 조직은 일반적인 기술적 제한을 피하면서 시간이 지남에 따라 Azure 내에서 데이터 자산을 확장할 수 있습니다. 이 문서에 설명된 두 가지 크기 조정 방법은 서로 다른 기술적 복잡성을 극복하는 데 도움이 되며 간단하고 효율적인 방법으로 사용할 수 있습니다.

다음 단계