sql server white paper templatedownload.microsoft.com/download/8/d/a/8da25dfb-0de8-497… · web...
TRANSCRIPT
SQL Server White Paper Template
SSIS 작업 및 조정 가이드
SQL Server 기술 문서
작성자: Alexei Khalyako, Carla Sabotta, Silvano Coriani, Sreedhar Pelluru, Steve Howard
기술 관련 검토자: Cindy Gross, David Pless, Mark Simms, Daniel Sol
게시일: 2012년 12월
적용 대상: SQL Server 2012, Windows Azure SQL 데이터베이스
요약: SSIS(SQL Server Integration Services)는 전체적인 EFL(추출, 변환 및 로드) 솔루션과 데이터 이동 솔루션의 일부로서 WA(Windows Azure) SQL 데이터베이스의 데이터를 이동하는 도구로 효과적으로 사용될 수 있습니다. SSIS를 효과적으로 사용하여 클라우드에서 원본과 대상 간에 데이터를 이동하고 하이브리드 시나리오에서 클라우드와 온-프레미스 간에 데이터를 이동할 수 있습니다. 이 백서에서는 클라우드 원본 및 대상에 대한 SSIS 모범 사례를 간략하게 설명합니다. SSIS 프로젝트가 모두 클라우드에 있거나 하이브리드 데이터 이동을 포함하는 경우에 대한 프로젝트 계획을 논의하고 데이터 이동을 확장하여 하이브리드 이동의 성능을 최대화하는 예를 살펴봅니다.
저작권
이 문서는 "있는 그대로" 제공됩니다. URL 및 기타 인터넷 웹 사이트 참조를 포함하여 이 문서의 내용 및 의견은 예고 없이 변경될 수 있습니다. 본 문서의 사용으로 발생하는 위험은 귀하의 책임입니다.
여기에 나와 있는 예제의 일부는 설명 목적으로만 제공되는 가상의 예제이며, 어떠한 실제 사례와도 연관시킬 의도가 없으며 그렇게 유추해서도 안 됩니다.
이 문서는 Microsoft 제품의 지적 재산에 대한 법적 권한을 제공하지 않습니다. 이 문서는 내부 참조용으로만 복사 및 사용할 수 있습니다.
© 2011 Microsoft. All rights reserved.
목차소개5프로젝트 디자인5문제 범위 및 설명5Azure에서 데이터 이동이 매우 중요한 이유6주요 데이터 이동 시나리오7온-프레미스에서 클라우드로 초기 데이터 로드 및 마이그레이션7클라우드에서 생성된 데이터를 온-프레미스 시스템으로 이동8클라우드 서비스 간 데이터 이동9기존 도구, 서비스 및 솔루션9SSIS(SQL Server Integration Services)10ADO.NET의 SqlBulkCopy 클래스10대량 복사 프로그램(BCP.EXE)11Azure 저장소 Blob 및 큐12디자인 및 구현 선택12부하 분산 아키텍처 디자인 및 구현13데이터 형식 고려 사항14솔루션 패키징 및 배포14이식 가능한 솔루션 만들기15패키지 및 코드 구성 요소 배포15데이터 이동 대상인 Azure SQL 데이터베이스16아키텍처 고려 사항17파이프라인 진행 작업의 손실 없이 다시 시작하기 위한 디자인17기본 원칙17단일 대상에 대한 예18여러 대상에 대한 예24다시 시작에 대한 기타 팁25수동 개입 없이 다시 시도하기 위한 디자인27다시 시도 통합27SSIS 성능 조정 옵션32네트워크 설정 조정32네트워크 설정32참고: 점보 프레임을 사용하도록 네트워크 인터페이스 카드 설정을 변경하는 경우 네트워크 인프라가 이러한 유형의 프레임을 지원하는지 확인하십시오.33SSIS 패키지 설정34BLOB 데이터에 대한 특별 고려 사항36SSIS 2012의 새로운 기능을 사용하여 분산 시스템에서 성능 모니터링38성능 통계 기록38실행 통계 보기40데이터 흐름 모니터링45결론50
소개
SSIS(SQL Server Integration Services)는 전체 EFL(추출, 변환 및 로드) 솔루션 또는 변환이 필요하지 않은 데이터 이동 솔루션의 일부분으로서 WA(Windows Azure) SQL 데이터베이스의 데이터를 이동하는 데 효과적인 도구입니다. SSIS는 모두 클라우드에 있거나 모두 온-프레미스이거나 하이브리드 솔루션에 혼합되어 있는 다양한 원본과 대상에 효과적입니다. 이 백서에서는 클라우드 원본 및 대상에 대한 SSIS 모범 사례를 간략하게 설명합니다. SSIS 프로젝트가 모두 클라우드에 있거나 하이브리드 데이터 이동을 포함하는 경우에 대한 프로젝트 계획을 논의하고 데이터 이동을 확장하여 하이브리드 이동의 성능을 최대화하는 예를 살펴봅니다
프로젝트 디자인
클라우드와 온-프레미스 데이터 저장소 간에 데이터를 이동하는 프로젝트는 다양한 솔루션 내의 여러 가지 프로세스와 관련될 수 있습니다. 상당 부분은 보통 대상의 초기 채우기에서 시작하며, 파티션 또는 분할된 데이터베이스 수가 변경될 때 데이터 집합의 부하 재분산, 주기적인 대량 데이터 작업 또는 새로 고침 지속 등의 유지 관리를 통해 다른 시스템이나 플랫폼에서 데이터를 가져올 수 있습니다. 클라우드에 데이터를 포함하는 솔루션의 경우 프로젝트 디자인과 기본 가정이 기존의 완전한 온-프레미스 데이터 이동 환경과 다른 경우가 많습니다. 많은 지식, 경험과 구현 방법이 여전히 적용되기는 하지만 상용 리소스가 공유 풀로 이동함에 따라 이제는 더 이상 독립적이고 자신이 완전히 제어할 수 있는 환경이 아니라는 사실과 같은 차이점을 수용하기 위해 변화해야 합니다. 이러한 차이점 때문에 보다 더 부하가 분산되고 확장 가능한 접근 방법이 필요합니다.
문제 범위 및 설명
클라우드용으로 처음부터 작성된 네이티브 솔루션뿐만 아니라 마이그레이션된 솔루션에서도 데이터 이동이 필요합니다. 데이터 이동은 응용 프로그램 수명 주기의 여러 단계에서 발생할 수 있습니다. 이러한 단계에는 프로덕션 전 테스트, 초기 데이터 로드, 클라우드에서 생성된 데이터와 원래 온-프레미스 데이터베이스 간의 이후 데이터 동기화, 클라우드에서 다른 온-프레미스 시스템(예: 데이터 웨어하우스)으로 가져온 데이터 스냅숏 반복이 포함됩니다.
그림 1 데이터 이동 시나리오
이 섹션의 주요 초점은 초기 데이터 로드 단계입니다. 데이터를 원본 데이터베이스에서 추출하여 온-프레미스에서 클라우드로 이동하고 최종 대상으로 로드하는 종단 간 경험을 살펴 봅니다. 중요한 것은 이 백서에 설명된 다수의 모범 사례와 최적화가 최소한의 변경으로 대부분의 설명된 시나리오에 동일하게 적용될 수 있다는 점입니다. 다음 섹션에서 이러한 시나리오와 주요 문제에 대해 살펴보겠습니다.
Azure에서 데이터 이동이 매우 중요한 이유
기존 데이터 센터 환경의 경우 응용 프로그램과 시스템 간 데이터 이동 문제가 일반적으로 응용 프로그램 호환성, 프로세스 오케스트레이션 및 동기화, 그리고 물리적 하드웨어 리소스 및 네트워킹 기능과 같은 문제와 연관된 반면, WA와 같은 클라우드 환경의 경우 여러 가지 복잡한 문제가 겹쳐져 있습니다. 복잡성은 온-프레미스와 클라우드 사이(또는 여러 클라우드 서비스 사이) 연결과 같은 영역에 존재할 수 있으며 연결 안정성, 대역폭 및 대기 시간과 관련될 수 있습니다. 최적의 데이터 이동 솔루션을 개발하려면 이 복잡성을 고려하는 것이 중요합니다. 솔루션에 이동 부분이 아주 많이 포함된 경우 포함된 모든 구성 요소와 기술 사이에 균형 있는 디자인을 찾는 데 집중하는 것이 보다 더 중요합니다. 또한 연결망의 가장 약한 고리로 "폭주"하면 다른 모든 요소에 부정적인 영향을 미치므로 이러한 현상을 방지하도록 노력해야 합니다.
테스트에 근거한 중요한 영역 중 하나는 외부에서 밀어넣은 데이터 양을 데이터 대상이 적절한 속도로 수집하는 능력입니다. 가장 일반적인 방법은 사용자 지정 분할(http://social.technet.microsoft.com/wiki/contents/articles/1926.how-to-shard-with-windows-azure-sql-database.aspx)을 사용하여 대상 데이터베이스를 여러 백 엔드 노드로 확장하는 것입니다. 이 방법은 로드할 데이터 양이 많은 경우(이 백서의 작성 시점에서 20GB/시를 초과하면 많은 것으로 간주됨) 필수적이며, WA VM(가상 컴퓨터)에서 실행되는 SQL Server와 Azure SQL 데이터베이스 인스턴스에 적용될 수 있습니다. 데이터 로드 솔루션에서 선형 확장성은 자동으로 도입되지 않으므로 솔루션의 다른 이동 부분에 대한 균형을 맞출 필요성이 높아집니다. 다음 섹션에서는 최종 결과를 극대화하기 위해 채택할 수 있는 디자인 옵션과 가장 중요한 영역에 대해 설명합니다.
주요 데이터 이동 시나리오
전체적인 종단 간 데이터 이동 경험의 일부로 고려할 세 가지 주요 시나리오는 다음과 같습니다. 이러한 시나리오에는 지금까지 발견한 반복되는 주제와 과제가 대부분 포함되어 있습니다.
· 온-프레미스에서 클라우드로 초기 데이터 로드 및 마이그레이션
· 클라우드에서 생성된 데이터를 온-프레미스 시스템으로 이동
· 클라우드 서비스 간 데이터 이동
온-프레미스에서 클라우드로 초기 데이터 로드 및 마이그레이션
(VM의 SQL Server 또는 SQL 데이터베이스) (그림 2 초기 데이터 로드 시나리오)
온-프레미스 배포에서 클라우드 환경으로 응용 프로그램을 이동하려면 항상 일정한 데이터 양도 이동해야 합니다. 데이터 양이 상당히 커지는 경우 이 작업으로 인한 중요한 문제를 해결하려면 온-프레미스에서 하던 것과는 약간 다른 접근 방법이 필요합니다. 그 이유는 주로 두 가지 영역인 공용 네트워크 대역폭과 대기 시간이며, 데이터 로드 단계를 실행하기 위한 (공유) 리소스 양은 클라우드 환경에서 데이터베이스(Azure SQL 데이터베이스 또는 WA VM)를 호스팅하는 물리적 하드웨어 노드에서 사용 가능합니다. 원본 데이터를 여러 버킷 파일로 분할하고 이러한 파일을 압축한 다음 네트워크를 통해 전송하는 것과 같은 구체적인 접근 방법(그림 2 참조)을 통해 전체 솔루션에서 가장 수행되지 않는 구성 요소의 영향을 최소화할 수 있습니다. 데이터를 분할하면 또한 클라이언트 쪽에서 용이하게 해당 데이터를 데이터 대상에 삽입할 수 있으므로 여러 Azure SQL 데이터베이스 인스턴스 사이에 분할되거나 여러 WA VM에서 호스팅될 가능성이 많습니다.
SSIS는 가져오기 및 내보내기 작업을 실제로 실행하기 위해 온-프레미스와 클라우드 양쪽에서 주요한 역할을 합니다. 전체 솔루션에서 SSIS 가져오기 프로세스의 여러 인스턴스 간에 중간 파일 형식을 저장하고 복사본을 오케스트레이션하며 작업을 검색하려면 Azure Blob 저장소 및 큐와 같은 추가 기술이 필요합니다.
Azure SQL 데이터베이스로 데이터베이스 스키마 및 개체를 마이그레이션하는 작업에 대한 자세한 내용은 Windows Azure로 데이터 중심 응용 프로그램 마이그레이션(http://msdn.microsoft.com/ko-kr/library/windowsazure/jj156154.aspx) 지침을 참조하십시오.
클라우드에서 생성된 데이터를 온-프레미스 시스템으로 이동
전체적인 목표 측면에서 차이점이 있을 수 있지만 기술적 측면에서는 로드 프로세스와 데이터 흐름을 바꾸는 것이므로 이 시나리오는 이전 시나리오를 약간 변형한 형태입니다. 이 시나리오는 일반적으로 데이터 웨어하우스와 같은 온-프레미스 시스템으로 반복적으로 검색되고 로드되어야 하는 클라우드 생성 데이터 또는 로컬 트랜잭션 솔루션에 제공되는 데이터와 관련되어 있습니다. 즉, 이전 섹션에 설명된 기법 및 기술이 대부분 이 시나리오에도 관련되어 있습니다. SSIS가 클라우드 쪽에서 데이터를 추출하여 압축한 다음 온-프레미스 시스템으로 다시 보내면 온-프레미스 시스템에서는 모든 기존 지침을 다시 적용합니다. 자세한 내용은 데이터 로드 성능 가이드(http://msdn.microsoft.com/ko-kr/library/dd425070(v=SQL.100).aspx)를 참조하십시오.
클라우드 서비스 간 데이터 이동
몇 가지 시나리오에서는 여러 클라우드 서비스와 데이터베이스 간에 데이터를 이동해야 합니다. 여기에는 서로 상호 작용해야 하는 여러 솔루션 간에 데이터를 교환하는 작업과 분할된 여러 데이터베이스에서 호스팅된 테이블 간에 분할된 데이터를 다시 분배하는 작업이 (VM의 SQL Server 또는 SQL 데이터베이스) (그림 3 분할된 데이터베이스 간 데이터 이동)포함됩니다.아래의 그림 3을 참조하십시오.
이러한 분할된 데이터베이스는 기본 접근 방법과 아키텍처 변경 없이 WA VM의 Azure SQL 데이터베이스 인스턴스 또는 SQL Server에서 균등하게 호스팅될 수 있습니다. 이전 시나리오와는 다르게 전체 데이터 이동 프로세스가 일반적으로 단일 WA 지역의 경계 안에서 발생하므로 네트워크 대기 시간의 영향이 크게 줄어들고 중간 저장소 위치(로컬 디스크 또는 Azure 저장소)를 통해 데이터를 내보내고 가져와야 할 필요성이 없어집니다. 일부 시나리오에서는 지역 간 데이터 이동이 필요할 수 있지만 이에 대한 설명은 이 백서의 범위를 벗어납니다. 이와 동시에 데이터 원본 및 대상이 공유 클라우드 환경에서 호스팅되고 특히 로드 단계를 신중하게 조정해야 할 필요성이 크게 증가합니다.
기존 도구, 서비스 및 솔루션
이전에 설명한 시나리오들을 처리하는 솔루션을 구현하기 위해 기존 도구와 새 도구를 함께 사용하고 온-프레미스와 클라우드 둘 다에서 도움이 될 수 있는 구성 요소와 접근 방법을 사용할 수 있습니다. 하이브리드 환경에서 일부 구성 요소는 기존 시스템 및 데이터 원본과 함께 온-프레미스에 배치되어야 하지만 다른 구성 요소는 데이터 대상과 함께 클라우드에 배치되는 이점을 얻을 수 있습니다.
SSIS(SQL Server Integration Services)
SSIS는 기본적인 데이터 이동 및 통합 솔루션으로서 이 시나리오 범위에 필요한 대부분의 영역을 처리하는 광범위한 기능을 제공합니다. SSIS 패키지는 하이브리드 환경에 맞게 디자인되지는 않았지만 WA VM의 등장에 따라 온-프레미스와 클라우드 양쪽에서 실행될 수 있으며 이 둘을 잠재적으로 직접 연결할 수 있습니다. 기존의 많은 전문가가 이 기술을 배우고 접하고 있으므로 DBA/ETL 개발자 커뮤니티의 엄청난 지식과 기술 재사용에 대한 기회가 열려 있습니다. 그러나 온-프레미스에서 클라우드로 데이터를 이동할 때 SSIS를 사용하여 구현된 기존 ETL 프로세스를 모두 직접 재사용할 수 있는 것은 아님을 명심해야 합니다.
프로세스 복잡도, 데이터 볼륨 및 속도, WA VM에서 실행되는 SQL Server 및 Azure SQL 데이터베이스와 같은 클라우드 기반 데이터 대상 간의 고유한 차이점에 따라 아키텍처 조정이 어느 정도 필요합니다.
이러한 과제 중 일부는 Windows Azure SQL 데이터베이스에 연결할 때 클라우드 연결 환경을 처리하기에 부족한 능력 또는 데이터 로드 프로세스 중에 오류와 다시 시도를 처리해야 하는 SSIS 패키지를 디자인하는 데 필요한 작업량과 관련될 수 있습니다.
또 다른 문제는 개수가 변경될 수 있는 물리적 노드 간에 데이터베이스 엔터티가 분산된 환경에서 분할된 데이터 대상에 연결해야 하는 패키지 디자인일 수 있습니다. 분할 논리와 메타데이터는 응용 프로그램 구성 파일 또는 데이터 구조를 통해 관리되고 검색되어야 합니다.
SSIS 플랫폼은 이러한 문제를 처리하는 기능을 이미 대부분 갖추고 있습니다. 예를 들어 조건부 분할 및 멀티캐스트 변환과 같은 데이터 흐름 구성 요소를 사용하여 분할 논리를 구현할 수 있습니다.
아키텍처 문제를 처리할 때 보다 복잡한 솔루션을 설계하려면 기존의 시각적 도구 접근 방법을 사용하거나 더욱 자동화된 프로그래밍 방식을 통해 새로운 디자인을 실제적으로 구현하는 노력이 필요합니다. SSIS는 프로그래밍 접근 방식의 경우 변환 파이프라인 내의 사용자 지정 작업 작성에서 패키지 실행에 대한 문제 해결과 디버깅에 도움이 되는 엔진 계측에 이르기까지 완전히 스크립팅 가능한 환경을 제공합니다.
공통 카탈로그 기반의 완전한 모니터링 및 관리 솔루션은 SQL Server 2012 Integration Services 릴리스의 일부로서 분산된 데이터 이동 솔루션을 디자인하고 패키지 실행 통계 및 결과 정보를 수집하는 데 도움을 줍니다.
ADO.NET의 SqlBulkCopy 클래스
사용자 지정 데이터 이동 솔루션 개발이 특정 데이터 이동 문제를 해결하는 기본 방법인 경우 ADO.NET 데이터 액세스 라이브러리 내의 SqlBulkCopy 클래스(http://msdn.microsoft.com/ko-kr/library/system.data.sqlclient.sqlbulkcopy.aspx)가 작업을 수행하는 가장 일반적인 도구 중 하나일 것입니다. ODBC 대량 복사 API에 대한 씬 래퍼로 작성된 이 클래스는 기존 데이터베이스 연결과 데이터 테이블을 입력으로 받아들이고 SQL Server 또는 Azure SQL 데이터베이스로 데이터를 로드하는 빠르고 완전하게 구성 가능한 방법을 제공합니다.
클라우드 기반 데이터 대상과 상호 작용하는 SqlBulkCopy 클래스를 사용하는 경우 중요한 측면은 서버와 상호 작용하는 데 사용되는 기존의 SqlConnection 클래스(http://msdn.microsoft.com/ko-kr/library/system.data.sqlclient.sqlconnection.aspx)를 임시 오류 처리 응용 프로그램 블록(http://msdn.microsoft.com/ko-kr/library/hh680934(v=PandP.50).aspx) 라이브러리의 일부인 보다 적합한 ReliableSqlConnection 클래스(http://msdn.microsoft.com/ko-kr/library/microsoft.practices.enterpriselibrary.windowsazure.transientfaulthandling.sqlazure.reliablesqlconnection(v=pandp.50).aspx)로 쉽게 바꿀 수 있다는 것입니다. 이렇게 하면 기존 또는 새로운 데이터 로드 프로세스에서 다시 시도 논리 메커니즘을 구현하는 작업이 상당히 간단해집니다. 라이브러리의 또 다른 흥미로운 측면은 다양한 연결 조건에 맞게 쉽게 조정하도록 표준 및 사용자 지정 다시 시도 정책을 제공할 수 있다는 점입니다.
SqlBulkCopy 클래스는 로드 프로세스를 거의 모든 조건에 맞게 조정할 수 있도록 필요한 모든 특성과 속성을 노출합니다. 이 문서에서는 데이터 로드 프로세스가 실행될 위치, 프로세스가 가져와야 할 데이터의 양, 프로세스와 데이터 대상 간에 사용할 수 있는 연결의 종류에 따라 일괄 처리 크기를 조정하고 최적화하는 방법에 대해 설명합니다.
SqlBulkCopy 클래스가 데이터를 대상으로 로드하는 방법이 가장 효율적이지 않은 경우는 단일 일괄 처리 내의 데이터 양이 아주 적을 때(예: 일괄 처리당 행 수가 10 ~ 1000개일 때)입니다. 이 경우 SqlBulkCopy 클래스가 데이터 로드 시작 전에 초기 메타데이터 검사를 설정해야 하는 오버헤드가 전체 성능에 영향을 미칠 수 있습니다. 일괄 처리의 크기가 작은 경우 효과적인 방법은 원하는 스키마를 구현하는 TVP(테이블 반환 매개 변수)를 정의하고 “INSERT INTO Destination SELECT * FROM @TVP”를 사용하여 데이터를 로드하는 것입니다.
대량 복사 API를 사용하는 전체 예를 보려면 SqlBulkCopy 클래스 (http://msdn.microsoft.com/ko-kr/library/system.data.sqlclient.sqlbulkcopy.aspx)를 참조하십시오.
대량 복사 프로그램(BCP.EXE)
대량 복사 프로그램(SqlBulkCopy 클래스에서 설명된 동일한 대량 복사 API에서 만들어진 명령줄 유틸리티)은 SQL Server 인스턴스에 데이터를 대량 로드하는 작업에 얼마 동안 사용되어 왔습니다. 이 프로그램은 간단한 데이터 이동 솔루션을 효율적으로 자동화하는 간단하지만 강력한 도구입니다. 이 도구의 주요 이점 중 하나는 쉽게 Azure 계산 노드 또는 VM에서 도구 설치를 자동화하고 기존 스크립트를 사용하여 클라우드 환경에서의 실행에 적응되도록 한다는 것입니다.
반면에 BCP.EXE는 고급 연결 관리 기능을 제공하지 않습니다. 6BCP.EXE는 연결이 불안정하거나 손실을 유발할 수 있는 다시 시도 작업에 따른 안정적인 데이터 이동 작업을 구현할 때 SSIS의 경우와 동일한 노력을 필요로 합니다. 또한 여기에서 언급한 다른 도구와 달리 BCP.EXE는 로컬 드라이브, 매핑된 드라이브 또는 연결된 드라이브에 호스팅된 물리적 파일의 데이터를 가져오거나 내보내야 합니다. 데이터는 원본에서 대상으로 직접 스트리밍할 수 없으며 SSIS 또는 SqlBulkCopy 기반 응용 프로그램에서와 같이 여러 원본에서 데이터를 프로그래밍 방식으로 읽을 수 없습니다.
Azure 저장소 Blob 및 큐
Azure 저장소 기능은 데이터 이동과 관련된 도구는 아니지만 온-프레미스 및 클라우드 프로세스 사이에 중간 저장소를 필요로 하는 복잡한 솔루션을 구현하는 데 분명히 필수적이며 두 환경 간에 단계와 작업을 오케스트레이션하는 데 필수적입니다. Azure 저장소 Blob는 중간 파일을 로드하고 Azure 계산 노드 또는 VM과 온-프레미스로 실행되는 응용 프로그램 간에 이러한 파일을 교환하기 위한 강력한 저장소 메커니즘입니다. Azure 저장소 큐는 데이터 로드 프로세스에서 Azure Blob로 저장된 콘텐츠 및 파일에 대한 액세스를 알리고 조정하는 데 사용할 수 있는 간단한 메시징 도구입니다.
Azure 저장소 Blob와 Azure 저장소 큐는 저장소 계정, 컨테이너, Blob 및 관련 작업과 상호 작용하는 간단한 클래스 집합을 제공하는 .NET Azure 저장소 클라이언트 라이브러리 덕분에 기존 응용 프로그램에 쉽게 통합됩니다. 이 라이브러리는 기본 REST 기반 인터페이스의 세부 사항을 숨기고 온-프레미스 및 클라우드 데이터 간의 연결을 제공합니다. Azure 저장소 큐 및 Blob 사용에 대한 자세한 내용은 큐 저장소 서비스를 사용하는 방법(http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/) 및 .NET에서 Windows Azure Blob 저장소 서비스를 사용하는 방법(http://www.windowsazure.com/en-us/develop/net/how-to-guides/blob-storage/)을 참조하십시오.
디자인 및 구현 선택
하이브리드 데이터 이동 솔루션과 관련된 디자인 및 구현 선택 시 영향을 미칠 수 있는 몇 가지 요인이 있습니다. 아키텍처 의사 결정은 기존 아티팩트 및 프로세스를 재사용할 것인지 아니면 맨 처음부터 시작할 것인지에 따라 가장 크게 영향을 받을 수 있으며 그 다음은 팀원의 기술력과 프로필(예를 들어 가능한 개발자 또는 DBA 여력)에 따라 영향을 받습니다. 팀에 완전한 사용자 지정 솔루션을 프로그래밍 방식으로 만들 기술력이 있습니까? 또는 팀에 기존 ETL 프로세스를 채택할 기술력이 있습니까? 두 경우에서 기존의 온-프레미스 환경에 대한 분명한 가정 중 일부는 클라우드 환경에서 유효하지 않을 수 있기 때문에 클라우드를 디자인에 도입할 때 고려해야 할 몇 가지 사항이 있습니다.
또 다른 중요한 디자인 측면은 분할이나 데이터 압축을 수행하는 조건부 분할 논리와 같은 특정 데이터 이동 작업 및 서비스를 배치하고 실행하는 위치입니다. 이러한 작업이 구성 요소 수준(SSIS 파이프라인 또는 사용자 지정 작업)에서 구현되는 방식에 따라 해당 구성 요소가 CPU를 매우 많이 사용할 수 있습니다. 리소스 사용의 부하를 분산하려면 작업을 Azure VM으로 이동하고 해당 클라우드 환경의 자연스러운 탄력성을 활용하는 것이 적합할 수 있습니다. 이와 동시에 이러한 유형의 솔루션에서 정말 중요할 수 있는 네트워크 대기 시간 감소 덕분에 이러한 작업이 수행될 데이터 원본과의 근접성은 훨씬 큰 혜택을 제공할 수 있습니다. 계획과 테스트는 특정 리소스 병목을 확인하고 다양한 작업을 구현하는 방법을 의사 결정하는 데 도움이 됩니다.
하이브리드 시나리오에 맞게 기존 솔루션을 구현하거나 조정하는 데 필요한 노력은 하이브리드 시나리오가 제공할 수 있는 혜택으로 당연하게 받아 들어야 합니다. 하이브리드 구현에 대해 올바로 인식하고 성공하려면 솔루션의 일부를 클라우드로 이동하는 경우와 부분적으로 손실될 수도 있는 집합으로 이동하는 경우를 비교하여 기술적 이점을 분명히 해야 합니다. 이러한 비교 분석은 솔루션 디자인의 매우 실재적인 측면과 관련되어 있습니다. 솔루션 구성 요소에 대한 제어를 너무 많이 잃지 않으면서 클라우드 플랫폼에서 제공하는 뛰어난 수평 확장 기능을 어떻게 활용할 수 있습니까? 수직 확장보다는 수평 확장을 위해 디자인된 플랫폼에 대해 데이터 로드 프로세스를 실행하면서 여전히 적절하게 예측 가능한 성능을 제공하려면 어떻게 해야 합니까? 이러한 질문에 대한 답을 얻으려면 네트워크 연결 성능 및 안정성, 항상 가동되고 실행되는 응용 프로그램 구성 요소 및 서비스, 성능 문제를 해결하기 위해 추가될 수 있는 리소스 대안 등에 대한 가정을 포기해야 합니다. 이를 위해서는 디자인에서 오류에 대비하고 대기 시간이 대개 과거 경험에서보다 길며 여러 작은 가상 컴퓨터 또는 서비스에 작업을 분할하는 것이 매우 권장되는 환경이 필요합니다.
부하 분산 아키텍처 디자인 및 구현
이동 부분이 많지만 어느 것도 기존 온-프레미스 구성 요소의 "동급 최고"에 해당하지 않는 복잡한 데이터 이동 솔루션을 디자인할 때 이러한 모든 고려 사항을 올바른 방향으로 이끌어야 합니다.
지침은 다음과 같습니다. 데이터 원본 추출에서 데이터 대상 로드에 이르기까지 데이터 이동 프로세스를 더 작은 여러 부분으로 분할합니다. 이러한 부분은 하이브리드 솔루션에 도입된 더 높은 대기 시간 환경에 맞추도록 비동기적이고 오케스트레이션되어야 합니다. 환경에 있는 모든 구성 요소 간에 적절한 균형점을 찾는 것이 단일 구성 요소의 한도에 도달하는 것보다 훨씬 중요합니다. Azure SQL 데이터베이스 아키텍처에서 단일 백 엔드 노드의 제한을 극복하려면 데이터 로드와 같은 이 프로세스의 개별 단계까지도 여러 분할된 데이터베이스 또는 물리적 데이터베이스에 적중하는 더 작은 로드 스트림으로 분할해야 할 수 있습니다.
시스템의 일부 구성 요소(SQL Server를 호스팅하는 WA VM의 Azure SQL 데이터베이스 노드 및 Azure 저장소 Blob 리포지토리)는 가용성이 높고 공유되는 다중 테넌트 특성을 갖고 있어서 너무 많은 데이터를 단일 노드에 밀어넣으면 추가 성능 문제가 발생할 수 있습니다. 복제 폭주 메커니즘은 성능 문제의 예로서 전체 데이터 로드 프로세스를 느리게 합니다.
그림 4 균형 잡힌 데이터 로드 아키텍처의 개략도
데이터 형식 고려 사항
사용되는 데이터베이스 스키마, 엔터티 디자인 및 데이터 형식은 여러 가지 방식으로 데이터 이동 프로세스에 영향을 줄 수 있습니다. 일반적으로, 데이터가 임시 작업을 위해 원본에서 Azure Blob 또는 로컬 저장소로 대량 로드될 때 많이 압축될 수 있는 데이터 형식은 여러 이득을 줄 수 있습니다. 데이터를 압축하여 네트워크로 전송하면 물론 성능이 향상됩니다.
솔루션 패키징 및 배포
온-프레미스 데이터 센터와 클라우드 기반 환경 사이에 걸쳐 있는 솔루션을 구현하고 배포하려면 대개 몇 가지 구성 요소와 서비스를 처리해야 합니다. 데이터 이동 솔루션의 여러 인스턴스를 배포하려는 경우 이러한 모든 부분을 배포하고 구성하는 데 높은 수준의 자동화를 제공하는 것이 보다 더 중요합니다. 가상화 기술은 마스터 이미지를 만드는 데 도움이 될 수 있습니다. 마스터 이미지는 온-프레미스와 Azure VM 인프라에 있어야 하는 공통 서비스의 배포를 단순화하기 위해 이들 두 환경에서 사용될 수 있습니다.
이와 동시에 WA VM을 사용하여 작업할 때 응용 프로그램 및 상호 관련된 패키지와 서비스(예: 시작 작업)의 측면에서 웹 역할, 작업자 역할 등의 다른 Azure 계산 노드가 제공할 수 있는 것과 비교하면 몇 가지 제한이 있습니다.
소프트웨어 배포 기능을 이미 활용하고 있는 경우 예를 들어 Windows Server 및 System Center 제품군을 통해 사용 가능한 경우, 일부 구성 요소는 클라우드에서 실행되고 다른 구성 요소는 온-프레미스 환경에서 실행되도록 솔루션 구성 요소 및 패키지를 배포할 수도 있습니다.
또한 SSIS 및 Azure SDK(Azure 저장소 기능 액세스용)와 같은 다양한 솔루션 구성 요소를 수동으로 설치하고 구성하면서 분산 환경의 일부로 실행될 각 VM에 필요한 모든 응용 프로그램 설치 패키지(.msi)를 수동으로 설치하고 구성할 수도 있습니다.
이식 가능한 솔루션 만들기
수평 확장 아키텍처에서 솔루션을 실행할 때 보다 중요해지는 한 가지 측면은 연결 문자열, 자격 증명과 같은 옵션과 솔루션에 포함될 다른 모든 구성 옵션을 신속하게 다시 구성하는 능력입니다. 이렇게 하려면 대개 중앙 집중화된 구성 메커니즘이 필요하며 여기서는 모든 변경에 최소한의 노력이 필요하도록 데이터 이동 프로세스에 관련된 다양한 모든 구성 요소와 서비스에 정보가 액세스되고 전파됩니다. SSIS와 같은 표준 도구뿐만 아니라 개발되는 사용자 지정 구성 요소 및 응용 프로그램도 이러한 접근 방식으로 쉽게 구현될 수 있습니다. Azure 저장소는 온-프레미스 및 클라우드 구성 요소가 쉽게 액세스 가능하고 사용할 수 있다는 점에서 구성 정보를 저장하고 유지 관리하는 데 적합한 옵션일 수 있습니다.
SSIS 플랫폼에는 구성 파일 및 매개 변수와 같이 솔루션의 이식과 확장을 단순화하는 몇 가지 기능이 이미 포함되어 있습니다. 종단 간 데이터 이동 솔루션을 구성하는 추가 프로세스 및 서비스가 동일한 종류의 구성 가능한 방법을 구현할 수 있으므로 여러 환경 간에 보다 쉽게 솔루션을 이동할 수 있습니다.
패키지 및 코드 구성 요소 배포
모든 솔루션 요소가 구현되었으면 여러 컴퓨터에 다양한 SSIS 패키지 및 코드 구성 요소를 물리적으로 배포하기 위해 선택하는 프로세스가 중요해집니다. 훨씬 더 중요한 또 다른 측면은 이러한 패키지와 코드 요소가 다양한 서버와 VM 내에서 호스팅되고 실행되는 방식입니다. SQL Server 2012의 SSIS 네이티브 환경이 여러 가지 패키지 저장소 유형과 배포 모델을 제공하지만, 종단 간 데이터 이동 솔루션을 개발하는 데는 다른 선택이 필요할 수 있습니다. 오케스트레이션 서비스/응용 프로그램을 실행하여 데이터 이동 프로세스를 감독하고 제어해야 하는 경우 이러한 서비스/응용 프로그램을 어떻게 구현할 수 있습니까? 그리고 어느 정도의 기본 SSIS 인프라를 사용할 수 있습니까? 구성 요소를 배포하고 조정하는 구체적인 예는 "Azure 및 하이브리드 데이터 이동을 위한 SQL Server 2012 SSIS” 백서에 나와 있습니다. 이 백서는 MSDN 라이브러리에서 SQL Server 2012의 Microsoft 백서 노드에 있습니다.
WA VM과 물리적 Windows Server 기반 서버는 Azure 플랫폼에서 웹 역할과 작업자 역할에 제공하는 기능 중 일부를 구현하지 않습니다. 따라서 최선의 선택은 해당 구성 요소를 Windows 서비스로 구현하고 다양한 호스트가 부팅될 때 프로세스가 시작되고 해당 컴퓨터에서 대화형 사용자 세션과 독립적으로 계속 실행되도록 하는 것입니다. .NET 플랫폼에서는 이전에 설명한 옵션을 사용하여 다양한 호스트에 분산하고 배포할 수 있는 이러한 종류의 소프트웨어 패키지를 매우 쉽게 만들고 패키지화할 수 있습니다.
오케스트레이션 서비스/응용 프로그램은 다양한 외부 구성 요소(Windows Azure Blob 저장소, 큐 등)와 상호 작용하고 SSIS 실행 엔진(DtExec.exe)을 호출하며 여러 호스트나 VM의 데이터 로드 및 변환 작업을 오케스트레이션합니다.
패키지 실행에 필요한 사용자 지정 구성 요소도 여러 노드에 분산되어야 합니다.
이렇게 분산된 방식으로 이식 가능하고 융통성 있는 강력한 배포 및 실행 환경을 만들어 완전한 하이브리드 인프라에서 종단 간 데이터 이동 솔루션을 호스팅할 수 있습니다.
데이터 이동 대상인 Azure SQL 데이터베이스
SQL Server와 Windows Azure SQL 데이터베이스가 유사하지만 둘을 동일하게 생각하는 것은 잘못입니다. SQL Server 데이터베이스와 비교할 때 응용 프로그램이 Windows Azure SQL 데이터베이스에서 작업을 수행하는 방식에 영향을 미칠 수 있는 몇 가지 차이점이 있습니다.
Windows Azure SQL 데이터베이스는 완전한 다중 테넌트 아키텍처를 구현하는 호스팅된 서비스입니다. 기존의 SQL Server 구현과 달리 Windows Azure SQL 데이터베이스는 기본적으로 제공되는 HA(고가용성), 자동화된 백업 등의 기능을 포함하고 있으며 큰 서버 대신 상용 하드웨어에서 실행됩니다. 이 데이터베이스는 데이터베이스 압축, 병렬 쿼리, ColumnStore 인덱스 및 테이블 분할과 같이 온-프레미스 환경에서 일반적으로 사용되는 기능의 하위 집합을 실행합니다. Windows Azure SQL 데이터베이스의 기능 제한에 대한 자세한 내용은 SQL Server 기능 제한(Windows Azure SQL 데이터베이스)(http://msdn.microsoft.com/ko-kr/library/windowsazure/ff394115.aspx)을 참조하십시오.
Windows Azure SQL 데이터베이스와 SQL Server의 가장 큰 차이점 중 하나는 Windows Azure SQL 데이터베이스가 Microsoft 데이터 센터에 있는 하나 이상의 컴퓨터 리소스를 여러 구독에서 공유하는 확장된 다중 테넌트 서비스를 노출한다는 것입니다. 목표는 가끔씩 고객을 서로 다른 컴퓨터로 이동하여 데이터 센터 내의 전체적인 부하를 분산하는 것입니다. 이러한 컴퓨터는 랙 기반의 표준 서버이며 전체적인 성능 대신 가격/성능을 최대화합니다. 모든 Windows Azure SQL 데이터베이스 노드가 호스팅 솔루션에서 초고성능 하드웨어를 사용하는 것은 아닙니다.
고객 응용 프로그램이 단일 컴퓨터의 한도를 초과해야 하는 경우 고객 작업을 단일 서버 대신 여러 데이터베이스(여러 컴퓨터를 의미할 수 있음)에 분산하도록 응용 프로그램을 수정해야 합니다. 이러한 환경에서는 탄력성과 관리 능력이라는 상충 요소를 제공하지만 때때로 응용 프로그램이 예기치 않게 다른 컴퓨터로 이동할 수 있다는 단점도 있습니다. 세션이 상태 비저장이므로 응용 프로그램 디자인에서 단일 실패 지점을 방지하는 기법을 사용해야 합니다. 여기에는 적절할 때 다른 계층에서 캐싱하고 연결과 명령에 대해 오류를 복원하는 다시 시도 논리를 사용하는 것이 포함됩니다.
또한 WA 인프라의 다양한 계층은 동일한 네트워크 서브넷에 배치되지 않으므로 클라이언트 응용 프로그램과 Windows Azure SQL 데이터베이스 간에 약간의 대기 시간 차이가 발생하게 됩니다. 이는 응용 프로그램과 데이터베이스가 동일한 물리적 데이터 센터에서 호스팅되는 경우에도 해당합니다. 매우 '수다스러운' 기존의 SQL Server 데이터 로드 솔루션은 이러한 물리적 네트워크 차이점 때문에 Windows Azure에서 보다 느리게 실행될 수 있습니다. 초기 클라이언트-서버 컴퓨팅에 익숙한 경우 동일한 솔루션이 여기에 적용됩니다. 눈에 띄는 대기 시간 차이를 처리하려면 솔루션의 계층 간 왕복에 대해 살펴보십시오.
아키텍처 고려 사항
SSIS 패키지의 가장 일반적인 과제는 실행 중 예기치 않은 오류를 처리하는 방법과 오류 이후 처리를 다시 시작해야 하는 경우 ETL 프로세스의 실행을 마치는 데 필요한 시간을 최소화하는 방법에 있습니다. 파일 시스템 작업과 같은 제어 흐름 작업의 경우 이미 완료된 작업을 다시 처리하지 않고 검사점을 사용하여 실행을 다시 시작할 수 있습니다. 검사점 사용에 대한 자세한 지침은 검사점을 사용하여 패키지 다시 시작(http://msdn.microsoft.com/ko-kr/library/ms140226.aspx)을 참조하십시오.
일반적으로 데이터 흐름은 SSIS 패키지의 가장 큰 부분입니다. 이 섹션에서는 오류 시 다시 시도를 자동으로 허용하도록 패키지를 디자인하고 전체 데이터 흐름을 다시 시도하는 대신 오류 지점에서 시작할 수 있도록 데이터 흐름 파이프라인을 디자인하기 위한 전략을 살펴봅니다.
WA 플랫폼의 임시 오류 처리에 대한 추가 고려 사항은 "Azure 및 하이브리드 데이터 이동을 위한 SQL Server 2012 SSIS” 백서에 나와 있습니다. 이 백서는 MSDN 라이브러리에서 SQL Server 2012의 Microsoft 백서 노드에 있습니다.
파이프라인 진행 작업의 손실 없이 다시 시작하기 위한 디자인
패키지를 디자인할 때 가장 큰 관심사 중 하나는 오류 시 해당 시점까지 패키지에서 진행한 모든 작업이 손실되지 않도록 하는 것입니다. 패키지의 제어 흐름에 있는 항목의 경우에는 검사점을 사용하면 되지만, 진행된 작업의 손실 없이 데이터 흐름을 다시 시작할 수 있는 기능은 패키지 디자인 차원에서만 구현할 수 있습니다. 이 섹션에서는 데이터 흐름이 오류 지점에서 다시 시작되고 연결이 중단되는 경우 패키지가 실패하지 않고 자동으로 다시 시도되도록 하는 패키지 디자인에 대한 전략을 살펴봅니다. 이러한 연결 중단이나 짧은 중단에 대한 계획은 WA SQL 데이터베이스에 대한 데이터 이동 시 특히 중요해집니다.
기본 원칙
모든 데이터 이동에서 성능이 중요하지만 데이터 이동 중에 문제가 발생하는 경우 손실되어도 괜찮은 진행 작업의 양과 성능 요구 사항 간의 균형을 맞춰야 합니다.
각 데이터 이동에서 대상에 이미 도착한 데이터와 그렇지 않은 데이터를 파악할 방법이 있어야 합니다. 삽입되기만 하는 데이터의 경우 기본 키만으로 가장 흔히 이를 파악할 수 있으며 다른 데이터의 경우에는 마지막으로 수정된 날짜로 파악할 수 있습니다. 데이터의 특성이 무엇이든 간에 다시 시작을 위한 디자인의 처음 부분은 대상에 이미 있는 데이터, 대상에서 업데이트되어야 하는 데이터 및 대상으로 배달되어야 하는 데이터를 식별하는 방법을 이해하는 것입니다. 이러한 방법을 이해했으면 대상에 도착하지 않은 데이터만 처리하고 수행되어야 하는 재작업의 양을 최소화할 수 있는 방식으로 데이터를 분할하고 순서대로 정렬할 수 있습니다.
청크로 분할하고 순서대로 정렬함으로써 처리된 청크를 쉽게 추적할 수 있으며 그 후 정렬을 통해 청크 내에서 이미 처리된 레코드를 추적할 수 있습니다. 이 방법을 따르면 레코드가 처리되었는지 확인하기 위해 모든 원본 행을 대상과 비교할 필요가 없습니다.
좀 더 복잡한 ETL 프로세스에는 몇 가지 준비 환경이 있을 수 있습니다. 각 준비 환경은 ETL의 한 단계에 대한 대상입니다. 이러한 유형의 환경에서 각 준비 환경을 별도의 대상으로 간주하고 다시 시작을 위해 ETL의 각 세그먼트를 디자인해야 합니다.
단일 대상에 대한 예
다시 시작할 수 있는 가장 간단한 데이터 흐름은 단일 정수가 기본 키인 작은 데이터 흐름입니다. SQL Server가 원본인 경우 원본에서 끌어오는 데이터를 제한하는 최선의 방법을 사용하여 이 원본에 대해 쿼리할 수 있습니다. AdventureWorks의 기본 예제 테이블인 "Production.TransactionHistory"를 살펴보겠습니다. 이 테이블의 구조는 다음과 같습니다.
CREATE TABLE [Production].[TransactionHistory]
(
[TransactionID]INTNOT NULLPRIMARY KEY,
[ProductID]INTNOT NULL,
[ReferenceOrderID]INTNOT NULL,
[ReferenceOrderLineID]INTNOT NULL,
[TransactionDate]INTNOT NULL,
[TransactionType]NCHAR(1)NOT NULL,
[Quantity]INTNOT NULL,
[ActualCost]MONEYNOT NULL,
[ModifiedDate]DATETIMENOT NULL,
)
이 예에서 테이블의 기본 키는 단일 정수입니다. 데이터가 이동 시 정적이거나 이 테이블에 삽입만 된 경우(업데이트 없음) 행이 대상에 도착했는지 파악하기 위해 필요한 것은 기본 키뿐입니다. 각 기본 키 값을 대상과 비교하는 데는 비교적 많은 비용이 소요되므로 대신 TransactionID 열을 기준으로 원본 파일의 데이터를 정렬하는 전략을 사용합니다.
이러한 전략을 사용하는 경우 데이터가 순서대로 처리되고 있는지 여부와 대상에서 커밋된 가장 큰 TransactionID만 파악하면 됩니다.
SSIS 패키지에서 다음을 수행하여 이를 파악할 수 있습니다.
1. 대상에서 가장 큰 키를 확인합니다.
2. 대상에서 가장 큰 TransactionID보다 큰 TransactionID를 갖고 있는 레코드만 원본에서 끌어오는 쿼리를 작성합니다.
3. 원본 쿼리에서 ORDER BY TransactionID를 사용하여 가장 큰 TransactionID의 비교가 다음에 패키지를 시작할 때 유효하도록 합니다.
SSIS에서 관계형 데이터 원본을 원본으로 사용하는 경우 SQL 실행 태스크를 사용하여 가장 큰 값을 패키지의 변수로 끌어올 수 있습니다. 그러나 대상에 행이 전혀 없을 가능성을 고려해야 합니다.
SELECT MAX(TransactionID) FROM Production.TransactionHistory
최대 TransactionID를 검색하려면 빈 테이블의 결과가 null인 경우를 고려해야 합니다. 이 경우 패키지에서 사용하는 논리에 몇 가지 문제가 발생할 수 있습니다. 더 나은 방법은 먼저 원본에서 SQL 실행 태스크를 사용하고 원본에서 처리되지 않은 최소 TransactionID를 찾는 것입니다. 그런 다음 대상에서 최대 TransactionID를 쿼리하거나 아무 것도 없는 경우 원본의 최소 TransactionID보다 작은 값을 사용합니다. 이 값보다 큰 레코드만 끌어오도록 원본 쿼리를 작성하되 쿼리에서 ORDER BY TransactionID를 사용하는 것을 잊지 말아야 합니다.
참고: 논리적으로는 ISNULL 함수를 사용하거나 원본 쿼리의 WHERE 절에서 CASE 문을 사용하여 대상에서 값을 하나만 검색하는 방법으로 동일한 결과를 얻을 수 있지만 이렇게 하면 특히 원본 쿼리가 복잡해지는 경우 성능 문제가 발생할 수 있습니다. 이렇게 손쉬운 방법을 사용하려는 충동을 자제하고 하한으로 안전하게 사용할 수 있는 값을 찾은 다음 그 값을 사용하여 원본 쿼리를 작성해야 합니다.
참고: 원본이 SQL Server인 경우 클러스터형 인덱스에 대해 ORDER BY 절을 사용하면 SQL Server가 정렬하기 위해 추가 작업을 수행하지 않습니다. 데이터는 SORT 수행 없이 검색 가능한 방식으로 이미 정렬되어 있습니다. 대상의 데이터에도 동일한 열에 클러스터형 인덱스가 있는 경우 원본에서 정렬하면 원본 쿼리가 최적화되고 대상에서의 삽입도 최적화됩니다. 다른 효과는 SSIS 파이프라인 내의 순서가 보장되어 오류 지점에서 데이터 흐름을 다시 시작할 수 있다는 것입니다.
이 예제 패키지를 작성하려면 다음을 수행하십시오.
1. 새로운 프로젝트나 기존 프로젝트에서 새 패키지를 만듭니다. 패키지 이름을 “SimpleRestart”로 바꿉니다.
2. 원본과 대상에 연결할 연결 관리자를 만듭니다. 이 예에서는 OLE DB 연결 관리자가 원본 및 대상 서버에 대해 만들어집니다.
3. 새로운 SQL 실행 태스크를 제어 흐름 화면으로 끌어오고 "Pull Min TransactionID From Source"로 이름을 바꿉니다.
4. 패키지 수준에서 SSIS 변수를 만들고 minTransactionIDAtSource로 이름을 지정합니다. 이 변수를 사용하여 방금 추가한 SQL 실행 태스크에서 끌어오는 값을 저장할 것입니다. 데이터 형식이 테이블의 TransactionID 값과 일치하도록 Int32인지 확인하고 적절한 초기 값을 설정합니다.
5. 다음과 같이 Pull Min TransactionID From Source를 구성합니다.
a. 편집하여 연결을 원본 서버의 연결 관리자로 설정합니다.
b. 변수에 SQLStatement를 저장할 수 있지만 이 예에서는 SQLSourceType을 직접 입력으로 둡니다. SQLStatement에 대한 입력 창을 열고 다음 쿼리를 입력합니다.
SELECT ISNULL(MIN(TransactionID), 0) FROM Production.TransactionHistory
참고: SQL 쿼리를 SSIS에서 편집기에 입력하기 전에 테스트하십시오. 이렇게 하면 SSIS 쿼리 편집기 창에 실제 디버깅 도움말이 없으므로 디버깅이 간단해집니다.
그림 5: 원본에서 최소 transactionID를 찾도록 SQL 실행 태스크 구성
c. 확인을 클릭하여 SQL 쿼리 입력 창을 닫습니다.
d. ResultSet 속성을 단일 행으로 설정합니다.
e. SQL 실행 태스크 편집기의 왼쪽 창에서 결과 집합을 클릭하여 이 쿼리에서 값을 캡처할 방법을 구성합니다.
f. 추가 단추를 클릭하여 결과 집합을 추가합니다.
g. 새로운 결과 집합에서 결과 이름을 0으로 변경합니다. User::minTransactionIDAtSource(4단계에서 만든 변수)가 변수 이름 아래에 표시되는지 확인하십시오. 이 변수는 SQL 쿼리의 결과를 저장합니다.
h. SQL 실행 태스크 편집기를 닫습니다. 닫은 후 태스크에 대한 오류가 표시되지 않아야 합니다.
6. 또 다른 SQL 실행 태스크를 제어 화면으로 끌어옵니다. 이 태스크의 이름을 Pull Max TransactionID from Destination으로 지정합니다. 성공 선행 제약 조건을 Pull Min TransactionID From Source에서 이 새로운 태스크로 연결합니다.
7. 패키지 범위의 새 변수를 만듭니다. 이 새 변수의 이름을 maxTransactionIDAtDestination으로 지정합니다. 이 변수의 데이터 형식을 TransactionID의 데이터 형식과 일치하도록 Int32로 설정하고 적절한 초기 값을 제공합니다.
8. 새 태스크에 대한 SQL 실행 태스크 편집기를 열고 다음을 수행합니다.
a. ResultSet를 단일 행으로 설정합니다.
b. 대상 서버 연결 관리자로 설정합니다.
c. SQLSourceType: 직접 입력
d. SQLStatement의 경우 SELECT ISNULL(MAX(TransactionID), ?) FROM Production.TransactionHistory를 사용합니다.
참고: ?는 쿼리 매개 변수로서 우리는 매개 변수의 값을 곧 설정할 것입니다.
e. 확인을 클릭하여 쿼리 편집기를 닫고 SQL 실행 태스크 편집기의 왼쪽 패널에서 매개 변수 매핑을 클릭합니다.
f. 추가를 클릭하여 단일 매개 변수를 추가합니다.
i. 변수 이름에서 User::minTransactionIDAtSource를 선택합니다.
ii. 방향에서는 입력을 선택해야 합니다.
iii. 데이터 형식은 이 맥락에서 32비트 정수인 LONG이어야 합니다.
iv. 매개 변수 이름을 0으로 변경합니다. 이 이름을 0으로 변경해야 합니다. 문자 이름은 오류를 발생시킵니다.
g. 왼쪽 창에서 결과 집합을 클릭합니다. 추가 단추를 클릭하여 새 결과 집합을 추가합니다.
i. 결과 이름을 0으로 변경합니다.
ii. 변수 이름 아래에서 7단계에서 만든 변수인 User::maxTransactionIDAtDestination을 선택합니다. 이 변수에는 이 태스크가 실행된 후 입력하는 쿼리의 결과가 포함됩니다.
참고: 다음 단계는 데이터 흐름에서 사용할 원본 유형에 따라 달라집니다. OLE DB 원본은 SQL 문을 쿼리로 포함하는 SSIS 변수를 사용할 수 있습니다. ADO.NET 연결은 이렇게 할 수 없지만 패키지 또는 프로젝트 매개 변수를 원본 쿼리로 사용하도록 매개 변수화될 수 있습니다. 이 첫 번째 예에서는 원본 쿼리가 포함된 변수와 함께 OLE DB 원본을 사용합니다.
9. 데이터 흐름 태스크를 제어 화면으로 끌어옵니다. 태스크의 이름을 Main data move로 바꾸고 성공 선행 제약 조건을 Pull Max TransactionID From Destination에서 이 데이터 흐름 태스크로 연결합니다.
패키지가 이 지점에서 실행되면 현재 실행의 시작점을 설정하기 위해 알아야 하는 값이 저장됩니다. 그러면 SQL 원본 쿼리를 저장할 변수를 설정해야 합니다.
10. 패키지 수준 범위의 새 변수를 만듭니다. 이 변수의 이름을 sourceQuery로 지정하고 데이터 형식을 문자열로 설정합니다. 다음을 수행하여 쿼리 시작점으로 결정한 값에 따라 런타임에 이 변수의 값을 동적으로 파생시키는 식을 사용합니다.
a. 식 열의 오른쪽에서 줄임표 단추를 클릭하여 식 작성기를 표시합니다.
b. 식 작성기의 왼쪽 상단 창에서 변수 및 매개 변수 노드를 확장합니다. 7단계에서 만든 User::MaxTransactionIDAtDestination 변수를 사용할 것입니다. 나열된 변수에 이 변수가 표시되어야 합니다. 이 변수는 int32이지만 String 변수의 일부로 이 변수를 사용할 것입니다. 이를 위해 이 변수를 DT_WSTR 데이터 형식으로 캐스팅해야 합니다. 오른쪽 위 패널에서 유형 캐스트 노드를 확장하여 (DT_WSTR, <>) 유형 캐스트를 찾습니다.
c. 식에 쿼리를 입력합니다. 변수 이름이나 유형 캐스트가 필요한 곳에서 해당 창의 항목을 식 상자로 끌어와 추가할 수 있습니다. 이렇게 하면 편집기에서 오타 수를 줄이는 데 도움이 됩니다. 다음과 같이 식을 작성하십시오.
"SELECT TransactionID, ProductID, ReferenceOrderID, ReferenceOrderLineID, TransactionDate, TransactionType, Quantity, ActualCost, ModifiedDate FROM Production.TransactionHistory WHERE TransactionID > " + (DT_WSTR, 12 ) @[User::maxTransactionIDAtDestination] + " ORDER BY TransactionID"
typecast를 사용하여 정수 값을 너비가 최대 12자인 문자열로 변경했습니다.
12자 너비는 해당하는 경우 음수가 포함된 SQL INT 값의 전체 범위를 포함할 정도로 크기 때문에 사용되었습니다. BIGINT의 경우 22자 너비가 필요합니다. 검색된 데이터 형식에 따라 문자 변수의 크기를 지정하십시오.
식을 입력했으면 식 계산 단추를 클릭하여 SSIS에서 식을 올바르게 구문 분석할 수 있는지 확인합니다. maxTransactionIDAtDestination의 초기 값을 계산된 식에 제대로 배치했음을 확인할 수 있습니다. 이 값은 런타임에 적절하게 설정됩니다.
SQL 문에 ORDER BY 절을 포함해야 합니다. ORDER BY를 사용해야만 관계형 데이터베이스에서 보장된 순서를 얻을 수 있습니다. 작성할 다시 시작 방법은 키 값의 순서에 따라 달라집니다.
d. 확인 단추를 클릭하여 식 작성기를 닫습니다. 동적으로 생성된 SQL 문은 이제 SourceQuery 변수에 저장됩니다.
11. Main data move 데이터 흐름 태스크를 두 번 클릭하여 데이터 흐름 디자인 화면을 엽니다.
12. OLE DB 원본을 데이터 흐름 제어 화면으로 끌어옵니다. 이름을 Retrieve from TransactionHistory로 바꿉니다.
참고: 데이터 흐름 구성 요소의 이름에 마침표를 포함할 수 없으므로 Pull From Production.TransactionHistory의 전체 이름이 허용되지 않습니다. 테이블 이름에 밑줄을 사용하지 않는 경우 SSIS 명명 규칙에서 밑줄을 마침표로 대체할 수 있습니다.
13. Retrieve From TransactionHistory 원본을 두 번 클릭하여 OLE DB 원본 편집기를 엽니다.
a. OLE DB 연결 관리자에서 원본 서버 연결 관리자를 선택합니다.
b. 데이터 액세스 모드 드롭다운 목록에서 변수를 사용한 SQL 명령을 선택합니다.
c. 변수 이름 드롭다운 목록에서 10단계에서 만든 User::sourceQuery 변수를 선택합니다.
d. 미리 보기를 클릭하여 쿼리가 원본 서버에서 실행될 수 있는지 확인합니다.
e. 편집기의 열 페이지에서 모든 열이 선택되었는지 확인합니다.
f. 확인을 클릭하여 OLE DB 원본 편집기를 끝냅니다.
14. OLE DB 대상을 제어 화면으로 끌어옵니다. 이름을 TransactionHistory Destination으로 바꿉니다. Retrieve From TransactionHistory 원본을 새 대상에 연결합니다. 두 번 클릭하여 대상을 열고 다음을 수행하여 구성합니다.
a. OLE DB 연결 관리자 드롭다운 목록에서 대상 서버 연결 관리자를 선택합니다.
b. 데이터 액세스 모드에서 테이블 또는 뷰 - 빠른 로드가 이미 선택되어 있지 않은 경우 선택합니다.
c. 테이블 또는 뷰 이름 아래 드롭다운에서 선택하거나 대상 서버의 이름을 입력합니다. 이 경우 이름은 Production.TransactionHistory입니다.
d. 위에서 제공된 TransactionHistory의 정의를 사용하는 경우 데모용으로 연결 관리자 페이지의 기본 설정을 유지할 수 있습니다. AdventureWorks 데이터베이스를 사용하는 경우에는 ID 값 유지를 선택해야 합니다.
e. 편집기의 매핑 페이지에서 열을 매핑합니다.
참고: 거의 모든 경우에 오류 행을 대상 파일에 보내고 출력을 리디렉션하는 것이 좋습니다. 이것은 파이프라인에서 다시 시작하는 것을 보여 주는 데는 필요하지 않습니다. 오류 흐름을 만들고 행을 리디렉션하는 단계는 데이터 흐름 구성 요소에서 오류 출력 구성(http://msdn.microsoft.com/ko-kr/library/ms140083.aspx)을 참조하십시오.
f. 확인을 클릭하여 OLE DB 대상 편집기를 끝냅니다.
15. 가져오기를 시작하고 중지한 다음 다시 시작하여 이 방법을 테스트합니다. 매번 데이터 흐름은 이동해야 하는 다음 행과 함께 시작되어야 합니다. 이전 행은 무시됩니다.
지금까지 오류 후 데이터 흐름을 다시 시작할 수 있는 간단한 패키지를 작성했습니다. 이 패키지는 다시 시도할 수 있는 패키지를 디자인하는 예제의 기반으로 사용됩니다. 제어 흐름의 태스크에서 검사점이 저장되지 않은 것에 유의하십시오. 패키지가 실패하고 다시 시작되어야 하는 경우 데이터 흐름이 이전 실행에서 중단된 곳을 정확히 찾으려면 Pull Min TransactionID From Source 및 Pull Max TransactionID From Destination 구성 요소가 필요합니다. 이와 같이 진행 지점을 찾고 흐름을 다시 시작하기 위해 패키지를 디자인할 때 데이터 흐름이 중단된 지점을 찾을 수 있도록 항상 데이터 내에 특성을 두는 것이 좋은 방법입니다. 그러나 이 방법은 네트워크 불확실성에 보다 취약한 클라우드와 같은 환경에서 특히 중요해집니다.
여러 대상에 대한 예
이 원칙은 여러 대상이 있는 데이터 흐름으로 확장될 수 있습니다. 이 원칙이 유용한 시나리오 중 하나는 WA SQL 데이터베이스를 통해 자주 수행되었듯이 분할된 데이터 모델로 데이터를 이동하는 경우입니다. 이러한 경우 조건부 분할이 각 행을 적절한 대상에 보내는 데 사용되며, 참조 데이터의 경우 멀티캐스트를 사용하여 모든 데이터를 모든 대상에 보낼 수 있습니다. 다음은 다시 시작을 위한 디자인에서 명심해야 하는 주요 원칙입니다.
· 오류 시 여러 대상이 여러 지점으로 진행되었을 수 있습니다. 따라서 각 대상에서 삽입된 가장 큰 키 값을 찾아야 합니다. 각 대상에서 가장 큰 값을 저장하는 변수를 만드십시오.
· 원본의 시작 지점은 대상에 성공적으로 삽입된 가장 작은 키 값 이후의 다음 레코드입니다. 예를 들어 분할된 데이터베이스 집합에 삽입된 가장 큰 키 값이 다음과 같은 경우 원본에서 1000 이후의 다음 레코드로 데이터 흐름을 다시 시작해야 합니다.
· Shard00 키 값 1000
· Shard01 키 값 1100
· Shard02 키 값 1050
이 경우 일부 데이터가 두 번 이상 추출될 수 있으므로 기본 키 위반을 방지하려면 각 대상에 대해 필터링해야 합니다. 조건부 분할 변환을 사용하여 이미 처리된 키 값을 필터링하십시오.
위의 분할 예에서는 maxTransactionIDAtShard00, maxTransactionIDAtShard01 및 maxTransactionIDAtShard02라는 변수를 만듭니다. SQL 실행 태스크에서 각각에 저장할 값을 찾고 조건부 분할에서 Shard00, Shard01 및 Shard02라는 출력을 정의할 수 있습니다. 이러한 출력을 사용하는 식은 다음과 같습니다.
ShardID == 0 && TransactionID > @[User::maxTransactionIDAtShard00]
ShardID == 1 && TransactionID > @[User::maxTransactionIDAtShard01]
ShardID == 2 && TransactionID > @[User::maxTransactionIDAtShard02]
분할된 특정 데이터베이스에서 TransactionID보다 작은 행이 파이프라인에 들어가지만 레코드가 해당 분할된 데이터베이스로 이동하지 않는 경우 레코드가 전송되지 않고 기본 키 위반이 발생하지 않습니다. 이러한 레코드는 더 이상 처리되지 않도록 기본 출력 또는 분리 출력으로 이동하십시오.
그림 2: 3개의 분할된 데이터베이스에 대해 구성되고 대상에서 기본 키 위반 없이 다시 시작할 수 있도록 구성된 조건부 분할. 실행이 시작될 때마다 각 대상의 최대 키 값이 maxTransactionIDAtShardXX 변수에 저장됩니다. 파이프라인에서 너무 작은 키 값으로 분할된 데이터베이스에 전송될 행들은 대상에 전송되지 않으므로 다시 처리되지 않습니다. 이러한 행은 기본 출력으로 이동합니다. 기본 출력이 연결되어 있지 않으므로 해당 행은 파이프라인에서 더 이상 진행되지 않습니다.
다시 시작에 대한 기타 팁
· 대상이 파일인 경우 파일 이름을 나타내는 변수를 사용하고 각 파일 이름을 의미 있게 만듭니다(예: 끝에 순서나 타임스탬프 추가). 데이터 청크를 각기 다른 파일에 처리합니다. 동일한 순서로 처리하고 청크가 확정적으로 정의된 경우 이미 만들어진 파일을 확인하고 거기에서 시작 지점을 결정할 수 있습니다. 요구와 논리에 따라 이미 처리된 파일을 이동하거나 삭제하거나 이름을 바꿔야 할 수 있습니다.
· 원본이 여러 파일인 경우 각 파일을 개별적으로 처리하고 현재 파일이 무엇인지 추적합니다. 다시 시작할 때 성공적으로 처리된 마지막 파일 다음에서 다시 시작할 수 있습니다. 매번 동일한 순서로 파일을 처리하고 성공적으로 처리된 마지막 파일을 쉽게 확인할 수 있도록 하기 위해 순서를 나타내는 파일 이름이나 날짜를 사용합니다.
· SQL Server가 원본인 경우 SSIS 문자열 데이터 형식을 사용하여 정수 값을 쿼리할 수 있습니다. 문자열을 SQL Integer로 캐스팅할 수 있으면 SQL은 최적화 중에 이 데이터 형식을 캐스팅합니다. 이 원칙을 사용하여 예제 패키지의 MaxTransactionIDAtDestination 및 MinTransactionIDAtSource 변수를 String으로 변경하고 Pull Max TransactionID From Destination의 입력 매개 변수 형식을 변경할 수 있으며 이 패키지를 문자 기본 키와도 작동하는 템플릿으로 사용할 수 있습니다. SQL의 다른 모든 데이터 형식에 대해 SQL_VARIANT 데이터 형식을 사용하지 마십시오. 이 데이터 형식을 사용하면 최소 및 최대 키 값을 검색할 때 전체 검색이 발생합니다.
· 원본이 파일이거나 WHERE 또는 다른 모든 유형의 필터 절을 사용하여 쿼리할 수 없는 경우 데이터 흐름에서 다음을 수행합니다.
1. 원본 및 대상 구성 요소 간에 조건부 분할 변환을 넣습니다.
2. 조건부 분할에서 하나의 출력을 구성합니다. 이 출력의 이름을 Trash 또는 해당 행을 원하지 않는다는 사실을 알 수 있는 다른 이름으로 지정합니다.
3. 행이 대상으로 전송되는 조건의 경우 식을 사용하여 이미 대상에 있는 행을 필터링합니다. 예를 들어 이전 예에 대한 식은 다음과 같습니다.
[TransactionID] <= @[User::maxTransactionIDAtDestination]
4. 해당 행을 반드시 평가해야 하는 경우가 아니면 Trash 출력을 구성 요소에 연결하지 않습니다. 이 출력의 유일한 목적은 마지막 실행에서 처리한 행을 필터링하는 것입니다.
이 방법이 이 파일에서 이미 처리한 행을 읽는 것을 방지하지는 않지만 해당 행을 대상에 다시 보내는 것을 방지하므로 네트워크 대역폭이 절약됩니다. 이미 처리한 행이 대상에 전송되지 않으므로 대상에서 데이터를 삭제할 필요가 없습니다.
· 복합 키를 처리하는 경우 상관 하위 쿼리를 사용하여 정확한 중지 지점을 찾습니다. 동일한 키를 기준으로 데이터를 정렬해야 합니다. 다음은 이에 대한 예입니다.
SELECT MAX(EmployeeID) AS EmployeeID,
(SELECT MAX(EffectiveDate)
FROM HumanResources.EmployeeHistory i_forDate
WHERE h.EmployeeID = i_forDate.EmployeeID) as EffectiveDate,
(SELECT MAX(EffectiveSequence)
from HumanResources.EmployeeHistory i_forSeq
where h.EmployeeID = i_forSeq.EmployeeID
and h.EffectiveDate = i.ForSeq.EffectiveDate) as EffectiveDate
FROM HumanResources.EmployeeHistory h
ORDER BY EmployeeID, EffectiveDate, EffectiveSequence
이 예에서 순서의 역할에 유의하십시오. 모든 직원의 모든 레코드를 이동하는 경우 이것이 키의 순서이면 좋은 정렬입니다. 그러나 직원의 전부 또는 일부가 이미 대상에 있고 마지막 가져오기 이후 적용된 변경 사항만 가져오려는 경우 EffectiveDate, EffectiveSequence 및 EmployeeID 기준 정렬은 중지된 곳에서 다시 시작하는 데 사용하기 위해 필요한 정렬입니다. 가져올 것을 분석하여 다시 시작해야 하는 지점을 결정할 수 있도록 하는 순서를 정의해야 합니다.
수동 개입 없이 다시 시도하기 위한 디자인
SSIS 원본 및 대상 구성 요소는 다시 시도 논리를 직접 통합하지 않습니다. 그러나 SSIS 패키지 개발자는 이 상황을 처리할 수 있습니다. 데이터 흐름에서 진행된 작업을 손실하지 않고 SSIS 패키지를 다시 시작할 수 있도록 패키지를 디자인하는 경우 몇 가지 사항을 추가로 고려하여 실패 후 자동으로 다시 시도할 수도 있습니다. WA SQL 데이터베이스에서 데이터를 이동할 때 리소스 또는 연결을 제한하는 것과 같은 임시 오류 상황 처리를 위해 자동으로 다시 시도를 해야 하는 경우도 있습니다. 이 섹션은 마지막 섹션에 설명된 개념을 바탕으로 패키지의 다시 시작 논리에 대한 예를 간단하게 보여 주며, 임시 오류가 발생할 가능성이 높은 기간 동안 패키지의 견고성을 높이기 위해 청크 분할 방식을 사용하여 각 청크를 다시 시도할 수 있도록 하는 방법을 보여 줍니다.
SQL 제한에 대한 자세한 내용은 Windows Azure SQL 데이터베이스 성능 및 탄력성 가이드(http://social.technet.microsoft.com/wiki/contents/articles/3507.windows-azure-sql-database-performance-and-elasticity-guide.aspx)를 참조하십시오.
다시 시도 통합
단일 패키지의 경우 다시 시도 통합에는 다음 단계가 포함됩니다.
1. 실패 전에 패키지가 다시 시도할 최대 횟수를 결정합니다. 이 예의 경우 패키지 실패 전에 구성 요소에 최대 5회의 다시 시도가 허용됩니다. 패키지에 maxNumOfRetries라는 변수를 만들어 int 형식으로 값 5를 지정합니다. 이 변수는 패키지의 식에서 사용됩니다.
2. 성공 상태를 저장할 변수를 설정합니다. SSIS 패키지에서 새 변수를 만들어 변수 이름을 attemptNumber로 지정합니다.
3. 데이터 흐름이 성공적이지 않은 경우 FOR 루프를 사용하여 최대 다시 시도 횟수까지 다시 시도합니다.
4. FOR 루프 안에 데이터 흐름 태스크를 넣습니다.
5. FOR 루프에서 MaximumErrorCount 속성을 데이터 흐름을 다시 시도할 최대 횟수로 설정하여 다시 시도 후 성공하면 패키지가 실패하지 않도록 합니다. 1단계에서 설정한 maxNumOfRetries 변수를 사용하는 식을 사용하여 다음과 같이 설정해야 합니다.
6. 마지막 섹션에 나와 있는 대로 SQL 실행 태스크를 사용하여 원본에서 최소 키 값을 찾고 대상에서 최대 키 값을 찾습니다. 간단한 다시 시도의 경우 FOR 루프 안에서 이 작업을 수행할 수 있습니다. 보다 고급 예의 경우에는 제어 흐름에서 FOR 루프 이전의 다른 곳에 이 작업이 나타날 수 있습니다.
7. SQL 실행 태스크를 FOR 루프에 배치합니다.
8. 성공 제약 조건을 SQL 실행 태스크에서 데이터 흐름 태스크로 연결합니다.
9. 성공 선행 제약 조건을 데이터 흐름 태스크에서 스크립트 태스크로 연결하여 성공 상태 변수를 FOR 루프를 벗어나는 true로 설정합니다. 다음은 스크립트 태스크 구성의 예입니다.
10. 가장 빈번하거나 가장 심각한 것으로 예상되는 문제보다 긴 것으로 예상하는 시간 동안 실패 선행 제약 조건을 데이터 흐름 태스크에서 다른 스크립트 태스크로 연결합니다. 이 예에서는 제한 가능성을 다루기 위해 10초를 사용합니다. 성공 변수의 값을 false로 설정합니다.
11. FOR 루프의 각 태스크에 대해 FailPackageOnFailure 속성을 false로 설정합니다. 이 구성에서는 구성된 다시 시도를 모두 사용한 후 FOR 루프가 실패하는 경우에만 실패를 보고하고 패키지를 실패시킵니다.
12. 실패 후 원본의 최소 키 값과 대상의 최대 키 값을 다시 확인하도록 SQL 실행 태스크를 구성하면 다시 작업을 수행하지 않고 진행되던 작업을 다시 시작할 수 있습니다. 이 문서 앞부분의 파이프라인 진행 작업의 손실 없이 다시 시작하기 위한 디자인 섹션의 다시 시작을 위한 디자인 하위 섹션에서 설명한 것처럼 SQL 실행 태스크를 설정하십시오.
최대 다시 시도 횟수에 도달하지 않은 경우 데이터 흐름에서 오류가 발생할 때마다 프로세스는 대상에서 최대 키 값을 찾는 지점으로 돌아갑니다. 프로세스는 대상에서 현재 커밋된 지점에서 처리하여 계속됩니다. 데이터 흐름에 여러 대상이 있는 경우 대상에 안전하게 도착한 가장 작은 키 값 이후에 시작하고 조건부 분할 또는 오류 흐름을 사용하여 기본 키 위반을 유발할 수 있는 모든 행을 처리합니다.
SSIS 성능 조정 옵션
ETL 성능 조정에 대한 팁과 요령을 설명하기 전에 뒤로 물러나서 갖고 있는 구성 요소와 이동 부분을 살펴봐야 합니다. 일반적으로 ETL 프로세스는 다음 구성 요소 중 하나 이상으로 구성됩니다.
· 데이터 원본 – 데이터를 배달합니다.
· SSIS 서버에서 실행되는 패키지 – 데이터 원본에서 데이터를 추출하고 필요한 경우 변환을 수행하며 데이터를 대상으로 로드합니다.
· 대상 - 데이터를 받습니다. 대상은 일반적으로 데이터를 받는 테이블이 있는 데이터베이스입니다.
이러한 주요 부분은 모두 네트워크 인터페이스를 통해 함께 작동하고 서로에게 데이터를 전달합니다. ETL 성능 조정의 처음 단계 중 하나는 네트워크에서 가능한 최고의 성능을 제공하도록 하는 것입니다.
SSIS 서버에 대한 자세한 내용은 Integration Services(SSIS) 서버(http://msdn.microsoft.com/ko-kr/library/gg471508.aspx)를 참조하십시오.
네트워크 설정 조정
위에서 정의한 부분 간에 데이터가 전송되는 방식에 영향을 미칠 수 있는 두 계층으로 물리적 네트워크 구성과 연결 설정이 있습니다.
네트워크 설정
이더넷 프레임은 네트워크를 통해 한 번에 전송될 수 있는 데이터의 양을 정의합니다. 각 프레임이 처리되어야 하므로 하드웨어 및 소프트웨어 리소스를 사용해야 합니다. 네트워크 어댑터가 지원하는 프레임 크기를 늘리는 방법으로 CPU에 대한 오버헤드를 줄여 더 많은 바이트를 전송하고 처리할 프레임 수를 줄여 처리량을 늘릴 수 있습니다.
이더넷 프레임은 최대 9000바이트를 전송할 수 있습니다. 이를 점보 프레임이라고 합니다. 점보 프레임 사용으로 전환하려면 NIC(네트워크 인터페이스 카드)의 설정을 변경해야 합니다. 다음 예와 같이 MaxJumboBuffers 속성은 점보 프레임을 사용할 수 있도록 8192로 설정합니다.
참고: 점보 프레임을 사용하도록 네트워크 인터페이스 카드 설정을 변경하는 경우 네트워크 인프라가 이러한 유형의 프레임을 지원하는지 확인하십시오.
SQL Server는 하나의 SSIS 패킷에서 최대 32676바이트를 받아들일 수 있습니다. 일반적으로 응용 프로그램의 기본 패킷 크기가 다른 경우 이 기본값이 SQL Server 설정을 재정의합니다. 따라서 SSIS 패키지에서 대상 연결 관리자의 패킷 크기 속성을 응용 프로그램 기본 패킷 크기로 설정하는 것이 좋습니다.
이 속성을 편집하려면 SSIS 디자이너에서 연결 관리자를 마우스 오른쪽 단추로 클릭하고 편집을 클릭합니다. 연결 관리자 대화 상자에서 모두를 클릭합니다.
SSIS 패키지 설정
연결 문자열 설정 외에도 SQL Server의 처리 능력을 증가시키기 위해 조정할 수 있는 몇 가지 다른 설정이 있습니다.
SSIS 데이터 흐름은 데이터 처리를 위해 메모리 버퍼를 예약합니다. 여러 코어가 포함된 전용 서버가 있고 메모리를 늘린 경우 SSIS에 대한 기본 메모리 설정을 조정하여 SSIS 서버의 용량을 보다 효과적으로 활용할 수 있습니다.
다음은 조정을 고려해야 하는 SSIS 메모리 설정입니다.
· DefaultBufferSize
· DefaultBufferMaxRows
· EngineThreads
DefaultBufferSize와 DefaultBufferMaxRows는 서로 관련되어 있습니다. 데이터 흐름 엔진은 단일 데이터 행의 크기를 예측하려고 합니다. 이 크기는 DefaultBufferMaxRows에 저장된 값과 곱해지며 데이터 흐름 엔진은 버퍼용으로 적절한 메모리 청크를 예약하려고 합니다.
[버퍼 크기 값] = [단일 데이터 행의 크기] x [DefaultBufferMaxRows]
버퍼 크기 값이 DefaultBufferSize 설정보다 큰 경우 데이터 흐름 엔진은 데이터 행의 수를 줄입니다.
내부적으로 계산된 최소 버퍼 크기 값이 버퍼 크기 값보다 크면 데이터 흐름 엔진은 데이터 행의 수를 늘립니다. 그러나 엔진은 DefaultBufferMaxRows 값을 초과하지 않습니다.
DefaultBufferSize 및 DefaultBufferMaxRows 설정을 조정하는 경우 디스크에 데이터를 쓰는 데이터 흐름 엔진에 영향을 주는 값에 주의하는 것이 좋습니다. SSIS 서버 디스크로 페이지 아웃된 메모리는 SSIS 패키지 실행의 성능에 부정적인 영향을 미칩니다. Buffers spooled 카운터를 보면 패키지가 실행되는 동안 데이터 버퍼가 디스크에 임시로 기록되는지 여부를 확인할 수 있습니다.
SSIS 패키지의 성능 카운터 및 카운터 통계에 대한 자세한 내용은 성능 카운터(http://msdn.microsoft.com/ko-kr/library/ms137622.aspx)를 참조하십시오.
EngineThreads 설정에서는 태스크 실행에 사용 가능한 스레드 수를 데이터 흐름 엔진에 제안합니다. 다중 코어 서버가 사용되는 경우 기본값 10을 늘리는 것이 좋습니다. 그러나 엔진은 이 속성의 값에 관계없이 필요한 것보다 많은 스레드를 사용하지 않습니다. 동시성 문제를 방지하기 위해 필요한 경우에는 엔진에서 이 속성에 지정된 것보다 많은 수의 스레드를 사용할 수도 있습니다. 복잡한 패키지의 경우 처음에는 기본값 10 아래로 내려가지 않으면서 실행 트리당 최소 1개의 엔진 스레드를 사용하는 것이 좋습니다.
설정에 대한 자세한 내용은 데이터 흐름 성능 기능(http://msdn.microsoft.com/ko-kr/library/ms141031.aspx)을 참조하십시오.
BLOB 데이터에 대한 특별 고려 사항
크기가 정해지지 않은 파이프라인 버퍼에 들어갈 수 있는 것보다 더 많은 데이터가 SSIS 파이프라인 집합에 있으면 데이터가 스풀링됩니다. 이는 특히 XML, 텍스트 또는 이미지 데이터와 같은 BLOB 데이터를 처리할 때 성능 문제가 됩니다. BLOB 데이터가 파이프라인에 있는 경우 SSIS는 버퍼의 절반을 행 내부 데이터용으로 설정하고 나머지 절반을 BLOB 데이터용으로 설정합니다. 이 때문에 버퍼의 절반에 들어가지 않는 BLOB 데이터는 스풀링됩니다. 따라서 BLOB 데이터가 파이프라인에 있으면 다음 작업을 수행하여 SSIS 패키지를 조정해야 합니다.
1. 고성능 드라이브를 가리키도록 BLOBTempStoragePath 및 BufferTempStoragePath의 값을 변경합니다. 기본적으로 스풀링된 개체는 TEMP 또는 TMP 환경 변수에 정의된 디렉터리의 임시 파일에 기록됩니다. 이 디렉터리는 기본적으로 운영 체제 드라이브에 있습니다. 일반적으로 운영 체제 드라이브는 고성능 드라이브가 아닙니다. 고성능 저장소의 디렉터리를 가리키도록 SSIS Dataflow 태스크 속성에서 BLOBTempStoragePath의 값을 변경하여 임시 데이터 스풀 파일이 고성능 드라이브에 기록되도록 할 수 있습니다. SSIS에 있는 모든 속성의 경우와 마찬가지로 식을 사용하여 이 값을 설정할 수 있습니다.
2. 스풀링 발생을 최소화하도록 DefaultBufferSize 및 DefaultBufferMaxRows의 크기를 조정합니다. 일반적으로 디스크가 서버에서 가장 느린 구성 요소이고 디스크 속도는 대개 프로세서나 메모리 속도보다 훨씬 느리므로 스풀링을 허용하는 것보다 버퍼를 비효율적으로 사용하는 것이 보다 효율적일 수 있습니다. 데이터 흐름에 BLOB 데이터가 있는 경우 BLOB 데이터로 인한 스풀링을 최소화하려면 다음과 같은 방법을 사용하여 DefaultBufferSize 및 DefaultBufferMaxRows를 결정합니다.
a. MaxBufferSize를 결정합니다. 데이터 흐름에 BLOB 데이터가 있으므로 적합한 시작 지점은 허용되는 최대값인 100MB 또는 104857600바이트일 수 있습니다.
b. 이 수를 2로 나눕니다. 이 예에서는 52428800바이트입니다. 이는 BLOB 데이터를 포함할 수 있는 버퍼의 절반에 해당합니다.
c. 이 데이터 흐름에서 처리할 BLOB 데이터의 예상 크기에 사용할 크기를 선택합니다. 이 크기에 적합한 시작 지점은 평균 길이 + 2 x 버퍼에 있을 모든 BLOB 데이터의 평균 길이에 대한 표준 편차입니다. 이 값에는 모든 BLOB 데이터의 약 98%가 포함됩니다. 두 개 이상의 행이 단일 SSIS 버퍼에 포함될 가능성이 높기 때문에 이 방법을 사용하면 스풀링이 거의 발생하지 않습니다.
· 원본이 SQL Server인 경우 다음과 같은 쿼리를 사용하여 길이를 얻을 수 있습니다.
SELECT CAST
(
AVG(DATALENGTH(ColName))
+ (2 * STDEV(DATALENGTH(Demographics)))
AS INT
) AS Length FROM SchemaName.TableName
· 테이블이 너무 커서 평균과 표준 편차를 구하기 위해 전체 데이터 집합을 쿼리할 수 없는 경우 T-SQL의 무작위 샘플링(http://msdn.microsoft.com/ko-kr/library/aa175776(v=SQL.80).aspx)에 설명된 것과 같은 방법을 사용하여 사용할 길이를 얻는 샘플을 찾을 수 있습니다.
d. b 단계에서 얻은 수를 c 단계에서 얻은 수로 나눕니다. 이 수를 사용하거나 데이터 흐름 태스크의 DefaultBufferMaxRows 값보다 약간 작은 수를 사용합니다.
팁: DefaultBufferMaxRows 및 MaxBufferSize는 식을 사용하여 구성할 수 있습니다. 이 방법은 BLOB 데이터 길이의 통계적 특성이 자주 변경될 수 있는 데이터 집합의 경우나 템플릿 패키지를 만들어 런타임에 이러한 값을 설정하는 경우에 사용할 수 있습니다. 이러한 값을 동적으로 만들려면 다음을 수행하십시오.
1. 패키지 수준에서 새 변수를 만듭니다. 새 변수의 이름을 DefaultMaxRowsInBuffer로 지정합니다. 데이터 형식을 Int32로 유지합니다. MaxBufferSize 속성을 동적으로 설정하려면 유사한 변수를 만들면 됩니다.
2. SQL 실행 태스크나 스크립트 태스크를 사용하여 DefaultBufferMaxRows에 사용할 값을 찾습니다. 계산하는 값을 1단계에서 만든 DefaultMaxRowsInBuffer 변수에 저장합니다.
참고: SQL 실행 태스크를 사용하여 단일 값을 SSIS 변수로 검색하는 방법에 대한 자세한 내용은 SQL 실행 태스크의 결과 집합(http://technet.microsoft.com/ko-kr/library/cc280492.aspx)을 참조하십시오.
3. DefaultBufferMaxRows를 설정할 데이터 흐름 태스크의 속성 상자에서 식을 선택하여 속성 식 편집기 대화 상자를 엽니다.
4. 속성 식 편집기의 속성 드롭다운 메뉴에서 DefaultBufferMaxRows를 선택하고 줄임표 단추를 클릭하여 식 작성기를 엽니다.
5. 1단계에서 만든 변수를 왼쪽 위 모퉁이에 있는 변수 및 매개 변수 목록에서 식 상자로 끌어오고 식 계산을 클릭하여 평가 값 상자에서 변수의 기본값을 확인합니다.
6. 식 작성기와 속성 식 편집기 대화 상자에서 확인을 클릭하여 구성을 저장합니다. 이 구성에서 속성의 값은 BLOB 데이터가 디스크에 스풀링되는 가능성을 최소화하기 위해 런타임에 설정됩니다.
SSIS 2012의 새로운 기능을 사용하여 분산 시스템에서 성능 모니터링
SSIS 서버에 배포하는 SSIS(Integration Services) 프로젝트의 성능을 모니터링하기 위해 SQL Server 2012에서 사용할 수 있는 새로운 기능이 있습니다. 패키지 실행에 대한 런타임 성능 정보를 기록하고 패키지 실행 통계를 보며 패키지 데이터 흐름을 모니터링할 수 있습니다.
성능 통계 기록
다음 로깅 수준 중 하나를 선택하여 패키지 실행 중에 기록되는 정보의 범위를 지정할 수 있습니다. 성능 통계를 기록하려면 성능 또는 자세히 로깅 수준을 선택합니다.
로깅 수준
값
설명
없음
0
로깅이 해제됩니다. 패키지 실행 상태만 기록됩니다.
기본
1
사용자 지정 이벤트 및 진단 이벤트 외의 모든 이벤트가 기록됩니다. 이 값은 기본값입니다.
성능
2
성능 통계와 OnError 및 OnWarning 이벤트만 기록됩니다.
자세히
3
사용자 지정 이벤트 및 진단 이벤트를 포함한 모든 이벤트가 기록됩니다.
Integration Services는 패키지 및 여러 태스크에 대한 로그 항목 기록을 위해 다양한 사용자 지정 이벤트 집합을 제공합니다. 나중에 분석할 수 있도록 미리 정의된 이벤트 또는 사용자 정의 메시지를 기록하여 실행 진행률, 결과 및 문제에 대한 세부 정보를 저장하는 데 이러한 항목을 사용할 수 있습니다.
자세한 내용은 로깅할 메시지 사용자 지정(http://msdn.microsoft.com/ko-kr/library/ms345174.aspx)을 참조하십시오.
패키지 실행 인스턴스에 대해 다음 중 하나 이상을 수행하여 로깅 수준을 지정할 수 있습니다.
· catalog.set_execution_parameter_value(http://msdn.microsoft.com/ko-kr/library/ff877990.aspx) 저장 프로시저를 사용하여 패키지 실행 인스턴스의 매개 변수 설정
· 패키지 실행 대화 상자를 사용하여 패키지 실행 인스턴스 구성
· 새 작업 단계 대화 상자를 사용하여 패키지 실행에 대한 SQL Server 에이전트 작업 구성
패키지 실행 대화 상자를 사용하여 로깅 수준을 설정하려면
1. SQL Server Management Studio의 개체 탐색기에서 패키지로 이동합니다.
2. 패키지를 마우스 오른쪽 단추로 클릭하고 실행을 선택합니다.
3. 고급 탭을 선택합니다.
4. 로깅 수준에서 로깅 수준을 선택합니다.
새 작업 단계 대화 상자를 사용하여 로깅 수준을 설정하려면
1. 개체 탐색기에서 SQL Server 에이전트 노드를 확장하고 작업을 마우스 오른쪽 단추로 클릭한 다음 새 작업을 클릭하여 새 작업을 만듭니다.
-또는-
SQL Server 에이전트 노드를 확장하고 기존 작업을 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭하여 기존 작업을 수정합니다.
2. 왼쪽 창에서 단계를 클릭한 다음 새로 만들기를 클릭하여 새 작업 단계 대화 상자를 엽니다.
3. 유형 목록 상자에서 SQL Server Integration Services 패키지를 선택합니다.
4. 패키지 탭의 패키지 원본 목록 상자에서 SSIS 카탈로그를 선택하고 서버를 지정한 다음 패키지 상자에 패키지 경로를 입력합니다.
5. 구성 탭에서 고급을 클릭한 다음 로깅 수준 목록 상자에서 로깅 수준을 선택합니다.
6. 작업 단계의 구성을 마치고 변경 내용을 저장합니다.
catalog.set_execution_parameter_value 저장 프로시저를 사용하여 로깅 수준을 설정하려면 parameter_name을 LOGGING_LEVEL로 설정하고 parameter_value를 성능 또는 자세히로 설정합니다. 다음 예에서는 Package.dtsx 패키지에 대한 실행 인스턴스를 만들고 로깅 수준을 2로 설정합니다. 패키지는 SSISPackages 프로젝트에 포함되어 있고 프로젝트는 패키지 폴더에 있습니다.
Declare @execution_id bigint
exec catalog.create_execution 'Packages', 'SSISPackages', 'Package.dtsx', NULL, 1, @execution_id output
exec catalog.set_execution_parameter_value @execution_id, 50, 'LOGGING_LEVEL', 2
실행 통계 보기
SQL Server Management Studio에서 사용 가능한 SSISDB 데이터베이스 뷰, 저장 프로시저 및 표준 보고서는 패키지 실행에 대한 정보와 실행 관련 정보를 풍부하게 제공합니다. 실행 파일은 패키지 실행의 인스턴스입니다.
표준 보고서 중에서 Integration Services 대시보드, 모든 실행 및 모든 연결 보고서는 패키지 실행 정보를 보는 데 특히 유용합니다.
Integration Services 대시보드 보고서는 실행 중이거나 지난 24시간 동안 실행을 완료한 패키지에 대한 다음 정보를 제공합니다.
Integration Services 대시보드 보고서
보고서 섹션
설명
실행 정보
다양한 상태(실패, 실행 중, 성공 등)에 있는 실행 수를 보여 줍니다.
패키지 정보
실행된 총 패키지 수를 보여 줍니다.
연결 정보
실패한 실행에 사용된 연결을 보여 줍니다.
패키지 세부 정보
각 패키지에 대해 완료된 실행의 세부 정보를 보여 줍니다. 예를 들어 실패한 실행 수, 총 실행 수, 실행 기간(초), 과거 3개월 동안의 평균 실행 기간을 보여 줍니다.
실행 성능, 개요 및 모든 메시지를 클릭하면 �