이 문서는 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 교육을 실시합니다.
- Google Cloud에 대한 실험 및 개념 증명을 빌드합니다.
- 대상 환경의 총소유비용(TCO)을 계산합니다.
- 먼저 마이그레이션할 워크로드를 선택합니다.
앱의 인벤토리 빌드
마이그레이션 범위를 지정하려면 먼저 앱 및 하드웨어 어플라이언스와 같은 항목이 현재 환경에 얼마나 있는지와 해당 종속 항목을 이해해야 합니다. 인벤토리를 빌드하는 것은 특히 자동 카탈로그 시스템이 없는 경우에 상당한 노력이 필요한 태스크입니다. 포괄적인 인벤토리를 확보하려면 현재 환경에서 각 워크로드의 디자인, 배포, 작업을 담당하는 팀의 전문성은 물론 환경 자체를 사용해야 합니다.
인벤토리는 앱에만 국한되어서는 안 되며 최소한 다음을 포함해야 합니다.
- 데이터베이스, 메시지 브로커, 구성 스토리지 시스템, 기타 구성요소 등 각 앱의 종속 항목
- 소스 저장소, 지속적 통합(CI) 도구, 아티팩트 저장소 등 앱 인프라를 지원하는 서비스
- 가상 또는 물리적 서버 및 런타임 환경
- 네트워크 기기, 방화벽, 기타 전용 하드웨어와 같은 물리적 어플라이언스
이 목록을 컴파일할 때 다음을 포함한 각 항목에 대한 정보도 수집해야 합니다.
- 소스 코드 위치 및 이 소스 코드를 수정할 수 있는지 여부
- 예를 들어 자동화된 배포 파이프라인 또는 수동 파이프라인을 사용하는 경우 런타임 환경의 워크로드 배포 방법
- 네트워크 제한 또는 보안 요구사항
- IP 주소 요구사항
- 워크로드를 클라이언트에 노출하는 방법
- 모든 소프트웨어 또는 하드웨어의 라이선스 요구사항
- 워크로드가 ID 및 액세스 관리 시스템에 대해 인증하는 방법
예를 들어 각 하드웨어 어플라이언스의 경우 이름, 공급업체, 기술, 인벤토리의 다른 항목에 대한 종속 항목 등의 세부 사양을 알아야 합니다. 예를 들면 다음과 같습니다.
- 이름: NAS Appliance
- 공급업체 및 모델: 공급업체 Y, 모델 Z
- 기술: NFS, iSCSI
- 종속 항목: 점보 프레임을 통해 VM 컴퓨팅 하드웨어로 네트워크 연결
이 목록에는 각 항목을 사용할 수 있는 라이선스 약관 및 기타 규정 준수 요구사항과 같은 비기술적 정보도 포함되어야 합니다. 클라우드 환경에서 앱을 배포할 수 있는 라이선스도 있지만 클라우드 배포를 명시적으로 금지하는 라이선스도 있습니다. 일부 라이선스는 사용 중인 CPU 또는 소켓 수를 기준으로 할당되며, 클라우드 기술에서 실행할 때 이러한 개념이 적용되지 않을 수 있습니다. 일부 데이터에는 데이터가 저장되는 지리적인 리전과 관련된 제한사항이 있을 수 있습니다. 마지막으로 일부 민감한 워크로드에는 단독 테넌시가 필요할 수 있습니다.
인벤토리와 함께, 수집한 데이터를 시각적으로 해석한 자료를 제공하는 데 유용합니다. 예를 들어 종속 항목 그래프와 차트를 제공하여 앱이 자동 또는 수동 배포 프로세스로 배포되는 방식 등 관심 있는 부분을 강조표시할 수 있습니다.
인벤토리를 빌드하는 방법
앱 인벤토리를 빌드하는 방법에는 여러 가지가 있습니다. 가장 빠른 시작 방법은 수동으로 진행하는 것이지만, 대규모 프로덕션 환경에서는 이 방법이 어려울 수 있습니다. 수동으로 빌드된 인벤토리의 정보는 금방 구식이 될 수 있으며, 잘못된 가정을 기반으로 하기 때문에 마이그레이션이 실패할 수 있습니다.
인벤토리를 빌드하는 것은 일회성 연습이 아닙니다. 현재 환경이 매우 동적이라면 인벤토리 생성 및 유지보수를 자동화하기 위한 노력을 기울여서 결과적으로 해당 환경에서 언제든지 모든 항목을 일관되게 파악할 수 있도록 해야 합니다. 앱 인벤토리를 빌드하는 방법은 마이그레이션 센터: 애셋 탐색 시작을 참조하세요.
Google은 여러 회사와 협력하여 마이그레이션 과정을 지원합니다. 자세한 내용은 도움말 찾기를 참조하세요.
앱 인벤토리의 예시
이 예시는 전자 상거래 앱을 지원하는 환경의 인벤토리입니다. 인벤토리에는 앱, 종속 항목, 여러 앱을 지원하는 서비스, 하드웨어 어플라이언스가 포함됩니다.
앱
다음 표에서는 환경의 각 앱에 대한 가장 중요한 기술, 배포 절차, 기타 요구사항을 보여줍니다.
| 이름 | 소스 코드 위치 | 기술 | 배포 절차 | 기타 요구사항 | 종속 항목 | 시스템 리소스 요구사항 |
|---|---|---|---|---|---|---|
| 마케팅 웹사이트 | 기업 저장소 | 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 |
해당 없음 | 해당 사항 없음 | 해당 없음 |
배포 및 운영 프로세스 평가
워크로드의 인벤토리를 빌드한 후 배포 및 운영 프로세스를 평가하는 것이 좋습니다. 배포 및 운영 프로세스는 프로덕션 환경과 여기에서 실행되는 워크로드를 준비하고 유지관리하는 관행의 중요한 부분입니다.
이러한 프로세스는 필요한 인프라를 프로비저닝하고 운영체제 패키지, 워크로드 배포 패키지, 운영체제 이미지, 컨테이너 이미지와 같이 워크로드에 필요한 아티팩트를 빌드할 수 있습니다. 각 워크로드에 대해 필요한 아티팩트 수, 각 아티팩트의 유형, 이러한 아티팩트를 빌드하는 방법, 아티팩트를 저장하는 방법 및 위치, 이러한 아티팩트를 환경에서 재사용할 수 있도록 런타임 구성을 삽입하는 방법에 대한 정보를 수집합니다.
배포 및 운영 프로세스를 평가한 후에는 이러한 프로세스가 Google Cloud로의 마이그레이션을 어떻게 지원할 수 있는지, 그리고 마이그레이션 범위와 위험을 줄이는 데 어떤 도움이 되는지 평가하는 것이 좋습니다. 예를 들어 마이그레이션이 진행되는 동안 원본 환경과 Google Cloud 모두에 아티팩트를 저장하도록 아티팩트 빌드 프로세스를 리팩터링할 수 있습니다. 두 환경 모두에 아티팩트가 있으면 마이그레이션 프로세스 초반에 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하지 않고도 원본 환경의 워크로드와 데이터를 Google Cloud로 마이그레이션하는 데 집중할 수 있습니다.
인프라 평가
배포 및 운영 프로세스를 평가한 후에는 현재 원본 환경에서 워크로드를 지원하는 인프라를 평가하는 것이 좋습니다.
인프라를 평가하려면 다음을 고려하세요.
- 코드형 인프라와 같이 워크로드에 필요한 리소스를 프로비저닝하기 위해 채택한 프로세스.
- 원본 환경에서 리소스를 구성하는 방법. 예를 들어 일부 환경은 조직 및 프로젝트와 같은 리소스 그룹을 서로 격리하는 구조를 사용하여 리소스 간의 논리적 분리를 지원합니다.
- 온프레미스 환경 및 다른 클라우드 제공업체와 같은 다른 환경에 환경을 연결한 방법
앱 분류
인벤토리를 완료한 후에는 앱을 다른 카테고리로 구성해야 합니다. 이 분류를 사용하면 앱의 복잡성과 클라우드로의 이전 위험에 따라 마이그레이션할 앱의 우선순위를 정할 수 있습니다.
카탈로그 매트릭스는 환경에서 고려 중인 각 평가 기준에 대해 하나의 측정기준을 가져야 합니다. 각 앱에 필요한 시스템 리소스를 포함하여 환경의 모든 요구사항을 충족하는 기준 집합을 선택합니다. 예를 들어 앱에 종속 항목이 있는지 또는 앱이 스테이트리스(Stateless)이거나 스테이트풀(Stateful)인지 여부를 알고 싶을 수 있습니다. 카탈로그 매트릭스를 디자인할 때 추가하는 각 기준에 대해 표시할 다른 측정기준을 추가하는 것이 좋습니다. 결과 행렬은 시각화하기 어려울 수 있습니다. 이 문제에 대해 가능한 해결책은 하나의 복잡한 행렬 대신 여러 개의 작은 행렬을 사용하는 것입니다.
또한 각 앱 옆에 마이그레이션 복잡성 표시기를 추가해야 합니다. 이 표시기는 각 앱의 마이그레이션 난이도를 평가합니다. 이 표시기의 세부사항은 환경에 따라 다릅니다. 기본적인 예시로는 세 가지 카테고리, 즉 마이그레이션하기 쉬움, 마이그레이션하기 어려움, 마이그레이션할 수 없음이 있을 수 있습니다. 이 활동을 완료하려면 마이그레이션의 복잡성을 측정하기 위해 인벤토리의 각 항목에 대한 전문가가 있어야 합니다. 이러한 마이그레이션의 복잡성 요인은 각 비즈니스마다 다릅니다.
카탈로그가 완료되면 시각 자료와 그래프를 빌드하면 개발자와 개발자의 팀이 관심 있는 측정항목을 빠르게 측정하는 데 도움이 될 수 있습니다. 예를 들어 종속 항목이 있는 구성요소 수를 강조표시하거나 각 구성요소의 마이그레이션 난이도를 강조표시하는 그래프를 그립니다.
앱 인벤토리를 빌드하는 방법은 마이그레이션 센터: 애셋 탐색 시작을 참조하세요.
앱 카탈로그의 예시
이 예시에서는 각 행렬 축에 대해 다음 평가 기준이 사용됩니다.
- 앱이 비즈니스에 얼마나 중요한지
- 앱에 종속 항목이 있는지 또는 앱이 다른 앱에 대한 종속 항목인지
- 앱에 허용되는 최대 다운타임
- 앱을 마이그레이션하기 얼마나 어려운지
| 비즈니스 중요도 | 종속 항목이 없음 | 종속 항목이 있음 | 최대 허용 다운타임 | 난이도 |
|---|---|---|---|---|
| 업무상 중요 | 스테이트리스(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 교육 전문 분야에 참석할 수 있습니다. 전 세계 공인 교육 파트너를 통해 이러한 과정에 온라인에서 자신의 속도에 맞게 참여하거나 클래스룸 교육에 참여할 수 있습니다. 이 과정은 일반적으로 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 리소스의 총 비용을 계산하려면 가격 계산기를 사용합니다.
먼저 마이그레이션할 앱 선택
현재 환경을 자세히 살펴 보았으므로 이제 마이그레이션할 앱의 초기 순서를 선택하여 마이그레이션 계획을 완료해야 합니다. Google Cloud에 대한 경험을 쌓고 환경과 앱을 이해하면 마이그레이션 중에 이 순서를 세분화할 수 있습니다.
팀이 Google Cloud에서 지식과 경험을 쌓을 수 있도록 하는 앱이 먼저 마이그레이션할 앱입니다. 팀이 클라우드에 대한 노출과 경험이 많을수록 마이그레이션 단계에서 문제가 발생할 위험이 줄어들고 이후의 마이그레이션이 더 쉬워지고 빨라집니다. 따라서 성공적인 마이그레이션을 위해서는 가장 먼저 이전할 앱을 올바르게 선택하는 것이 중요합니다. 하나의 앱을 선택하거나, 여러 앱 행렬에서 여러 개의 앱을 최초 이전할 목록에 포함시킬 수 있습니다.
최초로 이전할 앱을 식별하는 것은 복잡한 일이지만 다음과 같은 몇 가지 기준을 참고할 수 있습니다.
- 앱의 비즈니스 가치
- 앱이 다른 인프라와 비교하여 고유한 방식으로 배포되거나 실행되는 경우
- 앱의 개발, 배포, 작업을 담당하는 팀
- 앱의 종속 항목 수, 유형, 범위
- 새로운 환경에서 앱이 작동하도록 하는 리팩토링 작업
- 앱의 규정 준수 및 라이선스 요구사항
- 앱의 가용성 및 안정성 요구사항
비즈니스 가치
비즈니스에 중요하지 않은 앱을 선택하면 주요 비즈니스를 보호하고, 팀이 클라우드 기술을 학습하는 동안 발견되지 않은 위험과 실수로부터 비즈니스에 미치는 영향을 줄일 수 있습니다. 예를 들어 전자상거래 앱의 기본 금융 거래 로직이 최초 이전 앱으로 구현된 앱의 구성요소를 선택하면, 마이그레이션 과정에서 발생하는 실수가 주요 비즈니스 라인에 영향을 미칠 수 있습니다. 더 나은 방법은 앱을 지원하는 SQL Database 또는 스테이징 데이터베이스를 개선하는 것입니다.
거의 사용되지 않는 앱은 피해야 합니다. 예를 들어 적은 수의 사용자에 의해 1년에 몇 번만 사용되는 앱을 선택하면 마이그레이션의 위험성은 낮지만 마이그레이션의 모멘텀이 증가하지 않게 되고 문제를 감지하여 해결하기 어려울 수 있습니다.
특이 사례
또한 마이그레이션할 다른 앱에 적용할 수 있는 패턴을 찾을 수 있도록 특이 사례를 피해야 합니다. 최초 이전 앱을 선택할 때의 기본 목표는 조직의 공통 패턴을 경험하여 기술 자료를 구축하는 것입니다. 나중에 앱을 마이그레이션할 때 최초 이전 앱을 통해 학습한 내용을 다시 적용할 수 있습니다.
예를 들어 대부분의 앱이 테스트 기반 개발 방법에 따라 설계되었으며 Python 프로그래밍 언어를 사용하여 개발된 경우, 테스트 범위가 거의 없고 자바 프로그래밍 언어를 사용하여 개발된 앱을 선택하면 Python 앱을 마이그레이션할 때 적용할 수 있는 패턴을 찾을 수 없습니다.
팀
최초 이전 앱을 선택할 때 각 앱을 담당하는 팀에 주목하세요. 최초 이전 앱을 담당하는 팀은 Google Cloud 및 관련 서비스를 사용해 보고자 하는 의욕이 강합니다. 또한 비즈니스 리더십에는 최초 이전 앱을 담당하는 팀을 위한 명확한 목표가 있어야 하며, 이 프로세스를 통해 이들을 후원하고 지원하기 위해 적극적으로 노력해야 합니다.
예를 들어 DevOps와 같은 최신 개발 방법과 사이트 안정성 엔지니어링과 같은 분야를 구현한 입증된 기록이 있는 실적이 우수한 팀이 좋은 후보자가 될 수 있습니다. 또한 앱의 마이그레이션과 관련하여 팀에 하향식 리더십 스폰서와 명확한 목표가 있는 경우 해당 팀은 훌륭한 후보가 될 수 있습니다.
종속 항목
또한 다른 앱이나 서비스에서 종속 항목 수가 가장 적은 앱에 중점을 두어야 합니다. 종속 항목이 없는 앱의 마이그레이션은 Google Cloud에 대한 경험이 부족한 경우에 더 쉽습니다.
다른 구성요소에 대한 종속 항목이 있는 앱을 선택해야 하는 경우 종속 항목과 느슨하게 연결된 앱을 선택합니다. 앱이 종속 항목을 최종적으로 사용하지 못하도록 설계되었다면, 앱을 대상 환경으로 마이그레이션할 때 불편함을 줄일 수 있습니다. 예를 들어 느슨하게 결합된 앱의 후보는 메시지 브로커를 사용하여 통신하거나, 오프라인으로 작동하거나, 나머지 인프라의 비가용성을 허용하도록 설계된 앱입니다.
스테이트풀(Stateful) 앱의 데이터를 마이그레이션하는 전략이 있지만, 스테이트리스(Stateless) 앱은 데이터 마이그레이션이 거의 필요하지 않습니다. 스테이트리스(Stateless) 앱 마이그레이션은 데이터가 현재 환경과 대상 환경에 부분적으로 포함되는 일시적인 단계에 대해 걱정할 필요가 없기 때문에 더 쉽습니다. 예를 들어 스테이트리스(Stateless) 마이크로서비스는 로컬 스테이트풀(Stateful) 데이터에 의존하지 않으므로 좋은 최초 이전 후보입니다.
리팩토링 작업
최초 이전 앱에는 최소한의 리팩토링이 필요하므로 앱의 코드와 구성을 변경하는 데 많은 시간을 들이지 않고 마이그레이션 자체와 Google Cloud에 집중할 수 있습니다. 리팩토링은 앱을 현대화하고 최적화하는 데 중점을 두는 것보다 대상 환경에서 실행을 가능하게 하는 필요한 변경에 중점을 두어야 합니다. 즉, 마이그레이션의 나중 단계에서 처리됩니다.
예를 들어 구성 변경만 필요한 앱은 코드베이스에 변경사항을 구현할 필요가 없으며, 기존 아티팩트를 사용할 수 있으므로 좋은 최초 이전 앱입니다.
라이선스 및 규정 준수
일부 앱은 마이그레이션에 영향을 주는 약관에 따라 라이선스가 부여될 수 있으므로, 라이선스가 최초 이전 앱을 선택하는 역할도 합니다. 예를 들어 일부 라이선스는 클라우드 환경에서의 앱 실행을 명시적으로 금지합니다.
라이선스 약관을 검토할 때 일부 앱에 단독 테넌시 요구사항이 있을 수 있으므로 규정 준수 요구사항을 잊지 마세요. 이러한 이유로 라이선스 및 규정 준수 제한이 가장 적은 앱을 최초 이전 앱으로 선택해야 합니다.
예를 들어 데이터를 저장하는 리전을 선택할 수 있는 법적 권리가 고객에게 있을 수 있으며 고객의 데이터가 특정 리전으로 제한될 수 있습니다.
가용성 및 안정성
좋은 최초 이전 앱은 컷오버 기간으로 인해 발생한 다운타임을 감당할 수 있습니다. 가용성 요구사항이 엄격한 앱을 선택하는 경우 Y(쓰기 및 읽기) 또는 데이터 액세스 마이크로서비스의 개발과 같은 다운타임 없는 데이터 마이그레이션 전략을 구현해야 합니다. 이 접근 방식은 가능하지만, 팀은 이러한 전략을 구현하는 데 시간을 할애해야 하므로 Google Cloud에 대한 충분한 경험을 얻지 못합니다.
예를 들어 일괄 처리 엔진의 가용성 요구사항은 사용자가 거래를 완료하는 전자상거래 사이트의 고객 대상 앱보다 긴 다운타임을 허용할 수 있습니다.
다음 단계
- Google Cloud에서 마이그레이션을 계획하고 기반을 구축하는 방법 알아보기
- 마이그레이션에 대한 도움을 찾는 방법 알아보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기