마이그레이션 전 자산 수정
마이그레이션 평가 프로세스 동안 팀은 자산이 선택한 클라우드 공급자와 호환되지 않도록 하는 구성을 식별합니다. 수정은 비호환성을 해결하는 데 사용할 수 있는 마이그레이션 프로세스의 검사포인트입니다.
이 문서에서는 몇 가지 일반적인 수정 작업을 설명하고 수정이 현명한 투자인지 여부를 결정하는 데 도움이 됩니다.
수정 형식
배포 전체에서 계획해야 하는 두 가지 기본 유형의 수정 작업이 있습니다.
- 평가 활동의 결과에 따라
- 복제본(replica) 및 배포를 허용하기 위해 완료해야 하는 수정 작업입니다.
- 평가 단계 중에 워크로드 평가에서 이러한 수정 활동을 결정했습니다. 클라우드에서 워크로드를 올바르게 복제본(replica) 스테이징할 수 있도록 이러한 작업을 수행해야 합니다.
- 이는 주로 마이그레이션되는 원본 서버에 초점을 맞췄습니다.
- 테스트 작업의 결과에 따라
- 이는 마이그레이션 활동을 테스트하고 비즈니스 테스트를 수행하는 데서 비롯됩니다.
- 이러한 수정 작업은 복제본(replica)ted 대상 서버 및 부하 분산 장치, 가상 네트워크 및 스토리지 계정과 같은 모든 지원 서비스의 구성에 중점을 줍니다.
- 이러한 작업은 더 반복적일 수 있습니다. 모든 테스트 사례가 통과될 때까지 여러 주기를 통해 테스트 및 수정합니다.
수정 활동 추적
반복을 통해 평가 또는 테스트를 통해 워크로드에 대한 수정 작업을 식별할 수 있습니다. 이러한 작업을 프로젝트 활동으로 추적하여 작업이 완료되었는지 확인해야 합니다.
작은 마이그레이션 웨이브는 스프레드시트를 사용하여 항목을 추적할 수 있지만 많은 수정 작업이 있는 큰 웨이브는 여러 항목을 생성합니다. Azure DevOps와 같은 도구를 사용하여 작업 항목을 만들고 우선 순위를 지정하고 특정 단계를 진행하여 규모를 확장할 수 있습니다. 다른 작업에 Azure DevOps를 사용하지 않더라도 이를 사용하여 수정 문제를 심사하고 마이그레이션 프로세스에 대한 작업을 구성할 수 있습니다.
이러한 작업을 만들 때 영향을 주는 워크로드에 다시 연결해야 합니다. 이를 통해 수정 작업으로 인해 지연될 수 있는 워크로드를 평가할 수 있습니다. 그런 다음 워크로드 우선 순위에 따라 작업의 우선 순위를 지정할 수 있습니다.
일부 문제는 여러 워크로드에 영향을 줄 수 있습니다. 일반적으로 호스트, 광범위한 구성 또는 랜딩 존 전체의 문제가 있는 항목입니다. 이러한 문제는 수정을 위해 우선 순위가 지정된 첫 번째 문제여야 합니다.
일반적인 수정 작업
기술 부채는 회사 환경의 정상적이고 예상되는 부분입니다. 온-프레미스 환경에 적합한 아키텍처 결정이 클라우드 플랫폼에서는 적합하지 않을 수 있습니다. 두 경우 모두 자산의 마이그레이션을 준비하기 위해 일반적인 수정 작업이 필요할 수 있습니다. 다음은 몇 가지 예입니다.
- 부 호스트 업그레이드: 복제본(replica) 전에 오래된 호스트를 업그레이드해야 하는 경우도 있습니다.
- 부 게스트 운영 체제 업그레이드: 복제본(replica) 전에 운영 체제를 패치하거나 업그레이드해야 할 수 있습니다.
- SLA(서비스 수준 계약) 수정: 클라우드 플랫폼에서 백업 및 복구 프로세스가 크게 변경됩니다. 마이그레이션된 자산에 대한 백업 프로세스를 수정하여 클라우드에서 필요한 SLA를 계속 달성하도록 해야 할 수 있습니다.
- 애플리케이션 구성 변경: 마이그레이션된 애플리케이션은 종속 자산에 대한 네트워크 경로, 서비스 계정 변경 또는 종속 IP 주소 업데이트와 같은 변수를 조정해야 할 수 있습니다.
- 네트워크 경로의 사소한 변경: 사용자 트래픽을 새 자산으로 올바르게 라우팅하려면 라우팅 패턴을 수정해야 합니다. 이는 새 자산에 대한 프로덕션 라우팅이 아니라 일반적으로 자산에 대한 적절한 라우팅을 허용하는 구성입니다.
대규모 수정 작업
데이터 센터가 제대로 기본, 패치 및 업데이트될 때 수정할 필요가 거의 없습니다. 수정이 풍부한 환경은 대기업 내에서 공통적인 경향이 있습니다. 여기에는 대규모 IT 다운사이징, 레거시 관리 서비스 및 취득이 풍부한 환경의 조직이 포함될 수 있습니다. 이러한 각 환경에서 수정은 마이그레이션 작업의 상당 부분을 구성합니다. 다음 수정 작업은 마이그레이션 속도 또는 일관성에 자주 발생하거나 부정적인 영향을 줄 수 있습니다. 이 경우 수정을 병렬 작업으로 분리하고 클라우드 채택 및 클라우드 거버넌스와 유사한 팀을 구성합니다.
- 빈번한 호스트 업그레이드: 워크로드의 마이그레이션을 완료하기 위해 여러 호스트를 업그레이드하면 마이그레이션 팀이 지연됩니다. 영향을 받는 애플리케이션을 격리하고 계획된 릴리스에 영향을 받는 애플리케이션을 포함하기 전에 수정 단계를 처리합니다.
- 빈번한 게스트 운영 체제 업그레이드: 대기업에는 일반적으로 오래된 버전의 Linux 또는 Windows에서 실행되는 서버가 있습니다. 오래된 운영 체제 운영의 보안 위험 외에도 영향을 받는 워크로드의 마이그레이션을 방지하는 비호환성 문제도 있습니다. 여러 VM(가상 머신)에 운영 체제 수정이 필요한 경우 이러한 작업을 병렬 반복으로 분리해 보세요. 일부 업그레이드는 마이그레이션 프로세스의 일부로 마이그레이션 도구에서 완료할 수 있습니다(예: Azure Migrate 및 현대화의 Windows Server 업그레이드 기능).
대규모 수정 해결
더 작은 워크로드에 대한 수정은 간단할 수 있으므로 초기 마이그레이션 웨이브에 대해 더 작은 워크로드를 선택합니다. 마이그레이션 작업이 무르익으면서 더 큰 워크로드를 처리하기 시작하면 수정에 시간이 많이 걸리고 비용이 많이 들 수 있습니다. 예를 들어 VM이 5,000개 이상인 자산 풀과 관련된 Windows Server 2003 마이그레이션에 대한 수정 작업은 마이그레이션을 몇 개월 지연할 수 있습니다. 이러한 대규모 수정이 필요한 경우 영향을 받는 워크로드를 마이그레이션하기 위한 계획을 변경해야 할 수 있습니다. 이러한 경우 수정 작업의 가치를 최대화하는 현대화 작업이 더 효율적이고 생산적일 수 있습니다.
다음 질문을 사용하여 의사 결정을 안내할 수 있습니다.
- 수정의 영향을 받는 모든 워크로드가 마이그레이션 백로그에서 식별되고 알림이 표시되었나요?
- 영향을 받지 않는 워크로드의 경우 마이그레이션에서 ROI(투자 수익률)가 비슷한가요?
- 영향을 받는 자산을 원래 마이그레이션 타임라인 맞게 수정할 수 있나요? 타임라인 변경 내용이 ROI에 어떤 영향을 미치나요?
- 마이그레이션 노력과 동시에 자산을 수정하는 것이 경제적으로 실현 가능한가요?
이전 질문에 대한 답변이 없는 경우 다음 현대화 방법을 고려하세요.
- 컨테이너화: 일부 자산은 수정 없이 컨테이너화된 환경에서 호스트될 수 있습니다. 이렇게 하면 성능이 저하될 수 있으며 보안 또는 규정 준수 문제가 해결되지 않습니다.
- 자동화: 워크로드 및 수정 요구 사항에 따라 DevOps 접근 방식을 사용하여 새 자산에 배포를 스크립팅하면 더 수익성이 높아질 수 있습니다.
- 다시 빌드: 수정 비용과 비즈니스 가치가 동일하게 높은 경우 워크로드는 다시 빌드 또는 다시 설계에 적합합니다.