Google Cloud로 마이그레이션: 시작하기

이 문서는 워크로드를 Google Cloud로 마이그레이션하는 프로세스를 계획, 설계, 구현하는 데 도움이 됩니다. 앱을 환경 간에 이전하는 것은 경험이 풍부한 팀에게도 까다로운 작업이므로 마이그레이션을 계획하고 실행할 때는 주의를 기울여야 합니다.

이 문서는 시리즈의 일부입니다.

이 문서는 온프레미스 환경, 비공개 호스팅 환경, 다른 클라우드 제공업체에서 Google Cloud로 마이그레이션을 계획 중이거나, 마이그레이션 기회를 평가하고 그 결과를 살펴보고 싶은 경우에 유용합니다.

시작하기

Google Cloud로의 마이그레이션을 계획할 때는 마이그레이션과 관련된 환경을 먼저 정의해야 합니다. 시작점은 온프레미스 환경, 비공개 호스팅 환경 또는 다른 퍼블릭 클라우드 환경일 수 있습니다.

온프레미스 환경은 개발자에게 완전한 소유권과 책임이 있는 환경입니다. 즉, 냉각, 물리적 보안, 하드웨어 유지보수 등 환경의 모든 측면에 대한 전권을 보유합니다.

코로케이션 시설과 같은 비공개 호스팅 환경에서는 물리적 인프라와 관리적 측면의 일부를 타사로 아웃소싱합니다. 고객들 간에 이러한 인프라를 공유하는 것이 일반적입니다. 비공개 호스팅 환경에서는 개발자가 물리적 보안 및 안전 서비스를 관리할 필요가 없습니다. 일부 호스팅 환경에서는 서버, 랙, 네트워크 기기와 같은 물리적 하드웨어 일부를 관리할 수 있지만 나머지 환경에서는 이러한 하드웨어를 자동으로 관리해 줍니다. 일반적으로 전력 및 네트워크 케이블 배선은 서비스 형태로 제공되므로 관리할 필요가 없습니다. 물리적 리소스를 가상화하는 하이퍼바이저, 프로비저닝 대상인 가상화된 인프라, 인프라에서 실행할 워크로드에 대한 전체 제어 권한은 개발자에게 있습니다.

퍼블릭 클라우드 환경에서는 전체 리소스 스택을 직접 관리할 필요가 없다는 이점이 있습니다. 따라서 스택의 가장 중요한 측면에 집중할 수 있습니다. 비공개 호스팅 환경과 마찬가지로 기본적인 물리적 인프라를 관리할 필요가 없습니다. 또한 리소스 가상화 하이퍼바이저를 관리하지 않아도 됩니다. 이 새로운 인프라에 가상화된 인프라를 빌드하고 워크로드를 배포할 수 있습니다. 또한 완전 관리형 서비스를 구매할 경우 런타임 환경을 관리하는 데 따른 운영 부담을 전가하여 워크로드에만 집중할 수 있습니다.

본 문서에서는 각 환경과 관련하여 다음과 같은 측면은 물론 관련 서비스를 누가 제공하고 관리해야 하는지 평가합니다.

리소스 온프레미스 환경 비공개 호스팅 환경 퍼블릭 클라우드 환경
물리적 보안 및 안전 개발자 서비스 제공업체 서비스 제공업체
전력 및 네트워크 케이블 배선 개발자 서비스 제공업체 서비스 제공업체
하드웨어(유지보수 포함) 개발자 서비스 제공업체에 따라 다름 서비스 제공업체
가상화 플랫폼 개발자 개발자 서비스 제공업체
앱 리소스 개발자 개발자 개발자(궁극적으로 완전 관리형 서비스 활용)

이 문서에서 대상 환경은 Google Cloud입니다.

시작 환경과 대상 환경을 정의한 후에 마이그레이션 범위에 속하는 워크로드 유형과 관련 운영 프로세스를 정의합니다. 본 문서에서는 2가지 유형의 워크로드와 운영 즉, 레거시와 클라우드 기반을 고려합니다.

레거시 워크로드 및 운영은 클라우드 환경을 고려하지 않고 개발할 수 있습니다. 이러한 워크로드 및 운영은 일반적으로 어떠한 유형의 확장성도 지원하지 않으므로 변경이 어렵고 실행 및 유지보수 비용이 많이 들 수 있습니다.

클라우드 기반 워크로드 및 운영은 기본적으로 확장성, 이동성, 가용성, 안정성이 뛰어납니다. 워크로드 및 운영은 개발자 생산성과 비즈니스 대응력을 강화하는 데 도움을 줄 수 있는데, 이는 개발자가 개발 환경과 런타임 환경을 관리하고 번거로운 수동 개발 프로세스를 처리하는 데 역량을 투입하는 대신 실제 워크로드를 중점적으로 처리할 수 있기 때문입니다. 또한 Google Cloud에는 보안 책임 공유 모델이 있습니다. Google Cloud는 물리적 보안을 비롯한 인프라 보안을 책임지며 사용자는 인프라에 배포하는 워크로드의 보안을 책임집니다.

이러한 환경과 워크로드 유형을 고려할 때 시작 환경은 다음 중 하나일 수 있습니다.

  • 레거시 워크로드 및 운영으로 구성된 온프레미스 또는 비공개 호스팅 환경
  • 클라우드 기반 워크로드 및 운영으로 구성된 온프레미스 또는 비공개 호스팅 환경
  • 레거시 워크로드 및 운영으로 구성된 퍼블릭 클라우드 또는 비공개 호스팅 환경
  • 클라우드 기반 워크로드 및 운영으로 구성된 퍼블릭 클라우드 또는 비공개 호스팅 환경

마이그레이션 프로세스는 시작점에 따라 다릅니다.

기존 온프레미스 환경 또는 비공개 호스팅 환경의 워크로드를 퍼블릭 클라우드와 같은 클라우드 기반 환경으로 마이그레이션하는 작업은 까다롭고 위험할 수 있습니다. 성공적으로 마이그레이션 작업을 수행하려면 마이그레이션 작업 중에 마이그레이션할 워크로드를 최소화할 수 있어야 합니다. 레거시 온프레미스 앱을 클라우드로 이전하는 경우 여러 마이그레이션 단계를 거쳐야 할 수도 있습니다.

마이그레이션 유형

마이그레이션에는 3가지 주요 유형이 있습니다.

  • 리프트 앤 시프트
  • 개선 및 이동
  • 전면 교체

다음 섹션에서는 각 유형의 마이그레이션을 사용할 시점을 예시와 함께 정의합니다.

리프트 앤 시프트

리프트 앤 시프트 방식의 마이그레이션에서는 소스 환경의 워크로드를 변경을 최소화하거나 변경이나 리팩토링 없이 대상 환경으로 이전합니다. 마이그레이션할 워크로드에는 워크로드가 대상 환경에서 작동하는 데 필요한 최소한의 변경 사항만 적용해야 합니다.

리프트 앤 시프트 마이그레이션은 워크로드가 대상 환경에서 있는 그대로 작동하거나 변경에 대한 비즈니스 요구가 거의 없거나 전혀 없는 경우에 유용합니다. 이 마이그레이션 유형의 경우 리팩토링 규모가 최소한으로 유지되므로 최소한의 시간만 필요합니다.

기술적 문제로 리프트 앤 시프트 마이그레이션을 강제로 수행해야 하는 경우도 있습니다. 마이그레이션할 워크로드를 리팩토링할 수 없고 워크로드를 중단할 수 없는 경우에는 리프트 앤 시프트 마이그레이션 방식을 사용해야 합니다. 예를 들어 워크로드의 소스 코드 수정이 어렵거나 불가능할 수 있고, 또는 빌드 프로세스가 간단하지 않기 때문에 소스 코드의 리팩토링 후 새로운 아티팩트 생성이 불가능할 수 있습니다.

리프트 앤 시프트 마이그레이션은 새로운 전문 기술 없이 기존의 도구와 기술을 사용할 수 있기 때문에 가장 쉽게 수행할 수 있습니다. 이 방식은 기성품 소프트웨어도 지원합니다. 리프트 앤 시프트 마이그레이션은 최소 규모의 리팩토링으로 기존 워크로드를 마이그레이션하기 때문에 개선 및 이동, 전면 교체 방식과 비교할 때 속도가 가장 빠릅니다.

하지만 리프트 앤 시프트 마이그레이션을 수행하면 결과적으로 비클라우드 기반 워크로드가 대상 환경에서 실행됩니다. 이러한 워크로드는 수평 확장, 세밀한 가격 책정, 고도로 관리되는 솔루션 등 클라우드 플랫폼 기능을 최대한 활용하지 못합니다.

개선 및 이동

개선 및 이동 방식의 마이그레이션에서는 마이그레이션 과정 중에 워크로드를 개선합니다. 이 유형의 마이그레이션에서는 새로운 환경에서 작동하는 것뿐만 아니라 클라우드 기반 기능을 활용할 수 있도록 워크로드를 변경합니다. 성능, 기능, 비용 또는 사용자 환경에 적합하도록 각 워크로드를 개선할 수 있습니다.

현재 아키텍처나 앱의 인프라가 대상 환경에서 있는 그대로 지원되지 않는 경우 이러한 제한을 해결하기 위해서는 일정량의 리팩토링이 필요합니다.

개선 및 이동 방식을 선택해야 하는 또 다른 상황은 마이그레이션을 수행하는 데 필요한 업데이트 외에 워크로드에 대한 주요 업데이트가 필요할 때입니다.

개선 및 이동 방식의 마이그레이션에서는 확장성, 고가용성과 같은 클라우드 플랫폼의 기능을 활용할 수 있습니다. 또한 앱의 이동성을 높이기 위해 개선 기능을 설계할 수도 있습니다.

하지만 개선 및 이동 방식의 마이그레이션의 경우 앱을 마이그레이션하기 위해 리팩토링을 수행해야 하기 때문에 리프트 앤 시프트 방식보다 오래 걸립니다. 앱 수명 주기의 일부로 투입된 추가 시간과 노력을 평가해야 합니다.

개선 및 이동 마이그레이션을 수행하려면 새로운 기술을 습득해야 합니다.

전면 교체

전면 교체 방식의 마이그레이션에서는 기존 앱을 중단한 후 해당 앱을 클라우드 기반 앱으로 재설계하고 다시 작성합니다.

예를 들어 앱을 마이그레이션하고 싶지만 앞서 언급된 방법들 중 하나를 사용하기엔 마이그레이션 비용이 너무 많이 든다거나 앱이 Google Cloud에서 지원되지 않는 경우처럼 현재 앱이 목표에 부합하지 않을 때 전면 교체 마이그레이션을 활용할 수 있습니다.

전면 교체 마이그레이션을 이용하면 수평 확장성, 고도로 관리되는 서비스, 고가용성 등 Google Cloud 기능을 최대한 활용할 수 있습니다. 앱을 처음부터 다시 작성해야 하기 때문에 기존의 레거시 버전에 대한 기술적 채무를 피할 수도 있습니다.

그러나 전면 교체 마이그레이션은 리프트 앤 시프트나 개선 및 이동 마이그레이션보다 더 오래 걸릴 수 있습니다. 또한 이 유형의 마이그레이션은 앱을 다시 작성해야 하므로 기성품 앱에는 적합하지 않습니다. 앱 수명 주기의 일부로 앱을 재설계하고 재작성하는 데 투입되는 추가 시간과 노력을 평가해야 합니다.

전면 교체 마이그레이션에는 새로운 기술도 필요합니다. 새로운 도구 모음을 사용하여 새 환경을 프로비저닝 및 구성하고 이 환경에 앱을 배포해야 합니다.

Google Cloud 도입 프레임워크

마이그레이션을 시작하기 전에 적절한 클라우드 기술을 채택할 수 있도록 조직의 성숙도를 평가해야 합니다. Google Cloud 도입 프레임워크는 현재 보유한 비즈니스 정보 기술 역량을 확인할 수 있는 지도이자 미래에 필요한 역량을 결정할 수 있는 가이드 역할을 합니다.

이 프레임워크를 사용하면 아래 다이어그램에 설명된 것처럼 Goolge Cloud와 관련한 조직의 준비 상태를 평가하고 간격을 메꾸고 새로운 역량을 개발하기 위해 해야 할 일을 확인할 수 있습니다.

4가지 테마와 3단계로 구성된 Google Cloud 도입 프레임워크 아키텍처

이 프레임워크는 다음의 4가지 테마를 평가합니다.

  • 학습. 학습 프로그램의 품질과 규모를 의미합니다.
  • 리더십. Google Cloud로의 마이그레이션을 위해 IT 부서가 경영진에게 위임받은 권한의 정도를 의미합니다.
  • 확장성. 클라우드 기반 서비스를 사용하는 정도와 현재 사용 중인 운영 자동화 수준을 의미합니다.
  • 보안. 부적절한 무단 액세스로부터 현재 환경을 보호하는 능력을 의미합니다.

프레임워크에 따라 각 테마에는 다음 3가지 단계가 있습니다.

  • 전술. 개별 워크로드를 갖추었지만 모든 워크로드를 포괄하는 일관된 계획이 마련되어 있지 않습니다. 빠른 투자 수익과 IT 조직이 겪는 혼란을 최소화하는 데 초점을 맞춥니다.
  • 전략. 향후 확장을 염두에 두고 개별 워크로드를 개발하려는 계획이 마련되어 있습니다. 효율성이 향상되도록 운영을 간소화하기 위한 중기 목표에 초점을 맞춥니다.
  • 혁신. 원활하게 진행되는 클라우드 운영을 통해 수집한 데이터를 사용하여 IT 비즈니스를 개선합니다. IT 부서가 조직 혁신의 동력으로 자리매김할 수 있도록 하는 장기 목표에 초점을 맞춥니다.

이 3가지 단계와 관련해 4가지 테마를 평가할 때 클라우드 성숙도 검사를 이용합니다. 각 테마에서는 필요에 따라 새 기술을 채택한 시점부터 조직 전체에서 더욱 전략적으로 사용하기까지 벌어지는 일들을 확인할 수 있습니다. 즉, 더 깊고 포괄적이며 일관된 팀 교육으로 이어지게 됩니다.

마이그레이션 경로

기억해야 할 점은 마이그레이션이 여정이라는 것입니다. 기존 인프라 및 환경이 지점 A라면, 이제 지점 B에 도달하려고 합니다. A에서 B로 이동하려면 앞서 설명한 마이그레이션 중 하나를 선택하면 됩니다.

다음 다이어그램은 이 여정의 경로를 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

마이그레이션은 4가지 단계를 거칩니다.

  • 평가. 이 단계에서는 앱 및 환경 인벤토리를 이해하고, 앱 종속 항목과 요구사항을 식별하고, 총 소유 비용을 계산하며, 앱 성능 벤치마크를 설정하기 위해 기존 환경에 대한 철저한 평가와 탐색을 수행합니다.
  • 계획. 이 단계에서는 워크로드가 상주할 기본 클라우드 인프라를 구축하고 앱 이전 방식을 계획합니다. 이 계획에는 ID 관리, 조직 및 프로젝트 구조, 네트워킹, 앱 정렬, 우선적 전략 개요가 포함됩니다.
  • 배포. 이 단계에서는 워크로드를 Goolge Cloud로 마이그레이션하는 배포 프로세스를 계획하고 설계하며 실행합니다. 새로운 요구사항을 처리하기 위해 클라우드 인프라를 개선해야 할 수 있습니다.
  • 최적화. 이 단계에서는 성능, 확장성, 재해 복구, 비용, 교육뿐만 아니라 앱에 머신러닝 및 인공지능을 도입하는 등 비즈니스의 잠재력을 확대하기 위한 클라우드 기반 기술 및 기능을 활용하기 시작합니다.

마이그레이션 1단계: 평가

평가 단계에서는 마이그레이션하려는 워크로드와 현재 런타임 환경에 대한 정보를 수집합니다.

현황 파악

성공적인 마이그레이션의 핵심은 현재 환경에서 실행 중인 앱과 각 앱에 대한 종속 항목을 이해하는 것입니다. 이러한 요소에는 데이터베이스, 메시지 브로커, 데이터 웨어하우스, 네트워크 어플라이언스가 포함됩니다. 또한 머신, 하드웨어 사양, 운영체제, 라이선스, 그리고 각각에서 사용되는 앱 및 서비스의 목록을 만들어야 합니다.

카탈로그 앱

현황을 파악한 다음에는 카탈로그 매트릭스를 만들어 Goolge Cloud로의 마이그레이션과 관련한 복잡성과 위험을 바탕으로 앱을 분류할 수 있습니다.

다음 표는 카탈로그 매트릭스의 예시를 보여줍니다.

종속 항목이 없음 종속 항목이 있음
업무상 중요
  • 스테이트리스(Stateless) 마이크로서비스(보통)
  • ERP(어려움)
  • OLTP 데이터베이스(어려움)
  • 전자상거래 앱(어려움)
  • 데이터 웨어하우스(어려움)
  • 방화벽 어플라이언스(불가능)
업무상 중요하지 않음
  • 마케팅 웹사이트(쉬움)
  • 백업 및 보관처리(쉬움)
  • 개발 및 테스트 환경(쉬움)
  • 일괄 처리(쉬움)
  • 백오피스(어려움)
  • 데이터 분석(어려움)

이 카탈로그 매트릭스 예시에는 평가 기준에 대한 2가지 측정기준이 포함되어 있습니다. 실제 앱에는 추가 측정기준 또는 고려사항이 필요할 수 있습니다. 환경의 모든 고유한 요건을 포함할 수 있도록 매트릭스를 만들어야 합니다.

Google Cloud 관련 조직 교육

평가 단계에서 조직은 Google Cloud에 대해 배우기 시작해야 합니다. 소프트웨어 및 네트워크 엔지니어에게 클라우드의 작동 방식과 활용할 수 있는 Google Cloud 제품, Google Cloud에 워크로드를 배포하는 데 활용할 수 있는 프레임워크, API, 라이브러리를 교육해야 합니다.

개념 증명 실험 및 설계

평가 단계에서는 개념 증명(PoC)을 선택하고 이를 구현하거나 Goolge Cloud 제품을 시험적으로 사용하여 사용 사례 또는 그 외 불명확한 부분의 유효성을 확인하는 것 또한 중요합니다.

다음 사용 사례를 고려하세요.

  • 특정 영역에서 50,000개의 가상 CPU 코어를 가동할 수 있는지 여부 확인
  • 복잡한 워크로드에 방화벽 규칙 구현
  • 온프레미스 데이터베이스와 Cloud SQL, Cloud Spanner, Firestore 또는 Cloud Bigtable의 성능 비교
  • 리전별 GKE 클러스터의 가용성 실험
  • Google Cloud에서 실행하는 앱의 내부 및 외부 네트워크 지연 시간 테스트
  • GKE의 컨테이너에 대한 Cloud Build 배포 파이프라인의 속도와 안정성 평가
  • DataflowDataproc의 Spark 비교
  • BigQuery로 데이터 이전 및 정확성 테스트를 위해 업무상 중요한 쿼리 작성
  • 다른 로깅 메커니즘을 대체할 Cloud Logging 평가

각 실험을 통해 다음과 같은 비즈니스 영향을 평가해야 합니다.

  • 현재 환경과 비교하여 Google Cloud에서 가상 CPU 코어 50,000개를 가동할 수 있는 실행 시간이 95% 단축된 것으로 확인되면 이는 특정 요소에 의한 TTM(time to market) 단축을 의미합니다. 이러한 단축은 재해 복구 환경 설정 시간에도 영향을 주어 중요한 사업 분야의 다운타임을 줄일 수 있습니다.
  • 전역적으로 사용 가능한 상시 재해 복구 계획을 수립할 수 있으면 앱의 안정성을 높일 수 있습니다.
  • 클라우드 확장 기술을 사용하는 경우 리소스 요구량이 적을 때 축소하고 필요할 때 확장하면 총 서비스 비용을 절감할 수 있습니다.

총 소유 비용 계산

총 소유 비용 모델을 만들면 Google Cloud 비용을 현재 환경의 비용과 비교할 수 있습니다. Google Cloud 가격 계산기와 같은 유용한 도구와 Google의 파트너 서비스도 활용할 수 있습니다. 이때 온프레미스 또는 자체 데이터 센터에서 실행하는 경우의 운영 비용 즉, 전력, 냉각, 유지보수, 기타 총 소유 비용에 영향을 미치는 기타 서비스 비용을 잊지 마세요.

마이그레이션할 워크로드의 우선순위 지정

마이그레이션을 준비하려면 가장 먼저 이전할 앱과 기능을 파악해야 합니다. 단 하나만 선택하거나 최초 이전 후보 목록에 여러 앱을 포함시킬 수도 있습니다. 이러한 최초 이전 후보 목록을 사용하면 팀에서는 앱의 복잡성 대신 마이그레이션에 집중할 수 있는 클라우드 환경에서 앱을 실행하고 테스트할 수 있습니다. 복잡성이 낮은 앱부터 시작하면 초기 위험성을 낮출 수 있으며, 이후에 난이도가 높은 앱에 팀의 새로운 지식을 적용하여 앱을 마이그레이션할 수 있습니다.

최초 이전 후보를 지정하는 작업은 복잡하지만 일반적으로 다음의 워크로드 기준을 상당 수 충족하는 경우 후보로 적합한 것으로 간주할 수 있습니다.

  • 업무 상 중요하지 않으므로 주요 사업 분야가 마이그레이션의 영향을 받지 않습니다. 이 경우 팀은 클라우드 기술에 대한 중요한 경험이 아직 없을 수 있습니다.
  • 마이그레이션하려는 다른 워크로드에 동일한 패턴을 쉽게 적용할 수 있으므로 판단이 어려운 특이한 케이스가 아닙니다.
  • 기술 자료를 작성하는 데 사용할 수 있습니다.
  • Google Cloud에서 실행하고자 하는 의욕이 강한 팀의 지원이 있습니다.
  • 다른 워크로드를 이전하는 중앙 팀에서 이전합니다. 첫 번째 워크로드를 이전한 팀은 더 많은 경험을 얻게 되므로 이후 워크로드 마이그레이션에 꽤 도움이 될 수 있습니다.
  • 예를 들어 종속 항목이 적은 스테이트리스(Stateless) 워크로드는 다른 워크로드에 거의 영향을 미치지 않거나 구성 변경사항을 최소화하므로 쉽게 이전할 수 있습니다.
  • 최소한의 앱 변경사항이나 리팩토링이 요구됩니다.
  • 대량의 데이터를 마이그레이션할 필요가 없습니다.
  • 엄격한 규정 준수 요구사항이 없습니다.
  • 일부 공급업체에서는 클라우드 제품에 라이선스를 부여하지 않거나 라이선스 유형의 변경을 요구할 수 있으므로 타사 독점 라이선스가 필요하지 않습니다.
  • 단순 이전으로 인해 발생한 다운타임의 영향을 받지 않습니다. 예를 들어 현재 데이터베이스의 데이터를 내보낸 다음 계획된 유지보수 기간 중에 Google Cloud의 데이터베이스 인스턴스로 가져올 수 있습니다. 다운타임 없이 마이그레이션하기 위해 2개의 데이터베이스 인스턴스를 동기화하는 작업이 더 복잡할 수 있습니다.

마이그레이션 2단계: 계획

이 단계에서는 Google Cloud에서 워크로드를 지원할 클라우드 인프라와 서비스를 프로비저닝하고 구성합니다. 중요한 구성 및 서비스의 기반을 구축하는 것은 계속적으로 변경되는 프로세스입니다. 규칙, 거버넌스, 설정을 구성하는 경우 나중에 변경할 수 있는 여지를 남겨두어야 합니다. 또한 마이그레이션 수행에 방해가 되는 결정은 피해야 합니다. 나중에 상황이 변경될 경우에 대비해 이러한 변경사항을 지원하는 옵션이 있어야 합니다.

마이그레이션을 계획하려면 다음을 수행해야 합니다.

  • 사용자 및 서비스 ID 설정
  • 리소스 조직 설계
  • 리소스 그룹 및 역할에 대한 액세스 권한 정의
  • 네트워크 토폴로지 설계 및 연결 설정

ID 설정

Google Cloud에서 선택할 수 있는 ID 유형은 다음과 같습니다.

  • Google 계정. 일반적으로 Google Cloud와 상호작용하는 개별 사용자의 계정입니다.
  • 서비스 계정. 일반적으로 사용자가 아닌 앱이나 서비스에 속하는 계정입니다.
  • Google 그룹스. Google 계정을 모아 이름을 붙인 컬렉션입니다.
  • G Suite 도메인. 조직의 G Suite 계정에서 생성된 모든 Google 계정으로 구성된 가상 그룹입니다.
  • Cloud ID 도메인. 이러한 도메인은 G Suite 애플리케이션에 대한 액세스 권한이 없다는 점을 제외하고 G Suite 도메인과 같습니다.

자세한 내용은 각 ID 유형을 참조하세요.

예를 들어 Google Cloud를 Active Directory와 통합하여 하이브리드 환경에서 일관된 인증 및 승인 메커니즘을 구축할 수 있습니다.

리소스 조직 설계

앱에 필요한 ID를 설정한 후에는 앱에서 사용하는 프로젝트, 폴더 또는 버킷과 같은 리소스에 대한 권한을 부여해야 합니다. 이렇게 하려면 각 ID에 역할을 할당하면 됩니다. 역할이란 권한의 모음입니다. 권한은 리소스에 허용되는 작업의 모음입니다.

동일한 구성 단계를 반복하지 않으려면 리소스를 서로 다른 유형의 구조로 구성하면 됩니다. 이러한 구조는 계층 구조로 구조화됩니다.

  • 조직은 리소스 계층 구조의 루트로 회사와 같은 실제 조직을 나타냅니다. 조직에는 폴더와 프로젝트가 포함됩니다. 조직 관리자는 해당 조직에 포함된 모든 리소스에 적절한 권한을 부여할 수 있습니다.
  • 폴더는 프로젝트 간의 추가 격리 계층으로 조직 내의 하위 조직으로 보일 수 있습니다. 폴더에는 다른 폴더 및 프로젝트가 포함될 수 있습니다. 관리자는 폴더를 사용하여 관리자 권한을 위임할 수 있습니다.
  • 프로젝트는 기본 수준의 구성 항목으로 다른 Google Cloud 리소스에 액세스하는 데 사용됩니다. 개발자가 배포하고 사용하는 모든 리소스 인스턴스는 프로젝트에 포함되어야 합니다.

리소스는 상위 노드의 권한을 상속하므로 상위 요소가 동일한 리소스의 경우 같은 구성 단계를 반복해서 수행할 필요가 없습니다. ID 및 액세스 관리(IAM) 상속 메커니즘에 대한 자세한 내용은 Resource Manager 문서정책 상속 섹션을 참조하세요.

조직, 폴더, 프로젝트는 리소스이며 다른 모든 Google Cloud 리소스와 같은 작업 세트를 지원합니다. 다른 Google Cloud 리소스와 마찬가지로 이러한 리소스와 상호작용할 수 있습니다. 예를 들어 Resource Manager API를 사용하여 계층 구조 생성을 자동화할 수 있습니다. 필요에 따라 리소스 계층 구조를 구성할 수 있습니다. 각 계층 구조의 루트 노드는 항상 조직입니다. 다음 섹션에는 조직에 구현할 수 있는 계층 구조 유형이 나와 있습니다. 각 계층 유형은 구현의 복잡성과 유연성의 특징에 따라 규정됩니다.

환경 중심의 계층 구조

환경 중심의 계층 구조에는 환경별로 하나의 폴더가 포함된 조직이 하나 있습니다.

다음 다이어그램은 환경 중심의 계층 구조에 대한 예시를 보여줍니다.

환경 중심 계층 구조의 아키텍처

위의 그림에는 개발, 품질 보증, 프로덕션과 같은 다양한 환경이 구성되어 있으며, 각 환경에 동일한 2개의 앱인 내 앱 1과 내 앱 2를 배포했습니다.

이 계층 구조는 단 3개 레벨로 구성되어 있으므로 구현이 간단하지만 여러 환경에서 공유하는 서비스를 배포해야 할 경우 구현이 어려워질 수 있습니다.

기능 중심의 계층 구조

기능 중심의 계층 구조에는 비즈니스 기능(예: 정보 기술, 관리 등)별로 하나의 폴더가 포함된 조직이 하나 있습니다. 각 비즈니스 기능 폴더에는 여러 환경 폴더가 포함될 수 있습니다.

다음 다이어그램은 기능 중심의 계층 구조 예시를 보여줍니다.

기능 중심 계층 구조의 아키텍처

이 계층 구조에는 앱, 관리, 정보 기술과 같은 여러 비즈니스 기능이 설정되어 있습니다. 개발자는 내 앱의 여러 인스턴스와 Jira와 웹사이트와 같은 공유 서비스를 배포할 수 있습니다.

이 옵션을 사용하면 환경을 동일하게 분리하므로 환경 중심의 계층 구조를 사용할 때보다 훨씬 더 유연하게 공유 서비스를 배포할 수 있습니다. 그러나 기능 중심의 계층 구조는 환경 중심의 계층 구조보다 관리하기가 더 복잡하고 소매, 재무 등과 같은 비즈니스 단위 기준으로 액세스 권한을 분리하지 못합니다.

세부 액세스 중심 계층 구조

세부 액세스 중심의 계층 구조에는 비즈니스 단위(예: 소매, 재무 등)별로 하나의 폴더가 포함된 조직이 하나 있습니다. 각 비즈니스 단위 폴더에는 비즈니스 기능별로 하나의 폴더가 있습니다. 각 비즈니스 기능 폴더에는 환경별로 하나의 폴더가 있습니다.

다음 다이어그램은 세밀한 제어 중심의 계층 구조에 대한 예시를 보여줍니다.

액세스 중심 계층 구조의 아키텍처

이 계층 구조에는 여러 비즈니스 단위, 여러 비즈니스 기능, 환경이 설정되어 있습니다. 개발자는 내 앱 1 및 내 앱 2 앱에 대한 여러 인스턴스와 넷 호스트와 같은 공유 서비스를 배포할 수 있습니다.

이 계층 구조는 가장 유연하고 확장 가능한 옵션입니다. 하지만 구조, 역할, 권한을 관리하는 데 더 많은 노력을 들여야 합니다. 네트워크 토폴로지의 경우 다른 옵션에 비해 프로젝트 수가 높게 나타나므로 훨씬 더 복잡해질 수 있습니다.

리소스 액세스 권한 그룹 및 역할 정의

리소스에 필요한 액세스 권한을 부여하려면 그룹 및 역할을 설정해야 합니다. Google Cloud에서 조직의 리소스에 관리자 액세스 권한을 위임할 수 있습니다. 최소 다음과 같은 역할이 있어야 합니다.

  • 조직 관리자: IAM 정책 및 조직과 관련 리소스의 계층 구조를 정의합니다.
  • 네트워크 관리자: 네트워크, 서브네트워크, Cloud Router, Cloud VPN, Cloud Load Balancing과 같은 네트워크 기기를 만들고 구성합니다. 이 외에 보안 관리자와 협력하여 방화벽 규칙의 유지보수도 담당합니다.
  • 보안 관리자: 조직 및 관련 리소스의 정책 및 제한사항을 설정하고, 프로젝트의 새로운 IAM 역할을 구성하며, 로그 및 리소스에 대한 공개 상태를 유지관리합니다.
  • 결제 관리자: 결제 계정을 구성하고, 전체 조직에서의 리소스 사용량과 지출액을 모니터링합니다.

네트워크 토폴로지 설계 및 연결 설정

계획 단계의 마지막 단계는 기존 환경에서 Google Cloud로의 네트워크 토폴로지 및 연결을 설정하는 것입니다.

프로젝트를 만들고 ID를 설정한 후에는 하나 이상의 Virtual Private Cloud(VPC) 네트워크를 구축해야 합니다. VPC를 사용하면 여러 리전에 걸쳐있는 비공개 전역 주소 지정 공간을 활용할 수 있습니다. 리전 간 통신에는 공개 인터넷을 사용하지 않습니다. VPC를 구축하여 앱을 분리하거나 여러 프로젝트에 걸쳐있는 공유 VPC를 활용할 수 있습니다. VPC를 설정한 후에는 Cloud Logging을 사용하여 네트워크 흐름 로깅방화벽 규칙 로깅도 구성해야 합니다. VPC 및 VPC 설정 방법에 대한 자세한 내용은 VPC 설계에 관한 권장사항 및 참조 아키텍처를 참조하세요.

Google Cloud는 기존 환경을 Google Cloud 프로젝트에 연결하는 다양한 하이브리드 연결 옵션을 제공합니다.

  • 공개 인터넷
  • Cloud VPN
  • 피어링
  • Cloud Interconnect

Google의 기존 에지 네트워크를 사용하는 복원력이 우수한 인프라에서 지원하는 공개 인터넷을 통해 연결하는 방식은 설정이 간단하고 비용이 적게 듭니다. 그러나 이 인프라는 비공개 또는 전용 인프라가 아니므로, 이 옵션의 보안은 각 연결에서 데이터를 교환하는 앱에 따라 달라집니다. 따라서 암호화되지 않은 트래픽 전송에는 이 유형의 연결을 사용하지 않는 것이 좋습니다.

Cloud VPNIPSec 터널을 사용하여 기존 네트워크를 Google Cloud로 확장합니다. 트래픽은 암호화되어 공개 인터넷을 통해 두 네트워크를 오갑니다. Cloud VPN은 추가 구성을 필요로 하며 연결 처리량에 영향을 줄 수 있지만 앱 수준에서 트래픽을 암호화하지 않고 비공개 Google Cloud 리소스에 액세스해야 한다면 가장 적합한 선택이 될 수 있습니다.

피어링 방식을 사용하면 비공개 채널을 통해 Google의 네트워크에 대한 연결을 설정할 수 있습니다. 피어링에는 다음과 같은 2가지 유형이 있습니다.

  • 다이렉트 피어링을 사용하면 네트워크와 Google 에지 네트워크 사이에 다이렉트 피어링 연결을 설정할 수 있습니다. Google Cloud에서 비공개 리소스에 액세스할 필요가 없으며 Google의 피어링 요구사항에 부합한다면 이 방법을 사용하는 것이 좋습니다. 서비스수준계약(SLA)이 없는 경우 이 옵션을 사용하면 Cloud VPN의 공개 인터넷 액세스에 비해 이그레스 비용을 절감할 수 있습니다.
  • 이동통신사 피어링을 사용하면 서비스 제공업체에서 관리하는 엔터프라이즈급 네트워크 서비스를 사용하여 Google의 네트워크에 연결할 수 있습니다. Google은 이 연결 방법에 대한 SLA를 제공하지 않지만 서비스 제공업체의 SLA가 적용될 수 있습니다. 이 옵션의 가격을 평가할 때는 Google Cloud 이그레스 요금과 서비스 제공업체 요금을 모두 고려해야 합니다.

Cloud Interconnect를 활용하면 가용성이 높은 연결을 통해 기존의 네트워크를 Google의 네트워크까지 확장할 수 있습니다. 기본적으로 암호화된 채널을 제공하지 않으므로 이 옵션을 사용하려는 경우 앱 수준에서 민감한 트래픽을 암호화하는 것이 좋습니다. 다음 2가지 Cloud Interconnect 옵션 중에서 선택할 수 있습니다.

  • Dedicated Interconnect를 사용하면 10Gbps 이상의 고대역폭 비공개 연결을 설정할 수 있지만 코로케이션 시설에서 라우팅 장비를 사용해야 합니다. 즉, Google의 접속 지점(PoP) 중 하나에서 Google에 연결해야 합니다. Google은 Dedicated Interconnect 연결에 대한 엔드 투 엔드 SLA를 제공하며 요금은 전용 대역폭 및 연결 수를 기준으로 청구됩니다.
  • Partner Interconnect를 사용하면 Google 코로케이션 시설에서 라우팅 장비를 구성할 필요 없이 서비스 제공업체에서 관리하는 전용 고대역폭 비공개 연결을 사용할 수 있습니다. Google에서 Google과 서비스 제공업체 간의 연결에 대한 SLA를 보장합니다. 서비스 제공업체는 개발자와 서비스 제공업체 간의 연결에 대한 SLA를 보장할 수 있습니다. Partner Interconnect 요금은 연결 용량 및 상호 연결을 통한 이그레스 트래픽 양을 기준으로 청구됩니다. 또한 서비스 제공업체에서 서비스에 대한 요금을 부과할 수도 있습니다.

마이그레이션 3단계: 배포

Google Cloud 환경을 위한 기반을 구축한 후 워크로드를 배포할 수 있습니다. 배포 프로세스를 구현하고 마이그레이션 중 해당 프로세스를 개선할 수 있습니다. 마이그레이션이 진행됨에 따라 환경의 기초를 다시 확인해야 할 수 있습니다. 새로운 클라우드 환경, 플랫폼, 서비스, 도구에 익숙해지면 새로운 요구사항이 발생할 수 있습니다.

워크로드에 대한 배포 프로세스를 설계하는 경우 필요한 자동화 및 유연성 수준을 고려해야 합니다. 완전 수동 프로세스부터 간소화된 완전 자동 프로세스까지 다양한 배포 프로세스 유형 중에서 선택할 수 있습니다.

완전 수동 배포

완전 수동 프로비저닝, 구성, 배포를 통해 플랫폼과 도구를 신속하게 실험할 수 있지만, 오류가 발생할 수 있으며 문서화 및 반복이 어려울 수 있습니다. 따라서 다른 옵션이 없는 경우가 아니라면 완전 수동 배포는 피하는 것이 좋습니다. 예를 들어 Compute Engine 인스턴스와 같은 Cloud Console을 사용하여 리소스를 수동으로 만들고 명령어를 수동으로 실행하여 워크로드를 배포할 수 있습니다.

구성 관리 도구

구성 관리(CM) 도구를 사용하면 자동화되고 반복 가능한 제어 방법으로 환경을 구성할 수 있습니다. 환경을 구성하고 워크로드를 배포하는 데 CM 도구를 사용할 수도 있습니다. 이 프로세스는 완전 수동 배포에 비해 더 나은 것으로 보이지만 다운타임 없는 배포 또는 블루-그린 배포와 같이 정교한 배포를 구현할 수 있는 기능이 없습니다. 일부 CM 도구를 사용하면 자체 배포 로직을 구현하고 이러한 누락된 기능을 모방하는 데 사용할 수 있습니다. 그러나 배포 도구로 CM 도구를 사용하면 배포 프로세스가 복잡해질 수 있으며 전용 배포 도구 모음보다 관리와 유지보수가 어려울 수 있습니다. 맞춤설정된 배포 솔루션을 설계, 빌드, 유지보수하는 경우 운영팀의 부담이 크게 늘어날 수 있습니다.

컨테이너 조정

컨테이너화에 투자했다면 한 걸음 더 나아가 워크로드를 조정하기 위해 Google Kubernetes Engine(GKE)과 같은 서비스를 사용할 수 있습니다. 컨테이너 조정에 Kubernetes를 사용하면 기본 인프라와 배포 로직에 대해 걱정할 필요가 없습니다.

배포 자동화

지속적 통합 및 지속적 배포(CI/CD) 파이프라인과 같은 자동화된 아티팩트 프로덕션 및 배포 프로세스를 구현하여 아티팩트 생성과 배포를 자동화할 수 있습니다. 이 프로세스는 완전 자동화가 가능하고 필요한 경우 수동 승인 단계를 추가할 수도 있습니다.

이 프로세스의 구현에 관한 예시는 Spinnaker 및 Google Kubernetes Engine을 사용한 지속적 배포 파이프라인을 참조하세요.

코드형 인프라

CI/CD 파이프라인을 구현하여 배포 프로세스를 자동화할 수 있지만 인프라에 적합한 유사 프로세스를 채택해도 됩니다. 코드형 인프라를 정의하면 워크로드를 실행하는 데 필요한 모든 리소스를 자동으로 프로비저닝할 수 있습니다. 이 유형의 프로세스를 사용하면 인프라를 보다 쉽게 관찰하고 반복할 수 있습니다. 또한 인프라에 테스트 기반 개발 방식을 적용할 수도 있습니다. 그러나 코드형 인프라 프로세스를 구현하기 위해서는 시간과 노력을 투자해야 하므로 마이그레이션을 계획할 때 이 점을 고려해야 합니다.

Cloud Deployment ManagerGoogle Cloud에서 인프라를 코드 프로세스로 구현하는 데 도움이 되는 도구입니다.

마이그레이션 4단계: 최적화

워크로드를 배포한 후에는 대상 환경을 최적화해야 합니다. 이 최적화 단계에서는 다음과 같은 교차 영역 활동을 통해 대상 환경을 최적화할 수 있습니다.

  • 팀 구성 및 교육
  • 모든 항목 모니터링
  • 모든 항목 자동화
  • 모든 항목 코드화
  • 자체 관리형 서비스 대신 관리형 서비스 사용
  • 성능 및 확장성 최적화
  • 비용 절감

팀 구성 및 교육

마이그레이션을 계획할 때는 개발 및 운영 팀이 새로운 클라우드 환경을 최대한 활용할 수 있도록 교육을 제공해야 합니다. 효과적인 교육이 제공된다면 팀의 효율성이 향상될 뿐만 아니라 최고의 클라우드 기반 도구와 서비스를 활용할 수도 있습니다. 교육 기회는 기술 인재를 유지하고 엔지니어가 Google Cloud의 모든 이점을 활용할 수 있도록 지원합니다.

이 단계에서는 이러한 팀을 관리하는 비즈니스 프로세스도 검토합니다. 이러한 프로세스에서 비효율적이거나 불필요한 부담이 확인되면 교육을 통해 개선하고 향상시킬 수 있습니다.

모든 항목 모니터링

모니터링은 환경에 있는 모든 요소가 예상대로 작동하는지 확인하고 환경, 관행, 프로세스를 개선하는 데 있어 핵심적 요소입니다.

환경을 프로덕션 트래픽에 노출하기 전에 환경 및 관련 구성요소(워크로드 포함)의 정확한 작동을 평가하는 데 중요한 측정항목을 정의하는 모니터링 시스템을 설계하고 구현하는 것이 좋습니다. 예를 들어 컨테이너화된 인프라를 배포한다면 Prometheus로 화이트박스 모니터링 시스템을 구현할 수 있습니다. 또는 Cloud Logging 및 Cloud Functions를 사용하여 IoT Core 기기를 모니터링할 수 있습니다.

Cloud Monitoring 알림과 같은 알림 시스템도 설정하는 것이 좋습니다. 이렇게 하면 사후 대응이 아닌 사전 예방이 가능합니다. 치명적 오류와 조건에 대한 경고를 설정해야 하지만, 사용자에게 직접적인 영향을 미치기 전 잠재적인 운영 중단 상황을 해결할 기회를 주는 경고도 설정해야 합니다.

그러면 Cloud Logging 로그의 보관 기간이 제한적이므로 장기 보관하기 위해 Cloud Monitoring 측정항목 로그를 내보내거나, 환경이 운영되고 개선을 계획하는 방법에 대한 유용한 정보를 얻기 위해 로그에서 추출한 측정항목에 대해 데이터 분석을 실행할 수 있습니다.

모든 항목 자동화

수동 작업은 더 높은 오류 위험에 노출되고 시간이 오래 걸립니다. 대부분의 경우 배포, 보안 비밀 교환, 구성 업데이트 등 중요한 활동을 자동화할 수 있습니다. 이렇게 자동화하면 비용과 시간을 절약하고 위험을 효과적으로 줄일 수 있습니다. 또한 팀은 반복적인 업무에 시간을 뺏기지 않고 보다 효율적인 업무에 집중할 수 있게 됩니다. Google Cloud에서의 자동화 예시로는 Cloud Composer로 인프라 자동화Google Kubernetes Engine에서 Spinnaker를 사용한 카나리아 분석 자동화가 있습니다.

모든 항목 코드화

Google Cloud에서 대상 환경을 프로비저닝할 때는 코드에서 가능한 많은 부분을 캡처해야 합니다. 코드형 인프라코드형 정책과 같은 프로세스를 구현하면 완전히 감사 가능하고 반복할 수 있는 환경을 구축할 수 있습니다. 또한 코드 이외의 측면에 테스트 기반 개발 방식을 적용하여 환경에 적용하려는 변경사항에 대한 즉각적인 피드백을 얻을 수 있습니다.

자체 관리형 서비스 대신 관리형 서비스 사용

Google Cloud에는 기본 서버 또는 인프라를 관리하지 않고도 사용할 수 있는 서비스 및 제품 포트폴리오가 있습니다. 최적화 단계에서 이러한 서비스를 사용하도록 워크로드를 확장하거나 기존 워크로드 중 일부를 이러한 서비스로 바꿀 수 있습니다.

관리형 서비스의 몇 가지 예시는 다음과 같습니다.

  • 자체 MySQL 클러스터 대신 MySQL용 Cloud SQL 사용
  • 자체 머신러닝 모델을 배포하고 유지관리하는 대신 AutoML을 사용하여 태그 및 이미지 분류
  • 자체 관리형 Kubernetes 클러스터를 사용하거나 VM을 컨테이너로 마이그레이션한 후 GKE에서 실행하는 대신 GKE에 워크로드 배포
  • 서버리스 웹 호스팅에 App Engine 사용

성능 및 확장성 최적화

클라우드로 마이그레이션하는 경우의 이점 중 하나는 리소스에 액세스할 수 있다는 것입니다. 기존 리소스를 강화하고, 필요에 따라 리소스를 추가할 수 있으며, 불필요한 리소스는 확장 가능한 방식으로 삭제할 수도 있습니다.

온프레미스 배포와 비교할 때 더 많은 성능 최적화 옵션을 사용할 수 있습니다.

비용 절감

Google Cloud는 비용 절감에 도움이 되는 다양한 도구와 가격 책정 옵션을 제공합니다.

예를 들어 Compute Engine 인스턴스를 프로비저닝했으면 해당 인스턴스에 대한 크기 조정 권장사항을 적용할 수 있습니다.

결제 금액을 줄이기 위해 결제 보고서를 분석하여 지출 동향을 파악하고 가장 자주 사용하는 Google Cloud 제품을 확인할 수 있습니다. 결제 데이터를 BigQuery로 내보내거나 파일로 내보내 분석할 수도 있습니다.

비용을 더 줄이기 위해 Compute Engine 결제에 자동으로 할인을 적용하는 지속 사용 할인과 같은 기능을 Google Cloud에서 사용 설정할 수 있습니다. Compute Engine 인스턴스에 대한 할인을 받기 위해 약정 사용 계약을 구매할 수도 있으며 BigQuery의 경우에는 정액제 가격으로 가입할 수도 있습니다. Google Cloud 자동 확장 기능을 사용하면 클라이언트 요청에 따라 리소스의 규모를 축소하여 요금을 줄일 수 있고 Cloud Monitoring 및 Cloud Logging 사용을 최적화하여 모니터링 및 로깅 비용을 줄일 수도 있습니다.

도움 받기

Google Cloud는 Google Cloud 서비스를 최적으로 활용하는 데 필요한 도움과 지원을 받을 수 있는 다양한 옵션과 리소스를 제공합니다.

셀프서비스 자료실

전담 지원이 필요하지 않은 경우에는 다음과 같은 셀프서비스 자료를 사용할 수 있습니다.

  • 문서. Google Cloud는 각 제품과 서비스, API에 대한 문서를 제공합니다. 마이그레이션에 대한 자세한 내용은 Google Cloud 마이그레이션 센터를 참조하세요.
  • 도구. Google Cloud는 마이그레이션에 도움이 되는 여러 제품과 서비스를 제공합니다. 예를 들면 다음과 같습니다.
    • Migrate for Compute Engine은 온프레미스 및 클라우드 환경의 물리적 서버와 가상 머신을 Google Cloud로 마이그레이션할 때 사용하는 제품입니다. Migrate for Compute Engine을 사용하면 백그라운드에서 데이터가 복사되지만 가상 머신이 완전히 작동할 때 몇 분 내에 Google Cloud로 마이그레이션할 수 있습니다.
    • gsutil 명령줄 도구, Cloud Storage JSON API 또는 Cloud Console을 사용하여 Cloud Storage로 온라인 전송.
    • Storage Transfer Service를 사용하면 다른 클라우드 제공업체, 온라인 리소스, 로컬 데이터에서 Cloud Storage로 데이터를 가져올 수 있습니다.
    • Transfer Appliance는 비즈니스 운영 중단 없이 수백 테라바이트에서 최대 1페타바이트까지 대량의 데이터를 Google Cloud로 마이그레이션할 때 사용할 수 있는 하드웨어 어플라이언스입니다.
    • BigQuery Data Transfer Service는 Software as a service 앱에서 BigQuery로 정해진 일정에 따라 관리형으로 데이터 이동을 자동화합니다.
  • 백서. 이러한 백서에는 참조 아키텍처, 우수사례, 권장사항, 고급 가이드가 포함됩니다.
  • 미디어 콘텐츠. Google Cloud 팟캐스트를 듣거나 Google Cloud YouTube 채널에있는 동영상을 감상할 수 있습니다. 이러한 리소스는 제품 설명부터 개발 전략에 이르기까지 폭넓은 주제를 다룹니다.
  • 온라인 과정 및 실무형 실습 참여. Google Cloud는 Coursera에 동영상 콘텐츠, 읽기 자료, 실무형 실습을 비롯한 다양한 과정을 제공합니다. 또한 Qwiklabs를 사용하여 실무형 실습에 참여하거나 실시간 온라인 클래스에 참여할 수도 있습니다.

기술 파트너

Google Cloud는 여러 회사와의 제휴를 통해 제품 사용을 지원합니다. 일부 제품은 무료로 사용할 수 있으니 관련 내용을 회사나 담당 Google Cloud 계정 관리자에게 문의하세요.

이러한 제품에는 다음이 포함됩니다.

시스템 통합업체

Google Cloud는 제품 및 기술 회사뿐만 아니라 실무형 지원을 제공할 수 있는 시스템 통합업체와도 제휴합니다. 파트너 목록에서 클라우드 마이그레이션 전문 시스템 통합업체 목록을 확인할 수 있습니다.

Google Cloud 전문 서비스

Google의 전문 서비스팀은 Google Cloud 투자를 최대한 효과적으로 활용할 수 있도록 지원해 드립니다.

클라우드 계획 및 기초: 마이그레이션 도움 받기

전문 서비스 팀은 마이그레이션을 계획하고 클라우드 계획 및 기초 제품을 사용하여 프로덕션 환경에 워크로드를 배포할 수 있도록 지원해 드립니다. 이러한 전문가들은 Google Cloud 기초 설정부터 고유한 워크로드 요구사항에 맞는 플랫폼 최적화 및 워크로드 배포에 이르기까지 워크로드를 프로덕션 환경으로 마이그레이션하는 각 단계를 안내합니다.

클라우드 계획 및 기초의 목표는 다음과 같습니다.

  • Google Cloud 기초 설정
  • 설계 문서 작성
  • 배포 및 마이그레이션 작업 계획
  • 워크로드를 프로덕션 환경에 배포
  • 문제 및 위험성 추적

전문 서비스 팀은 다음과 같은 활동 및 결과물을 팀에 안내합니다.

  1. 기술 킥오프 워크숍 실시
  2. 기술 설계 문서 작성
  3. 마이그레이션 계획 수립
  4. 프로그램 차터 작성
  5. 프로젝트 관리 제공
  6. 기술 전문 지식 제공

Cloud Sprint: Google Cloud로의 마이그레이션 가속화

Cloud Sprint는 Google Cloud로의 앱 마이그레이션 속도를 높이는 집중 실습 워크숍입니다. 이 워크숍에서 Google Cloud 전문 서비스는 대화형 토론, 화이트보드 세션, 대상 앱 검토를 통해 한 팀의 Google Cloud로의 마이그레이션을 지도합니다. Cloud Sprint 중에는 전문 서비스가 개발팀 팀원들과 협력하여 향후 Google Cloud 마이그레이션을 위한 다음 단계를 이해하는 데 도움이 되는 배포 활동을 통해 클라우드 솔루션을 직접 경험할 수 있도록 지원합니다.

교육: 팀의 기술 개발

Google Cloud 전문 서비스는 팀의 요구에 따라 현장 교육을 제공할 수 있습니다.

다음 단계