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

Azure SQL 데이터베이스 마이그레이션 프로젝트 계획

업데이트 날짜: 2014년 4월

이 항목에서는 Microsoft Azure SQL 데이터베이스 마이그레이션 프로젝트에서 로 내부 SQL Server 데이터베이스 마이그레이션을 계획하고 수행하는 몇 가지 최선의 구현 방법을 설명합니다. 이 항목에서는 다음과 같은 사항을 다룹니다.

  1. 데이터베이스 마이그레이션에 대해 염두에 두어야 할 사항

  2. 데이터베이스 마이그레이션을 위한 프로젝트 목표를 설정하는 분석

  3. 계획 및 디자인, 개발, 테스트, 안정화배포 단계로 데이터 마이그레이션 하위 프로젝트 관리

저자: Shaun Tinline-Jones
참여자: Steve Howard
검토자: Shawn Hernan

데이터베이스 마이그레이션은 보다 큰 솔루션 마이그레이션 프로젝트의 하위 프로젝트입니다. 일반적으로 응용 프로그램 마이그레이션 프로젝트와 데이터베이스 마이그레이션 프로젝트 간에는 통합점과 종속성이 있습니다. 그러나 데이터베이스 마이그레이션은 대개 거의 병목 현상 없이 진행할 수 있습니다.

Azure SQL 데이터베이스 마이그레이션 프로젝트에 접근할 때는 다음의 세 가지 사항을 염두에 두어야 합니다.

  • 프로젝트의 수명 주기는 기본적으로 빠르고 반복적이어야 합니다. 초기 조사를 바탕으로 최초 계획을 만듭니다. 새로운 반복을 계획하는 동안 이전 반복에서 수행한 조사를 기초로 계획을 구체화합니다.

  • 데이터베이스와 관련 응용 프로그램의 크기 및 복잡성이 마이그레이션 프로젝트의 다양한 요인을 결정합니다.

    • 데이터베이스의 복잡성에 따라 데이터베이스를 마이그레이션하는 데 필요한 엔지니어링 작업이 결정됩니다.

    • 데이터베이스의 크기, 즉 데이터베이스에 들어 있는 데이터의 양에 따라 새 데이터베이스를 채우고 내부 데이터베이스에서 Azure SQL 데이터베이스에 호스팅된 데이터베이스로 옮기는 데 걸리는 시간이 결정됩니다.

  • 데이터베이스를 새 플랫폼으로 마이그레이션하면 대개 데이터베이스가 변경되며 데이터베이스를 사용하는 다른 솔루션 계층에도 영향이 있습니다. 마이그레이션 프로젝트에서는 영향을 받는 모든 계층에서 개발 작업을 조정하고 변경된 모든 구성 요소의 통합된 배포를 제공해야 합니다.

마이그레이션되는 각 데이터베이스는 크기와 복잡성을 기준으로 정의된 4개의 사분면 중 하나로 분류할 수 있습니다. 데이터베이스가 속하는 사분면은 데이터베이스를 Azure SQL 데이터베이스로 마이그레이션하는 데 필요한 프로젝트 범위를 이해하고 적절한 마이그레이션 메커니즘을 선택하는 데 도움이 됩니다. 사분면은 다음과 같습니다.

프로젝트 크기 및 복잡성 사분면

대형 데이터베이스는 인터넷을 통해 데이터를 전송하는 데 더 오래 걸리므로 Azure SQL 데이터베이스로 마이그레이션(단독형)하는 데 더 긴 시간이 필요합니다. 데이터베이스가 복잡할수록 더 많은 변경 작업이 필요하므로 엔지니어링 작업량도 더 많아집니다.

원본 데이터베이스의 크기와 복잡성 파악은 마이그레이션 프로젝트의 목표를 설정할 데 있어 중요한 측면입니다.

분석 단계에서는 프로젝트에 대한 목표와 비전이 설정됩니다. 전체 프로젝트 목표에는 마이그레이션할 데이터베이스에 대한 목표가 포함되어야 합니다.

모든 데이터베이스는 가용성, 복구, 응답 시간 및 보안 및 개인 정보 규칙 준수 등의 비즈니스 요구 사항을 충족해야 합니다. 데이터베이스를 Azure SQL 데이터베이스로 마이그레이션하는 경우 이러한 비즈니스 요구 사항을 준수하도록 데이터베이스 서비스를 구성하거나 Azure SQL 데이터베이스를 통해 충족될 수 있는 새로운 요구 사항을 협상합니다. 관리 프로세스를 변경해야 할 수도 있습니다. 예를 들어 현재 야간 데이터베이스 백업을 수행 중인 경우 Azure SQL 데이터베이스에서 지원하는 데이터 복사 또는 데이터 계층 응용 프로그램 내보내기 기능으로 변경해야 할 수 있습니다.

비즈니스 요구 사항은 기존 데이터베이스와 응용 프로그램 코드를 분석하여 확인할 수 없습니다. 이해 관계자나 관리자에게 요청하거나 서비스 수준 계약 등의 프로세스 문서를 검토하여 요구 사항을 수집해야 합니다.

데이터베이스 마이그레이션과 관련된 마이그레이션 프로젝트 목표는 데이터베이스에 대한 비즈니스 요구 사항을 충족하고 데이터베이스의 크기와 복잡성을 반영해야 합니다. 복잡한 데이터베이스는 단순한 데이터베이스보다 마이그레이션하는 데 더 많은 엔지니어링 작업을 필요로 합니다. 복잡한 데이터베이스를 마이그레이션하는 프로젝트의 경우 내부 데이터베이스에 사용되는 기능을 마이그레이션하는 것으로 초기 프로젝트를 제한하여 위험을 줄일 수 있습니다. 후속 프로젝트에서 Azure SQL 데이터베이스 고유의 통합 기능을 수행할 수 있습니다.

분석 단계는 계획 및 디자인 단계를 위한 상위 수준 지침을 제공합니다. 분석 단계에서 마이그레이션에 영향을 줄 수 있는 모든 문제를 검토해야 하지만, 이 단계에서 세부적인 사항에 너무 중점을 두지는 마십시오. 다음에는 계획과 디자인 단계의 첫 번째 반복 부분을 자세히 검토하여 보다 세분화된 디자인과 계획을 수립해야 합니다. 피드백 프로세스를 실시하여 조기 계획 및 디자인 작업의 결과에 맞춰 비전과 범위 문서를 조정합니다.

Azure SQL 데이터베이스 마이그레이션 프로젝트의 복잡성 평가는 성공적인 마이그레이션을 수행하는 데 얼마큼의 변경이 필요한지 결정하는 것을 의미합니다. Azure SQL 데이터베이스 마이그레이션 프로젝트의 각 단계를 거칠 때마다 마이그레이션으로 인해 발생하는 엔지니어링 변경의 범위를 점점 더 정확하게 평가해야 합니다. 초기 일반 평가는 프로젝트 목표 정의와 프로젝트 실행 결정으로 나누어야 합니다. 또한 이러한 일반 평가는 조기 프로젝트 계획 및 디자인 작업의 기초가 됩니다. 프로젝트 후반에 수행되는 심층 조사의 결과가 점점 더 상세화되는 프로젝트 계획, 디자인 및 프로젝트 목표 조정 사항에 반영되어야 합니다.

마이그레이션 프로젝트의 일부로 Azure SQL 데이터베이스에서 지원하지 않는 기능에 대한 모든 종속성을 해결합니다. 초기에는 프로덕션 시스템에 액세스하지 않고도 이러한 종속성을 식별할 수 있습니다. 데이터베이스 디자인 문서 또는 응용 프로그램 사양과 Azure SQL 데이터베이스에서 지원하는 기능에 대한 기존 문서를 비교해 보면 됩니다. 이 문서를 데이터베이스 및 응용 프로그램 디자인에 친숙한 사람들이 검토할 수도 있습니다. 나중에 Azure SQL 데이터베이스 마이그레이션 마법사와 같은 도구를 사용하여 특정 종류의 종속성을 확인할 수 있습니다.

많은 내부 데이터베이스가 데이터베이스 외부의 서비스에 종속되어 있습니다. 예를 들면 복제 토폴로지 참여, SQL Server 통합 서비스 추출 프로세스 또는 SQL Server 에이전트에서 관리하는 반복 유지 관리 작업 등이 있습니다. 마이그레이션 프로젝트에는 이와 같은 서비스에 대한 종속성을 변경하는 데 필요한 비용과 개발 시간이 포함되어야 합니다. Azure SQL 데이터베이스에서 지원하지 않는 서비스에 대한 종속성을 제거합니다. Azure SQL 데이터베이스와 SQL Server 간의 구조적 차이로 인해 Azure SQL 데이터베이스를 지원하는 다른 시스템을 변경해야 할 수 있습니다.

또한 내부 데이터베이스에 Transact-SQL에서 지원하지 않는 Azure SQL 데이터베이스 개체가 있을 수 있습니다. 데이터베이스에 액세스하는 응용 프로그램과 저장 프로시저나 트리거와 같은 데이터베이스 개체의 코드가 Azure SQL 데이터베이스에서 지원하지 않는 구문 요소를 사용할 수도 있습니다.

다음 자료에 설명된 문제에 대해 데이터베이스 및 응용 프로그램 디자인 또는 코드를 검토하여 데이터베이스 복잡성에 대한 초기 평가를 수행할 수 있습니다.

데이터베이스를 Azure SQL 데이터베이스로 마이그레이션할 때 데이터베이스를 사용하는 응용 프로그램과 시스템을 변경해야 하는 경우가 많습니다.

먼저 응용 프로그램이 Azure SQL 데이터베이스 환경에서 효과적으로 작동하는 데 필요한 변경 작업을 수행해야 합니다. Azure SQL 데이터베이스는 데이터 센터 외부에서 호스팅되는 웹 서비스입니다. 따라서 데이터베이스 서버가 응용 프로그램 서버와 동일한 랙에 있을 때는 특별한 영향이 없는 최상의 몇몇 데이터베이스 구현 방법이 데이터베이스를 Azure SQL 데이터베이스로 마이그레이션할 때는 중요해집니다. Azure SQL 데이터베이스에 호스팅된 각 데이터베이스는 전체 가용성 향상을 위해 여러 서버에 클러스터됩니다. 그러나 현재 서버의 오류나 특정 작업으로 인해 열린 연결이 모두 닫히고 활성 트랜잭션이 롤백되는 일시적인 장애 조치(failover) 이벤트가 발생할 수 있습니다. 그러므로 연결 끊김 오류 발생 시 트랜잭션을 다시 시작하는 견고한 재시도 논리가 응용 프로그램에 반드시 포함되어야 합니다.

적절한 성능을 지원하는 데 필요한 응용 프로그램 변경에 대한 자세한 내용은 Windows Azure SQL 데이터베이스 사용 시 성능 고려 사항을 참조하십시오.

Azure SQL 데이터베이스에서 효과적으로 작동하는 데 필요한 추가 응용 프로그램 변경은 다음 문서에서 설명합니다.

또한 데이터베이스에 대한 모든 변경 내용에 맞게 조정하는 데 필요한 응용 프로그램 변경도 수행해야 합니다. 예를 들어 사용자 정의 집계를 데이터베이스에서 제거한 경우 Transact-SQL 문을 실행하여 해당 집계를 참조하는 모든 응용 프로그램을 변경해야 합니다.

계획과 디자인 작업은 복잡성 평가 중에 시작해야 합니다. 이 단계의 주요 부분은 다음 두 섹션에서 다루는 문제에 대해 점점 더 자세한 조사를 수행하는 것입니다.

변경해야 할 기능이 식별되면 프로젝트의 조기 반복에서 이러한 변경에 필요한 작업의 초기 추정치를 공식화합니다. 각 후속 반복에서는 데이터베이스에 대한 보다 포괄적인 검토를 수행하여 모든 변경 사항을 식별하고 필요한 변경 범위에 대한 세부 정의를 공식화해야 합니다. 계획 및 디자인 반복 중에 세부 조사의 결과를 반영하도록 프로젝트 목표와 범위를 조정할 수 있는 피드백 프로세스를 설정합니다. 첫 번째 반복에서는 프로덕션 환경에 액세스할 필요가 없지만 프로덕션 환경의 요소가 정확히 반영되어야 합니다.

Azure SQL 데이터베이스 마이그레이션 마법사를 활용하고 내부 SQL Server와 Azure SQL 데이터베이스 간의 차이를 단계적으로 늘려간다면 이러한 초기 계획 보기를 끌어낼 수 있습니다. 이에 대한 내용은 각 항목에서 자세히 설명합니다. SQL Server Data Tools(SSDT)는 이 단계에서 매우 유용한 도구이며, 특히 데이터 계층의 ALM(응용 프로그램 수명 주기 관리)에 이 도구의 사용이나 데이터베이스 개체의 스크립트가 포함되는 경우에는 더욱 유용합니다. Azure SQL 데이터베이스 마이그레이션 마법사만큼은 아니지만 상당히 쉽게 사용할 수 있으며 그다지 번거롭지 않습니다. 경고를 두 번 클릭하면 문제가 되는 행으로 직접 이동하는 등의 일반적인 Visual Studio의 생산성 기능은 매우 유용합니다.

여러 도구를 사용하여 Transact-SQL 지원과 같은 문제에 대한 평가를 확인할 수 있습니다.

  • Azure SQL 데이터베이스 마이그레이션 마법사를 내부 데이터베이스의 테스트 또는 프로덕션 복사본에 연결하고 Azure SQL 데이터베이스에서 실행하도록 변경해야 하는 개체에 대한 보고서를 생성할 수 있습니다. 자세한 내용은 방법: SQL Azure 마이그레이션 마법사사용를 참조하십시오.

  • DAC(데이터 계층 응용 프로그램)에서 내부 데이터베이스의 모든 개체를 지원하는 경우 DAC 패키지를 추출하고 다음 중 하나를 수행할 수 있습니다.

평가 도구는 Azure SQL 데이터베이스에서 지원하지 않는 기능을 식별하는 데 도움이 될 수 있지만, 동일한 기능을 수행하는 데 사용할 수 있는 대체 기능을 반드시 식별하지는 않습니다. 프로젝트 기획자는 해당 기능의 비즈니스 용도와 이를 지원할 디자인 대안을 이해해야 합니다. 단순히 기능 지원 누락을 이유로 Azure SQL 데이터베이스 사용을 중단하는 대신 대안 개발 및 배포 비용의 평가를 기반으로 진행 결정을 해야 합니다.

비 마이그레이션 목표를 포함하지 마십시오(특히 복잡한 마이그레이션의 경우). 복잡성 추가는 마이그레이션 프로젝트 실패의 일반적인 이유 중 하나입니다. 범위에 속하는 공통 영역은 확장 데이터베이스 모델 활용입니다. 다음과 같이 꼭 필요한 경우에만 복잡성을 추가하십시오.

  • Azure SQL 데이터베이스에서 지원하는 최대 크기보다 더 큰 데이터베이스를 마이그레이션하려는 경우

  • 비즈니스 사례가 착수할 때 다중 테넌시를 구현하는 경우에만 실행 가능한 경우

  • 데이터베이스의 컴퓨팅 요구 사항이 단일 Azure SQL 데이터베이스 데이터베이스에 대한 예상 컴퓨팅 요구 사항을 초과하는 경우

계획 및 디자인에 비용 고려 사항을 포함해야 합니다. 비용 요인은 각 단계 중과 반복마다 평가해야 하며, 진행 여부에 대한 각 의사 결정의 중요 부분입니다. 문제가 되는 이 위험의 확률이 낮을 때는 이 요소를 계획과 디자인에서 제외할 수 있지만 비용 과소 평가의 심각성은 상당히 높을 수 있습니다.

주요 성공 요인은 위험을 식별하고 그러한 위험에 확률과 심각도 등급을 지정하는 것입니다. 사소한 것이라고 빠짐 없이 모든 위험을 나열합니다. 모든 이해 관계자가 확률이 높은 위험에 적절한 등급을 지정했음에 동의해야 합니다. 확률이 높은 위험마다 위험이 문제로 바뀌는 경우 허용 가능한 수준의 계획을 포함하는 완화 계획이 있어야 합니다. 마이그레이션의 모든 단계 중에 발견된 새 위험에 대한 계획을 추가하기 위한 프로세스를 설정합니다. 최종 배포 단계에서 발견 및 확인된 문제를 향후 프로젝트의 위험으로 기록해야 합니다. 또한 보다 친숙한 내부 환경에 적용하는 방식이 아닌 클라우드 환경에 적용할 때의 위험을 평가하는 것이 중요합니다.

변환 비용과 Azure SQL 데이터베이스에서 데이터베이스 실행 시 비용의 추정치와 함께, 데이터베이스에 사용되는 모든 기능을 Azure SQL 데이터베이스에서 지원하는 기능과 비교하며 프로젝트에서 포괄적으로 검토해야 합니다. 비용이 이점보다 높을 경우 프로젝트를 취소할 수 있도록 이 검토는 충분히 이른 시점의 반복에서 발생해야 합니다. 한 Azure SQL 데이터베이스 마이그레이션 프로젝트의 경우에는 프로젝트 기획자가 Azure SQL 데이터베이스에서 지원하지 않는 내부 데이터베이스에 사용되는 데이터 압축에 대해 몰라서 뒤늦게 어려움을 겪기도 했습니다. 이 문제는 Azure SQL 데이터베이스에서 데이터베이스를 실행하는 데 드는 예상 비용을 크게 변경했으며, 프로젝트의 조기 시점에 식별해야 할 문제 유형입니다.

계획 및 디자인 단계의 각 반복에는 데이터 계층에 필요한 변경에 대한 심층적인 평가가 포함되어야 합니다. 예를 들어 두 번째 반복에 기능 테스트 환경의 프로파일러 추적을 만들고 SQLAzureMW를 통해 실행하는 작업을 포함할 수 있습니다. 세 번째 반복에서는 성능 테스트 환경으로 진행할 수 있습니다. 이 환경에서는 성능 모니터링 도구가 마이그레이션할 수 있는 잠재 영역을 식별하기 위한 도구 상자에 포함됩니다.

Azure SQL 데이터베이스에서는 SQL Server 2008 이상의 버전에서 제거된 SQL Server 2000 및 SQL Server 2005 기능을 지원하지 않습니다. 예를 들어 Azure SQL 데이터베이스에서는 조인을 지정하는 *= or =* 구문을 지원하지 않습니다. 따라서 이러한 데이터베이스를 Azure SQL 데이터베이스로 마이그레이션하려면 SQL Server 2000 또는 SQL Server 2005에서 업그레이드하는 경우에 발생하는 동일한 여러 문제를 해결해야 합니다. 성능 모니터 카운터, XEvents 및 SQL Server 업그레이드 관리자와 같은 도구를 사용하여 이러한 종속성을 찾아낼 수 있습니다. 이러한 문제의 연구에 대한 자세한 데이터베이스 엔진 업그레이드를 참조하십시오.

개발은 계획 및 디자인 단계에서 생성된 작업을 수행하는 개별 작업입니다. 개발 작업에 배정된 사람들에게 마이그레이션 프로젝트의 다른 단계의 작업을 배정해서는 안 됩니다.

Azure SQL 데이터베이스로 마이그레이션되는 대부분의 데이터베이스에는 응용 프로그램 계층에 적용되는 변경이 필요합니다. 데이터 형식, 반환되는 열 수, 동적 Transact-SQL 또는 입력 매개 변수 등의 요소가 변경되면 응용 프로그램 코드의 데이터 계층도 바로 수정해야 합니다. 마이그레이션으로 인해 변경되는 데이터베이스 개체가 없더라도 Azure SQL 데이터베이스 아키텍처는 견고한 재시도 논리와 오류 처리와 같은 응용 프로그램 변경 요구 사항을 결정합니다. 즉, 데이터베이스 개발을 응용 프로그램 계층 개발과 통합해야 합니다.

데이터베이스 개발 작업은 SQL Server 데이터베이스를 지원하는 모든 데이터베이스 개발 도구를 사용하여 수행할 수 있습니다. Azure SQL 데이터베이스에 대한 논리를 포함하는 SSDT와 같은 도구를 사용할 경우 데이터베이스 프로젝트 빌드 대상을 Azure SQL 데이터베이스로 설정하여 코드를 작성할 때 SSDT에서 호환되지 않는 구문을 식별할 수 있다는 장점이 있습니다. 자세한 내용은 Microsoft SQL Server Data Tools를 참조하십시오. SSDT가 출시되기 전에는 개발자들이 Azure Emulation Kit를 사용하여 SQL Server Express에 연결했습니다. SSDT는 편의성을 추가하고 오프라인 개발 느낌을 제공하지만, 여전히 내부 기능 집합이므로 Azure SQL 데이터베이스에서 가능한 사항을 잘못 알려줄 수도 있습니다. 보다 생산적이고 효율적인 환경은 가능하면 계획 시점 초기에 문제를 식별하는 것이며, 코딩하는 시점에는 그러한 문제가 코드로 작성되어야 합니다. Azure SQL 데이터베이스에 대한 논리를 포함하는 도구를 사용하여 개발하지 않는 경우 가능한 빨리 Azure SQL 데이터베이스에 대한 개발을 시작할 수 있습니다. SSDT와 같은 오프라인 개발 도구는 동일한 프로젝트에 대해 동시에 작업하는 여러 개발자의 가치 제안을 제공합니다. SSDT에는 Team Foundation Server에 있는 것과 같은 원본 제어 및 빌드 기능도 통합되어 있습니다. 마이그레이션이 응용 프로그램과 데이터베이스 코드 모두에 영향을 주는 경우 데이터베이스 프로젝트를 동일한 빌드 환경에 통합할 수 있습니다. 마이그레이션이 응용 프로그램과 데이터베이스 모두에 영향을 주는 경우 SSDT 프로젝트를 응용 프로그램 프로젝트 빌드 프로세스와 동일한 솔루션에 통합할 수 있습니다. 이러한 특징은 Azure SQL 데이터베이스에 대해 직접 개발할 때의 명백한 연결 문제 외에 누릴 수 있는 이점입니다.

마이그레이션에 데이터 모델 변경이 거의 필요 없는 경우에는 데이터 모델을 SSDT로 가져와서 변경 적용을 시작합니다. 여기서의 가치 제안은 개인 개발 인력이 각각의 중점 영역에 대해 작업하고 빌드 단계에서 이러한 작업을 통합할 수 있다는 점입니다.

각 프로젝트 반복에서 개발 팀은 계획 팀에게 정기적으로 피드백을 제공하고 주기에 따라 사전 대응해야 합니다. 유효성 검사 없이 장기간 코드로 있을 때보다 정기적으로 유효성을 검사하고 나서 실패 후 복구하는 것이 덜 위험한지 확인합니다. 이것은 새로운 패러다임은 아닙니다. 하지만 클라우드 기반 솔루션을 개발할 때 이러한 패러다임을 따르지 못한다면 비용이 많이 들 수 있습니다.

마이그레이션 프로젝트 응용 프로그램 수명 주기의 다른 활동과 마찬가지로, Azure SQL 데이터베이스로 마이그레이션하는 작업인 것과 상관없이 항상 변하지 않는 활동과 목적이 있습니다. Azure SQL 데이터베이스에 중요하지만 기획자와 개발자가 간과하기 쉬운 일반적인 테스트 영역은 다음과 같습니다.

  • 오류 처리

  • 재시도 논리

  • 제한에 대한 응답

  • 변경 내용 배포

  • 확장 패러다임

  • 네트워크 대기 시간 영향

  • 보안

  • Logging

이러한 요소는 기능 및 성능 테스트 사용 사례가 파생될 수 있는 기준을 제공하므로 각별히 유의하십시오. 여러 테스트 도구가 있지만, 그 중에서도 데이터베이스 작업을 분리하는 기능이 있습니다. 기능 테스트는 SQL Server에 나타나지 않는 Azure SQL 데이터베이스 기능을 정확히 찾아내기 위한 개발 도구의 미숙함을 완화하여 생산성을 높입니다. 개발 도구와 빌드 메커니즘에 따라 기능 테스트가 문제를 보고하지 않을 수도 있으며, 보다 오래 걸리고 비용이 많이 드는 성능 테스트 장비에 앞서 단지 추가 보호 수단으로만 사용될 수도 있습니다.

마이그레이션된 솔루션 테스트는 내부 구현에 영향을 거의 미치지 않은 새로운 사용 사례를 제시해야 합니다. 트랜잭션 재시도가 필요한 오류를 강제로 발생시키는 테스트를 만든 후 최대 적중 영향과 최고 부하량의 영향을 테스트합니다. 좋은 클라우드 솔루션은 문제 해결 시간을 줄여줍니다. 이러한 솔루션을 구현하려면 작업을 기록하고 시스템의 현재 상태를 정기적으로 분석하는 응용 프로그램 논리를 개발하면 됩니다. 데이터베이스의 로깅 작업은 비용이 많이 들고 다른 테이블에 쓰는 것으로 제한될 수 있으므로, 데이터베이스 호출을 실행하는 응용 프로그램 코드가 오류, 경고 및 기간을 기록해야 합니다. 예를 들어 고객이 성능이 좋지 않은 일부 서버의 문제를 해결하는 데 몇 시간을 소비했습니다. 이들은 여러 가지 도구를 활용하여 문제가 발생한 후에 문제의 원인을 식별하려고 했습니다. 몇 시간이 지나서 서버가 갑자기 예상했던 대로 작동하기 시작했습니다. 문제는 응용 프로그램과 관련이 없었으며 그보다는 플랫폼 업그레이드가 진행 중이었습니다. 데이터 지점을 기록하도록 응용 프로그램을 더 잘 설계하고 관리자가 솔루션 상태를 정기적으로 분석했다면 문제를 해결하는 데 든 작업량을 크게 줄일 수 있었을 것입니다. 이들은 문제의 근본 원인을 보다 쉽게 식별할 수 있도록 지원 센터 엔지니어에게 더 나은 데이터를 제공할 수 있었을 것입니다. 물론, 향후 이러한 데이터 형식의 용도에는 소비자를 다른 데이터 센터로 리디렉션하는 것도 포함될 수 있습니다.

쉽게 간과할 수 있는 부분 중 하나가 배포 환경입니다. 테스트에는 배포 환경을 포함해야 하며, 테스트를 통해 미래의 변경 사항을 기존 환경에 어떻게 적용할 수 있는지에 대한 통찰력이나 확신을 얻을 수 있어야 합니다. 새 데이터베이스를 배포하고 시드하며 프로덕션용으로 준비하는 일은 기존 프로덕션 환경에 변경 사항을 배포하는 것과는 매우 다릅니다. 이 부분은 내부 고려 사항과 다르지 않지만, 두 가지 이유에서 말씀 드리고자 합니다.

  • 내부에서 작동했던 배포 작업이 클라우드 기반 솔루션에서 작동하지 않을 수 있습니다.

  • 테스트 계획에 이 부분을 포함하기 위해 상당한 작업량이 요구되지만, 즉각적인 반환 결과가 거의 없습니다.

테스트는 반복 모델에도 참여해야 합니다. 반복 모델에서는 문제가 개별 및 계획 팀으로 다시 전달됩니다. 처음에는 테스트가 상당히 기초적이고 내부 테스트 장비와 매우 유사할 수 있습니다. 각 반복과 다른 클라우드 인식 테스트 사례를 통합하십시오. 테스트 사례에서는 위의 복잡성 평가 섹션에 연결된 문서에서 식별된 문제를 다루어야 합니다.

마이그레이션 복잡성은 중단 시간 제약 조건의 결과일 수 있으며, 이 경우 제안된 배포 계획 테스트의 중요도가 더 커집니다.

이 단계는 일반 소프트웨어 개발 수명 주기의 목적과 다르지 않습니다. 마이그레이션 프로젝트의 경우 개발자가 데이터베이스 마이그레이션 버전의 첫 번째 버전을 더 이상 코딩하지 않고 테스트에서 발생된 문제에 대해서만 신경 쓰는 시점에 이르게 됩니다.

안정화와 마찬가지로, 클라우드로 마이그레이션하기 위한 배포 단계는 내부 마이그레이션 프로젝트와 다르지 않습니다. 좋은 테스트는 이 단계의 성공 확률을 높여줍니다.

바람직한 의사 소통은 마이그레이션의 주요 성공 요인입니다. 상태의 소비자에 대해 적당한 세부 수준으로 상태를 정기적으로 업데이트하는 일은 좋은 환경, 아니면 적어도 클라우드로 마이그레이션의 보다 광범위한 비즈니스 목적을 깨달을 수 있는 환경을 만드는 데 중요합니다.

배포 단계의 성공은 이전 단계에서 수행된 작업의 품질에 따라 달라집니다. 부족한 연구, 계획, 개발 및 테스트는 배포 중에 문제 발생의 위험을 크게 높입니다. 때로는 배포 문제가 너무 심각하여 프로젝트를 중단하고 내부 시스템으로 롤백하기도 합니다. 경우에 따라 이러한 문제는 회사 자체의 클라우드 기반 시스템 사용 능력을 의심하게 만들기도 합니다. 일반적으로 좋은 연구, 계획, 개발 및 테스트는 배포가 계획에 따라 실행되는 결과를 가져옵니다. 좋은 계획에는 문제가 발생하더라도 문제의 영향을 줄이는 만일의 대비책이 마련되어 있습니다.

표시:
© 2014 Microsoft