Synapse POC 플레이북: Azure Synapse Analytics의 전용 SQL 풀이 있는 데이터 웨어하우징

아티클
06/01/2023

이 문서에서는 전용 SQL 풀을 위한 효과적인 Azure Synapse Analytics POC(개념 증명) 프로젝트를 준비하고 실행하기 위한 상위 수준 방법론을 제시합니다.

참고 항목

이 문서는 Azure Synapse 개념 증명 플레이북 시리즈 문서의 일부를 구성합니다. 시리즈에 대한 개요는 Azure Synapse 개념 증명 플레이북을 참조하세요.

팁

전용 SQL 풀을 처음 사용하는 경우 Azure Synapse Analytics를 사용하여 데이터 웨어하우스 작업 학습 경로를 통해 작업하는 것이 좋습니다.

POC 준비

Azure Synapse POC 목표를 결정하기 전에 먼저 Azure Synapse SQL 아키텍처 문서를 읽고 전용 SQL 풀이 업계 최고의 성능을 제공하기 위해 컴퓨팅과 스토리지를 분리하는 방법을 숙지하는 것이 좋습니다.

스폰서 및 잠재적 차단자 식별

Azure Synapse에 익숙해지면 POC가 필요한 지원을 받고 장애물에 부딪히지 않도록 해야 합니다. 다음을 수행해야 합니다.

클라우드로 데이터를 이동하고 클라우드에 데이터를 저장하는 것과 관련하여 조직에서 가지고 있는 제한 사항이나 정책을 식별합니다.
클라우드 기반 데이터 웨어하우스 프로젝트에 대한 경영진 및 비즈니스 스폰서쉽을 식별합니다.
워크로드가 Azure Synapse에 적합한지 확인합니다. 자세한 내용은 Azure Synapse Analytics의 전용 SQL 풀 아키텍처를 참조하세요.

타임라인 설정

POC는 성공을 정의하는 구체적이고 측정 가능한 목표와 메트릭이 포함된 범위 및 시간 제한이 있는 연습입니다. 이상적으로는 결과가 의미가 있으려면 비즈니스 현실에 어느 정도 근거가 있어야 합니다.

POC는 작업 일정에 있을 때 최상의 결과를 얻습니다. 작업 일정 수립은 작업에 고정된 최대 시간 단위를 할당합니다. 경험상 2주는 너무 많은 사용 사례나 복잡한 테스트 행렬의 부담 없이 작업을 완료할 수 있는 충분한 시간입니다. 이 고정된 기간 내에 작업하려면 다음 일정을 따르는 것이 좋습니다.

데이터 로드: 3일 이하
쿼리: 5일 이내
부가가치 테스트: 2일 이내

다음 팁을 참조하세요.

계획의 작업을 완료하는 데 필요한 시간을 현실적으로 예상합니다.
POC를 완료하는 데 걸리는 시간은 데이터 세트의 크기, 데이터베이스 개체(테이블, 보기 및 저장 프로시저)의 수, 데이터베이스 개체의 복잡성, 테스트할 인터페이스의 수와 관련이 있음을 인식합니다.
POC가 4주 이상 실행될 것으로 예상되는 경우 가장 중요한 목표에만 집중하도록 범위를 줄이는 것이 좋습니다.
POC를 시작하기 전에 타임라인에 대한 모든 리드 리소스와 스폰서의 지원을 받으세요.

즉각적인 장애물이 없다고 판단하고 일정을 설정한 후에는 상위 수준 아키텍처의 범위를 지정할 수 있습니다.

상위 수준 범위 아키텍처 만들기

상위 수준 향후 아키텍처에는 많은 데이터 원본과 데이터 소비자, 빅 데이터 구성 요소, 기계 학습 및 AI 데이터 소비자가 포함될 수 있습니다. POC 목표를 설정된 일정 범위 내에서 달성 가능한 상태로 유지하려면 이러한 구성 요소 중 POC의 일부를 구성하고 제외할 구성 요소를 결정합니다.

또한 이미 Azure를 사용 중인 경우 다음을 식별합니다.

POC 중에 사용할 수 있는 기존 Azure 리소스. 예를 들어 리소스에는 Microsoft Entra ID 또는 Azure ExpressRoute가 포함될 수 있습니다.
조직에서 기본 설정하는 Azure 지역.
비프로덕션 POC 작업에 사용할 수 있는 구독.
Azure에 대한 네트워크 연결의 처리량.

Important

POC가 프로덕션 솔루션에 부정적인 영향을 미치지 않으면서 해당 처리량의 일부를 소비할 수 있는지 확인합니다.

마이그레이션 옵션 적용

레거시 데이터 웨어하우스 시스템에서 Azure Synapse로 마이그레이션하는 경우 고려해야 할 몇 가지 질문은 다음과 같습니다.

마이그레이션 중이며 기존 ETL(추출, 변환 및 로드) 프로세스와 데이터 웨어하우스 사용을 가능한 한 적게 변경하려고 하나요?
마이그레이션 중이지만 그 과정에서 몇 가지 광범위한 개선 작업을 수행하려고 하나요?
완전히 새로운 데이터 분석 환경(그린필드 프로젝트라고도 함)을 빌드하고 있나요?

다음으로, 통증 포인트를 고려해야 합니다.

현재의 문제점 파악

POC에는 현재 문제점을 해결할 수 있는 잠재적 솔루션을 증명하는 사용 사례가 포함되어야 합니다. 고려해야 할 질문은 다음과 같습니다.

Azure Synapse가 현재 구현에서 어떤 격차를 없앨 것으로 예상하나요?
지원해야 하는 새로운 비즈니스 요구 사항은 무엇인가요?
어떤 SLA(서비스 수준 계약)를 충족해야 하나요?
워크로드는 무엇인가요(예: ETL, 일괄 처리 쿼리, 분석, 보고 쿼리 또는 대화형 쿼리)?

다음으로 POC 성공 기준을 설정해야 합니다.

POC 성공 기준 설정

POC를 수행하는 이유를 확인하고 명확한 목표를 정의합니다. 또한 POC에서 원하는 출력과 이를 사용하여 수행할 계획을 아는 것도 중요합니다.

POC는 제한된 개념 집합을 신속하게 증명하거나 테스트하기 위한 짧고 집중적인 활동이어야 합니다. 증명할 항목의 목록이 긴 경우 여러 POC로 분류할 수 있습니다. POC 사이에 게이트가 있을 수 있으므로 다음 POC로 진행할지 여부를 결정할 수 있습니다.

다음은 몇 가지 POC 목표의 예입니다.

크고 복잡한 보고 쿼리에 대한 쿼리 성능이 새로운 SLA를 충족한다는 사실을 알아야 합니다.
대화형 사용자의 쿼리 성능을 알아야 합니다.
기존 ETL 프로세스가 적합한지 여부와 개선이 필요한 부분을 알아야 합니다.
ETL 런타임을 얼마나 단축할 수 있는지 여부를 알아야 합니다.
Synapse Analytics에는 데이터를 적절하게 보호할 수 있는 충분한 보안 기능이 있다는 것을 알아야 합니다.

다음으로 테스트 계획을 작성해야 합니다.

테스트 계획 만들기

목표를 사용하여 해당 목표를 지원하고 식별된 결과를 제공하기 위해 실행할 특정 테스트를 식별합니다. 각 목표와 예상 결과에 대해 최소한 하나의 테스트가 있는지 확인하는 것이 중요합니다. 정량화 가능한 결과를 제공하기 위해 실행할 특정 쿼리, 보고서, ETL 및 기타 프로세스를 식별합니다.

발생하는 테이블 구조 질문을 명확히 하기 위해 여러 테스트 시나리오를 추가하여 테스트를 구체화합니다.

일반적으로 효과적인 POC 실행을 정의하도록 계획하는 것이 좋습니다. 모든 관련자가 각 POC 목표를 명확하게 명시된 일련의 테스트 사례 및 성공 측정과 연결하는 서면 테스트 계획에 동의해야 합니다.

대부분의 테스트 계획은 성능과 예상되는 사용자 환경을 중심으로 수행됩니다. 다음은 테스트 계획의 예입니다. 비즈니스 요구 사항에 맞게 테스트 계획을 사용자 지정해야 합니다. 테스트할 대상을 명확하게 정의하면 이 프로세스의 후반부에 이익을 얻을 수 있습니다.

목표	테스트	예상 결과
크고 복잡한 보고 쿼리에 대한 쿼리 성능이 새로운 SLA를 충족한다는 것을 알아야 합니다.	- 복잡한 쿼리의 순차적 테스트 - 명시된 SLA에 대한 복잡한 쿼리의 동시성 테스트	- 쿼리 A, B, C는 각각 10초, 13초, 21초 안에 완료 - 동시 접속자 10명 기준으로 A, B, C 쿼리는 평균 11초, 15초, 23초 만에 완료
대화형 사용자의 쿼리 성능을 알아야 합니다.	- 50명의 사용자 예상 동시성 수준에서 선택한 쿼리의 동시성 테스트. - 결과 집합 캐싱으로 이전 쿼리 실행	- 동시 접속자 50명에서 평균 실행 시간은 10초 미만으로 예상되며 결과 집합 캐싱 없음 - 동시 사용자 50명에서 결과 집합 캐싱으로 평균 실행 시간은 5초 미만으로 예상됨
기존 ETL 프로세스가 SLA 내에서 실행될 수 있는지 여부를 알아야 합니다.	- 하나 또는 두 개의 ETL 프로세스를 실행하여 프로덕션 로드 모방	- 핵심 팩트 테이블에 점진적으로 로드하는 작업은 20분 이내에 완료되어야 함(스테이징 및 데이터 정리 포함) - 차원 처리 시간은 5분 이내 필요
데이터 웨어하우스가 데이터를 보호하기에 충분한 보안 기능을 가지고 있음을 알아야 합니다.	- 네트워크 보안(VNet 및 프라이빗 엔드포인트), 액세스 제어(행 수준 보안, 동적 데이터 마스킹) 검토 및 사용	- 데이터가 테넌트에서 나가지 않는다는 것을 증명 - 고객 콘텐츠가 쉽게 보호되는지 확인

다음으로 POC 데이터 세트를 식별하고 유효성을 검사해야 합니다.

POC 데이터 세트 식별 및 유효성 검사

범위 테스트를 사용하여 이제 Azure Synapse에서 해당 테스트를 실행하는 데 필요한 데이터 세트를 식별할 수 있습니다. 다음을 고려하여 데이터 세트를 검토합니다.

데이터 세트가 콘텐츠, 복잡성 및 규모 측면에서 프로덕션 데이터 세트를 적절하게 나타내는지 확인합니다.
대표 성능을 달성하지 못할 수 있으므로 너무 작은(1TB 미만) 데이터 세트를 사용하지 마세요.
POC는 전체 데이터 마이그레이션을 완료하기 위한 것이 아니므로 너무 큰 데이터 세트를 사용하지 마세요.
각 테이블의 분산 패턴, 인덱스 생성 옵션 및 분할을 식별합니다. 배포, 인덱싱 또는 분할에 관한 질문이 있는 경우 POC에 테스트를 추가하여 답변합니다. 일부 테이블에 대해 둘 이상의 배포 옵션 또는 인덱싱 옵션을 테스트할 수 있음을 명심합니다.
POC 데이터 세트를 클라우드로 이동하는 데 방해 요소가 있는지 비즈니스 소유자에게 확인합니다.
보안 또는 개인 정보 보호 문제를 식별합니다.

Important

데이터를 클라우드로 이동하기 전에 차단 요소가 있는지 비즈니스 소유자에게 확인합니다. 데이터를 클라우드로 이동하기 전에 수행해야 하는 보안 또는 개인 정보 보호 문제 또는 데이터 난독 처리 요구 사항을 식별합니다.

다음으로 전문가 팀을 구성해야 합니다.

팀을 구성

POC를 지원하기 위한 팀 구성원과 해당 약정을 확인합니다. 팀 구성원은 다음을 포함해야 합니다.

POC 프로젝트를 실행하는 프로젝트 관리자.
요구 사항 및 결과를 감독하는 비즈니스 담당자
POC 데이터 세트의 데이터를 소싱하는 애플리케이션 데이터 전문가.
Azure Synapse 전문가.
POC 테스트를 최적화하는 전문가 고문.
특정 POC 프로젝트 작업에 필요하지만 전체 기간 동안은 필요하지 않은 사용자. 이러한 지원 리소스에는 네트워크 관리자, Azure 관리자 또는 Microsoft Entra 관리자가 포함될 수 있습니다.

팁

POC를 지원하기 위해 전문가 고문을 고용하는 것이 좋습니다. Microsoft 파트너 커뮤니티에는 Azure Synapse를 평가(assess), 평가(evaluate) 또는 구현하는 데 도움을 줄 수 있는 전문 컨설턴트가 전 세계에 있습니다.

이제 완전히 준비되었으므로 POC를 실천할 때입니다.

POC 실행

다음 사항에 주의해야 합니다.

모든 프로덕션 프로젝트의 분야와 엄격함으로 POC 프로젝트를 구현합니다.
계획에 따라 POC를 실행합니다.
POC 범위가 증가하거나 변경되는 것을 방지하기 위해 변경 요청 프로세스를 마련합니다.

테스트를 시작하기 전에 테스트 환경을 설정해야 합니다. 여기에는 4단계가 포함됩니다.

설정
데이터 로드
쿼리
부가 가치 테스트

Image shows the four test environment stages: Setup, Data loading, Querying, and Value added tests.

설정

다음 단계에 따라 Azure Synapse에서 POC를 설정할 수 있습니다.

이 빠른 시작을 사용하여 Synapse 작업 영역을 프로비저닝하고 POC 테스트 계획에 따라 스토리지 및 권한을 설정합니다.
이 빠른 시작을 사용하여 전용 SQL 풀을 Synapse 작업 영역에 추가합니다.
요구 사항에 따라 네트워킹 및 보안을 설정합니다.
POC 팀 구성원에게 적절한 액세스 권한을 부여합니다. 전용 SQL 풀에 액세스하기 위한 인증 및 권한 부여에 대한 이 문서를 참조하세요.

팁

DW500c 서비스 수준(또는 그 이하)을 사용하여 코드 및 단위 테스트를 개발하는 것이 좋습니다. DW1000c 서비스 수준(또는 그 이상)을 사용하여 부하 및 성능 테스트를 실행하는 것이 좋습니다. 언제든지 전용 SQL 풀의 컴퓨팅을 일시 중지하여 컴퓨팅 청구를 중지할 수 있으므로 비용이 절감됩니다.

데이터 로드

전용 SQL 풀을 설정했으면 다음 단계에 따라 데이터를 로드할 수 있습니다.

데이터를 Azure Blob Storage에 로드합니다. POC의 경우 LRS(로컬 중복 스토리지)와 함께 범용 V2 스토리지 계정을 사용하는 것이 좋습니다. Azure Blob Storage로 데이터를 마이그레이션하기 위한 여러 도구가 있지만 가장 쉬운 방법은 파일을 스토리지 컨테이너에 복사할 수 있는 Azure Storage Explorer를 사용하는 것입니다.
전용 SQL 풀에 데이터를 로드합니다. Azure Synapse는 PolyBase 및 COPY 문이라는 두 가지 T-SQL 로드 방법을 지원합니다. SSMS를 사용하여 전용 SQL 풀에 연결하여 두 방법 중 하나를 사용할 수 있습니다.

전용 SQL 풀에 데이터를 처음 로드하는 경우 사용할 분산 패턴 및 인덱스 옵션을 고려해야 합니다. 전용 SQL 풀은 두 가지를 모두 지원하지만 기본 설정을 사용하는 것이 가장 좋습니다. 기본 설정은 라운드 로빈 배포 및 클러스터형 columnstore 인덱스를 사용합니다. 필요한 경우 이 문서의 뒷부분에서 설명하는 이러한 설정을 나중에 조정할 수 있습니다.

다음 예는 COPY 로드 방법을 보여 줍니다.

--Note when specifying the column list, input field numbers start from 1
COPY INTO
    test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
    'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
    FILE_TYPE = 'CSV',
    CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
    FIELDQUOTE = '"',
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '0x0A',
    ENCODING = 'UTF8',
    FIRSTROW = 2
);

쿼리

데이터 웨어하우스의 주요 목적은 데이터 웨어하우스를 쿼리해야 하는 분석을 수행하는 것입니다. 대부분의 POC는 데이터 웨어하우스에 대해 소수의 대표 쿼리를 처음에는 순차적으로 실행한 다음 동시에 실행하는 것으로 시작합니다. 테스트 계획에서 두 방법을 모두 정의해야 합니다.

순차적 쿼리 테스트

SSMS에서 순차적 쿼리 테스트를 실행하는 것은 쉽습니다. 충분히 큰 리소스 클래스가 있는 사용자를 통해 이러한 테스트를 실행하는 것이 중요합니다. 리소스 클래스는 쿼리 실행을 위한 컴퓨팅 리소스 및 동시성을 제어하는 전용 SQL 풀에서 미리 결정된 리소스 제한입니다. 간단한 쿼리의 경우 사전 정의된 staticrc20 리소스 클래스를 사용하는 것이 좋습니다. 더 복잡한 쿼리의 경우 사전 정의된 staticrc40 리소스 클래스를 사용하는 것이 좋습니다.

다음 첫 번째 쿼리는 쿼리 레이블을 사용하여 쿼리를 추적하는 메커니즘을 제공합니다. 두 번째 쿼리는 sys.dm_pdw_exec_requests 동적 관리 뷰를 사용하여 레이블로 쿼리합니다.

/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
    *
FROM
    [dbo].[Date]
OPTION (LABEL = 'Test1');

/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
    Total_elapsed_time AS [Elapsed_Time_ms],
    [label]
FROM
    sys.dm_pdw_exec_requests
WHERE
    [label] = 'Test1';

동시 쿼리 테스트

순차적 쿼리 성능을 기록한 후 여러 쿼리를 동시에 실행할 수 있습니다. 이러한 방식으로 전용 SQL 풀에 대해 실행되는 비즈니스 인텔리전스 워크로드를 시뮬레이션할 수 있습니다. 이 테스트를 실행하는 가장 쉬운 방법은 스트레스 테스트 도구를 다운로드하는 것입니다. 가장 널리 사용되는 도구는 타사 오픈 소스 도구인 Apache JMeter입니다.

이 도구는 지정된 동시성 수준에 대한 최소, 최대 및 중간 쿼리 기간에 대해 보고합니다. 예를 들어, 100개의 동시 쿼리를 생성하는 비즈니스 인텔리전스 워크로드를 시뮬레이션한다고 가정합니다. 루프에서 100개의 동시 쿼리를 실행한 다음 정상 상태 실행을 검토하도록 JMeter를 설정할 수 있습니다. 결과 집합 캐싱을 설정하거나 해제하여 해당 기능의 적합성을 평가할 수 있습니다.

결과를 문서화합니다. 다음은 일부 결과의 예입니다.

동시성	# 쿼리 실행	DWU	최소 기간(초)	최대 기간(초)	중간 기간(초)
100	1,000	5,000	3	10	5
50	5,000	5,000	3	6	4

혼합 워크로드 테스트

혼합 워크로드 테스트는 동시 쿼리 테스트의 확장입니다. 워크로드 조합에 데이터 로딩 프로세스를 추가하면 워크로드가 실제 프로덕션 워크로드를 더 잘 시뮬레이션할 수 있습니다.

데이터 최적화

Azure Synapse에서 실행되는 쿼리 워크로드에 따라 데이터 웨어하우스의 배포 및 인덱스를 최적화하고 테스트를 다시 실행해야 할 수 있습니다. 자세한 내용은 Azure Synapse Analytics의 전용 SQL 풀에 대한 모범 사례를 참조하세요.

설정 중에 볼 수 있는 가장 일반적인 실수는 다음과 같습니다.

대규모 쿼리는 너무 낮은 리소스 클래스로 실행됩니다.
전용 SQL 풀 서비스 수준 DWU가 워크로드에 비해 너무 낮습니다.
큰 테이블에는 해시 배포가 필요합니다.

쿼리 성능을 개선하기 위해 다음을 수행할 수 있습니다.

공통 집계와 관련된 쿼리를 가속화할 수 있는 구체화된 뷰를 만듭니다.
특히 작은 차원 테이블의 경우 테이블 복제.
조인되거나 집계된 대규모 팩트 테이블을 해시 배포.

부가 가치 테스트

쿼리 성능 테스트가 완료되면 특정 기능을 테스트하여 의도한 사용 사례를 충족하는지 확인하는 것이 좋습니다. 다음과 같은 기능이 있습니다.

마지막으로 POC 결과를 해석해야 합니다.

POC 결과 해석

데이터 웨어하우스에 대한 테스트 결과가 있으면 해당 데이터를 해석하는 것이 중요합니다. 사용할 수 있는 일반적인 방법은 가격/성능 측면에서 실행을 비교하는 것입니다. 간단히 말해서 가격/성능은 DWU 또는 서비스 하드웨어당 가격 차이를 제거하고 각 성능 테스트에 대해 하나의 비교 가능한 수치를 제공합니다.

예를 들면 다음과 같습니다.

테스트	테스트 지속 시간	DWU	DWU의 경우 $/시간	테스트 비용
테스트 1	10분	1000	$12/시간	$2
테스트 2	30분	500	$6/시간	$3

이 예를 통해 DWU1000의 테스트 1이 테스트 실행당 $3에 비해 테스트 실행당 $2로 비용 효율적이라는 것을 쉽게 알 수 있습니다.