내보내기(0) 인쇄
모두 확장

Azure에 대한 마이그레이션 계획 구현

업데이트 날짜: 2014년 4월

Azure는 Microsoft 데이터 센터에 호스팅된 인터넷 규모의 컴퓨팅 및 서비스입니다. Azure를 사용하면 모든 기본 운영 체제, 하드웨어, 네트워크, 저장소 리소스 및 플랫폼 업데이트가 Microsoft에서 자동으로 처리되므로 개발자와 관리자가 기본 소프트웨어 및 하드웨어 인프라를 구현할 필요가 없습니다.

새로 배포한 응용 프로그램에 대해 수행하던 것처럼, 가급적이면 응용 프로그램을 클라우드로 마이그레이션한 후 응용 프로그램에 대한 기능 및 성능 테스트를 실행하는 것이 좋습니다. Azure는 내부 플랫폼과는 다르므로 마이그레이션을 구현할 때 다음 중요 문제를 고려해야 합니다.

이 항목에서는 Azure 클라우드 서비스에 초점을 맞추고 있습니다. Azure 가상 컴퓨터의 SQL Server 관련 마이그레이션에 대한 자세한 내용은 Windows Azure 가상 컴퓨터로 마이그레이션을 참조하십시오.

저자: Kun Cheng, Steve Howard
참여자: Selcin Turkarslan

응용 프로그램을 클라우드로 마이그레이션하는 동안 클라우드에서 응용 프로그램이 예상대로 작동되도록 응용 프로그램을 테스트하고 디버깅하는 방법을 알아야 합니다. 다음은 응용 프로그램을 테스트하는 데 사용할 수 있는 접근 방식 목록입니다.

  • Azure Tools for Microsoft Visual Studio: 응용 프로그램을 빌드한 다음 Azure Tools의 일부로 제공된 계산 및 저장소 에뮬레이터를 사용하여 이 응용 프로그램을 로컬로 실행 및 디버그할 수 있습니다. 이를 통해 응용 프로그램을 Azure에 게시하기 전에 로컬로 개발할 수 있습니다. Azure Tools for Microsoft Visual Studio는 Visual Studio 2010을 확장하여 Azure 기능의 대부분을 제공하는 컴퓨팅 및 저장소 에뮬레이터를 사용하여 응용 프로그램을 테스트할 수 있도록 합니다. 기능 테스트의 조기 단계에서 이 테스트 유형을 수행하는 것이 좋습니다. 자세한 내용은 Azure Tools for Microsoft Visual Studio를 참조하십시오.

  • SQL Server Data Tools: SSDT(SQL Server Data Tools)는 데이터베이스를 디자인하거나, 데이터베이스 개체 및 데이터를 작성 또는 편집하거나, 지원되는 모든 SQL 플랫폼(외부 Azure SQL 데이터베이스와 내부 Microsoft SQL Server 2012 포함)에 대해 쿼리를 실행하는 데 사용할 수 있는 통합 환경을 Visual Studio 2010 내에서 제공합니다. 이 환경에서는 응용 프로그램의 관계형 데이터 액세스 부분을 검사하여 로컬 기본 데이터베이스나 Azure SQL 데이터베이스를 사용하는 데이터베이스 프로젝트 솔루션을 테스트할 수 있습니다. 자세한 내용은 SQL Server Data Tools를 참조하십시오. 참고: Azure Tools for Microsoft Visual Studio와 SSDT 둘 다에서 오프라인 및 온라인 데이터 원본을 사용하여 응용 프로그램에 대한 기본 기능 및 호환성 테스트를 수행할 수 있습니다. 실제 클라우드 응용 프로그램의 모든 기능, 성능 및 확장성 측면을 테스트하려면 응용 프로그램이 배포되고 실행 중인 Azure에서 시뮬레이션 테스트를 수행해야 합니다.

  • 자동화된 테스트 프레임워크: 여러 기존 응용 프로그램에는 이미 응용 프로그램 작업의 모든 구성 요소나 기능이 예상대로 작동하는지 확인하는 데 사용할 수 있는 자동화된 테스트 프레임워크가 있습니다. 응용 프로그램을 Azure에서 실행하는 경우 자동화된 테스트 프레임워크가 디자인된 방식에 따라 작동하지 않을 수도 있습니다. 내부에서 실행하는 데 자동화된 테스트 프레임워크가 필요하지만 정의된 끝점을 사용하여 Azure에 있는 응용 프로그램에 연결할 수 있는 경우 자동화된 테스트 프레임워크가 여전히 작동할 수 있습니다. 그렇지 않으면, 자동화된 테스트 프레임워크와 Azure의 응용 프로그램을 둘 다 호스팅하여 잠재적인 연결 손실 및 대기 시간 문제를 줄이는 것이 좋습니다.

  • Visual Studio 부하 테스트: 응용 프로그램에 기존의 자동화된 테스트 프레임워크가 없는 경우 새로운 자동화된 테스트 프레임워크를 만들고 Visual Studio 부하 테스트를 사용하여 여러 동시 사용자에 대해 시뮬레이션 테스트를 수행하는 것이 좋습니다.

테스트, 준비 및 프로덕션 간에는 실제 이동 시간을 가능한 최소화하려고 노력해야 합니다. 내부의 큰 데이터베이스를 Azure로 복사하는 데 몇 시간 또는 몇 일이 걸릴 수 있습니다. 또한 기존 데이터를 완전히 마이그레이션하는 데 소요되는 시간 동안 응용 프로그램이 중단되는 것을 원하지 않을 것입니다. 그렇기 때문에 이동으로 인한 모든 중단 시간을 최소화할 계획을 마련해야 하는 것입니다. 이동(cut over) 시간이란 Azure로 최종 이동을 실행하는 데 소요되는 시간을 말합니다. 이동하기 전에 테이블을 살펴보고 정적 데이터를 포함하는 테이블과 이동 중에 변경될 수 있는 데이터를 포함하는 테이블을 결정하십시오. 정적 데이터의 경우 이동 시간에 데이터를 이동할 필요가 없습니다. 하지만 특정 테이블의 데이터가 이동 중에 변경될 수 있는지 여부가 확실하지 않을 경우 나중에 모든 변경을 마이그레이션하기 위한 논리를 시스템에 포함해야 합니다. 또한 응용 프로그램이 Azure에서 가동되기 전에 내부 시스템의 모든 데이터를 클라우드로 마이그레이션해야 하는지 여부도 고려하는 것이 좋습니다. 응용 프로그램을 가동할 수 있고 응용 프로그램에서 데이터를 나중에 catch할 수 있는 경우에는 모든 중단 시간을 없앨 수 있습니다.

하지만 Azure의 데이터가 Azure에서 가동되기 전에 내부 데이터와 일치해야 하는 경우 이동할 때 마이그레이션해야 하는 데이터의 양을 최소화하는 것을 고려하십시오. 이는 실제 이동에 소요되는 중단 시간을 최소화하는 데 도움이 됩니다. 경우에 따라 이동 전에 일부 데이터를 이동하고 나서 실제 이동 후 나머지 데이터를 이동하는 것이 적합할 수도 있습니다. 이와 같은 경우에는 마이그레이션 계획에서 먼저 마이그레이션해야 하는 데이터와 나중에 이동 후에 마이그레이션할 수 있는 나머지 데이터를 명확히 식별해야 합니다. 이렇게 하면 나머지 데이터를 마이그레이션하는 동안 응용 프로그램이 프로덕션 환경에 있을 수 있으므로 보다 적은 중단 시간으로 Azure에서 응용 프로그램을 가동할 수 있습니다. 다음과 같은 데이터 동기화 방법을 사용하여 이동 전에 데이터 마이그레이션을 수행할 수 있습니다.

SQL 데이터 동기화(미리 보기) 서비스에서는 SQL 데이터베이스(SQL Server 및 SQL 데이터베이스)에 대한 데이터 동기화 기능을 제공합니다. 이 서비스에는 현재 두 가지 주요 기능이 포함되어 있습니다.

  • 내부 SQL Server 데이터베이스와 SQL 데이터베이스 인스턴스 간 데이터의 동기화. 내부 및 클라우드 기반 응용 프로그램에서 같은 데이터를 사용할 수 있습니다.

  • 두 개 이상의 SQL 데이터베이스 인스턴스 간 데이터 동기화. 인스턴스는 같은 데이터 센터, 다른 데이터 센터 또는 다른 지역에 있을 수 있습니다.

SQL 데이터 동기화(미리 보기)는 다음 상황에서 내부 데이터베이스와 SQL 데이터베이스 인스턴스를 동기화할 수 있는 유용한 옵션입니다.

  • 응용 프로그램의 병렬 테스트를 수행해야 하는 경우

  • 모든 내부 데이터 작업을 로 최종 이동하기 전에 응용 프로그램을 병렬로 실행해야 하는 경우

  • 로 마이그레이션하는 동안 응용 프로그램을 내부에서 실행하면서 동시에 중단 시간을 최소화해야 하는 경우

  • 내부 응용 프로그램과 응용 프로그램 사이에서 혼합 솔루션의 일부로서 연속 데이터 동기화를 수행해야 하는 경우

SQL 데이터 동기화(미리 보기)에서는 증분 데이터 변경 사항을 추적하기 위해 동기화 그룹이 구성될 때 동기화되고 있는 각 테이블에 대해 변경 추적 테이블을 추가합니다. SQL 데이터 동기화(미리 보기)를 사용하는 경우 공간 계획에서 변경 내용 추적 테이블을 고려해야 합니다. 또한 동기화 그룹을 다시 초기화하지 않을 경우 동기화가 설정된 후 동기화되는 테이블의 테이블 구조 또는 기본 키를 변경해서는 안 됩니다. SQL 데이터 동기화(미리 보기)는 중간 또는 진행 중 데이터 동기화가 필요한 상황에는 적합하지 않습니다.

경고: SQL 데이터 동기화(미리 보기)는 현재 미리 보기로만 사용할 수 있으며 이후 릴리스를 위한 제품 사용자 의견용으로만 사용되므로 프로덕션 환경에서는 사용할 수 없습니다.

SQL 데이터 동기화(미리 보기)에 대한 자세한 내용은 SQL 데이터 동기화를 참조하십시오.

복제, 미러링 또는 로그 전달을 사용하여 내부 SQL Server의 데이터를 다른 내부 SQL Server 또는 Azure 가상 컴퓨터에서 실행 중인 SQL Server의 인스턴스로 이동할 수 있습니다. 하지만 Azure SQL 데이터베이스 내부 또는 외부로 데이터를 이동할 때는 이러한 기능을 사용할 수 없습니다. 자세한 내용은 로그 전달 및 복제데이터베이스 미러링 및 로그 전달을 참조하십시오.

이동 시 데이터를 전송하는 데 드는 시간을 최소화하기 위해서는 실제 이동 전에 가능한 많은 데이터를 Azure 플랫폼으로 이동해야 합니다. 내부 시스템에서 Azure 환경으로 변경된 데이터를 이동하기 위한 사용자 지정 ETL 작업을 만들 수 있습니다. 내부 SQL Server 2008 이상에서 마이그레이션하는 경우에는 변경 데이터 캡처 또는 변경 데이터 추적을 사용하여 모든 변경된 데이터와 실제로 변경된 데이터만 내부 데이터베이스에서 Azure SQL 데이터베이스 인스턴스로 이동되는지 확인하는 것이 좋습니다. 이러한 두 기능에 대한 자세한 내용은 SQL Server Books 온라인 설명서의 데이터 변경 내용 추적을 참조하십시오. 변경 데이터 캡처 또는 변경 데이터 추적을 사용하지 않는 데이터베이스의 경우 마이그레이션된 변경 내용과 데이터에 대한 추적 시스템을 만들어야 합니다. 어느 경우든 실제 이동에 소요되는 중단 시간을 최소화하기 위해서는 실제 이동 시 이동할 데이터의 양을 최소화하는 것이 핵심입니다.

DAC를 사용하여 SQL Server 인스턴스에서 데이터를 내보낸 후 Azure Blob 저장소에 저장할 수 있습니다. 이 저장소에서 데이터를 Azure SQL 데이터베이스로 가져올 수 있습니다. DAC를 사용하여 가져오거나 내보낼 테이블에 대한 필터를 설정할 수 있습니다. 하지만 행 수준의 필터는 설정할 수 없습니다. 바로 이러한 이유로 전체 테이블이 단일 데이터베이스에 포함된 경우에는 DAC가 적절하지만 확장된 데이터베이스에서는 정상적으로 작동하지 않는 것입니다. 진행 중 데이터 동기화가 필요한 응용 프로그램에 대한 데이터를 마이그레이션하는 경우에는 DAC가 적합하지 않습니다. 자세한 내용은 SQL Server 온라인 설명서의 데이터 계층 응용 프로그램 내보내기를 참조하십시오.

데이터베이스 백업을 만드는 목적은 관리 오류, 응용 프로그램 오류 또는 전체 데이터 센터 손실로 인한 데이터 손실로부터 복구할 수 있도록 하기 위한 것입니다. Azure SQL 데이터베이스에서 데이터를 백업하고 복원하는 작업은 내부 SQL Server에서와는 다르며 사용 가능한 리소스 및 도구를 사용하여 작업해야 합니다. 따라서 복구용으로 안정된 백업 및 복원을 사용하려면 Azure SQL 데이터베이스 백업 및 복원 전략이 필요합니다. Azure SQL 데이터베이스 인스턴스에서 복구가 필요할 수 있는 일반적인 문제 범주에는 세 가지가 있습니다.

  • 인프라 또는 하드웨어 오류: 데이터 센터 내에서 하드웨어 오류가 발생할 수 있습니다. 예를 들면 Azure SQL 데이터베이스 인스턴스를 실행 중인 실제 노드가 중단될 수 있습니다.

  • 응용 프로그램 또는 사용자에 의해 발생한 문제 또는 오류: 사용자 또는 응용 프로그램이 데이터에 대한 원치 않는 변경을 발생시킬 수 있습니다. 이로 인해 되돌리기 작업이 필요할 수 있습니다. 예를 들어 잘못된 고객에게 속한 데이터를 수정하는 경우가 있을 수 있습니다.

  • 데이터 센터 시설 손실: 현재 Azure SQL 데이터베이스 서비스 수준 계약에는 재해와 같은 Microsoft의 적정 제어 범위를 벗어난 요인에 대한 예외 항목이 명확하게 포함되어 있습니다. 재해 발생 시 데이터베이스를 복제본 또는 현장 백업본으로부터 복구할 수 없을 정도로 데이터 센터가 손상될 수 있습니다.

결국 Azure SQL 데이터베이스 데이터 센터 안에 저장된 데이터와 관련하여 허용할 위험 수준을 결정해야 합니다. 사용할 수 있는 백업 및 복원 도구와 이러한 도구와 관련된 재해 복구 전략을 작성하는 방법에 대한 자세한 내용은 MSDN 라이브러리의 Azure SQL 데이터베이스 비즈니스 연속성 문서를 참조하십시오.

실제로 응용 프로그램을 Azure로 마이그레이션할 때는 다음 접근 방식을 따를 수 있습니다.

  • 동시 실행: 이 접근 방식을 사용하면 응용 프로그램을 내부와 Azure 모두에서 동시에 실행할 수 있습니다. 따라서 응용 프로그램이 클라우드에 완전히 종속되기 전에 Azure에 있는 응용 프로그램에 대한 라이브 테스트를 수행할 수 있습니다. 테스트는 기능 테스트, 성능 테스트 및 확장성 테스트를 포함하되, 이에 제한되지 않습니다. Azure의 테스트 시스템에 대한 테스트를 완전히 완료한 후에는 최종 데이터 마이그레이션을 수행하고 내부 시스템을 종료합니다.

  • 일시 중지 및 이동: 이 접근 방식은 Azure에서 완전히 가동되기 전에 모든 데이터를 동기화해야 하는 경우에 적합합니다. 이 접근 방식을 사용하는 경우 먼저 Azure에서 모든 기능 및 성능 테스트를 완료해야 합니다. 그런 다음 위에 명시된 데이터 동기화 방법 중 하나를 사용하여 데이터를 Azure 환경으로 복제합니다. 최종 이동 전에 마지막 동기화 또는 ETL에 소요되는 시간의 양을 최소화하여 가능한 동기화된 상태에 가깝게 데이터를 유지하는 것이 좋습니다. Azure로 이동할 때가 되었으면 내부 시스템을 종료하고 마지막 데이터 동기화를 수행한 후 Azure에서 응용 프로그램을 불러옵니다.

참고 항목

표시:
© 2015 Microsoft