이 문서는 Google Cloud로의 마이그레이션 평가 단계를 계획, 설계, 구현하는 데 도움이 됩니다. 워크로드 및 서비스 인벤토리를 탐색하고 종속 항목을 매핑하면 마이그레이션해야 할 항목과 순서를 식별하는 데 도움이 됩니다. Google Cloud로의 마이그레이션을 계획하고 설계할 때는 먼저 현재 환경과 마이그레이션할 워크로드에 대한 심도 있는 지식이 필요합니다.
이 문서는 Google Cloud로 마이그레이션에 대해 여러 편으로 구성된 다음 시리즈 중 일부입니다.
- Google Cloud로 마이그레이션: 시작하기
- Google Cloud로 마이그레이션: 워크로드 평가 및 탐색(본 문서)
- Google Cloud로 마이그레이션: 기반 계획 및 빌드
- Google Cloud로 마이그레이션: 대규모 데이터 세트 전송
- Google Cloud로 마이그레이션: 워크로드 배포
- Google Cloud로 마이그레이션: 수동 배포에서 자동 컨테이너화된 배포로 마이그레이션
- Google Cloud로 마이그레이션: 환경 최적화
- Google Cloud로 마이그레이션: 마이그레이션 계획 검증을 위한 권장사항
- Google Cloud로 마이그레이션: 비용 최소화
다음 다이어그램은 마이그레이션 과정을 보여줍니다.
이 문서는 온프레미스 환경, 비공개 호스팅 환경, 다른 클라우드 제공업체로부터 마이그레이션을 계획 중이거나 마이그레이션 기회를 평가하고 평가 단계를 살펴보는 경우에 유용합니다.
평가 단계에서는 원본 환경을 Google Cloud로 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.
평가 단계는 마이그레이션의 성공에 매우 중요합니다. 마이그레이션하려는 워크로드, 요구사항, 종속 항목, 현재 환경에 대해 자세히 알고 있어야 합니다. Google Cloud 마이그레이션을 성공적으로 계획하고 실행하려면 시작점을 이해해야 합니다.
평가 단계는 다음 작업으로 구성됩니다.
- 워크로드의 포괄적인 인벤토리를 빌드합니다.
- 워크로드의 속성과 종속 항목에 따라 워크로드를 분류합니다.
- 팀에 Google Cloud 교육을 실시합니다.
- Google Cloud에서 실험 및 개념 증명을 빌드합니다.
- 대상 환경의 총 소유 비용(TCO)을 계산합니다.
- 워크로드에 적합한 마이그레이션 전략을 선택합니다.
- 마이그레이션 도구를 선택합니다.
- 마이그레이션 계획 및 타임라인을 정의합니다.
- 마이그레이션 계획을 검증합니다.
워크로드의 인벤토리 빌드
마이그레이션 범위를 지정하려면 먼저 워크로드 및 하드웨어 어플라이언스와 같은 항목이 현재 환경에 얼마나 있는지와 해당 종속 항목을 이해해야 합니다. 인벤토리를 빌드하는 것은 특히 자동 카탈로그 시스템이 없는 경우에 상당한 노력이 필요한 태스크입니다. 포괄적인 인벤토리를 확보하려면 현재 환경에서 각 워크로드의 디자인, 배포, 작업을 담당하는 팀의 전문성은 물론 환경 자체를 사용해야 합니다.
인벤토리는 워크로드에만 국한되어서는 안 되며 최소한 다음을 포함해야 합니다.
- 데이터베이스, 메시지 브로커, 구성 스토리지 시스템, 기타 구성요소 등 각 워크로드의 종속 항목
- 소스 저장소, 지속적 통합 및 지속적 배포(CI/CD) 도구, 아티팩트 저장소와 같은 워크로드 인프라를 지원하는 서비스
- 가상 또는 물리적 서버 및 런타임 환경
- 네트워크 기기, 방화벽, 기타 전용 하드웨어와 같은 물리적 어플라이언스
이 목록을 컴파일할 때 다음을 포함한 각 항목에 대한 정보도 수집해야 합니다.
- 소스 코드 위치 및 이 소스 코드를 수정할 수 있는지 여부
- 예를 들어 자동화된 배포 파이프라인 또는 수동 파이프라인을 사용하는 경우 런타임 환경의 워크로드 배포 방법
- 네트워크 제한 또는 보안 요구사항
- IP 주소 요구사항
- 워크로드를 클라이언트에 노출하는 방법
- 모든 소프트웨어 또는 하드웨어의 라이선스 요구사항
- 워크로드에서 ID 및 액세스 관리 시스템에 인증하는 방법
예를 들어 각 하드웨어 어플라이언스의 경우 이름, 공급업체, 기술, 인벤토리의 다른 항목에 대한 종속 항목 등의 세부 사양을 알아야 합니다. 예를 들면 다음과 같습니다.
- 이름: NAS Appliance
- 공급업체 및 모델: 공급업체 Y, 모델 Z
- 기술: NFS, iSCSI
- 종속 항목: 점보 프레임을 통해 VM 컴퓨팅 하드웨어로 네트워크 연결
이 목록에는 각 항목을 사용할 수 있는 라이선스 약관 및 기타 규정 준수 요구사항과 같은 비기술적 정보도 포함되어야 합니다. 클라우드 환경에서 워크로드를 배포할 수 있는 라이선스도 있지만 클라우드 배포를 명시적으로 금지하는 라이선스도 있습니다. 일부 라이선스는 사용 중인 CPU 또는 소켓 수를 기준으로 할당되며, 클라우드 기술에서 실행할 때 이러한 개념이 적용되지 않을 수 있습니다. 일부 데이터에는 데이터가 저장되는 지리적인 리전과 관련된 제한사항이 있을 수 있습니다. 마지막으로 일부 민감한 워크로드에는 단독 테넌시가 필요할 수 있습니다.
인벤토리와 함께, 수집한 데이터를 시각적으로 해석한 자료를 제공하는 데 유용합니다. 예를 들어 종속 항목 그래프와 차트를 제공하여 워크로드가 자동 또는 수동 배포 프로세스로 배포되는 방식 등 관심 있는 부분을 강조표시할 수 있습니다.
인벤토리를 빌드하는 방법
워크로드 인벤토리를 빌드하는 방법에는 여러 가지가 있습니다. 가장 빠른 시작 방법은 수동으로 진행하는 것이지만, 대규모 프로덕션 환경에서는 이 방법이 어려울 수 있습니다. 수동으로 빌드된 인벤토리의 정보는 금방 구식이 될 수 있으며, 인벤토리의 콘텐츠를 확인하지 않았기 때문에 마이그레이션이 실패할 수 있습니다.
인벤토리를 빌드하는 것은 일회성 연습이 아닙니다. 현재 환경이 매우 동적이라면 인벤토리 생성 및 유지보수를 자동화하기 위한 노력을 기울여서 결과적으로 해당 환경에서 언제든지 모든 항목을 일관되게 파악할 수 있도록 해야 합니다. 워크로드 인벤토리를 빌드하는 방법은 Migration Center: 애셋 탐색 시작을 참조하세요.
워크로드 인벤토리의 예시
이 예시는 전자상거래 앱을 지원하는 환경의 인벤토리입니다. 인벤토리에는 워크로드, 종속 항목, 여러 워크로드를 지원하는 서비스, 하드웨어 어플라이언스가 포함됩니다.
워크로드
다음 표에서는 환경의 각 워크로드에 대한 가장 중요한 기술, 배포 절차, 기타 요구사항을 보여줍니다.
| 이름 | 소스 코드 위치 | 기술 | 배포 절차 | 기타 요구사항 | 종속 항목 | 시스템 리소스 요구사항 |
|---|---|---|---|---|---|---|
| 마케팅 웹사이트 | 기업 저장소 | Angular 프런트엔드 | 자동 | 법률 부서에서 콘텐츠를 검증해야 함 | 캐싱 서비스 | CPU 코어 5개 8GB RAM |
| 백오피스 | 기업 저장소 | 자바 백엔드, Angular 프런트엔드 | 자동 | 해당 사항 없음 | SQL Database | CPU 코어 4개 4GB RAM |
| 전자상거래 워크로드 | 독점 워크로드 | 공급업체 X 모델 Y 버전 1.2.0 |
수동 | 고객 데이터는 유럽 연합 내에 있어야 함 | SQL Database | CPU 코어 10개 32GB RAM |
| 전사적 자원 관리(ERP) | 독점 워크로드 | 공급업체 Z, 모델 C, 버전 7.0 | 수동 | 해당 사항 없음 | SQL Database | CPU 코어 10개 32GB RAM |
| 스테이트리스(Stateless) 마이크로서비스 | 기업 저장소 | 자바 | 자동 | 해당 사항 없음 | 캐싱 서비스 | CPU 코어 4개 8GB RAM |
종속 항목
다음 표는 인벤토리에 나열된 워크로드 종속 항목의 예시입니다. 워크로드가 제대로 작동하려면 이러한 종속 항목이 필요합니다.
| 이름 | 기술 | 기타 요구사항 | 종속 항목 | 시스템 리소스 요구사항 |
|---|---|---|---|---|
| SQL Database | PostgreSQL | 고객 데이터는 유럽 연합 내에 있어야 함 | 백업 및 보관처리 시스템 | CPU 코어 30개 512GB RAM |
지원 서비스
사용자 환경에 여러 워크로드를 지원하는 서비스가 있을 수 있습니다. 이 전자상거래 예시에는 다음과 같은 서비스가 있습니다.
| 이름 | 기술 | 기타 요구사항 | 종속 항목 | 시스템 리소스 요구사항 |
|---|---|---|---|---|
| 소스 코드 저장소 | Git | 해당 사항 없음 | 백업 및 보관처리 시스템 | CPU 코어 2개 4GB RAM |
| 백업 및 보관처리 시스템 | 공급업체 G, 모델 H, 버전 2.3.0 | 법률에 따라 일부 항목에는 장기 스토리지가 필요함 | 해당 사항 없음 | CPU 코어 10개 8GB RAM |
| CI 도구 | Jenkins | 해당 사항 없음 | 소스 코드 저장소 아티팩트 저장소 백업 및 보관처리 시스템 |
CPU 코어 32개 128GB RAM |
| 아티팩트 저장소 | 공급업체 A 모델 N 버전 5.0.0 |
해당 사항 없음 | 백업 및 보관처리 시스템 | CPU 코어 4개 8GB RAM |
| 일괄 처리 서비스 | CI 도구 내에서 실행되는 크론 작업 | 해당 사항 없음 | CI 도구 | CPU 코어 4개 8GB RAM |
| 캐싱 서비스 | Memcached Redis |
해당 사항 없음 | 해당 사항 없음 | CPU 코어 12개 50GB RAM |
하드웨어
예시 환경에는 다음과 같은 하드웨어 어플라이언스가 있습니다.
| 이름 | 기술 | 기타 요구사항 | 종속 항목 | 시스템 리소스 요구사항 |
|---|---|---|---|---|
| 방화벽 | 공급업체 H 모델 V |
해당 사항 없음 | 해당 사항 없음 | 해당 사항 없음 |
| 서버 j의 인스턴스 | 공급업체 K 모델 B |
더 이상 지원되지 않으므로 사용 중단되어야 함 | 해당 사항 없음 | 해당 사항 없음 |
| NAS 어플라이언스 | 공급업체 Y 모델 Z NFS iSCSI |
해당 사항 없음 | 해당 사항 없음 | 해당 사항 없음 |
배포 및 운영 프로세스 평가
배포 및 운영 프로세스의 작동 방식을 명확하게 이해하는 것이 중요합니다. 이러한 프로세스는 프로덕션 환경과 그 환경에서 실행되는 워크로드를 준비하고 유지관리하는 관행의 중요한 부분입니다.
배포 및 운영 프로세스에서 워크로드가 작동하는 데 필요한 아티팩트를 빌드할 수 있습니다. 따라서 각 아티팩트 유형에 대한 정보를 수집해야 합니다. 예를 들어 아티팩트는 운영체제 패키지, 애플리케이션 배포 패키지, 운영체제 이미지, 컨테이너 이미지 등일 수 있습니다.
아티팩트 유형 외에도 다음 태스크를 완료하는 방법을 고려하세요.
- 워크로드 개발. 개발팀이 워크로드를 빌드하기 위해 마련한 프로세스를 평가합니다. 예를 들어 개발팀이 워크로드를 어떻게 설계, 코딩, 테스트하는지 평가합니다.
- 원본 환경에 배포하는 아티팩트 생성. 원본 환경에 워크로드를 배포하기 위해 컨테이너 이미지 또는 운영체제 이미지와 같은 배포 가능한 아티팩트를 생성하거나 소프트웨어를 설치 및 구성하여 제3자 운영체제 이미지와 같은 기존 아티팩트를 맞춤설정할 수 있습니다. 이러한 아티팩트를 생성하는 방법에 대한 정보를 수집하면 생성된 아티팩트가 Google Cloud 배포에 적합한지 확인하는 데 도움이 됩니다.
아티팩트 저장. AWS의 Artifact Registry에 저장하는 아티팩트를 생성하는 경우 Google Cloud 환경에서 아티팩트를 사용할 수 있도록 해야 합니다. 다음과 같은 전략을 사용하면 수행할 수 있습니다.
- 환경 간 통신 채널 설정: 원본 환경의 아티팩트를 대상 Google Cloud 환경에서 연결할 수 있도록 합니다.
- 아티팩트 빌드 프로세스 리팩터링: 원본 환경과 대상 환경 모두에 아티팩트를 저장할 수 있도록 원본 환경의 마이너 리팩터링을 완료합니다. 이 방식은 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하기 전에 아티팩트 저장소와 같은 인프라를 빌드하여 마이그레이션을 지원합니다. 이 접근 방식을 직접 구현하거나 통신 채널을 먼저 설정하는 이전의 접근 방식으로 빌드할 수 있습니다.
원본 환경과 대상 환경 모두에서 아티팩트를 사용할 수 있으면 마이그레이션의 일환으로 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하지 않고도 마이그레이션에 집중할 수 있습니다.
코드 스캔 및 서명. 아티팩트 빌드 프로세스의 일부로 코드 스캔을 사용하여 일반적인 취약점과 의도하지 않은 네트워크 노출을 방지하고, 코드 서명을 사용하여 신뢰할 수 있는 코드만 환경에서 실행되도록 할 수 있습니다.
원본 환경에 아티팩트 배포. 배포 가능한 아티팩트를 생성한 후 원본 환경에 배포할 수 있습니다. 각 배포 프로세스를 평가하는 것이 좋습니다. 이 평가는 배포 프로세스가 Google Cloud와 호환되는지 확인하는 데 도움이 됩니다. 또한 프로세스를 리팩터링하는 데 필요한 노력을 파악하는 데도 도움이 됩니다. 예를 들어 배포 프로세스가 원본 환경에서만 작동하는 경우 Google Cloud 환경을 타겟팅하도록 이를 리팩터링해야 할 수 있습니다.
런타임 구성 삽입. 특정 클러스터, 런타임 환경 또는 워크로드 배포에 대한 런타임 구성을 삽입할 수 있습니다. 이 구성으로 환경 변수와 보안 비밀, 사용자 인증 정보, 키와 같은 기타 구성 값이 초기화될 수 있습니다. 런타임 구성 삽입 프로세스가 Google Cloud에서 작동하는지 확인하려면 원본 환경에서 실행되는 워크로드를 구성하는 방법을 평가하는 것이 좋습니다.
로깅, 모니터링, 프로파일링. 원본 환경의 상태, 관심 측정항목, 이러한 프로세스에서 제공하는 데이터 사용 방식을 모니터링하기 위해 마련한 로깅, 모니터링, 프로파일링 프로세스를 평가합니다.
클러스터 인증. 원본 환경에 대해 인증하는 방법을 평가합니다.
리소스 프로비저닝 및 구성. 원본 환경을 준비하기 위해 리소스를 프로비저닝하고 구성하는 프로세스를 설계하고 구현했을 수 있습니다. 예를 들어 구성 관리 도구와 함께 Terraform을 사용하여 원본 환경에서 리소스를 프로비저닝하고 구성할 수 있습니다.
인프라 평가
배포 및 운영 프로세스를 평가한 후에는 원본 환경에서 워크로드를 지원하는 인프라를 평가하는 것이 좋습니다.
해당 인프라를 평가하려면 다음을 고려하세요.
- 원본 환경에서 리소스를 구성하는 방법. 예를 들어 일부 환경은 조직, 프로젝트, 네임스페이스와 같은 리소스 그룹을 서로 격리하는 구조를 사용하여 리소스 간의 논리적 분리를 지원합니다.
- 온프레미스 환경 및 기타 클라우드 제공업체와 같은 다른 환경에 환경을 연결하는 방법
워크로드 분류
인벤토리를 완료한 후에는 워크로드를 다른 카테고리로 구성해야 합니다. 이 분류를 사용하면 워크로드의 복잡성과 클라우드로의 이전 위험에 따라 마이그레이션할 워크로드의 우선순위를 정할 수 있습니다.
카탈로그 매트릭스는 환경에서 고려 중인 각 평가 기준에 대해 하나의 측정기준을 가져야 합니다. 각 워크로드에 필요한 시스템 리소스를 포함하여 환경의 모든 요구사항을 충족하는 기준 집합을 선택합니다. 예를 들어 워크로드에 종속 항목이 있는지 또는 워크로드가 스테이트리스(Stateless)이거나 스테이트풀(Stateful)인지 여부를 알고 싶을 수 있습니다. 카탈로그 매트릭스를 디자인할 때 추가하는 각 기준에 대해 표시할 다른 측정기준을 추가하는 것이 좋습니다. 결과 행렬은 시각화하기 어려울 수 있습니다. 이 문제에 대해 가능한 해결책은 하나의 복잡한 행렬 대신 여러 개의 작은 행렬을 사용하는 것입니다.
또한 각 워크로드 옆에 마이그레이션 복잡성 표시기를 추가해야 합니다. 이 표시기는 각 워크로드의 마이그레이션 난이도를 평가합니다. 이 표시기의 세부사항은 환경에 따라 다릅니다. 기본적인 예시로는 세 가지 카테고리, 즉 마이그레이션하기 쉬움, 마이그레이션하기 어려움, 마이그레이션할 수 없음이 있을 수 있습니다. 이 활동을 완료하려면 마이그레이션의 복잡성을 측정하기 위해 인벤토리의 각 항목에 대한 전문가가 있어야 합니다. 이러한 마이그레이션의 복잡성 요인은 각 비즈니스마다 다릅니다.
카탈로그가 완료되면 시각 자료와 그래프를 빌드하면 개발자와 개발자의 팀이 관심 있는 측정항목을 빠르게 측정하는 데 도움이 될 수 있습니다. 예를 들어 종속 항목이 있는 구성요소 수를 강조표시하거나 각 구성요소의 마이그레이션 난이도를 강조표시하는 그래프를 그립니다.
워크로드 인벤토리를 빌드하는 방법은 Migration Center: 애셋 탐색 시작을 참조하세요.
워크로드 카탈로그의 예시
이 예시에서는 각 행렬 축에 대해 다음 평가 기준이 사용됩니다.
- 워크로드가 비즈니스에 얼마나 중요한지
- 워크로드에 종속 항목이 있는지 또는 워크로드가 다른 워크로드에 대한 종속 항목인지
- 워크로드의 최대 허용 다운타임
- 워크로드를 마이그레이션하기 얼마나 어려운지
| 비즈니스 중요도 | 종속 항목이 없음 | 종속 항목이 있음 | 최대 허용 다운타임 | 난이도 |
|---|---|---|---|---|
| 업무상 중요 | 스테이트리스(Stateless) 마이크로서비스 | 2분 | 쉬움 | |
| ERP | 24시간 | 어려움 | ||
| 전자상거래 워크로드 | 다운타임 없음 | 어려움 | ||
| 하드웨어 방화벽 | 다운타임 없음 | 이동할 수 없음 | ||
| SQL Database | 10분 | 쉬움 | ||
| 소스 코드 저장소 | 12시간 | 쉬움 | ||
| 업무상 중요하지 않음 | 마케팅 웹사이트 | 2시간 | 쉬움 | |
| 백업 및 보관처리 | 24시간 | 쉬움 | ||
| 일괄 처리 서비스 | 48시간 | 쉬움 | ||
| 캐싱 서비스 | 30분 | 쉬움 | ||
| 백오피스 | 48시간 | 어려움 | ||
| CI 도구 | 24시간 | 쉬움 | ||
| 아티팩트 저장소 | 30분 | 쉬움 |
카탈로그에서 결과를 시각화하는 데 도움이 되도록 시각 자료와 차트를 만들 수 있습니다. 다음 차트는 마이그레이션 난이도를 보여줍니다.
위의 차트에서 대부분의 워크로드는 이동하기 쉬우며, 그 중 3개는 이동하기 어렵고 그 중 하나는 이동할 수 없습니다.
Google Cloud 관련 조직 교육
Google Cloud를 최대한 활용하려면 조직에서 비즈니스가 Google Cloud에서 사용할 수 있는 서비스, 제품, 기술에 대해 학습해야 합니다. 직원은 실험하고 학습하는 데 도움이 되는 크레딧이 포함된 Google Cloud 무료 체험판 계정으로 시작할 수 있습니다. 테스트 및 학습을 위한 무료 환경을 만드는 것은 직원의 학습 경험에 매우 중요합니다.
다음과 같은 몇 가지 학습 옵션이 있습니다.
- 공개 및 개방형 리소스: 실무형 실습, 동영상 시리즈, Cloud OnAir 웹 세미나, Cloud OnBoard 학습 이벤트를 통하여 무료로 Google Cloud 학습을 시작할 수 있습니다.
- 심층 과정: Google Cloud 작동 방식을 더 자세히 알고 싶으면 Google Cloud Skills Boost의 주문형 과정, 자신의 속도에 맞게 온라인 과정에 참여할 수 있는 Coursera의 Google Cloud 교육 전문 분야 또는 전 세계 Google 공인 교육 파트너에서 제공하는 클래스룸 교육에 참여하면 됩니다. 이 과정은 일반적으로 1일에서 수일 동안 진행됩니다.
- 역할 기반 학습 과정: 조직 내 역할에 따라 엔지니어를 교육할 수 있습니다. 예를 들어 워크로드 개발자 또는 인프라 운영자에게 Google Cloud 서비스를 가장 효과적으로 사용하는 방법을 교육할 수 있습니다.
또한 여러 수준의 다양한 자격증을 통해 엔지니어의 Google Cloud 지식을 인증할 수 있습니다.
- 어소시에이트 자격증: Google Cloud를 처음 사용하는 사람을 위한 시작점으로, 어소시에이트 클라우드 엔지니어 자격증과 같은 전문가의 인증을 받을 수 있습니다.
- 프로페셔널 자격증: 수년간의 경험을 통해 Google Cloud의 고급 설계와 구현 기술을 평가하려는 경우 프로페셔널 클라우드 설계자 또는 프로페셔널 데이터 엔지니어와 같은 자격증을 받을 수 있습니다
- Google Workspace 자격증: Google Workspace 자격증으로 Google Workspace 도구를 사용하여 공동작업 기술을 입증할 수 있습니다.
- Apigee 자격증: Apigee 인증된 API 엔지니어 자격증을 통해 강력하고 안전하며 확장 가능한 API를 설계 및 개발할 수 있는 능력을 입증할 수 있습니다.
- Google 개발자 자격증: 어소시에이트 Android 개발자(이 자격증 업데이트 중) 및 모바일 웹 전문가 자격증을 통해 개발 기술을 입증할 수 있습니다.
교육 및 자격증 외에 Google Cloud를 경험하는 가장 좋은 방법 중 하나는 제품을 사용하여 비즈니스 개념 증명을 빌드하는 것입니다.
개념 증명 실험 및 설계
Google Cloud의 가치와 효율성을 보여 주려면 워크로드 카탈로그의 각 워크로드 카테고리에 하나 이상의 개념 증명(PoC)을 설계하고 개발하는 것이 좋습니다. 실험 및 테스트를 통해 가정을 검증하고 비즈니스 리더에게 클라우드의 가치를 입증할 수 있습니다.
PoC에는 최소한 다음이 포함되어야 합니다.
- 일반적이지 않고 특수한 경우를 비롯하여 워크로드에서 지원하는 사용 사례의 포괄적인 목록
- 성능, 확장성, 일관성 요구사항, 장애 조치 메커니즘, 네트워크 요구사항 등 각 사용 사례의 모든 요구사항
- 조사하고 테스트하려는 기술 및 제품의 잠재적인 목록
목록의 모든 사용 사례를 검증하려면 PoC 및 실험을 설계해야 합니다. 각 실험에는 정확한 유효성 컨텍스트, 범위, 예상 출력, 측정 가능한 비즈니스 영향이 있어야 합니다.
예를 들어 CPU 제한을 받는 워크로드 중 하나가 수요를 만족하기 위해 빠르게 확장되어야 하는 경우, 영역이 가상 CPU 코어를 많이 만들 수 있는지와 이를 수행하는 데 걸리는 시간을 확인하기 위해 실험을 진행할 수 있습니다. 현재 환경에 비해 새로운 워크로드의 수직 확장 시간을 95% 줄이는 등 가치가 눈에 띄게 향상하는 경우에는 즉시 비즈니스 가치를 입증할 수 있습니다.
온프레미스 데이터베이스의 성능을 Cloud SQL, Spanner, Firestore, Bigtable과 비교하는 데 관심이 있는 경우 동일한 비즈니스 로직이 다른 데이터베이스를 사용하는 PoC를 구현할 수 있습니다. 이 PoC를 사용하면 여러 벤치마크 및 작업 비용 전반에서 워크로드에 적합한 관리형 데이터베이스 솔루션을 식별하는 데 위험성이 낮은 기회를 제공합니다.
Google Cloud에서 VM 프로비저닝 프로세스의 성능을 평가하려면 PerfKit Benchmarker와 같은 타사 도구를 사용하여 Google Cloud를 다른 클라우드 제공업체와 비교할 수 있습니다. 엔드 투 엔드 시간을 측정하여 지연 시간, 처리량, 완료 소요 시간을 포함한 최대 성능의 표준 측정항목에 대해 보고하는 것 외에도 클라우드에서 리소스를 프로비저닝할 수 있습니다. 예를 들어 많은 Kubernetes 클러스터를 프로비저닝하는 데 걸리는 시간과 노력에 관심이 있을 수 있습니다. PerfKit Benchmarker는 Google을 포함한 연구자, 학술 기관, 회사 등 500명 이상의 참여자가 활동하는 오픈소스 커뮤니티 활동입니다.
총소유비용 계산
새 환경에 필요한 리소스를 명확하게 파악하면 Google Cloud의 비용을 현재 환경의 비용과 비교할 수 있는 총소유비용 모델을 빌드할 수 있습니다.
이 비용 모델을 빌드할 때는 하드웨어 및 소프트웨어 비용뿐만 아니라 전원, 냉각, 유지보수, 기타 지원 서비스와 같은 모든 자체 데이터 센터 운영 비용도 고려해야 합니다. 또한 일반적으로 보다 엄격한 온프레미스 데이터 센터에 비해 Google Cloud 리소스의 탄력적인 확장성으로 인해 손쉽게 비용을 절감할 수 있음을 고려합니다.
클라우드 마이그레이션을 고려할 때 일반적으로 간과되는 비용은 클라우드 네트워크의 사용입니다. 데이터 센터에서 라우터 및 스위치와 같은 네트워크 인프라를 구매한 다음 적절한 네트워크 케이블 배선을 운영하는 것은 일회성 비용이며, 네트워크의 전체 용량을 사용할 수 있도록 합니다. 클라우드 환경에서 네트워크 사용 요금이 청구될 수 있는 방법은 다양합니다. 데이터 집약적인 워크로드나 대량의 네트워크 트래픽을 발생시키는 워크로드의 경우, 클라우드의 네트워킹 비용을 낮추기 위해 새로운 아키텍처와 네트워크 흐름을 고려해야 할 수 있습니다.
또한 Google Cloud는 리소스 및 비용의 지능형 확장을 위해 다양한 옵션을 제공합니다. 예를 들어 Compute Engine에서는 Migrate for Compute Engine을 사용하여 마이그레이션하는 중이나 VM이 이미 실행되거나 인스턴스의 자동 확장 그룹을 빌드한 후에 크기를 조정할 수 있습니다. 이러한 옵션은 서비스 실행 비용에 큰 영향을 미칠 수 있으므로 이를 살펴보고 총소유비용(TCO)을 계산해야 합니다.
Google Cloud 리소스의 총 비용을 계산하려면 가격 계산기를 사용합니다.
워크로드에 적합한 마이그레이션 전략 선택
마이그레이션할 각 워크로드에 대해 사용 사례에 가장 적합한 마이그레이션 전략을 평가하고 선택합니다. 예를 들어 워크로드에 다음과 같은 조건이 있을 수 있습니다.
- 미션 크리티컬 워크로드와 같은 다운타임이나 데이터 손실을 허용하지 않습니다. 이러한 워크로드의 경우 다운타임이 없거나 거의 없는 마이그레이션 전략을 선택할 수 있습니다.
- 보조 또는 백엔드 워크로드와 같은 다운타임을 허용합니다. 이러한 워크로드의 경우 다운타임이 필요한 마이그레이션 전략을 선택할 수 있습니다.
마이그레이션 전략을 선택할 때는 다운타임이 없거나 거의 없는 마이그레이션 전략은 다운타임이 필요한 마이그레이션 전략보다 설계 및 구현하는 데 일반적으로 더 많은 비용이 들고 더 복잡하다는 점에 유의하세요.
마이그레이션 도구 선택
워크로드에 적합한 마이그레이션 전략을 선택한 후에는 마이그레이션 도구를 검토하고 결정합니다.
특정 마이그레이션 사용 사례에 맞게 최적화된 여러 마이그레이션 도구를 사용할 수 있습니다. 사용 사례에는 다음이 포함될 수 있습니다.
- 마이그레이션 전략
- 원본 및 대상 환경
- 데이터 및 워크로드 크기
- 데이터 및 워크로드 변경 빈도
- 마이그레이션을 위한 관리형 서비스 사용 가능성
원활한 마이그레이션 및 컷오버를 보장하기 위해서는 애플리케이션 배포 패턴, 인프라 조정, 커스텀 마이그레이션 애플리케이션을 사용할 수 있습니다. 그러나 관리형 마이그레이션 서비스라고 부르는 전문화된 도구는 한 환경에서 다른 환경으로 데이터, 워크로드, 심지어 전체 인프라를 이동하는 과정에 도움이 될 수 있습니다. 이러한 기능을 통해 복잡한 마이그레이션 로직을 캡슐화하고 마이그레이션 모니터링 기능을 제공합니다.
마이그레이션 계획 및 타임라인 정의
현재 환경을 자세히 살펴 보았으므로 이제 다음을 수행하여 마이그레이션 계획을 완료해야 합니다.
- 배치로 마이그레이션할 워크로드 및 데이터를 그룹화합니다(경우에 따라 스프린트라고도 함).
- 배치를 마이그레이션할 순서를 선택합니다.
- 각 배치 내에서 워크로드를 마이그레이션할 순서를 선택합니다.
마이그레이션 계획의 일환으로 다음 문서를 작성하는 것이 좋습니다.
- 기술 설계 문서
- RACI 표
- 타임라인(예: T-Minus 계획)
Google Cloud에 대한 경험을 쌓고, 마이그레이션에 대한 모멘텀을 얻고, 환경을 이해하면 다음을 수행할 수 있습니다.
- 마이그레이션할 워크로드 및 데이터의 그룹화를 미세 조정합니다.
- 마이그레이션 배치의 크기를 늘립니다.
- 배치 및 배치 내 워크로드를 마이그레이션하는 순서를 업데이트합니다.
- 배치 구성을 업데이트합니다.
배치로 마이그레이션할 워크로드와 데이터를 그룹화하고 마이그레이션 순서를 정의하려면 다음과 같은 여러 기준에 따라 워크로드를 평가합니다.
- 워크로드의 비즈니스 가치
- 워크로드가 다른 인프라와 비교하여 고유한 방식으로 배포되거나 실행되는지 여부
- 워크로드의 개발, 배포, 작업을 담당하는 팀
- 워크로드의 종속 항목 수, 유형, 범위
- 새로운 환경에서 워크로드가 작동하도록 하는 리팩터링 작업
- 워크로드의 규정 준수 및 라이선스 요구사항
- 워크로드의 가용성 및 안정성 요구사항
팀이 Google Cloud에서 지식과 경험을 쌓을 수 있도록 하는 워크로드가 먼저 마이그레이션할 워크로드입니다. 팀이 클라우드에 대한 노출과 경험이 많을수록 마이그레이션 단계에서 문제가 발생할 위험이 줄어들고 이후의 마이그레이션이 더 쉬워지고 빨라집니다. 따라서 성공적인 마이그레이션을 위해서는 가장 먼저 이전할 워크로드를 올바르게 선택하는 것이 중요합니다.
비즈니스 가치
비즈니스에 중요하지 않은 워크로드를 선택하면 주요 비즈니스를 보호하고, 팀이 클라우드 기술을 학습하는 동안 발견되지 않은 위험과 실수로부터 비즈니스에 미치는 영향을 줄일 수 있습니다. 예를 들어 전자상거래 워크로드의 기본 금융 거래 로직이 최초 이전 워크로드로 구현된 워크로드의 구성요소를 선택하면, 마이그레이션 과정에서 발생하는 실수가 주요 비즈니스 라인에 영향을 미칠 수 있습니다. 더 나은 방법은 워크로드를 지원하는 SQL Database 또는 스테이징 데이터베이스를 개선하는 것입니다.
거의 사용되지 않는 워크로드는 피해야 합니다. 예를 들어 적은 수의 사용자에 의해 1년에 몇 번만 사용되는 워크로드를 선택하면 마이그레이션의 위험성은 낮지만 마이그레이션의 모멘텀이 증가하지 않게 되고 문제를 감지하여 해결하기 어려울 수 있습니다.
특이 사례
또한 마이그레이션할 다른 워크로드에 적용할 수 있는 패턴을 찾을 수 있도록 특이 사례를 피해야 합니다. 최초 이전 워크로드를 선택할 때의 기본 목표는 조직의 공통 패턴을 경험하여 기술 자료를 구축하는 것입니다. 나중에 워크로드를 마이그레이션할 때 최초 이전 워크로드를 통해 학습한 내용을 다시 적용할 수 있습니다.
예를 들어 대부분의 워크로드가 테스트 기반 개발 방법론에 따라 설계되었고 Python 프로그래밍 언어를 통해 개발된 경우 테스트 범위가 거의 없고 Java 프로그래밍 언어를 통해 개발된 워크로드를 선택하면 Python 워크로드를 마이그레이션할 때 적용할 수 있는 패턴을 찾을 수 없습니다.
팀
최초 이전 워크로드를 선택할 때 각 워크로드를 담당하는 팀에 주목하세요. 최초 이전 워크로드를 담당하는 팀은 Google Cloud 및 관련 서비스를 사용해 보고자 하는 의욕이 강합니다. 또한 비즈니스 리더십에는 최초 이전 워크로드를 담당하는 팀을 위한 명확한 목표가 있어야 하며, 이 프로세스를 통해 이들을 후원하고 지원하기 위해 적극적으로 노력해야 합니다.
예를 들어 DevOps와 같은 최신 개발 방법과 사이트 안정성 엔지니어링과 같은 분야를 구현했다는 입증된 기록이 있는 실적이 우수한 팀이 좋은 후보자가 될 수 있습니다. 또한 각 워크로드 마이그레이션과 관련하여 팀에 하향식 리더십 스폰서와 명확한 목표가 있는 경우 해당 팀은 훌륭한 후보가 될 수 있습니다.
종속 항목
또한 다른 워크로드나 서비스에서 종속 항목 수가 가장 적은 워크로드에 중점을 두어야 합니다. 종속 항목이 없는 워크로드의 마이그레이션은 Google Cloud에 대한 경험이 부족한 경우에 더 쉽습니다.
다른 구성요소에 대한 종속 항목이 있는 워크로드를 선택해야 하는 경우 종속 항목과 느슨하게 결합된 워크로드를 선택합니다. 워크로드가 종속 항목을 최종적으로 사용하지 못하도록 설계되었다면, 워크로드를 대상 환경으로 마이그레이션할 때 불편함을 줄일 수 있습니다. 예를 들어 느슨하게 결합된 워크로드의 후보는 메시지 브로커를 사용하여 통신하거나, 오프라인으로 작동하거나, 나머지 인프라의 비가용성을 허용하도록 설계된 워크로드입니다.
스테이트풀(Stateful) 워크로드의 데이터를 마이그레이션하는 전략이 있지만, 스테이트리스(Stateless) 워크로드는 데이터 마이그레이션이 거의 필요하지 않습니다. 스테이트리스(Stateless) 워크로드 마이그레이션은 데이터가 현재 환경과 대상 환경에 부분적으로 포함되는 일시적인 단계에 대해 걱정할 필요가 없기 때문에 더 쉽습니다. 예를 들어 스테이트리스(Stateless) 마이크로서비스는 로컬 스테이트풀(Stateful) 데이터에 의존하지 않으므로 좋은 최초 이전 후보입니다.
리팩토링 작업
최초 이전 워크로드에는 최소한의 리팩터링이 필요하므로 워크로드의 코드와 구성을 변경하는 데 많은 시간을 들이지 않고 마이그레이션 자체와 Google Cloud에 집중할 수 있습니다. 리팩터링은 워크로드를 현대화하고 최적화하는 데 중점을 두는 것보다 대상 환경에서 실행을 가능하게 하는 필요한 변경에 중점을 두어야 합니다. 즉, 마이그레이션의 나중 단계에서 처리됩니다.
예를 들어 구성 변경만 필요한 워크로드는 코드베이스에 변경사항을 구현할 필요가 없으며, 기존 아티팩트를 사용할 수 있으므로 좋은 최초 이전 워크로드입니다.
라이선스 및 규정 준수
일부 워크로드는 마이그레이션에 영향을 주는 약관에 따라 라이선스가 부여될 수 있으므로, 라이선스가 최초 이전 워크로드를 선택하는 역할도 합니다. 예를 들어 일부 라이선스는 클라우드 환경에서의 워크로드 실행을 명시적으로 금지합니다.
라이선스 약관을 검토할 때 일부 워크로드에 단독 테넌시 요구사항이 있을 수 있으므로 규정 준수 요구사항을 잊지 마세요. 이러한 이유로 라이선스 및 규정 준수 제한이 가장 적은 워크로드를 최초 이전 워크로드로 선택해야 합니다.
예를 들어 데이터를 저장하는 리전을 선택할 수 있는 법적 권리가 고객에게 있을 수 있으며 고객의 데이터가 특정 리전으로 제한될 수 있습니다.
가용성 및 안정성
좋은 최초 이전 워크로드는 컷오버 기간으로 인해 발생한 다운타임을 감당할 수 있습니다. 가용성 요구사항이 엄격한 워크로드를 선택하는 경우 Y(쓰기 및 읽기) 또는 데이터 액세스 마이크로서비스 개발과 같은 다운타임 없는 데이터 마이그레이션 전략을 구현해야 합니다. 이 접근 방식은 가능하지만, 팀은 이러한 전략을 구현하는 데 시간을 할애해야 하므로 Google Cloud에 대한 충분한 경험을 얻지 못합니다.
예를 들어 일괄 처리 엔진의 가용성 요구사항은 사용자가 거래를 완료하는 전자상거래 사이트의 고객 대상 워크로드보다 긴 다운타임을 허용할 수 있습니다.
마이그레이션 계획 검증
마이그레이션 계획을 시작하기 위한 조치를 취하기 전에 실행 가능성을 검증하는 것이 좋습니다. 자세한 내용은 마이그레이션 계획 검증 권장사항을 참조하세요.
다음 단계
마이그레이션에 대한 도움을 찾는 방법 알아보기
Cloud 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기
참여자
작성자: 마르코 페라리 | 클라우드 솔루션 설계자