마이그레이션 계획

마이그레이션 계획은 워크로드를 Azure로 마이그레이션하기 위한 특정 순서, 타이밍 및 접근 방식을 정의합니다. 이 계획은 고급 마이그레이션 전략을 실행 가능한 배포 시퀀스로 변환합니다. 워크로드 우선 순위 지정, 마이그레이션 시퀀싱 및 데이터 전송 방법과 같은 전술적 결정을 해결하여 클라우드 채택 계획을 기반으로 합니다.

필수 조건:마이그레이션 채택 계획, Azure 랜딩 존

마이그레이션 준비 상태 및 기술 평가

준비 상태 평가를 통해 팀은 마이그레이션 계획을 실행하는 데 필요한 기술과 지원을 받을 수 있습니다. 이 단계에서는 기능 격차를 식별하고 대상 학습 또는 외부 지원을 통해 진행률을 가속화합니다.

1. 팀의 Azure 기술을 평가합니다. 팀의 Azure 서비스, 마이그레이션 도구 및 절체 전환에 대한 경험을 검토합니다. 이 평가는 특정 지식 격차를 식별하고 팀이 성공하기 위해 필요한 교육을 결정하는 데 도움이 됩니다.

2. 필요한 경우 외부 전문 지식을 활용합니다. 팀이 클라우드 마이그레이션 경험이 부족한 경우 Microsoft 또는 Microsoft 파트너를 가져옵니다. 외부 전문가는 마이그레이션 전략의 유효성을 검사하고, 적절한 도구를 추천하며, 현실적인 타임라인을 설정하는 데 도움을 줄 수 있습니다. 이 지원은 특히 복잡하거나 대규모 프로젝트의 경우 위험을 줄이고 마이그레이션 속도를 향상시킵니다.

데이터 마이그레이션 경로 선택

데이터 마이그레이션 경로는 현재 위치에서 Azure로 데이터를 이동하는 방법입니다. 올바른 경로는 데이터를 안전하고, 빠르고, 비용 효율적으로 전송할 수 있도록 합니다. 먼저 사용 가능한 네트워크 연결( ExpressRoute, VPN 또는 공용 인터넷)을 확인하여 옵션을 이해합니다.

1. ExpressRoute가 있다면 이를 사용하세요. ExpressRoute는 인터넷 연결보다 더 빠르고 안전한 프라이빗 전용 Azure 연결을 제공합니다. ExpressRoute가 이미 있거나 가져올 계획이 있는 경우 모든 워크로드에 이 메서드를 사용합니다. ExpressRoute에는 설정 시간이 필요하며 데이터 전송 비용이 있습니다.

2. ExpressRoute를 사용할 수 없는 경우 VPN을 사용합니다. 보안 데이터 전송이 필요하지만 ExpressRoute가 없는 경우 VPN을 선택합니다. VPN은 인터넷을 통해 Azure로 암호화된 터널을 만들지만 일반적으로 ExpressRoute보다 느립니다. 시작하기 전에 Azure에서 VPN Gateway를 구성했는지 확인합니다.

3. 많은 양의 데이터에 Azure Data Box를 사용합니다. Data Box는 많은 데이터가 있는 오프라인 마이그레이션에 가장 적합합니다. Microsoft는 데이터를 복사할 물리적 디바이스를 배송한 다음 다시 배송합니다. 이 옵션은 네트워크 사용을 방지하지만 배송 시간으로 인해 가장 오래 걸립니다.

4. 덜 중요한 데이터에 공용 인터넷을 사용합니다. 이 옵션은 데이터에 암호화가 필요하지 않고 ExpressRoute 또는 Data Box를 사용할 수 없는 경우에 작동합니다. 이 방법은 어디서나 사용할 수 있지만 보안이 가장 낮으며 다른 인터넷 활동을 느리게 할 수 있습니다.

마이그레이션 시퀀스 확인

마이그레이션 시퀀싱은 위험을 줄이고 워크로드 마이그레이션에 대한 논리적 순서를 설정하여 팀의 신뢰를 구축합니다. 시퀀스는 먼저 이동하는 워크로드와 종속 구성 요소가 함께 마이그레이션되어 서비스 중단을 방지하는 방법을 결정합니다. 대규모 포트폴리오를 마이그레이션 웨이브로 구성합니다. 웨이브 계획에 대한 자세한 지침은 마이그레이션 웨이브 계획을 참조하세요.

종속성 찾기

1. 먼저 모든 종속성을 검색합니다. 워크로드 간의 종속성으로 인해 함께 마이그레이션되지 않으면 서비스 중단이 발생합니다. 마이그레이션 그룹을 만들기 전에 내부 및 외부 종속성을 매핑하여 이러한 연결을 검색합니다.

2. 종속성 유형 및 중요도를 분석합니다. 종속성 유형에 따라 마이그레이션 방법이 다릅니다. 다음 범주를 구분합니다.

   종속성 유형	Description	마이그레이션 접근 방식
   직접 종속성	구성 요소 간의 즉각적인 통신 및 짧은 대기 시간이 필요합니다.	성능을 유지하고 중단을 방지하기 위해 직접 연결된 모든 구성 요소를 함께 이동합니다.
   간접 종속성	시스템 간의 간헐적 또는 중요하지 않은 상호 작용을 포함합니다.	연결이 대기 시간을 허용하거나 하이브리드 사용을 지원하는 경우 함께 또는 별도의 웨이브로 마이그레이션합니다.
   비즈니스 종속성	조직 또는 관리 관계에 따라 달라집니다.	관련 워크로드 및 보고 시스템을 그룹화하고 마이그레이션하여 비즈니스 우선 순위에 맞춥니다.

3. 종속성 관계별로 워크로드를 그룹화합니다. 공유 데이터베이스, API, 인증 서비스 또는 네트워크 연결을 기반으로 그룹을 만듭니다. 이러한 그룹은 마이그레이션 웨이브의 기초를 형성하고 기능에 필요한 모든 구성 요소가 함께 이동되도록 합니다. 종속성 중요도에 대한 불확실성이 있는 경우 구성 요소를 함께 그룹화합니다. 이 보수적인 접근 방식은 향후 분리를 위한 유연성을 제공합니다.

4. 각 종속성 그룹을 체계적으로 문서화합니다. 일관된 명명 규칙을 사용하여 종속성 그룹을 기반으로 자산에 태그를 지정합니다. 다음을 사용하여 각 그룹을 문서화합니다.

   • 그룹 이름 및 ID - 고유 식별자 및 설명이 포함된 이름
   • 구성 요소 인벤토리 - 모든 인프라 요소, 애플리케이션 및 서비스
   • 중요 종속성 - 특별한 처리가 필요한 필수 연결
   • 마이그레이션 제약 조건 - 비즈니스, 기술 또는 타이밍 요구 사항

5. 그룹 완성도의 유효성을 검사합니다. 부하 분산 장치, DNS 레코드 또는 캐싱 계층과 같은 인프라를 지원하는 것을 포함하여 애플리케이션이 작동하는 데 필요한 모든 구성 요소가 각 그룹에 포함되도록 합니다.

분리된 환경 작업을 처리하기

1. 이동 불가능한 종속성을 계획합니다. 기술 또는 규정상의 이유로 원본 환경에 유지되어야 하는 구성 요소를 식별합니다. 이동할 수 없는 이유, 다른 시스템에 연결하는 방법 및 공유하는 데이터를 문서화합니다. 이 설명서는 이러한 구성 요소가 클라우드 시스템에서 원활하게 작동하기 위한 전략을 만드는 데 도움이 됩니다.

2. 분할 환경 작업 시간을 최소화합니다. 구성 요소가 나중에 클라우드로 이동할 수 있지만 즉시 이동할 수 없는 경우 클라우드 시스템과의 연결 및 데이터 흐름을 문서화합니다. 일정 및 위험 관리 접근 방식을 사용하여 명확한 계획을 만들어 두 환경에서 워크로드가 작동하는 시간을 줄입니다. 더 많은 구성 요소가 함께 이동할 수 있는 경우 마이그레이션을 지연하는 것이 좋습니다.

3. 환경을 효과적으로 연결합니다. API 게이트웨이, 메시지 큐 및 데이터 동기화와 같은 통합 방법을 사용하여 클라우드 워크로드와 원본 환경 구성 요소 간에 안정적인 연결을 만듭니다. 이러한 접근 방식은 지연을 줄이고, 보안을 개선하며, 최종적으로 나머지 구성 요소를 클라우드로 이동할 수 있는 방법을 준비합니다.

마이그레이션할 워크로드 우선 순위 지정

1. 워크로드 세부 정보를 검토합니다. 관련자와 협력하여 각 워크로드에 대한 비즈니스 및 기술 세부 정보를 검토합니다. 가동 중지 시간 또는 실패 영향을 잘 이해하고 현재 비즈니스 우선 순위에 맞게 조정해야 합니다. 마이그레이션 채택 계획을 사용하여 사업부, 워크로드 소유자, 기술 종속성 및 중요도 분류와 같은 세부 정보를 확인합니다. 이러한 세부 정보는 워크로드의 우선 순위를 지정하고 효율적으로 시퀀스하는 데 도움이 됩니다.

   Priority	비즈니스 가치	Effort	Description
   High	High	Low	빠른 승리 - 즉각적인 영향을 위해 먼저 마이그레이션
   Medium-High	High	High	전략적 투자 - 적절한 리소스로 신중하게 계획
   Medium-Low	Low	Low	쉬운 후보 - 주요 마이그레이션 간의 간격 채우기
   Low	Low	High	피하거나 연기 - 더 높은 가치의 기회에 리소스 집중

2. 위험을 줄이기 위해 더 간단한 워크로드로 시작합니다. 덜 복잡하고 위험이 낮은 워크로드 마이그레이션을 시작합니다. 이 접근 방식은 팀이 더 어려운 워크로드를 해결하기 전에 자신감을 얻고 마이그레이션 프로세스를 구체화하는 데 도움이 됩니다. 독립 실행형 아키텍처 및 최소 통합 지점을 사용하여 내부 도구, 개발 환경 또는 사용량이 적은 애플리케이션을 대상으로 합니다.

3. 프로덕션 전에 비프로덕션 환경을 이동합니다. 비프로덕션 환경은 전체 마이그레이션 프로세스를 테스트할 수 있는 안전한 공간을 제공합니다. 프로덕션 전에 개발, 스테이징 및 QA 환경을 마이그레이션하여 준비 상태의 유효성을 검사합니다. 이 순서를 통해 팀은 사용자에게 영향을 주지 않고 구성, 성능 및 복구 절차를 테스트할 수 있습니다. 비프로덕션 마이그레이션을 사용하여 운영 팀을 학습시킵니다.

4. 초기 성공을 입증한 후 중요한 시스템의 일정을 잡으십시오. 중요한 애플리케이션은 Azure로 이동하기 전에 검증된 마이그레이션 기능이 필요합니다. 팀이 Azure 서비스와의 역량을 보여 줄 때 이후 웨이브에 대해 이러한 마이그레이션을 계획합니다. 하드웨어 새로 고침 주기와 같은 비즈니스 최종 기한을 사용하려면 더 많은 안전 장치와 확장된 테스트 기간을 사용하여 중요한 애플리케이션의 우선 순위를 더 일찍 지정해야 할 수 있습니다.

5. 대표적인 복잡한 워크로드를 포함하여 시나리오를 테스트합니다. 각 초기 웨이브에 하나 또는 두 개의 복잡한 워크로드를 추가하여 중요 업무용 애플리케이션에서 직면한 문제를 노출합니다. 다중 계층 애플리케이션 또는 데이터베이스 종속 시스템과 같은 일반적인 패턴을 나타내는 워크로드를 선택합니다.

자세한 마이그레이션 일정 만들기

1. 각 마이그레이션에 대한 시작 및 종료 날짜를 설정합니다. 원활한 실행을 보장하기 위해 테스트 및 문제 해결을 위한 버퍼 시간을 포함합니다. 이 자세한 일정은 지연 위험을 줄이고 효과적인 리소스 계획을 지원합니다.

2. 비즈니스 이벤트에 타임라인을 맞춥니다. 재무 종료, 제품 출시 또는 휴일과 같은 중요한 비즈니스 기간 동안 마이그레이션을 예약하지 마세요. 이 조정은 비즈니스 중단의 위험을 줄이고 이해 관계자의 신뢰를 보장합니다.

3. 프로젝트 관리 도구를 사용하여 진행 상황을 추적합니다. Azure DevOps와 같은 도구를 사용하여 종속성을 관리하고, 마일스톤을 추적하고, 변경 내용을 효과적으로 전달합니다. 이러한 도구는 마이그레이션 진행 상황을 파악하고 사전 문제 해결을 지원합니다.

각 워크로드에 대한 마이그레이션 방법 선택

마이그레이션 방법은 가동 중지 시간이 있는 마이그레이션과 가동 중지 시간이 거의 없는 마이그레이션이라는 두 가지 범주로 구분됩니다. 가동 중지 시간 허용 시간 및 비즈니스 중요도에 따라 각 워크로드에 가장 적합한 마이그레이션 방법을 선택합니다.

1. 계획된 중단을 허용할 워크로드에 대한 가동 중지 시간 마이그레이션을 선택합니다. 가동 중지 시간 마이그레이션은 원본 환경과 대상 환경 간의 실시간 동기화가 필요하지 않으므로 더 간단하고 빠릅니다. 이 방법은 예약된 유지 관리 기간이 있는 개발 환경, 테스트 시스템 또는 애플리케이션과 같은 비임계 워크로드에 적합합니다. 각 워크로드에 허용되는 가동 중지 시간을 문서화하고 사용량이 적은 기간 동안 마이그레이션을 예약하여 비즈니스 효과를 최소화합니다.

2. 중요한 워크로드에 대해 거의 0에 가까운 가동 중지 시간 마이그레이션을 선택합니다. 가동 중지 시간이 거의 0에 가까운 마이그레이션은 연속 데이터 복제 및 단독형 기술을 통해 전환 중에 중요한 워크로드가 계속 작동하도록 합니다. 이 방법은 엄격한 서비스 수준 계약이 있는 고객 관련 애플리케이션, 실시간 트랜잭션 시스템 또는 워크로드에 필수적입니다. 워크로드 아키텍처가 연속 복제를 지원하고 네트워크 대역폭이 실시간 데이터 전송을 처리할 수 있는지 확인합니다. 비프로덕션 환경에서 연결 및 복제 프로세스를 테스트하여 이 마이그레이션 방법에 대한 준비 상태를 확인합니다.

롤백 계획 정의

롤백 계획을 사용하면 배포가 실패하거나 위험이 발생할 때 팀이 변경 내용을 신속하게 되돌릴 수 있습니다. 잘 정의된 계획은 가동 중지 시간을 최소화하고, 비즈니스 영향을 제한하며, 시스템 안정성을 유지합니다. 마이그레이션 또는 배포를 시작하기 전에 항상 롤백 조건 및 절차를 설정합니다.

1. 실패한 배포를 정의합니다. 비즈니스 관련자, 워크로드 소유자 및 운영 팀과 협력하여 실패한 배포로 간주되는 사항을 결정합니다. 예를 들어 실패한 상태 검사, 성능 저하, 보안 문제 또는 충족되지 않은 성공 메트릭이 있습니다. 이 정의는 롤백 결정이 조직의 위험 허용 오차와 일치하도록 보장합니다. CPU 사용량 제한, 응답 시간 임계값 또는 오류 속도와 같은 배포 계획에서 롤백을 트리거하는 특정 조건을 포함합니다. 이 평가는 인시던트 중에 롤백 결정을 명확하고 일관되게 만듭니다.

2. CI/CD 파이프라인에서 롤백 단계를 자동화합니다. Azure Pipelines 또는 GitHub Actions와 같은 도구를 사용하여 롤백 프로세스를 자동화합니다. 예를 들어 상태 검사가 실패하는 경우 이전 버전을 다시 배포하도록 파이프라인을 구성합니다.

3. 워크로드별 롤백 지침을 만듭니다. 워크로드 유형, 환경 및 배포 방법과 일치하는 롤백 단계를 개발합니다. 예를 들어 코드 기반 인프라 배포에는 이전 템플릿을 다시 적용해야 합니다. 애플리케이션 롤백에는 이전 컨테이너 이미지를 다시 배포하는 작업이 포함됩니다. 롤백 스크립트, 구성 스냅샷 및 코드로서의 인프라 템플릿을 롤백 계획에 연결합니다. 이러한 자산은 신속한 실행을 가능하게 하고 수동 개입에 대한 의존도를 줄입니다.

4. 테스트 롤백 절차. 사전 프로덕션 환경에서 배포 실패를 시뮬레이션하여 롤백 효율성의 유효성을 검사합니다. 자동화, 권한 또는 종속성에서의 격차를 식별하고 해결합니다. 롤백이 시스템을 안정적이고 정상 상태로 복원하는지 확인합니다.

5. 롤백 전략 개선 각 배포 또는 롤백 이벤트 후에는 회고전을 수행하여 무엇이 작동하고 무엇이 작동하지 않았는지 평가합니다. 학습된 교훈, 아키텍처 변경 또는 새 도구에 따라 롤백 조건, 프로시저 및 자동화를 업데이트합니다. 롤백 전략이 최신 상태이고 효과적으로 유지되도록 설명서를 유지합니다.

마이그레이션 계획에 관련자 참여

관련자 승인은 마이그레이션 계획이 비즈니스 요구 사항 및 위험 허용 범위를 충족하는지 확인합니다. 마이그레이션을 실행하기 전에 공식적인 승인을 확보해야 합니다.

1. 비즈니스 근거를 사용하여 마이그레이션 계획을 문서화합니다. 워크로드 이름, 소유자, 중요도, 마이그레이션 방법, 가동 중지 시간 및 비즈니스 효과를 보여 주는 구조화된 계획을 만듭니다. 각 접근 방식에 대한 근거를 포함하고 위험을 최소화하는 방법을 설명합니다.

2. 테스트된 롤백 프로시저를 제공합니다. 단계, 기간 및 성공 조건을 사용하여 특정 롤백 계획을 표시합니다. 자동화된 수동 기능을 포함합니다. 사전 프로덕션 테스트 결과를 문서화하여 빠른 서비스 복원을 증명합니다.

3. 비즈니스 제약 조건에 대한 일정의 유효성을 검사합니다. 중요한 비즈니스 기간, 유지 관리 동결 및 계절적 피크를 방지하기 위해 관련자와의 일정을 검토합니다. 충돌이 있는 경우 대체 옵션의 장단점을 제공합니다.

4. 공식 승인 및 롤백 권한을 얻습니다. 마이그레이션 계획 및 롤백 절차에 대한 관련자의 서면 승인을 보호합니다. 의사 결정 권한을 정의하고 긴급 통신 채널을 설정합니다.

5. 성공 조건을 정의하고 검사점을 검토합니다. 성능 벤치마크, 기능 유효성 검사 및 사용자 동의 조건을 포함하여 측정 가능한 메트릭을 설정합니다. 공식적인 고/노고 결정 검토 지점을 예약합니다.

다음 단계