Synapse 구현 성공 방법론: 서버리스 SQL 풀 디자인 평가

서버리스 SQL 풀 디자인을 평가하여 문제를 식별하고 지침 및 요구 사항을 충족하는지 확인해야 합니다. “솔루션 개발이 시작되기 전에” 디자인을 평가하면 방해 요소 및 예기치 않은 디자인 변경을 방지할 수 있습니다. 이렇게 하면 프로젝트의 타임라인과 예산을 보호할 수 있습니다.

최신 데이터, 분석 플랫폼, 서비스에 대한 스토리지 및 컴퓨팅의 아키텍처 분리는 추세이며 자주 사용되는 패턴입니다. 비용 절감 및 더 많은 유연성을 제공하여 스토리지 및 컴퓨팅의 독립적인 주문형 스케일링을 허용합니다. Synapse SQL 서버리스는 데이터 레이크 데이터를 직접 쿼리하는 기능을 추가하여 이 패턴을 확장합니다. 셀프 서비스 유형의 워크로드를 사용할 때 컴퓨팅 관리에 대해 걱정할 필요가 없습니다.

간격 분석 맞춤

Azure Synapse 내에서 SQL 서버리스 풀을 구현하려는 경우 먼저 서버리스 풀이 워크로드에 적합한지 확인해야 합니다. 운영 효율성, 성능 효율성, 안정성, 보안을 고려해야 합니다.

운영 우수성

운영 우수성에 대해 다음 사항을 평가합니다.

• 솔루션 개발 환경: 이 방법론 내에는 솔루션 개발 환경에 대한 평가가 있습니다. 환경(개발, 테스트, 프로덕션)이 솔루션 개발을 지원하도록 설계된 방식을 식별합니다. 일반적으로 프로덕션 및 비프로덕션 환경(개발 및 테스트용)을 찾을 수 있습니다. 모든 환경에서 Synapse 작업 영역을 찾아야 합니다. 대부분의 경우 프로덕션 및 개발/테스트 사용자 및 워크로드를 분리해야 합니다.
• Synapse 작업 영역 디자인: 이 방법론 내에는 Synapse 작업 영역 디자인에 대한 평가가 있습니다. 작업 영역이 솔루션에 맞게 디자인된 방법을 식별합니다. 디자인에 익숙해지고 솔루션이 단일 작업 영역을 사용할지 또는 여러 작업 영역이 솔루션의 일부를 구성하는지 여부를 파악합니다. 단일 또는 여러 작업 영역 디자인이 선택된 이유를 알아보세요. 다중 작업 영역 디자인은 종종 엄격한 보안 경계를 적용하기 위해 선택됩니다.
• 배포: SQL 서버리스는 모든 Synapse 작업 영역에서 주문형으로 사용할 수 있으므로 특별한 배포 작업이 필요하지 않습니다. 서비스의 지역 근접성과 연결된 ADLS Gen2(Azure Data Lake Storage Gen2) 계정의 근접성을 확인합니다.
• 모니터링: 기본 제공 모니터링이 충분한지 여부와 기록 로그 데이터를 저장하기 위해 외부 서비스를 배치해야 하는지 여부를 확인합니다. 로그 데이터를 사용하면 성능 변경을 분석할 수 있으며 특정 상황에 대한 경고 또는 트리거된 작업을 정의할 수 있습니다.

성능 효율성

기존 데이터베이스 엔진과 달리 SQL 서버리스는 자체 최적화된 스토리지 계층을 사용하지 않습니다. 이러한 이유로 해당 성능은 ADLS Gen2에서 데이터를 구성하는 방법에 크게 좌우됩니다. 성능 효율성에 대해 다음 사항을 평가합니다.

• 데이터 수집: 데이터가 데이터 레이크에 저장되는 방법을 검토합니다. 파일 크기, 파일 수, 폴더 구조는 모두 성능에 영향을 줍니다. 일부 파일 크기는 SQL 서버리스에서 작동할 수 있지만 다른 엔진 또는 애플리케이션에서 효율적으로 처리하거나 사용하는 데 문제가 발생할 수 있습니다. SQL 서버리스 및 솔루션의 일부를 구성하는 다른 데이터 도구를 비롯한 모든 데이터 소비자에 대해 데이터 스토리지 디자인을 평가하고 유효성을 검사해야 합니다.
• 데이터 배치: 디자인에 데이터 배치를 위한 통합 및 정의된 공통 패턴이 있는지 평가합니다. 디렉터리 분기가 보안 요구 사항을 지원할 수 있는지 확인합니다. 시계열 데이터를 정리하는 데 도움이 되는 몇 가지 일반적인 패턴이 있습니다. 원하는 대로 다른 엔진 및 워크로드에서도 작동하는지 확인합니다. 또한 Spark 애플리케이션 및 외부 테이블에 대한 파티션 자동 검색에 도움이 될 수 있는지 확인합니다.
• 데이터 형식: 대부분의 경우 SQL 서버리스에서는 Parquet 형식을 사용하여 최상의 성능과 향상된 호환성 기능을 제공합니다. 성능 및 호환성 요구 사항을 확인합니다. Parquet은 더 나은 압축 및 IO 감소(분석에 필요한 열만 읽는 기능) 덕분에 성능이 향상되지만 더 많은 컴퓨팅 리소스가 필요하기 때문입니다. 또한 일부 원본 시스템은 기본적으로 Parquet을 내보내기 형식으로 지원하지 않으므로 전체 아키텍처에서 파이프라인 및/또는 종속성에서 더 많은 변환 단계를 수행할 수 있습니다.
• 탐색: 모든 업계가 다릅니다. 그러나 대부분의 경우 가장 자주 실행되는 쿼리에서 발견되는 일반적인 데이터 액세스 패턴이 있습니다. 패턴에는 일반적으로 날짜, 범주 또는 지리적 지역별 필터링 및 집계가 포함됩니다. 가장 일반적인 필터링 조건을 식별하고 가장 자주 실행되는 쿼리에서 읽거나 삭제하는 데이터의 양과 연결합니다. 데이터 레이크에 대한 정보가 탐색 요구 사항 및 기대치에 맞게 구성되었는지 확인합니다. 디자인 및 평가에서 식별된 쿼리의 경우 OPENROWSET 경로 매개 변수에서 불필요한 파티션을 제거할 수 있는지 또는 외부 테이블이 있는 경우 더 많은 인덱스를 만드는 것이 도움이 될 수 있는지를 참조하세요.

안정성

안정성에 대해 다음 사항을 평가합니다.

• 가용성: 평가 단계에서 식별된 가용성 요구 사항의 유효성을 검사합니다. SQL 서버리스에 대한 특정 SLA는 없지만 쿼리 실행에 대한 시간 제한은 30분입니다. 평가에서 가장 오래 실행되는 쿼리를 식별하고 서버리스 SQL 디자인에 대해 유효성을 검사합니다. 30분 시간 제한은 워크로드에 대한 기대치를 깨뜨리고 서비스 문제로 나타날 수 있습니다.
• 일관성: SQL 서버리스는 주로 읽기 워크로드용으로 설계되었습니다. 따라서 데이터 레이크 데이터 프로비저닝 및 형성 프로세스 중에 모든 일관성 검사가 수행되었는지 확인합니다. 트랜잭션에 대한 ACID(원자성, 일관성, 격리, 내구성) 보증을 지원하는 Delta Lake 오픈 소스 스토리지 계층과 같은 새로운 기능을 계속 유지합니다. 이 기능을 사용하면 효과적인 람다 또는 카파 아키텍처를 구현하여 스트리밍 및 일괄 처리 사용 사례를 모두 지원할 수 있습니다. 프로젝트의 타임라인이나 비용을 희생하지 않고 새 기능을 적용할 수 있는 기회를 위해 디자인을 평가해야 합니다.
• 백업: 평가 중에 확인된 재해 복구 요구 사항을 검토합니다. 복구를 위해 SQL 서버리스 디자인에 대해 유효성을 검사합니다. SQL 서버리스 자체에는 자체 스토리지 계층이 없으므로 데이터의 스냅샷 및 백업 복사본을 처리해야 합니다. 서버리스 SQL에서 액세스하는 데이터 저장소는 외부(ADLS Gen2)입니다. 이러한 데이터 세트에 대한 프로젝트의 복구 디자인을 검토합니다.

보안

유연한 보안 기반을 구축하는 데는 데이터 구성이 중요합니다. 대부분의 경우 서로 다른 프로세스와 사용자는 데이터 레이크 또는 논리 데이터 웨어하우스의 특정 하위 영역에 대한 다양한 권한과 액세스 권한이 필요합니다.

보안에 대해 다음 사항을 평가합니다.

• 데이터 스토리지: 평가 단계에서 수집된 정보를 사용하여 일반적인 원시, 스테이지, 큐레이팅된 데이터 레이크 영역을 독립적인 스토리지 계정 대신 동일한 스토리지 계정에 배치해야 하는지 여부를 식별합니다. 후자는 역할 및 권한 측면에서 더 많은 유연성을 가져올 수 있습니다. 또한 아키텍처가 많은 동시 읽기/쓰기 워크로드(예: 실시간 또는 IoT 시나리오)를 지원해야 하는 경우 필요할 수 있는 IOPS(초당 입출력 작업) 용량을 더 추가할 수 있습니다. 샌드박스 및 마스터 데이터 영역을 별도의 스토리지 계정에 유지하여 추가로 분리해야 하는지 여부를 확인합니다. 대부분의 사용자는 데이터를 업데이트하거나 삭제할 필요가 없으므로 샌드박스 및 프라이빗 영역을 제외하고 데이터 레이크에 대한 쓰기 권한이 필요하지 않습니다.
• 평가 정보에서 요구 사항이 Always Encrypted, 동적 데이터 마스킹 또는 행 수준 보안과 같은 보안 기능을 사용하는지 여부를 식별합니다. OPENROWSET 함수와 함께 사용되는 경우와 같은 특정 시나리오에서 이러한 기능의 가용성을 확인합니다. 필요할 수 있는 잠재적 해결 방법을 예상합니다.
• 평가 정보에서 가장 적합한 인증 방법을 식별합니다. Microsoft Entra 서비스 주체, SAS(공유 액세스 서명), 인증 통과를 사용하고 고객이 선택한 탐색 도구에 통합할 수 있는 시기와 방법을 고려합니다. 디자인을 평가하고 디자인의 일부로 최상의 인증 방법의 유효성을 검사합니다.

기타 고려 사항

디자인을 검토하고 모범 사례 및 권장 사항을 적용했는지 확인합니다. 조건자 푸시다운이 제대로 작동하는지 확인하기 위해 필터 최적화 및 데이터 정렬에 특히 주의하세요.

다음 단계

Azure Synapse 성공 디자인 시리즈의 다음 문서에서 Spark 풀 디자인을 평가하여 문제를 식별하고 지침 및 요구 사항을 충족하는지 확인하는 방법을 알아봅니다.