웨이브 계획

기본적으로 웨이브 플랜은 마이그레이션 일정이며 다른 프로젝트 계획 활동과 유사합니다. 마이그레이션 웨이브를 사용하여 관리 가능한 그룹을 생성하고, 위험을 줄이고, 해당 그룹에 대한 활동을 구성하는 것이 좋습니다.

효과적이고 신뢰도가 높은 마이그레이션 웨이브 플랜을 생성하려면 애플리케이션 포트폴리오, 관련 인프라(컴퓨팅, 스토리지, 네트워크), 종속성 매핑 및 마이그레이션 전략을 전체적으로 파악해야 합니다.

소프트웨어 및 인프라 구성 요소 모음을 그룹화하는 형태의 비즈니스 애플리케이션 외에도 다른 그룹 수준을 사용할 수 있습니다. 파도는 가장 높은 그룹 수준입니다. 웨이브 내에서 종속성 그룹을 생성할 수 있습니다. 이 유형의 하위 그룹에는 둘 이상의 애플리케이션이 포함될 수 있습니다. 예를 들어 짧은 지연 시간 또는 기타 요인과 같은 기술적 종속성으로 인해 동시에 마이그레이션해야 하는 두 개 이상의 애플리케이션이 있습니다. 그러면 해당 종속성 그룹이 전체적으로 관리됩니다. 여러 종속성 그룹을 웨이브에 할당할 수 있습니다. 다음으로 전체 웨이브 또는 웨이브 내의 개별 종속성 그룹에 마이그레이션 날짜를 할당할 수 있습니다. 마이그레이션 날짜는 해당 그룹이 현재 위치에서 중지되고 활성화된 날짜와 시간입니다 AWS.

마이그레이션 웨이브에는 여러 활동이 있습니다. 웨이브를 단계별로 구성하고 각 단계의 예상 기간을 설정하는 것이 좋습니다. 아래 단계는 예제 역할을 합니다.

마이그레이션 웨이브에는 사전 정의된 기간이 없으며 작업 및 복잡성 수준에 따라 달라집니다. 마이그레이션 웨이브는 6~10주 이내에 유지하는 것이 좋습니다. 예를 들어 애플리케이션 구성 요소를 완전히 다시 작성하는 경우와 같이 더 많은 시간이 필요한 경우 일반적으로 마이그레이션 웨이브 외부에서 더 잘 처리됩니다.

성공을 측정하고 진행 상황을 추적하려면 파도가 성과 및 비즈니스 동인에 부합해야 합니다. 이는 파도 지속 시간 및 파도에 포함된 종속성 그룹에도 영향을 미칩니다. 웨이브 완료에는 측정 가능한 업적이 반영되어야 합니다.

마이그레이션 웨이브를 구성하는 방법에는 여러 가지가 있습니다. 다음 표에서는 가장 일반적인 웨이브 조직 옵션을 설명합니다. 이들은 일반적으로 결합됩니다.

 애플리케이션 포트폴리오의 기준을 설정하는 단원에서는 네 가지 범주의 기술 종속성을 설명했습니다. 이러한 종속성은 마이그레이션 웨이브 생성과 종속성 그룹의 정의에 기여합니다. 종속성 그룹은 종속성의 중요도에 따라 결정됩니다. 또한 비기술적 종속성을 고려해야 합니다. 예를 들어 애플리케이션 릴리스 일정, 유지 관리 기간 및 주요 비즈니스 날짜(예: 월말 또는 분기말 처리)는 웨이브 플랜에 영향을 미칠 수 있습니다.

종속성이 소프트인지 하드인지 확인합니다. 소프트 종속성은 두 개 이상의 자산 간 또는 자산과 제약 조건 간의 관계이며 구성 요소의 위치에 따라 달라지지 않습니다. 예를 들어, 동일한 로컬 네트워크(또는 동일한 인프라)에서 작동하는 두 시스템은 해당 시스템 중 하나를 클라우드로 이동하여 분할할 수 있으며 다른 하나는 온프레미스에 남아 있습니다. 하드 종속성은 위치에 따라 두 개 이상의 자산 또는 자산과 제약 조건 간의 관계입니다. 예를 들어 동일한 로컬 네트워크에서 작동하고 애플리케이션 서버와 데이터베이스 서버 간의 통신을 위해 짧은 지연 시간에 크게 의존하는 두 시스템은 엄격한 종속성을 갖습니다. 이러한 시스템 중 하나만 클라우드로 이동하면 해결할 수 없는 기능 또는 성능 문제가 발생합니다. 마찬가지로 리소스 가용성(예: 마이그레이션을 수행하는 팀) 또는 운영 제약 조건(예: 지정된 기간에만 두 시스템을 마이그레이션할 수 있는 유지 관리 기간)과 같은 비기술적 이유로 인해 이러한 자산에 대한 엄격한 종속성이 발생할 수 있습니다.

마이그레이션 웨이브 플랜을 생성하려면 특수 검색 도구와 같은 신뢰할 수 있는 데이터 소스에서 종속성을 분석하여 종속성 그룹을 결정합니다. 이 정보를 애플리케이션 우선 순위 기준 및 운영 상황과 결합합니다.

기술적 종속성을 결정하는 것은 어렵습니다. 여러 데이터 포인트가 필요하며 데이터 소스에 모두 포함되어 있지 않습니다. 예를 들어 검색 도구에서 process-to-process 통신 정보를 얻을 수 있지만 소프트 종속성과 하드 종속성으로 분류하기는 어렵습니다. 지연 시간 허용 오차는 네트워크 데이터만으로는 확인하기 어렵습니다.

다음 기법은 실제 종속성을 결정하는 모호성을 처리하는 데 도움이 될 수 있습니다.

AWS Transform은 종속성을 분석하고 웨이브 계획을 수행하는 데 도움이 될 수 있습니다.

웨이브 플랜 생성

애플리케이션 웨이브를 마이그레이션하기 위한 사전 조건은 애플리케이션 포트폴리오 데이터와 웨이브에서 마이그레이션할 애플리케이션 그룹에 대한 자세한 애플리케이션 평가입니다. 세부 평가에는 웨이브의 애플리케이션 목록, 관련 인프라 세부 정보, 대상 설계 및 각 애플리케이션에 대한 마이그레이션 전략이 포함되어야 합니다. 

파도 소유권 및 거버넌스를 설정하는 것은 파도 작업, 프로그램 종속성, 변경 관리, 문제 및 위험을 관리하고 추적하는 데 중요합니다. 계획을 관리하기 위한 거버넌스 프레임워크가 마련되어 있는지 확인합니다.

웨이브 플랜을 간략하게 설명하려면 기본 웨이브 구성으로 시작합니다. 파도 내에서는 어떻게 되나요? 초기 입력이 정의되면 웨이브가 시작될 수 있습니다. 일반적으로 활동은 다음과 같습니다. 

이러한 각 활동의 소요 시간은 범위의 복잡성, 파도 용량, 관련된 사람 및 고유한 상황에 따라 결정됩니다. 가능하면 파도가 작을수록 지연이나 마이그레이션 차단기의 영향을 줄일 수 있기 때문에 더 좋습니다. 팀과 함께 파도의 기본 지속 시간을 결정합니다.

다음으로 날짜를 분석하여 빈 웨이브의 초기 상위 수준 구조를 생성합니다(애플리케이션이 아직 할당되지 않음). 다음 질문을 고려하세요.

이러한 고려 사항을 고려하여 웨이브를 계획에 표시합니다. 마이그레이션 프로세스를 가속화하려면 가능하면 겹치는 웨이브를 사용하는 것이 좋습니다. 겹치는 파도의 핵심은 파도 내에서 발생하는 일을 정의하고 고려하는 것입니다. 일반적으로 배포 활동, 대상 인프라 검증 및 데이터 동기화는 웨이브의 상반기 동안 발생합니다. 하반기는 실제 마이그레이션, 테스트 및 운영 인계에 중점을 둡니다. 즉, 프로세스의 각 절반에 서로 다른 팀이 관여하며 효율성을 어느 정도 높일 수 있습니다. 예를 들어 대상 인프라 준비에 관여한 팀이 작업을 완료하자마자 다음 웨이브의 요구 사항에 대한 작업을 시작할 수 있습니다. 일반적으로 대부분의 웨이브는 마이그레이션에 대한 공장과 유사한 접근 방식을 용이하게 하기 위해 길이와 구조가 비슷한 것이 좋습니다. 그러나 웨이브 계획 프로세스 중에 종속성 또는 운영 요구 사항을 충족하도록 지정된 웨이브의 크기를 확장할 수 있습니다. 

그런 다음 식별된 종속성 그룹을 기반으로 포함할 수 있는 종속성 그룹 수를 기준으로 웨이브의 최대 크기를 결정합니다. 파도 크기는 일반적으로 위험 선호도(예: 병렬 변경을 허용할 수 있는 정도) 및 리소스 가용성(예: 사용 가능한 리소스, 기술 및 예산으로 병렬 변경을 수행할 수 있는 정도)에 따라 결정됩니다. 그러나 초기 계획 중에는 리소스 요구 사항 및 가용성에 의해 제한되지 않습니다. 둘 이상의 종속성 그룹을 포함하는 파도는 향후 반복에서 더 작은 파도로 분해될 수 있습니다.

지정된 웨이브에 대한 종속성 그룹이 확인되면 웨이브 마이그레이션을 위한 리소스 요구 사항을 검토합니다. 리소스 요구 사항에 따라 웨이브 크기(포함된 종속성 그룹 수)를 조정하는 것이 좋습니다. 이로 인해 파도가 작거나 커질 수 있습니다. 모든 웨이브가 정의될 때까지 필요에 따라 웨이브 플랜을 반복합니다. AWS 전문 서비스 또는 AWS 마이그레이션 역량 파트너와 협력하여 프로세스 전반에 걸쳐 전문가를 지원할 수 있습니다.

변경 관리

마이그레이션 프로그램의 수명 주기 동안 애플리케이션 및 관련 인프라 포트폴리오가 변경됩니다. 장기 실행 마이그레이션 프로그램은 정상적인 비즈니스 진화 및 변화와 공존합니다. 애플리케이션은 마이그레이션을 기다리면서 계속 진화합니다. 서버가 추가 또는 제거되고 새 인프라가 온프레미스에 배포됩니다. 웨이브 또는 종속성 그룹의 범위는 변경해야 합니다. 특히 마이그레이션 날짜에 가까워지거나, 이전에 알려지지 않은 종속성이 식별되거나, 인벤토리에 새 서버가 포함된 경우 변경이 필요합니다. 마이그레이션 자체 중에이 문제가 발생할 수 있습니다.

범위 변경은 종속성 그룹 및 웨이브에 영향을 미칩니다. 변경을 처리하고 영향을 최소화하려면 범위 제어 메커니즘을 설정하는 것이 중요합니다. 범위 변경 제어 메커니즘에는 범위에 대한 단일 실제 소스의 정의가 필요합니다. 마이그레이션 프로그램 거버넌스에서 정의한 범위 또는 .csv 파일, 스프레드시트 또는 데이터베이스를 관리하는 도구일 수 있습니다. 조치를 취할 수 있도록 변경 사항을 식별하고, 영향을 분석하고, 관련 이해관계자에게 변경 사항을 전달해야 합니다. 결과적으로 웨이브 플랜이 반복됩니다.