Teradata 마이그레이션에 대한 보안, 액세스 및 작업

이 문서는 Teradata에서 Azure Synapse Analytics로 마이그레이션하는 방법에 대한 지침을 제공하는 7부작 시리즈 중 3부입니다. 이 문서는 보안 액세스 작업에 대한 모범 사례에 중점을 두고 있습니다.

보안 고려 사항

이 문서에서는 기존 레거시 Teradata 환경의 연결 방법과 위험 및 사용자 영향을 최소화하면서 기존 연결 방법을 Azure Synapse Analytics로 마이그레이션하는 방법에 대해 설명합니다.

이 문서에서는 기존 연결 방법 및 사용자/역할/권한 구조를 있는 그대로 마이그레이션해야 하는 요구 사항이 있다고 가정합니다. 그렇지 않은 경우 Azure Portal을 사용하여 새 보안 체제를 만들고 관리합니다.

Azure Synapse 보안 옵션에 대한 자세한 내용은 보안 백서를 참조하세요.

연결 및 인증

Teradata 권한 부여 옵션

Teradata는 연결 및 권한 부여를 위한 여러 메커니즘을 지원합니다. 유효한 메커니즘 값은 다음과 같습니다.

• TD1은 인증 메커니즘으로 Teradata 1을 선택합니다. 사용자 이름과 암호가 필요합니다.

• TD2는 인증 메커니즘으로 Teradata 2를 선택합니다. 사용자 이름과 암호가 필요합니다.

• TDNEGO는 사용자의 개입 없이 정책에 따라 자동으로 인증 메커니즘 중 하나를 선택합니다.

• LDAP- LDAP는 LDAP(Lightweight Directory Access Protocol)를 인증 메커니즘으로 선택합니다. 애플리케이션은 사용자 이름과 암호를 제공합니다.

• KRB5는 Windows 서버에서 작업하는 Windows 클라이언트에서 Kerberos(KRB5)를 선택합니다. KRB5를 사용하여 로그인하려면 사용자가 도메인, 사용자 이름 및 암호를 제공해야 합니다. 도메인은 사용자 이름을 MyUserName@MyDomain으로 설정하여 지정됩니다.

• NTLM은 Windows 서버에서 작업하는 Windows 클라이언트에서 NTLM을 선택합니다. 애플리케이션은 사용자 이름과 암호를 제공합니다.

Kerberos(KRB5), Kerberos Compatibility(KRB5C), NTLM(NT LAN Manager) 및 NTLMC(NT LAN Manager Compatibility)는 Windows 전용입니다.

Azure Synapse 권한 부여 옵션

Azure Synapse는 연결 및 권한 부여에 대한 두 가지 기본 옵션을 지원합니다.

• SQL 인증: SQL 인증은 데이터베이스 식별자, 사용자 ID 및 암호와 기타 선택적 매개 변수를 포함하는 데이터베이스 연결을 통해 수행됩니다. 이는 Teradata TD1, TD2 및 기본 연결과 기능적으로 동일합니다.

• Microsoft Entra 인증: Microsoft Entra 인증을 사용하면 데이터베이스 사용자 및 다른 Microsoft 서비스의 ID를 하나의 중앙 위치에서 관리할 수 있습니다. 중앙 ID 관리는 SQL Data Warehouse 사용자 관리를 위한 단일 위치를 제공하며 권한 관리를 간소화합니다. Microsoft Entra ID는 LDAP 및 Kerberos 서비스에 대한 연결도 지원할 수 있습니다. 예를 들어 데이터베이스 마이그레이션 후 그대로 유지되는 경우 Microsoft Entra ID를 사용하여 기존 LDAP 디렉터리에 연결할 수 있습니다.

사용자 역할 및 권한

개요

Teradata와 Azure Synapse는 모두 사용자, 역할 및 권한의 조합을 통해 데이터베이스 액세스 제어를 구현합니다. 둘 다 표준 SQL CREATE USER 및 CREATE ROLE 문을 사용하여 사용자 및 역할을 정의하고, GRANT 및 REVOKE 문을 사용하여 해당 사용자 및/또는 역할에 권한을 할당하거나 제거합니다.

개념적으로 두 데이터베이스는 비슷하며 기존 사용자 ID, 역할 및 권한의 마이그레이션을 어느 정도 자동화할 수 있습니다. Teradata 시스템 카탈로그 테이블에서 기존 레거시 사용자 및 그룹 정보를 추출하고 동일한 사용자/역할 계층 구조를 다시 만들기 위해 Azure Synapse에서 실행할 일치하는 동일한 CREATE USER 및 CREATE ROLE 문을 생성하여 이러한 데이터를 마이그레이션합니다.

데이터 추출 후에는 Teradata 시스템 카탈로그 테이블을 사용하여 동일한 GRANT 문을 생성하여 권한을 할당합니다(해당하는 명령문이 있는 경우). 다음 다이어그램에서는 기존 메타데이터를 사용하여 필요한 SQL을 생성하는 방법을 보여줍니다.

사용자 및 역할

Teradata 시스템의 현재 사용자 및 역할에 대한 정보는 시스템 카탈로그 테이블 DBC.USERS(또는 DBC.DATABASES) 및 DBC.ROLEMEMBERS에 있습니다. 이러한 테이블을 쿼리하여(사용자가 해당 테이블에 대한 SELECT 액세스 권한을 갖고 있는 경우) 시스템 내에 정의된 현재 사용자 및 역할 목록을 가져옵니다. 다음은 개별 사용자에 대해 이 작업을 수행하는 쿼리의 예입니다.

/***SQL to find all users***/
SELECT
DatabaseName AS UserName
FROM DBC.Databases
WHERE dbkind = 'u';

/***SQL to find all roles***/
SELECT A.ROLENAME, A.GRANTEE, A.GRANTOR,
  A.DefaultRole, 
  A.WithAdmin,
  B.DATABASENAME, 
  B.TABLENAME,
  B.COLUMNNAME, 
  B.GRANTORNAME,
  B.AccessRight
FROM DBC.ROLEMEMBERS A 
JOIN DBC.ALLROLERIGHTS B 
ON A.ROLENAME = B.ROLENAME 
GROUP BY 1,2,3,4,5,6,7
ORDER BY 2,1,6;

이러한 예제는 SELECT 문 내에 적절한 텍스트를 리터럴로 포함하여 일련의 CREATE USER 및 CREATE ROLE 문의 결과 집합을 생성하도록 SELECT 문을 수정합니다.

기존 암호를 검색할 수 있는 방법이 없으므로, Azure Synapse에서 새로운 초기 암호를 할당하기 위한 체계를 구현해야 합니다.

사용 권한

Teradata 시스템에서는 사용자 및 역할에 대한 액세스 권한이 시스템 테이블 DBC.ALLRIGHTS 및 DBC.ALLROLERIGHTS에 보관됩니다. 이러한 테이블을 쿼리하여(사용자가 해당 테이블에 대한 SELECT 액세스 권한을 갖고 있는 경우) 시스템 내에 정의된 현재 액세스 권한 목록을 가져옵니다. 다음은 개별 사용자에 대한 쿼리의 예입니다.

/**SQL for AccessRights held by a USER***/
SELECT UserName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE 
ALRTS.AccessRight
END AS AccessRight, GrantAuthority, GrantorName, AllnessFlag, CreatorName, CreateTimeStamp
FROM DBC.ALLRIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv Abbv
ON ALRTS.AccessRight = Abbv.AccessRight 
WHERE UserName='UserXYZ'
Order By 2,3,4,5;

/**SQL for AccessRights held by a ROLE***/
SELECT RoleName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE 
ALRTS.AccessRight
END AS AccessRight, GrantorName, CreateTimeStamp
FROM DBC.ALLROLERIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv
Abbv
ON ALRTS.AccessRight = Abbv.AccessRight 
WHERE RoleName='BI_DEVELOPER'
Order By 2,3,4,5;

SELECT 문 내에 적절한 텍스트를 리터럴로 포함하여 일련의 GRANT 문의 결과 집합을 생성하도록 이러한 예제 SELECT 문을 수정합니다.

조인 키가 축약된 ‘type’ 필드이므로 표 AccessRightsAbbv를 사용하여 액세스 권한의 전체 텍스트를 조회합니다. Teradata 액세스 권한과 이에 해당하는 Azure Synapse 액세스 권한 목록은 다음 표를 참조하세요.

AccessRightsAbbv 테이블 참고 사항:

1. Teradata PROFILE은 기능적으로 Azure Synapse의 LOGIN과 동일합니다.

2. 다음 표에는 Teradata의 매크로와 저장 프로시저 간의 차이점이 요약되어 있습니다. Azure Synapse에서 프로시저는 표에 설명된 기능을 제공합니다.

   Macro	저장 프로시저
   SQL 포함	SQL 포함
   BTEQ dot 명령을 포함할 수 있음	포괄적인 SPL 포함
   전달된 매개 변수 값을 받을 수 있음	전달된 매개 변수 값을 받을 수 있음
   하나 이상의 행을 검색할 수 있음	커서를 사용하여 둘 이상의 행을 검색해야 함
   DBC PERM 공간에 저장됨	DATABASE 또는 USER PERM에 저장됨
   클라이언트에 행을 반환	하나 이상의 값을 매개 변수로 클라이언트에 반환할 수 있음

3. SHOW, GLOP 및 TRIGGER는 Azure Synapse에 대등한 항목이 없습니다.

4. 이러한 기능은 Azure Synapse의 시스템에서 자동으로 관리됩니다. 운영 고려 사항을 참조하세요.

5. Azure Synapse에서 이러한 기능은 데이터베이스 외부에서 처리됩니다.

Azure Synapse에서의 액세스 권한에 대한 자세한 내용은 Azure Synapse Analytics 보안 권한을 참조하세요.

운영상의 고려 사항

이 섹션에서는 사용자에게 미치는 위험과 영향을 최소화하면서 Azure Synapse에서 일반적인 Teradata 운영 작업을 구현하는 방법에 대해 설명합니다.

모든 데이터 웨어하우스 제품과 마찬가지로, 프로덕션 환경으로 전환한 이후에는 시스템을 효율적으로 실행하고 모니터링 및 감사 데이터를 제공하는 데 필요한 지속적인 관리 작업이 있습니다. 향후 성장을 위한 리소스 사용률 및 용량 계획도 데이터의 백업/복원과 마찬가지로 이 범주에 속합니다.

개념적으로는 다양한 데이터 웨어하우스에 대한 관리 및 운영 작업이 비슷하지만, 개별 구현은 다를 수 있습니다. 일반적으로 Azure Synapse 같은 최신 클라우드 기반 제품은 Teradata와 같은 레거시 데이터 웨어하우스의 보다 “수동”적인 접근 방식과 달리 보다 자동화된 “시스템 관리형” 접근 방식을 통합하는 경향이 있습니다.

다음 섹션에서는 다양한 운영 작업에 대한 Teradata 및 Azure Synapse 옵션을 비교합니다.

하우스키핑 작업

대부분의 레거시 데이터 웨어하우스 환경에서는 이전 버전의 업데이트되거나 삭제된 행을 제거하거나 효율성을 위해 데이터 로그 파일 또는 인덱스 블록을 다시 구성하여 디스크 스토리지 공간을 회수하는 것과 같은 정기적인 “하우스키핑” 작업을 수행해야 합니다. 통계 수집은 잠재적으로 시간이 많이 걸리는 작업이기도 합니다. 통계 수집은 대량 데이터 수집 후에 쿼리 최적화 프로그램에 쿼리 실행 계획 세대의 기반이 될 최신 데이터를 제공하기 위해 필요한 작업입니다.

Teradata는 다음과 같은 통계 수집을 권장합니다.

• 채워지지 않은 테이블에 대한 통계를 수집하여 내부 처리에 사용되는 간격 히스토그램을 설정합니다. 이 초기 수집을 사용하면 후속 통계 수집이 더 빨라집니다. 데이터가 추가된 후에는 반드시 통계를 다시 수집합니다.

• 새로 채워진 테이블에 대한 프로토타입 단계 통계를 수집합니다.

• 테이블 또는 파티션의 상당한 변화(전체 행의 ~10%) 후의 프로덕션 단계 통계를 수집합니다. 날짜 또는 타임스탬프와 같은 고유하지 않은 값이 많은 경우 7%에서 다시 수집하는 것이 유리할 수 있습니다.

• 사용자를 만들고 실제 쿼리 로드를 데이터베이스에 적용한 후 프로덕션 단계 통계를 수집합니다(최대 약 3개월의 쿼리).

• CPU 사용률이 낮은 기간 동안 업그레이드 또는 마이그레이션한 이후에 처음 몇 주 동안 통계를 수집합니다.

통계 수집은 자동화된 통계 관리 오픈 API를 사용하거나 Teradata Viewpoint Stats Manager 포틀릿을 사용하여 수동으로 관리할 수 있습니다.

Teradata Database의 Data Dictionary에는 자동으로 또는 특정 기능이 활성화된 후에 데이터를 누적하는 여러 로그 테이블이 포함되어 있습니다. 로그 데이터는 시간이 지날수록 커지기 때문에 영구 공간을 사용하지 않도록 이전 정보를 제거해야 합니다. 사용 가능한 로그의 유지 관리를 자동화하는 옵션이 있습니다. 다음에는 유지 관리가 필요한 Teradata 사전 테이블에 대해 설명합니다.

유지 관리할 사전 테이블

소프트웨어와 함께 제공되는 DBC.AMPUsage 뷰 및 ClearPeakDisk 매크로를 사용하여 누적기 및 최댓값을 다시 설정합니다.

• DBC.Acctg: 계정/사용자별 리소스 사용량

• DBC.DataBaseSpace: 데이터베이스 및 테이블 공간 회계

Teradata는 이러한 테이블을 자동으로 유지 관리하지만 잘 사용하면 크기를 줄일 수 있습니다.

• DBC.AccessRights: 개체에 대한 사용자 권한

• DBC.RoleGrants: 개체에 대한 역할 권한

• DBC.Roles: 정의된 역할

• DBC.Accounts: 사용자별 계정 코드

이러한 로깅 테이블을 보관하고(원하는 경우) 60-90일이 지난 정보를 제거합니다. 보존은 고객 요구 사항에 따라 달라집니다.

• DBC.SW_Event_Log: 데이터베이스 콘솔 로그

• DBC.ResUsage: 리소스 모니터링 테이블

• DBC.EventLog: 세션 로그온/로그오프 기록

• DBC.AccLogTbl: 로그된 사용자/개체 이벤트

• DBC.DBQL tables: 로그된 사용자/SQL 활동

• .NETSecPolicyLogTbl: 동적 보안 정책 감사 내역을 로그에 기록

• .NETSecPolicyLogRuleTbl: 동적 보안 정책이 기록되는 시기 및 방법을 제어

연결된 이동식 미디어가 만료되고 덮어쓰여지면 이러한 테이블을 제거합니다.

• DBC.RCEvent보관/복구 이벤트

• DBC.RCConfiguration: 보관/복구 구성

• DBC.RCMedia: 보관/복구를 위한 VolSerial

Azure Synapse에는 필요에 따라 사용할 수 있도록 자동으로 통계를 만드는 옵션이 있습니다. 인덱스 및 데이터 블록의 조각 모음을 수동으로, 예약된 시간에 또는 자동으로 수행합니다. 기본 제공 Azure 기능을 활용하면 마이그레이션 실행에 드는 수고를 줄일 수 있습니다.

모니터링 및 감사

Teradata는 Teradata Viewpoint 및 Ecosystem Manager를 포함하여 작업을 모니터링하는 여러 도구를 제공합니다. 쿼리 기록을 로깅하기 위한 DBQL(데이터베이스 쿼리 로그)은 사용자 정의 규칙에 따라 쿼리의 기록 레코드와 해당 기간, 성능 및 대상 작업을 저장할 수 있는 일련의 미리 정의된 테이블을 제공하는 Teradata 데이터베이스 기능입니다.

데이터베이스 관리자는 Teradata Viewpoint를 사용하여 시스템 상태, 추세 및 개별 쿼리 상태를 확인할 수 있습니다. 시스템 사용량 추세를 관찰하여 시스템 관리자는 프로젝트 구현, 일괄 처리 작업 및 사용량 피크 기간을 방지하기 위한 유지 관리를 더 잘 계획할 수 있습니다. 비즈니스 사용자는 Teradata Viewpoint를 사용하여 보고서 및 쿼리의 상태에 빠르게 액세스하고 세부 정보로 드릴다운할 수 있습니다.

마찬가지로, Azure Synapse는 Azure Portal 내에서 데이터 웨어하우스 워크로드에 대한 인사이트를 제공하는 다양한 모니터링 환경을 제공합니다. 데이터 웨어하우스를 모니터링할 때는 구성 가능한 보존 기간, 경고, 권장 사항, 메트릭과 로그용 사용자 지정 가능한 차트 및 대시보드를 제공하는 도구인 Azure Portal을 사용하는 것이 좋습니다.

또한 이 포털을 통해 OMS(Operations Management Suite) 및 Azure Monitor(로그)와 같은 다른 Azure 모니터링 서비스와 통합하여 데이터 웨어하우스뿐만 아니라 Azure 분석 플랫폼 전체에 대한 전체적인 모니터링 환경을 제공함으로써 통합된 모니터링 환경을 구현할 수 있습니다.

Azure Synapse의 리소스 사용률 통계는 시스템 내에 자동으로 기록됩니다. 각 쿼리에 대한 메트릭에는 CPU, 메모리, 캐시, I/O 및 임시 작업 영역의 사용 통계와 실패한 연결 시도와 같은 연결 정보가 포함됩니다.

Azure Synapse는 DMV(동적 관리 뷰) 세트를 제공합니다. 이러한 보기는 워크로드로 인한 성능 병목 상태를 적극적으로 해결하고 식별할 때 유용합니다.

자세한 내용은 Azure Synapse 운영 및 관리 옵션을 참조하세요.

HA(고가용성) 및 DR(재해 복구)

Teradata는 ARC(보관 복원 복사본) 유틸리티 및 DSA(데이터 스트림 아키텍처)와 같은 FALLBACK기능을 구현하여 데이터 복제 및 보관을 통해 HA(데이터 손실 및 고가용성)를 방지합니다. DR(재해 복구) 옵션에는 복구 시간 요구 사항에 따라 이중 활성 솔루션, 서비스형 DR 또는 교체 시스템이 포함됩니다.

Azure Synapse는 데이터베이스 스냅샷을 사용하여 웨어하우스의 고가용성을 제공합니다. 데이터 웨어하우스 스냅샷은 데이터 웨어하우스를 복구하거나 이전 상태로 복사하는 데 사용할 수 있는 복원 지점을 만듭니다. Azure Synapse이 분산 시스템이므로 데이터 웨어하우스 스냅샷은 Azure Storage에 있는 여러 파일로 구성됩니다. 스냅샷은 데이터 웨어하우스에 저장된 데이터의 증분 변경 내용을 캡처합니다.

Azure Synapse는 하루 종일 자동으로 스냅샷을 만들고, 7일 동안 사용할 수 있는 복원 지점을 만듭니다. 이 보존 기간은 변경할 수 없습니다. Azure Synapse는 8시간 RPO(복구 지점 목표)를 지원합니다. 지난 7일 동안 만든 스냅샷 중 하나의 주 지역에 데이터 웨어하우스를 복원할 수 있습니다.

사용자 정의 복원 지점도 지원되므로, 스냅샷을 수동으로 트리거하여 대량 수정 전과 후에 데이터 웨어하우스의 복원 지점을 만들 수 있습니다. 이 기능은 복원 지점을 논리적으로 일관되게 유지하여 워크로드 중단 또는 사용자 오류 발생 시 8시간 미만의 목표 RPO를 달성할 수 있도록 추가적인 데이터 보호를 제공합니다.

앞에서 설명한 스냅샷 외에도, Azure Synapse는 쌍을 이루는 데이터 센터에 매일 한 번씩 지역 백업을 표준으로 수행합니다. 지역 복원의 RPO는 24시간입니다. Azure Synapse가 지원되는 다른 지역의 서버로 지역 백업을 복원할 수 있습니다. 지역 백업을 사용하면 주 지역의 복원 지점을 사용할 수 없는 경우 데이터 웨어하우스를 복원할 수 있습니다.

워크로드 관리

워크로드는 일반적인 특성을 가진 데이터베이스 요청의 클래스로 일련의 규칙을 사용해 워크로드의 데이터베이스에 대한 액세스를 관리할 수 있습니다. 워크로드는 다음에 유용합니다.

• 다양한 유형의 요청에 대해 서로 다른 액세스 우선 순위를 설정

• 리소스 사용 패턴, 성능 튜닝 및 용량 계획 모니터링

• 동시에 실행할 수 있는 요청 또는 세션 수 제한

Teradata 시스템에서 워크로드 관리는 시스템 활동을 모니터링하고 미리 정의된 한도에 도달할 때 작동하여 워크로드 성능을 관리하는 작업입니다. 워크로드 관리는 규칙을 사용하며 각 규칙은 일부 데이터베이스 요청에만 적용됩니다. 그러나 모든 규칙의 컬렉션은 플랫폼의 모든 활성 작업에 적용됩니다. TASM(Teradata Active System Management)은 Teradata 데이터베이스에서 전체 워크로드 관리를 수행합니다.

Azure Synapse에서 리소스 클래스는 쿼리 실행을 위한 컴퓨팅 리소스와 동시성을 관리하는 미리 결정된 리소스 제한입니다. 리소스 클래스를 사용하면 동시에 실행되는 쿼리 수와 각 쿼리에 할당되는 컴퓨팅 리소스에 대한 제한을 설정하여 워크로드를 관리할 수 있습니다. 메모리와 동시성 사이에는 장단점이 있습니다.

Azure Synapse는 리소스 사용률 통계를 자동으로 기록합니다. 메트릭에는 각 쿼리에 대한 CPU, 메모리, 캐시, I/O 및 임시 작업 영역에 대한 사용 통계가 포함됩니다. Azure Synapse는 실패한 연결 시도와 같은 연결 정보도 기록합니다.

Azure Synapse는 다음과 같은 기본 워크로드 관리 개념을 지원합니다.

• 워크로드 분류: 중요도 수준을 설정하기 위해 워크로드 그룹에 요청을 할당할 수 있습니다.

• 워크로드 중요도: 요청이 리소스에 액세스하는 순서에 영향을 줄 수 있습니다. 기본적으로 쿼리는 리소스를 사용할 수 있게 되면 선입선출 방식으로 큐에서 해제됩니다. 워크로드 중요도를 통해 우선 순위가 높은 쿼리가 큐와 관계없이 즉시 리소스를 받을 수 있습니다.

• 워크로드 격리: 워크로드 그룹에 대한 리소스를 예약하고, 다양한 리소스에 대해 최대 및 최소 사용량을 할당하고, 요청 그룹이 사용할 수 있는 리소스를 제한하고, 런어웨이 쿼리를 자동으로 종료하도록 시간 제한 값을 설정할 수 있습니다.

혼합된 워크로드를 실행하면 사용량이 많은 시스템에서 리소스 문제가 발생할 수 있습니다. 성공적인 워크로드 관리 체계는 리소스를 효과적으로 관리하고, 매우 효율적인 리소스 사용률을 보장하며, ROI(투자 수익률)를 극대화합니다. 워크로드 분류, 워크로드 중요도 및 워크로드 격리를 통해 워크로드가 시스템 리소스를 활용하는 방법을 더 잘 제어할 수 있습니다.

워크로드 관리 가이드에서는 워크로드를 분석하고 워크로드 중요도를 관리 및 모니터링하는 기술을 설명합니다.](../../sql-data-warehouse/sql-data-warehouse-how-to-manage-and-monitor-workload-importance.md) 및 리소스 클래스를 워크로드 그룹으로 변환하는 단계입니다. Azure Portal 및 DMV의 T-SQL 쿼리를 사용하여 해당 리소스가 효율적으로 활용되도록 워크로드를 모니터링합니다. Azure Synapse 워크로드 관리의 모든 측면을 모니터링하기 위한 DMV(동적 관리 뷰) 세트를 제공합니다. 이러한 보기는 워크로드의 성능 병목 상태를 적극적으로 해결하고 식별할 때 유용합니다.

이 정보는 추가 사용자 또는 애플리케이션 워크로드에 필요한 리소스를 결정하는 용량 계획에도 사용할 수 있습니다. “피크” 워크로드를 비용 효율적으로 지원하기 위한 컴퓨팅 리소스의 스케일 업/스케일 다운 계획에도 적용됩니다.

Azure Synapse의 워크로드 관리에 대한 자세한 내용은 리소스 클래스를 사용한 워크로드 관리를 참조하세요.

컴퓨팅 리소스 스케일링

Azure Synapse의 아키텍처는 스토리지와 컴퓨팅을 분리하므로, 각각 독립적으로 스케일링할 수 있습니다. 따라서 데이터 스토리지에 관계없이 성능 요구 사항에 맞게 컴퓨팅 리소스를 스케일링할 수 있습니다. 또한 컴퓨팅 리소스를 일시 중지했다가 다시 시작할 수도 있습니다. 이 아키텍처의 태생적 이점은 컴퓨팅 요금과 스토리지 요금이 각각 따로 청구된다는 것입니다. 데이터 웨어하우스를 사용하지 않는 경우 컴퓨팅을 일시 중지하여 컴퓨팅 비용을 절감할 수 있습니다.

데이터 웨어하우스의 데이터 웨어하우스 단위 설정을 조정하여 컴퓨팅 리소스를 스케일 업 또는 스케일 백할 수 있습니다. 데이터 웨어하우스 단위를 추가하면 로드 및 쿼리 성능이 선형적으로 증가합니다.

컴퓨팅 노드를 추가하면 컴퓨팅 성능과 더 많은 병렬 처리를 활용할 수 있는 기능이 추가됩니다. 컴퓨팅 노드 수가 늘어나면 컴퓨팅 노드당 배포 수가 줄어들어 쿼리에 더 많은 컴퓨팅 및 병렬 처리 성능이 제공됩니다. 마찬가지로, 데이터 웨어하우스 단위를 줄이면 컴퓨팅 노드 수가 줄어들어 쿼리에 제공되는 컴퓨팅 리소스가 줄어듭니다.

다음 단계

시각화 및 보고에 대한 자세한 내용은 이 시리즈의 다음 문서인 Teradata 마이그레이션에 대한 시각화 및 보고를 참조하세요.