Azure에서 클라우드 규모 분석 스케일링
확장성 있는 데이터 플랫폼은 기업이 급격하게 증가하는 데이터를 수용하는 데 매우 중요합니다. 전 세계에서 매초 엄청난 양의 데이터가 생성됩니다. 향후 몇 년 동안 생성되는 데이터의 양이 기하급수적으로 증가할 것으로 예상됩니다. 데이터 생성 속도가 빨라질수록 데이터 이동 속도도 빨라집니다.
데이터 양에 관계없이 사용자는 빠른 쿼리 응답을 요구합니다. 사용자는 몇 시간이 아닌 몇 분 안에 결과를 얻기를 기대합니다. 이 문서에서는 Azure 클라우드 규모 분석 솔루션의 크기를 조정하고 속도에 대한 사용자 요구를 계속 충족하는 방법을 설명합니다.
소개
많은 기업에는 대규모 데이터 플랫폼 모놀리스가 있습니다. 이러한 모놀리식은 단일 Azure Data Lake Gen2 계정, 때로는 단일 스토리지 컨테이너를 중심으로 빌드됩니다. 단일 Azure 구독은 모든 데이터 플랫폼 관련 작업에 자주 사용됩니다. 대부분의 아키텍처 플랫폼에는 구독 수준 스케일링이 없으며, 이는 사용자가 Azure 구독 또는 서비스 수준 제한에 도달할 때 지속적인 Azure 채택을 방해할 수 있습니다. 일부 제약 조건은 소프트 제한이지만 제약 조건에 도달하면 데이터 플랫폼에 상당한 부정적인 영향을 줄 수 있습니다.
데이터 플랫폼을 구성할 때 조직의 구조를 고려합니다. 팀의 데이터 소유권 및 기능적 책임에 유의하세요. 조직에서 팀에게 높은 수준의 자율성과 분산 소유권을 제공하는 경우 데이터 메시 아키텍처가 가장 좋은 옵션입니다.
수집, 클린sing, 집계 및 봉사와 같은 솔루션의 다양한 작업을 담당하는 다른 팀이 있는 상황을 방지합니다. 여러 팀에 따라 속도가 크게 저하될 수 있습니다. 예를 들어 서비스 계층의 데이터 소비자가 새 데이터 자산을 온보딩하거나 특정 데이터 자산에 대한 기능 변경을 구현해야 하는 경우 다단계 프로세스를 거쳐야 합니다. 이 예제의 단계는 다음과 같습니다.
- 데이터 소비자는 데이터 파이프라인 단계를 담당하는 모든 팀에 티켓을 제출합니다.
- 계층이 상호 연결되므로 팀은 동기화된 상태로 함께 작업해야 합니다. 새 서비스에는 데이터 클린sing 계층을 변경해야 하므로 데이터 집계 계층이 변경되어 서비스 계층이 변경됩니다. 변경 내용은 모든 파이프라인 단계에 영향을 줄 수 있습니다.
- 전체 종단 간 수명 주기에 대한 개요가 없으므로 팀에서 변경 내용 처리의 잠재적 효과를 보기가 어렵습니다. 기존 소비자 및 파이프라인에 미치는 영향을 최소화하는 잘 정의된 릴리스 계획을 설계하려면 함께 작업해야 합니다. 이 종속성 관리는 관리 오버헤드를 증가시킵니다.
- 일반적으로 팀은 데이터 소비자가 요청하는 데이터 자산에 대한 전문가의 대상이 아닙니다. 새 데이터 세트 기능 또는 매개 변수 값을 이해하려면 전문가에게 문의해야 합니다.
- 모든 변경 내용이 구현되면 데이터 소비자에게 새 데이터 자산을 사용할 준비가 되었다는 알림이 표시됩니다.
각 대규모 조직에는 수천 명의 데이터 소비자가 있습니다. 중앙 집중식 팀이 사업부의 병목 현상이 되기 때문에 설명한 것과 같은 복잡한 프로세스는 대규모 아키텍처의 속도를 심각하게 감소합니다. 그 결과 혁신이 줄어들고 효율성이 제한됩니다. 잠재적으로 사업부는 서비스를 종료하고 대신 자체 데이터 플랫폼을 빌드하도록 결정할 수 있습니다.
스케일링 방법
클라우드 규모 분석은 다음 두 가지 핵심 개념을 사용하여 크기 조정 문제를 해결합니다.
- 크기 조정을 위해 데이터 랜딩 존 사용
- 분산 및 탈중앙화 데이터 소유권을 가능하게 하기 위해 크기 조정을 위해 데이터 제품 또는 데이터 통합 사용
단일 데이터 랜딩 존 또는 여러 데이터 랜딩 존을 배포할 수 있습니다. 데이터 랜딩 존을 사용하면 데이터 관리 랜딩 존에 연결하여 데이터를 검색하고 관리할 수 있습니다. 각 데이터 관리 랜딩 존은 단일 Azure 구독 내에 있습니다.
구독은 Azure의 관리, 요금 청구 및 스케일링 단위입니다. 대규모 Azure 채택 계획에서 중요한 역할을 합니다.
데이터 랜딩 존을 사용하여 스케일링
클라우드 규모 분석의 핵심 개념은 데이터 관리 랜딩 존 및 데이터 랜딩 존입니다. 각각 자체 Azure 구독에 배치해야 합니다. 이를 분리하면 의무를 명확하게 구분하고, 최소 권한 원칙을 따르고, 이전에 멘션 구독 규모 문제를 부분적으로 해결할 수 있습니다. 최소 클라우드 규모 분석 설정에는 단일 데이터 랜딩 존 및 단일 데이터 관리 랜딩 존이 포함됩니다.
그러나 최소 설정은 대규모 데이터 플랫폼 배포를 감당하기에 충분하지 않습니다. 기업은 대규모 플랫폼을 구축하고 시간이 지남에 따라 데이터 및 분석 노력을 일관되고 효율적으로 확장하기 위해 투자합니다. 구독 수준 제한을 극복하기 위해 클라우드 규모 분석은 Azure 랜딩 존에서 설명한 대로 구독을 크기 조정 단위로 사용합니다. 이 기술을 사용하면 아키텍처에 더 많은 데이터 랜딩 존을 추가하여 데이터 플랫폼 공간을 늘릴 수 있습니다. 또한 이 기술을 채택하면 각 데이터 랜딩 존에 세 개의 데이터 레이크가 포함되기 때문에 전체 조직에 사용되는 하나의 Azure Data Lake Gen2 문제가 해결됩니다. 여러 do기본의 프로젝트와 활동을 둘 이상의 Azure 구독에 분산하여 확장성을 높일 수 있습니다.
클라우드 규모 분석 아키텍처를 구현하기 전에 조직에 필요한 데이터 랜딩 존 수를 결정합니다. 올바른 결정을 내리면 효과적이고 효율적인 데이터 플랫폼의 기반이 됩니다.
필요한 데이터 랜딩 존의 수는 특히 다음과 같은 여러 요인에 따라 달라집니다.
- 조직 조정(예: 자체 데이터 랜딩 존이 필요한 사업부 수)
- 조직에서 사업부와 관련된 운영 리소스 및 리소스를 조정하는 방법과 같은 운영 고려 사항입니다.
올바른 데이터 랜딩 존 모델을 사용하면 데이터 제품 및 데이터 자산을 한 랜딩 존에서 다른 랜딩 존으로 이동하려는 향후 노력이 최소화됩니다. 또한 향후 빅 데이터 및 분석 활동을 효과적이고 일관되게 확장하는 데 도움이 됩니다.
배포할 데이터 랜딩 존 수를 결정할 때 다음 요소를 고려합니다.
| 요인 | 설명 |
|---|---|
| 조직 구조 및 데이터 소유권 | 조직의 구조화 방식과 조직에서 데이터를 소유하는 방법을 고려합니다. |
| 지역 및 위치 | 여러 지역에 배포하는 경우 데이터 영역을 호스트할 지역 또는 지역을 결정합니다. 모든 데이터 상주 요구 사항을 준수해야 합니다. |
| 할당량 | 구독 할당량은 용량을 보장하지 않으며 지역별로 적용됩니다. |
| 데이터 주권 | 데이터 주권 규정으로 인해 데이터는 특정 지역에 저장되고 지역별 정책을 따라야 합니다. |
| Azure 정책 | 데이터 랜딩 존은 다양한 Azure 정책의 요구 사항을 따라야 합니다. |
| 관리 경계 | 구독은 거버넌스 및 격리를 위한 관리 경계를 제공하여 문제를 명확하게 구분합니다. |
| 네트워킹 | 각 랜딩 존에는 가상 네트워크가 있습니다. 가상 네트워크는 단일 지역에 있기 때문에 각 새 지역에는 새 랜딩 존이 필요합니다. 상호 기본 통신을 사용하려면 가상 네트워크가 피어 가상 네트워크여야 합니다. |
| 제한 | 구독에는 제한이 있습니다. 여러 구독을 사용하면 이러한 제한에 도달하는 위험을 완화할 수 있습니다. |
| 비용 할당 | 중앙에서 지불되는 스토리지 계정과 같은 공유 서비스를 사업부별로 분할해야 하는지기본 고려합니다. 별도의 구독을 사용하면 비용 할당 경계가 만들어집니다. 태그를 사용하여 동일한 기능을 구현할 수 있습니다. |
| 데이터 분류 및 기밀 데이터 | 보안 메커니즘은 데이터 제품 개발 및 데이터 플랫폼의 유용성에 영향을 줄 수 있습니다. 데이터 분류를 고려하고 고도로 기밀 데이터 세트에 Just-In-Time 액세스, CMK(고객 관리형 키), 세분화된 네트워크 제어 또는 더 많은 암호화와 같은 특별한 처리가 필요한지 여부를 결정합니다. |
| 기타 법적 또는 보안 영향 | 데이터의 논리적 또는 물리적 분리가 필요한 다른 법적 또는 보안 요구 사항이 있는지 여부를 고려합니다. |
데이터 메시 아키텍처를 구현하는 경우 데이터 랜딩 존 및 데이터를 배포하는 방법을 결정할 때 다음 요소를 고려합니다기본.
| 요인 | 설명 |
|---|---|
| 데이터 도메인 | 조직에서 사용하는 데이터 기본 고려하고 데이터 플랫폼에 포함할 데이터를 결정합니다. 개별 데이터 도메인의 크기를 고려합니다. 자세한 내용은 데이터가 무엇을 합니까기본 참조하세요. |
| 대기 시간 | 대량의 데이터를 협업하는 도메인은 랜딩 존 간에 대량의 데이터를 전송할 수 있습니다. 동일한 랜딩 존 또는 지역에 도메인을 할당하는 것이 좋습니다. 이를 분리하면 대기 시간이 증가하고 지역 간 작업에서 비용이 증가할 수 기본. |
| 보안 | 일부 서비스 배포 또는 구성은 구독에서 상승된 권한이 필요합니다. 한 도메인의 사용자에게 이러한 권한을 부여하면 동일한 구독 내의 다른 도메인에서 해당 사용자에게 동일한 권한이 암시적으로 부여됩니다. |
구독에 대한 클라우드 채택 프레임워크 지침에서 더 많은 고려 사항을 찾을 수 있습니다.
많은 조직에서는 엔터프라이즈 데이터 플랫폼의 효율적인 크기 조정을 원합니다. 사업부는 고유한 요구 사항을 충족하기 위해 자체 데이터 솔루션 및 애플리케이션을 빌드할 수 있어야 합니다. 여러 기존 데이터 플랫폼이 확장성 및 탈중앙화 소유권 개념을 중심으로 구축되지 않기 때문에 이 기능을 제공하기가 어려울 수 있습니다. 이러한 단점은 이러한 데이터 플랫폼의 아키텍처, 팀 구조 및 ops 모델에서 명확하게 확인할 수 있습니다.
데이터 랜딩 존은 조직 내에 데이터 사일로를 만들지 않습니다. 클라우드 규모 분석에 권장하는 네트워크 설정을 사용하면 랜딩 존에서 안전하고 준비가 완료된 데이터 공유를 사용할 수 있으며, 이를 통해 데이터 도메인 및 사업부에서 혁신이 가능하게 됩니다. 자세한 내용은 네트워크 아키텍처 고려 사항을 참조하세요.
ID 계층도 마찬가지입니다. 단일 Microsoft Entra 테넌트를 사용하는 경우 ID에 여러 데이터 랜딩 존의 데이터 자산에 대한 액세스 권한을 부여할 수 있습니다. 사용자 및 ID 권한 부여 프로세스에 대한 자세한 내용은 데이터 액세스 관리를 참조하세요.
참고 항목
여러 데이터 랜딩 존이 있는 경우 각 영역은 다른 영역에서 호스트되는 데이터에 연결할 수 있습니다. 이를 통해 그룹은 회사 전체에서 협업할 수 있습니다.
클라우드 규모 분석은 공통 아키텍처를 사용하여 일관적인 거버넌스를 지원합니다. 아키텍처는 기준 기능과 정책을 정의합니다. 모든 데이터 랜딩 존은 동일한 감사 및 제어를 준수합니다. 팀은 데이터 파이프라인을 만들고, 원본을 수집하고, 보고서 및 대시보드와 같은 데이터 제품을 만들 수 있습니다. 또한 필요에 따라 Spark/SQL 분석을 수행할 수 있습니다. 정책의 기능에 서비스를 추가하여 데이터 랜딩 존 기능을 보강할 수 있습니다. 예를 들어 팀은 비즈니스 요구 사항을 해결하기 위해 타사 그래프 엔진을 추가할 수 있습니다.
클라우드 규모 분석은 중앙 카탈로그 및 분류에 중점을 두어 데이터를 보호하고 다양한 그룹이 데이터 제품을 검색할 수 있도록 합니다.
주의
다른 지역의 데이터를 쿼리하지 않는 것이 좋습니다. 대신, 데이터가 지역 경계를 유지하면서 데이터를 사용하는 컴퓨팅과 가까운지 확인합니다.
클라우드 규모 분석 아키텍처와 데이터 랜딩 존의 개념을 통해 조직은 시간이 지남에 따라 데이터 플랫폼의 크기를 쉽게 늘릴 수 있습니다. 단계적으로 더 많은 데이터 랜딩 존을 추가할 수 있습니다. 고객은 처음에는 여러 랜딩 존을 가질 필요가 없습니다. 이 아키텍처를 채택할 때는 몇 가지 데이터 랜딩 존 및 해당 영역에 포함된 데이터 제품의 우선 순위를 지정합니다. 적절한 우선 순위를 지정하면 클라우드 규모 분석 배포의 성공을 보장하는 데 도움이 됩니다.
데이터 제품 또는 데이터 통합을 사용하여 스케일링
각 랜딩 존 내에서 조직은 데이터 애플리케이션을 사용하여 크기를 조정할 수 있습니다. 데이터 애플리케이션은 다른 데이터 애플리케이션에서 사용할 수 있도록 읽기 최적화 데이터 제품을 제공하는 기능을 캡슐화하는 데이터 아키텍처의 단위 또는 구성 요소입니다. Azure에서 데이터 애플리케이션은 기능 간 팀이 데이터 솔루션 및 워크로드를 구현할 수 있도록 하는 리소스 그룹 형태의 환경입니다. 관련 팀은 수집, 클린sing, 집계 및 서비스 작업을 포함하는 데이터 솔루션의 엔드 투 엔드 수명 주기를 처리합니다.
클라우드 규모 분석은 앞에서 설명한 데이터 통합 및 책임 문제를 해결합니다. 참조 디자인은 테이블 수집 및 원본 시스템 통합에 대한 모놀리식 기능 책임 대신 데이터 do기본s에 의해 구동되는 분산 아키텍처를 제공합니다. 부서간 업무 팀은 데이터 범위에 대한 엔드 투 엔드 기능 책임 및 소유권을 담당합니다.
중앙 집중식 기술 스택과 데이터 처리 워크플로의 모든 작업을 담당하는 팀이 있는 대신, 여러 자율적인 기능 간 데이터 통합 팀에 엔드 투 엔드 책임을 분산할 수 있습니다. 각 팀은 do기본 또는 subdo기본 기능을 소유하고 있으며 데이터 소비자가 요구하는 대로 데이터 세트를 제공하는 것이 좋습니다.
이러한 아키텍처 차이로 인해 데이터 플랫폼의 속도가 향상됩니다. 데이터 소비자는 더 이상 중앙 집중식 팀 집합에 의존하거나 요청된 변경 내용의 우선 순위를 정하기 위해 싸울 필요가 없습니다. 엔드투엔드 통합 워크플로의 소유권을 갖는 팀의 규모가 작을수록 데이터 공급자와 데이터 소비자 간의 피드백 루프가 훨씬 짧아집니다. 이 방법을 사용하면 우선 순위가 더 빨라지고 개발 주기가 빨라지고 개발 프로세스가 더 민첩해집니다. 부서간 데이터 통합 팀은 엔드 투 엔드 기술 스택과 변경 내용의 의미를 완전히 인식하므로 팀은 더 이상 프로세스와 릴리스 계획을 동기화할 필요가 없습니다. 소프트웨어 엔지니어링 사례를 사용하여 단위 및 통합 테스트를 실행하여 소비자에게 미치는 전반적인 영향을 최소화할 수 있습니다.
이상적으로는 데이터 통합 시스템을 소유하는 팀도 원본 시스템을 소유합니다. 이 팀은 원본 시스템에서 작업하는 데이터 엔지니어, 데이터 세트, 클라우드 엔지니어 및 데이터 제품 소유자를 위한 SEM(실무 전문가)으로 구성되어야 합니다. 이러한 종류의 부서간 업무 팀을 구축하면 외부 팀과의 통신 양이 줄어들고 인프라에서 실제 데이터 파이프라인으로 전체 스택을 개발하는 동안 필수적입니다.
데이터 플랫폼의 기반은 원본 시스템에서 통합된 데이터 세트입니다. 이러한 데이터 세트를 사용하면 데이터 제품 팀이 비즈니스 팩트 테이블에서 혁신하고 의사 결정 및 비즈니스 프로세스를 개선할 수 있습니다. 데이터 통합 팀과 데이터 제품 팀은 소비자에게 SLA를 제공하고 모든 계약이 충족되는지 확인해야 합니다. 제공된 SLA는 데이터 품질, 타임라인ss, 오류율, 가동 시간 및 기타 작업과 관련이 있을 수 있습니다.
요약
클라우드 규모 분석 아키텍처의 크기 조정 메커니즘을 사용하여 조직은 잘 알려진 기술적 제한을 피하면서 시간이 지남에 따라 Azure 내에서 데이터 자산을 확장합니다. 이 문서에 설명된 두 가지 크기 조정 방법은 서로 다른 기술적 복잡성을 극복하는 데 도움이 되며 간단하고 효율적인 방법으로 사용할 수 있습니다.