마이그레이션 웨이브 계획

이 문서에서는 마이그레이션 웨이브를 계획하는 방법을 설명합니다.

이전 후보를 이전 웨이브로 그룹화할 수 있습니다. 탐색 및 평가 단계에서 수집한 정보를 기반으로 상위 수준(카테고리 기반) 또는 세부 수준(애플리케이션, 위치, 구성요소)에서 그룹화를 수행할 수 있습니다.

애플리케이션 카탈로그 만들기

계획을 시작하려면 애플리케이션 카탈로그를 만듭니다. 애플리케이션 아키텍처, 비즈니스 고려사항, IT 운영을 기반으로 애플리케이션을 카테고리로 구성합니다. 이렇게 하면 비즈니스 중요도, 복잡성, 클라우드 이전과 관련된 위험에 따라 우선순위를 정할 수 있습니다. 이러한 요소의 조합과 우선순위는 조직, 비즈니스 요구사항, 이러한 요구사항을 현재 아키텍처와 향후 Google Cloud 아키텍처 모두에서 워크로드에 매핑하는 방식에 따라 다릅니다.

다음 목록에는 세 가지 주요 카테고리와 각 카테고리 내에서 고려해야 할 요소가 나와 있습니다.

  • 애플리케이션 아키텍처

    • 기술적 제약
    • 종속 항목 수
    • 등급 수
    • 스테이트풀(Stateful)과 스테이트리스(Stateless) 비교
    • 성능 요구사항
    • 지역 종속 항목
  • 비즈니스 고려사항

    • 규정 준수 요구사항
    • 비즈니스 중요도
    • 비즈니스 변경 기능
    • 사용자 수
    • 사용자 유형(내부, 외부)
    • TCO
  • IT 운영

    • 운영 환경
    • 서비스수준계약
    • 사용 가능 여부
    • 백업

애플리케이션 카탈로그에 고려할 측정기준입니다.

매핑 및 우선순위

애플리케이션 카탈로그에서 복잡도와 타겟팅된 마이그레이션 접근 방식에 따라 애플리케이션을 매핑합니다. 마이그레이션 접근 방식은 마이그레이션 중과 마이그레이션 후에 예상되는 비즈니스 결과, 마이그레이션 작업, 관련 위험 요소를 기반으로 해야 합니다.

그런 다음 비즈니스 가치와 이전에 필요한 노력을 기준으로 이전 후보를 우선순위에 따라 순위 지정합니다. 이전을 준비하려면 가장 먼저 이전할 가능성이 높은 기능이 있는 앱을 파악해야 합니다. 하나만 선택하거나 첫 번째 단계에 여러 앱을 포함시킬 수 있습니다. 첫 번째 단계의 앱을 사용하면 팀에서 클라우드 환경에서 배포를 테스트하면서 앱의 복잡성 대신 마이그레이션에 집중할 수 있습니다.

독립형 앱부터 시작하면 초기 위험성을 낮출 수 있으며, 이후에 더 복잡하고 종속 항목이 많은 애플리케이션에 팀의 새로운 지식을 적용하여 앱을 마이그레이션할 수 있습니다.

첫 번째 물결의 앱은 일반적으로 비즈니스상 중요하지 않으며 시스템 및 네트워크 간 종속 항목이 적습니다. 또한 리팩터링이 덜 필요하고 일반적으로 데이터 중력이 적으며 특정 규정 준수 문제가 없으며 전환 기간을 확보할 수 있습니다. 자세한 내용은 먼저 마이그레이션할 앱을 선택하는 방법을 참고하세요.

복잡도별 애플리케이션 매핑

웨이브에서 애플리케이션 그룹화

각 웨이브의 의견을 바탕으로 계획을 수정하는 데 걸리는 시간과 함께 각 웨이브와 연결된 타임라인을 사용하여 애플리케이션을 여러 웨이브로 그룹화합니다.

  • 웨이브 1: 높은 비즈니스 가치, 구현하기 위한 노력이 덜 필요합니다.
    • 이러한 애플리케이션은 초기 이전 또는 개념 증명에 적합합니다.
  • 웨이브 2: 높은 비즈니스 가치, 구현하기 위한 노력이 많이 필요합니다.
    • 이러한 애플리케이션은 다음 우선순위로 지정될 수 있습니다.
  • 웨이브 3: 낮은 비즈니스 가치, 구현하기 위한 노력이 덜 필요합니다.
    • 이러한 애플리케이션은 다음 우선순위로 지정될 수 있습니다.
  • 웨이브 4: 낮은 비즈니스 가치, 구현하기 위한 노력이 많이 필요합니다.
    • 이러한 애플리케이션은 마지막 우선순위로 지정되어야 합니다.

마이그레이션 웨이브 계획

마이그레이션 웨이브를 정의한 후에는 프로젝트 계획에서 이를 구성할 수 있습니다.

이전 타임라인 및 프로젝트 계획

권장사항 따르기

마이그레이션 계획을 개선하려면 마이그레이션 계획 검증을 위한 권장사항을 따르세요. 이 문서의 개념을 따른다고 해서 반드시 성공한다는 보장은 없습니다. 하지만 이 문서에서는 마이그레이션을 계획할 때 종종 간과되는 몇 가지 사항을 강조 표시합니다.

  1. 마이그레이션 계획의 각 단계에 대한 롤백 전략이 있는지 확인
  2. 이 문서의 앞부분에서 설명한 점진적 롤아웃 및 배포 계획
  3. 워크로드 마이그레이션을 책임진 모든 개발팀과 운영팀에 알림
  4. 대상 프로덕션 환경에서 개념 증명 리소스 및 실험을 삭제
  5. 원본 환경을 안전하게 중단하기 위한 기준 정의
  6. 각 마이그레이션 웨이브에 대해 마이그레이션 위험 평가를 수행하고 식별된 위험에 대한 완화 실행

다음 단계