마이그레이션 웨이브 계획

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

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

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

계획을 시작하려면 애플리케이션 카탈로그를 만듭니다. 애플리케이션 아키텍처, 비즈니스 고려사항, IT 운영을 기준으로 애플리케이션을 카테고리로 구성하세요. 이는 클라우드로 이전하는 데 필요한 비즈니스 중요도, 복잡성, 위험에 따라 우선순위를 지정하는 데 도움이 됩니다. 이러한 요소의 조합과 우선순위는 조직, 비즈니스 필수 요소, 현재 아키텍처와 미래 Google Cloud 아키텍처 모두에서 워크로드에 대한 명령 매핑에 따라 달라집니다.

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

  • 애플리케이션 아키텍처

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

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

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

애플리케이션 카탈로그에서 고려해야 할 측정기준

매핑 및 우선순위 지정

애플리케이션 카탈로그에서 복잡성과 대상 마이그레이션 방법을 기반으로 애플리케이션을 매핑합니다. 마이그레이션 접근법은 기대하는 비즈니스 성과, 마이그레이션 작업, 마이그레이션 도중 및 이후에 발생하는 위험 요소를 기준으로 해야 합니다.

그런 다음 비즈니스 가치와 마이그레이션에 필요한 작업을 기준으로 마이그레이션 후보의 우선순위를 지정합니다. 마이그레이션을 준비하려면 가장 먼저 이동할 가능성이 있는 기능으로 앱을 식별하세요. 하나만 선택하거나 첫 번째 웨이브에 여러 앱을 포함할 수 있습니다. 첫 번째 웨이브의 앱을 사용하면 팀에서는 앱의 복잡성 대신 마이그레이션에 중점을 두어 클라우드 환경에서 배포를 테스트할 수 있습니다.

독립형 앱으로 시작하면 이후에 팀의 복잡성이 커져 종속 항목이 많은 애플리케이션에 적용할 수 있으므로 초기의 위험이 줄어듭니다.

첫 번째 웨이브의 앱은 일반적으로 비즈니스에 중요하지 않으며 시스템 및 네트워크 간 종속 항목이 더 적습니다. 또한 리팩토링이 적고 데이터 중력이 적으며 특정 규정 준수 과제가 없고 a오버 기간을 감당할 수 있습니다. 자세한 내용은 먼저 마이그레이션할 앱을 선택하는 방법을 참조하세요.

복잡성에 따라 애플리케이션 매핑

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

애플리케이션을 각 웨이브와 연결된 타임라인과 함께 여러 웨이브로 그룹화하고 각 웨이브의 피드백을 기반으로 계획을 수정할 수 있습니다.

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

마이그레이션 웨이브 계획

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

마이그레이션 타임라인 및 프로젝트 계획

권장사항 따르기

마이그레이션 계획을 개선하려면 마이그레이션 계획 검증 권장사항을 따르세요. 이 문서의 개념을 따라도 성공이 보장되지 않습니다. 그러나 이 문서에서는 다음과 같이 마이그레이션을 계획할 때 자주 간과하는 몇 가지 사항을 설명합니다.

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

다음 단계