Synapse 구현 성공 방법론: 작업 영역 디자인 평가

참고 항목

이 문서는 디자인에 따른 Azure Synapse 구현 성공 문서 시리즈의 일부를 구성합니다. 시리즈에 대한 개요는 Azure Synapse 구현 성공 디자인을 참조하세요.

Synapse 작업 영역은 코드 및 프로세스 오케스트레이션과 함께 분석 및 데이터 처리 엔진, 데이터 레이크, 데이터베이스, 테이블, 데이터 세트 및 보고 아티팩트를 모두 연결하는 통합 그래픽 사용자 환경입니다. Synapse 작업 영역에 통합되는 기술 및 서비스의 수를 고려하여 주요 구성 요소가 디자인에 포함되는지 확인합니다.

Synapse 작업 영역 디자인 검토

하나의 Synapse 작업 영역 또는 여러 작업 영역이 솔루션 디자인에 포함되는지 확인합니다. 이 디자인의 추진 요인을 결정합니다. 여러 가지 이유가 있을 수 있지만, 대부분의 경우 여러 작업 영역에 대한 이유는 보안 분리 또는 청구 분리로 인한 것입니다. 작업 영역 수와 데이터베이스 경계를 ​​결정하는 경우 구독당 20개 작업 영역으로 제한됩니다.

각 작업 영역 내에서 공유해야 하는 요소 또는 서비스와 리소스를 식별합니다. 리소스에는 데이터 레이크, IR(통합 런타임), 메타데이터 또는 구성 및 코드가 포함될 수 있습니다. 잠재적인 시너지 효과 측면에서 이 특정 디자인을 선택한 이유를 확인합니다. 이러한 시너지 효과가 추가 비용과 관리 오버헤드를 정당화하는지 자문해 보세요.

데이터 레이크 디자인 검토

데이터 레이크(솔루션의 일부인 경우)를 적절하게 계층화하는 것이 좋습니다. 데이터 레이크를 Bronze, Silver 및 Gold 데이터 세트와 관련된 세 가지 주요 영역으로 나눠야 합니다. Bronze(또는 원시 계층)는 저장될 수 있는 마스크 해제되지 않은 중요한 데이터로 인해 더 엄격한 액세스 제어가 있으므로 별도의 자체 스토리지 계정에 상주할 수 있습니다.

보안 디자인 검토

작업 영역에 대한 보안 디자인을 검토하고 평가 중에 수집한 정보와 비교합니다. 모든 요구 사항이 충족되고 모든 제약 조건이 고려되었는지 확인합니다. 관리 편의를 위해 사용자는 적절한 권한 프로파일링이 있는 그룹으로 구성하는 것이 좋습니다. 액세스 제어는 역할에 맞는 보안 그룹을 사용하여 간소화할 수 있습니다. 이렇게 하면 네트워크 관리자가 적절한 보안 그룹에서 사용자를 추가하거나 제거하여 액세스를 관리할 수 있습니다.

서버리스 SQL 풀 및 Apache Spark 테이블은 데이터를 작업 영역과 연결된 ADLS Gen2(Azure Data Lake Gen2) 컨테이너에 저장합니다. 사용자가 설치한 Apache Spark 라이브러리도 이 동일한 스토리지 계정에서 관리됩니다. 이러한 사용 사례를 사용하도록 설정하려면 사용자와 작업 영역 MSI(관리 서비스 ID)를 모두 ADLS Gen2 스토리지 컨테이너의 Storage Blob 데이터 기여자 역할에 추가해야 합니다. 보안 요구 사항에 대해 이 요구 사항을 확인합니다.

전용 SQL 풀은 중요한 데이터를 암호화하고 마스크하는 다양한 보안 세트를 제공합니다. 전용 및 서버리스 SQL 풀은 모두 기본 제공 역할, 사용자 정의 역할, SQL 인증 및 Microsoft Entra 인증을 포함하여 SQL Server 권한의 전체 노출 영역을 사용하도록 설정합니다. 솔루션의 전용 SQL 풀과 서버리스 SQL 풀 액세스 및 데이터에 대한 보안 디자인을 검토합니다.

Azure Synapse Analytics 솔루션의 일부를 구성하는 데이터 레이크 및 모든 ADLS Gen2 스토리지 계정(및 기타)에 대한 보안 계획을 검토합니다. ADLS Gen2 스토리지 자체는 컴퓨팅 엔진이 아니므로 데이터 특성을 선택적으로 마스크하는 기본 제공 기능이 없습니다. ADLS Gen2 권한은 RBAC(역할 기반 액세스 제어)를 사용하여 스토리지 계정 또는 컨테이너 수준에서 및/또는 ACL(액세스 제어 목록)을 사용하여 폴더 또는 파일 수준에서 적용할 수 있습니다. 디자인을 주의 깊게 검토하고 불필요한 복잡성을 방지하기 위해 노력합니다.

보안 디자인에 대해 고려해야 할 몇 가지 사항은 다음과 같습니다.

• Microsoft Entra ID 설정 요구 사항이 디자인에 포함되는지 확인합니다.
• 테넌트 간 시나리오를 확인합니다. 일부 데이터가 다른 Azure 테넌트에 있거나 다른 테넌트로 이동해야 하거나 다른 테넌트의 사용자가 액세스해야 하므로 이러한 문제가 발생할 수 있습니다. 이러한 시나리오가 디자인에서 고려되는지 확인합니다.
• 각 작업 영역에 대한 역할은 무엇인가요? 작업 영역을 어떻게 사용하나요?
• 보안은 작업 영역 내에서 어떻게 설계되나요?
  • 누가 모든 스크립트, Notebook 및 파이프라인을 볼 수 있나요?
  • 누가 스크립트와 파이프라인을 실행할 수 있나요?
  • 누가 SQL 및 Spark 풀을 만들고, 일시 중지하고, 다시 시작할 수 있나요?
  • 누가 변경 내용을 작업 영역에 게시할 수 있나요?
  • 누가 원본 제어에 대한 변경 내용을 커밋할 수 있나요?
• 파이프라인에서 저장된 자격 증명 또는 작업 영역 관리 ID를 사용하여 데이터에 액세스하나요?
• Synapse Studio에서 데이터를 찾아보기 위해 사용자에게 데이터 레이크에 대한 적절한 액세스 권한이 있나요?
• RBAC와 ACL의 적절한 조합을 사용하여 데이터 레이크를 올바르게 보호하나요?
• SQL 풀 사용자 권한이 각 역할(데이터 과학자, 개발자, 관리자, 비즈니스 사용자 등)에 대해 올바르게 설정되었나요?

네트워킹 디자인 검토

네트워크 디자인에 대해 고려해야 할 몇 가지 사항은 다음과 같습니다.

• 모든 리소스 간의 연결을 설계하나요?
• 사용할 네트워킹 메커니즘(Azure ExpressRoute, 퍼블릭 인터넷 또는 프라이빗 엔드포인트)은 무엇인가요?
• Synapse Studio에 안전하게 연결할 수 있어야 하나요?
• 데이터 반출을 고려했나요?
• 온-프레미스 데이터 원본에 연결해야 하나요?
• Azure Machine Learning과 같은 다른 클라우드 데이터 원본 또는 컴퓨팅 엔진에 연결해야 하나요?
• 적절한 연결 및 데이터 이동을 위해 NSG(네트워크 보안 그룹)와 같은 Azure 네트워킹 구성 요소를 검토했나요?
• 프라이빗 DNS 영역과의 통합을 고려했나요?
• Synapse Studio 내에서 데이터 레이크를 찾아보거나 서버리스 SQL 또는 PolyBase를 사용하여 데이터 레이크의 데이터를 간단히 쿼리할 수 있어야 하나요?

마지막으로 모든 데이터 소비자를 식별하고 해당 연결이 디자인에서 고려되는지 확인합니다. 네트워크 및 보안 전초 기지에서 서비스가 필요한 온-프레미스 원본에 액세스할 수 있고 해당 인증 프로토콜 및 메커니즘이 지원되는지 확인합니다. 일부 시나리오에서는 Microsoft Power BI와 같은 SaaS 솔루션용 자체 호스팅 IR 또는 데이터 게이트웨이가 둘 이상 필요할 수 있습니다.

모니터링 디자인 검토

Azure Synapse 구성 요소에 대한 모니터링 디자인을 검토하여 평가 중에 식별된 요구 사항과 기대치를 충족하는지 확인합니다. 리소스 및 데이터 액세스에 대한 모니터링이 설계되었고 각 모니터링 요구 사항을 식별하는지 확인합니다. 강력한 모니터링 솔루션은 프로덕션에 대한 첫 번째 배포의 일부로 배치해야 합니다. 이렇게 하면 오류를 적시에 식별, 진단 및 해결할 수 있습니다. 기본 인프라 및 파이프라인 실행 외에도 데이터를 모니터링해야 합니다. 사용 중인 Azure Synapse 구성 요소에 따라 각 구성 요소에 대한 모니터링 요구 사항을 식별합니다. 예를 들어 Spark 풀이 솔루션의 일부를 구성하는 경우 잘못된 형식의 레코드 저장소를 모니터링합니다. 

모니터링 디자인에 대해 고려해야 할 몇 가지 사항은 다음과 같습니다.

• 누가 각 리소스 종류(파이프라인, 풀 등)를 모니터링할 수 있나요?
• 데이터베이스 활동 로그를 얼마나 보존해야 하나요?
• 작업 영역 및 데이터베이스 로그 보존에서 Log Analytics 또는 Azure Storage를 사용하나요?
• 파이프라인 오류가 발생하는 경우 경고를 트리거하나요? 그렇다면 누구에게 알려야 하나요?
• 경고를 트리거해야 하는 SQL 풀의 임계값 수준은 무엇인가요? 누구에게 알려야 하나요?

원본 제어 디자인 검토

기본적으로 Synapse 작업 영역은 기본 제공 게시 기능을 사용하여 변경 내용을 Synapse 서비스에 직접 적용합니다. 많은 이점을 제공하는 원본 제어 통합을 사용하도록 설정할 수 있습니다. 향상된 협업, 버전 관리, 승인 및 릴리스 파이프라인을 통해 개발, 테스트 및 프로덕션 환경에 대한 변경을 촉진할 수 있는 이점이 있습니다. Azure Synapse는 작업 영역당 단일 원본 제어 리포지토리를 허용합니다. 이 리포지토리는 Azure DevOps Git 또는 GitHub일 수 있습니다.

원본 제어 디자인에 대해 고려해야 할 몇 가지 사항은 다음과 같습니다.

• Azure DevOps Git을 사용하는 경우 Synapse 작업 영역과 해당 리포지토리가 동일한 테넌트에 있나요?
• 누가 원본 제어에 액세스할 수 있나요?
• 원본 제어에서 각 사용자에게 부여되는 권한은 무엇인가요?
• 분기 및 병합 전략을 개발했나요?
• 다른 환경에 배포하기 위해 릴리스 파이프라인을 개발하나요?
• 승인 프로세스를 병합 및 릴리스 파이프라인에 사용하나요?

참고 항목

개발 환경의 디자인은 프로젝트의 성공에 매우 중요합니다. 개발 환경이 설계되면 이 방법론의 별도 단계에서 평가됩니다.

다음 단계

Azure Synapse 성공 디자인 시리즈의 다음 문서에서 데이터 통합 ​​디자인을 평가하고, 지침 및 요구 사항을 충족하는지 확인하는 방법을 알아봅니다.