마이그레이션 프로세스
마이그레이션은 고도로 반복적인 프로세스입니다. 현재 로컬 데이터 센터에 이진 자산(가상 머신, 애플리케이션 및 데이터)의 컬렉션이 있습니다. 내일은 이러한 이진 자산을 클라우드로 복제하고 동일한 자산의 새 복사본을 사용하도록 프로덕션 트래픽을 옮기려 합니다.
대부분의 반복 가능한 프로세스와 마찬가지로, 작업 대부분을 자동화하여 사람의 반복적인 작업을 줄일 수 있습니다. 그러나 대부분의 마이그레이션 팀이 빠르게 발견함에 따라 반복 가능한 프로세스가 쉬운 부분입니다. 이 프로세스 안에는 의사 결정과 사용자의 개입이 필요한 변경 관리 작업이 숨겨져 있습니다.
다음과 같은 마이그레이션 분야는 Azure Migrate 도구와 클라우드 채택 프레임워크를 함께 사용하여 필요한 사용자 개입을 반복 가능한 프로세스에 통합하는 방법을 간략하게 설명합니다.
대량 마이그레이션 대 반복적인 마이그레이션
클라우드로 이동하는 이진 자산은 이론적으로 하나의 대량 일괄 처리로 마이그레이션할 수 있습니다. 일부 조직은 Azure Migrate를 사용하여 모든 자산의 대량 마이그레이션에 성공했습니다. 이렇게 하려면 계획적인 분석과 수정을 통해 모든 자산이 클라우드와 호환되도록 해야 합니다. 또한 이러한 자산에서 실행되는 워크로드마다 성능을 테스트하고 보증하기 위한 자세한 계획도 필요합니다.
계획의 정도와 비즈니스 사용자에게 미치는 영향 때문에 대량 마이그레이션 접근 방식에 관심을 보이는 조직은 거의 없습니다. 대안적 방식은 스크럼과 같은 Agile 방법론의 원칙을 적용하여 대량 마이그레이션을 여러 개의 웨이브로 나누고 일정한 주기로 더 작은 워크로드 컬렉션을 마이그레이션하는 것입니다.
반복적 마이그레이션 방식을 사용하면 비즈니스가 소화해야 하는 변화의 단위가 작아지고 업무 중단이 적게 발생합니다. 또한 팀이 측정을 통해 각 반복에서 배울 수 있습니다. 팀은 반복 간에 점진적으로 속도와 전문성을 얻을 수 있습니다.
이 모듈의 나머지 부분에서는 Tailwind Traders가 반복적 마이그레이션 방식을 따른다고 가정해도 좋습니다.
분야
모든 반복 마이그레이션 프로세스에서 팀은 각 워크로드를 Azure로 성공적으로 마이그레이션하기 위한 세 가지 작업 또는 분야 집합을 완료합니다.
워크로드 평가: 각 웨이브의 워크로드를 평가하는 동안 설계자는 주로 자산 간의 클라우드 호환성 및 종속성을 찾습니다. 또한 현대화 및 최적화 기회와의 호환성도 찾습니다. 때때로 Azure Well-Architected Review를 사용하여 고급 최적화 작업을 수행하기 위해 개별 워크로드의 아키텍처에 근접합니다.
워크로드 배포: 워크로드의 마이그레이션 또는 배포 중에 팀은 마이그레이션 도구를 사용하여 클라우드에 대한 자산(가상 머신, 애플리케이션 및 데이터)의 복제본(replica)tion을 완료합니다. 이 단계에서 팀은 기본 반복 가능한 프로세스를 지시하고 감독하여 선택한 워크로드에 대한 자산의 정확한 복제본(replica)를 보장합니다.
워크로드 릴리스: 각 기술 플랫폼과 워크로드가 클라우드로 마이그레이션되면 팀은 새로 마이그레이션된 워크로드로의 프로덕션 트래픽을 테스트, 최적화, 릴리스해야 합니다. 테스트하려면 새로 배포된 워크로드 네트워크 경로의 사용자 라우팅 및 최적화 평가가 필요할 수도 있습니다.
마이그레이션 계획의 워크로드마다 이러한 세 가지 분야를 반복하면 성공적인 클라우드 마이그레이션이 보장됩니다.
스프린트 계획
마이그레이션 작업을 계획할 때 첫 번째 단계 중 하나는 더 작은 그룹으로 마이그레이션할 워크로드 목록을 분류하는 것입니다.
팀의 속도(스프린트에서 이동할 수 있는 워크로드 수)에 대해 알아보면 Power of 10 접근 방식부터 시작하는 것이 좋습니다. 이 방식에서는 각 웨이브에서 10개 공통 워크로드로 이루어진 그룹을 일관되게 정의합니다. 그런 다음, Azure DevOps에서 클라우드 채택 플랜을 사용하여 10개 워크로드로 이루어진 그룹을 2주 반복 또는 스프린트에 매핑합니다. 단계별 지침은 플랜 모듈을 참조하세요.
각 스프린트 전에 마이그레이션 팀은 마이그레이션할 다음 워크로드 웨이브를 평가해야 합니다. 이 평가의 목표는 팀이 현재 스프린트에서 성공하는 데 필요한 모든 정보와 액세스 권한을 가지고 있는지 확인하는 것입니다. 또한 이전 스프린트에서 학습한 내용을 기반으로 다음 10개의 워크로드를 조정할 기회도 제공합니다. 팀이 스프린트에 커밋되면 실제 작업을 시작할 수 있습니다.
팀 조직
팀 구조에 기본 구성 원칙을 적용하여 사용 가능한 속도에 따라 각 스프린트의 출력을 최대화할 수 있습니다. 팀 조직의 가장 일반적인 두 가지 형태는 다음과 같습니다.
자체 구성 팀: 이러한 유형의 조직은 민첩한 방법론에 부합합니다. 자기 조직화 팀에서는 마이그레이션 팀의 구성원이 각 분야를 집단적으로 수행할 수 있습니다. 각 스프린트에서 팀은 웨이브의 각 워크로드에서 각 분야와 관련된 작업을 수행하는 사람을 식별합니다.
이 조직에서 목표는 현재 스프린트의 각 워크로드마다 세 가지 분야를 모두 완료하는 것입니다.
마이그레이션 팩터리: 마이그레이션 분야의 반복적인 특성은 고도로 전문화된 팀들의 분업에 적합합니다. 이 접근 방식에서는 한 팀이 각 마이그레이션 분야에 전념합니다. 평가 팀은 항상 마이그레이션 팀보다 1~2개 웨이브 앞선 상태를 유지합니다. 릴리스 팀은 항상 마이그레이션 팀보다 1~2개 스프린트 늦습니다.
이 방식은 수천 개의 자산과 수백 개의 워크로드를 포함하는 대규모 마이그레이션 작업에서 효과적일 수 있습니다.
공통 방해 요인
기술이 마이그레이션 프로세스에 방해가 되는 경우는 거의 없습니다. 마이그레이션 방해 요인 대부분은 마이그레이션 프로세스에 대한 업스트림 또는 다운스트림 종속성에서 누락된 단계에서 비롯됩니다. 방해 요인을 흔한 순서로 나열하면 다음과 같습니다.
전략 및 계획: 성공적인 마이그레이션의 가장 일반적인 방해 요인은 전략 또는 계획 도중 누락된 단계에서 발생합니다. 경영진, 프로젝트 관리자, 기술 담당자와 함께 올바른 기대 수준을 설정하지 않으면 모든 기술 분야가 계획대로 실행되는 경우에도 방해 요인이 생길 수 있습니다.
대규모 마이그레이션 작업을 시작하려면 먼저 클라우드 채택 전략과 클라우드 채택 계획을 세우고 관련자들에게 검토까지 받았는지 확인해야 합니다.
환경: 그다음으로 일반적인 마이그레이션 성공 방해 요인은 잘못 구성된 환경입니다. 특히 마이그레이션을 수행하려면 적절한 연결 및 액세스 요구 사항을 위해 최소한의 네트워킹 및 ID 구성이 필요합니다.
대부분의 마이그레이션 작업의 경우 마이그레이션 프로세스 전에 거버넌스 및 운영 고려 사항을 조기에 해결해야 합니다. 적절한 환경 구성을 위해서는 환경 준비에 대한 클라우드 채택 프레임워크 학습 모듈을 참조하세요.
거버넌스: 대부분의 조직에는 기본적 환경 구성 이상의 비용, 보안, 일관성, ID 관리 요구 사항이 있습니다. 대부분의 조직에서 프로덕션 트래픽을 클라우드로 마이그레이션하려고 할 때까지 이러한 요구 사항을 이해하지 못합니다.
모든 마이그레이션 팀은 대규모 마이그레이션 작업을 시작하기 전에 클라우드 채택 프레임워크의 거버넌스 방법론에 관한 Learn 모듈을 검토하는 것이 좋습니다. 이 정보를 검토하면 예상치 못하게 런타임에 바인딩되는 상황을 방지할 수 있습니다.
운영: 마찬가지로 대부분의 조직에서는 현재 데이터 센터의 프로덕션 워크로드에 대한 운영 요구 사항이 설정되어 있습니다. 프로덕션 트래픽이 클라우드로 이동할 때 이러한 운영 요건이 효과가 있다고 가정하는 경우가 많습니다. 마이그레이션 팀이 원하는 규모의 마이그레이션 작업을 시작하기 전에 클라우드의 운영 관리에 대한 기본 기대 사항을 이해하기 위해 명확한 전략 개발에 관한 Learn 모듈을 검토해야 합니다.
기술: 경우에 따라 합리화 전략의 수정, 현대화, 요구 사항의 증가로 인해 워크로드가 막힐 수 있습니다. 개별 워크로드가 차단되는 경우 문제가 되는 워크로드를 표준 흐름에서 제거하는 기술 스파이크(technical spike)로 해결할 수 있습니다.
일반적으로 병렬 스프린트에서 발생하는 기술적 스파이크는 별도의 팀에서 해결합니다. 마이그레이션 팀은 수정 및 현대화와 관련된 많은 기술적 문제를 해결할 수 있습니다. 이러한 문제들은 이 모듈 끝에서 클라우드 채택 프레임워크 마이그레이션 시나리오를 설명하면서 다루겠습니다.
애플리케이션 아키텍처에 영향을 주는 포괄적인 변경이 워크로드에 필요한 경우 워크로드 팀은 Well-Architected Framework Learn 모듈을 검토하여 추가 지침을 얻어야 합니다.