관리형 컨테이너 런타임 환경 선택

Last reviewed 2024-08-30 UTC

이 문서에서는 기술적 및 조직적 고려사항에 따라 애플리케이션 요구사항을 평가하고 Cloud Run과 Google Kubernetes Engine (GKE) Autopilot 중에서 선택하는 데 도움이 됩니다. 이 문서는 워크로드에 사용할 Google Cloud 타겟 컨테이너 런타임 환경을 선택해야 하는 클라우드 아키텍트를 대상으로 합니다. 이 튜토리얼에서는 사용자가 Kubernetes 및 Google Cloud에 익숙하고 Cloud Run, Cloud Run 함수, AWS Lambda와 같은 클라우드 서버리스 런타임 환경에 대해 어느 정도 알고 있다고 가정합니다.

Google Cloud는 다양한 기능을 갖춘 여러 런타임 환경 옵션을 제공합니다. 다음 다이어그램은 Google Cloud 관리형 제품의 범위를 보여줍니다.

관리 수준이 가장 높은 Google Cloud 제품부터 가장 낮은 Google Cloud 제품까지

다이어그램에 표시된 항목은 다음과 같습니다.

  • 가장 관리가 많은 런타임 환경 (이 가이드의 초점):

    이러한 옵션은 Google에서 관리하며 사용자는 기본 컴퓨팅 인프라를 관리할 수 없습니다.

  • 최소 관리 런타임 환경:

    • 엔터프라이즈 워크로드에 최적화되어 있으며 최대 15,000개 노드의 단일 클러스터 확장성을 제공하는 GKE Standard
    • 머신러닝 (ML) 및 고성능 컴퓨팅 (HPC) 워크로드용 가속기 최적화 A3 가상 머신 계열이 포함된 Compute Engine

    이러한 옵션에는 컴퓨팅 기능의 기반이 되는 가상 머신 (VM)과 같은 어느 정도의 사용자 수준 인프라 관리가 필요합니다. GKE Standard의 VM은 Kubernetes 클러스터 노드입니다. Compute Engine의 VM은 요구사항에 맞게 맞춤설정할 수 있는 핵심 플랫폼 제품입니다.

이 가이드를 통해 가장 관리가 잘되는 런타임 환경인 Cloud Run과 GKE Autopilot 중에서 선택할 수 있습니다. Google Cloud 런타임 환경에 관한 자세한 내용은 Google Cloud 애플리케이션 호스팅 옵션 가이드를 참고하세요.

환경 개요

이 섹션에서는 Cloud Run 및 GKE Autopilot 기능을 간략히 설명합니다. Cloud Run과 GKE Autopilot은 모두 Google Cloud 내에서 긴밀하게 통합되어 있으므로 두 가지 사이에는 많은 공통점이 있습니다. 두 플랫폼 모두 Google의 안정적이고 확장 가능한 부하 분산 서비스를 통해 여러 부하 분산 옵션을 지원합니다. 또한 더 세분화된 비공개 네트워킹이 필요한 경우 VPC 네트워킹, Identity-Aware Proxy (IAP), Google Cloud Armor도 모두 지원합니다. 두 플랫폼 모두 애플리케이션에 사용하는 정확한 리소스에 대해서만 비용을 청구합니다.

소프트웨어 제공 관점에서 컨테이너 런타임 환경인 Cloud Run 및 GKE Autopilot은 Google Cloud 컨테이너 생태계를 구성하는 서비스에서 지원됩니다. 이러한 서비스에는 애플리케이션을 프로덕션에 안전하고 안정적으로 배포할 수 있도록 지원하는 Cloud Build, Artifact Registry, Binary Authorization, Cloud Deploy를 통한 지속적 배포가 포함됩니다. 즉, 개발자와 개발팀이 빌드 및 배포 결정을 소유합니다.

두 플랫폼 간의 공통점으로 인해 GKE와 Cloud Run 함께 사용 가이드에 설명된 대로 애플리케이션을 배포할 위치에 유연한 접근 방식을 채택하여 각 플랫폼의 장점을 활용하는 것이 좋습니다. 다음 섹션에서는 Cloud Run 및 Autopilot의 고유한 측면을 설명합니다.

Cloud Run

Cloud Run은 Google의 확장 가능한 인프라에서 직접 애플리케이션을 실행할 수 있게 해주는 서버리스 관리형 컴퓨팅 플랫폼입니다. Cloud Run은 두 가지 주요 애플리케이션 유형에 자동화 및 확장을 제공합니다.

  • Cloud Run 서비스: 웹 요청에 응답하는 코드용입니다.
  • Cloud Run 작업: 하나 이상의 백그라운드 작업을 실행한 후 작업이 완료되면 종료되는 코드에 사용합니다.

Cloud Run은 이러한 두 가지 배포 모델을 통해 다양한 애플리케이션 아키텍처를 지원하는 동시에 권장사항을 사용 설정하고 개발자가 코드에 집중할 수 있도록 합니다.

Cloud Run은 다음 소스에서 애플리케이션 코드 배포도 지원합니다.

  • 개별 경량 함수
  • 소스 코드의 전체 애플리케이션
  • 컨테이너화된 애플리케이션

Cloud Run은 사전 빌드된 컨테이너 런타임 기능과 함께 FaaS와 소스에서 빌드하는 기능을 모두 지원하는 빌드 및 배포 기능을 통합합니다. 이러한 방식으로 Cloud Run을 사용하면 실행할 애플리케이션 컨테이너 이미지를 빌드 및 배포하는 단계가 완전히 자동화되며 맞춤 구성이 필요하지 않습니다.

GKE Autopilot

GKE Autopilot은 GKE의 기본 클러스터 작업 모드이며 권장됩니다. Autopilot을 사용하면 인프라 관리에 따른 오버헤드 없이 Kubernetes에서 애플리케이션을 실행할 수 있습니다. Autopilot을 사용하면 Google에서 노드 프로비저닝 및 확장, 기본 보안 상태, 기타 사전 구성된 설정을 포함하여 클러스터 구성의 기본적인 측면을 관리합니다. Autopilot에서 노드 리소스를 관리하므로 워크로드에서 요청한 리소스에 대해서만 비용을 지불합니다. Autopilot은 인프라 리소스를 지속적으로 모니터링하고 최적화하여 최적의 리소스를 제공하는 동시에 워크로드에 SLA를 제공합니다.

GKE Autopilot은 Cloud Run에 적합하지 않을 수 있는 워크로드를 지원합니다. 예를 들어 GKE Autopilot은 일반적으로 장기 실행 워크로드 또는 스테이트풀 워크로드를 지원합니다.

런타임 환경 선택

일반적으로 워크로드의 특성이 관리형 플랫폼에 적합한 경우 Cloud Run의 서버리스 런타임 환경이 이상적입니다. Cloud Run을 사용하면 관리해야 할 인프라와 자체 관리 구성이 줄어들고 운영 오버헤드가 줄어듭니다. Kubernetes를 구체적으로 원하거나 필요하지 않다면 먼저 서버리스를 대상 런타임 환경으로 고려하는 것이 좋습니다. Kubernetes는 개방형 플랫폼의 강력한 추상화를 제공하지만 이를 사용하면 복잡성이 증가합니다. Kubernetes가 필요하지 않은 경우 애플리케이션이 서버리스에 적합한지 고려하는 것이 좋습니다. 워크로드가 서버리스에 적합하지 않은 기준이 있는 경우 Autopilot을 사용하는 것이 좋습니다.

다음 섹션에서는 이러한 질문에 답하는 데 도움이 되는 몇 가지 기준, 특히 워크로드가 서버리스에 적합한지 여부에 관한 기준을 자세히 설명합니다. 앞의 섹션에 설명된 Autopilot과 Cloud Run의 공통점을 고려할 때 기술적 또는 기타 차단 요소가 없는 경우 플랫폼 간에 마이그레이션하는 것은 간단한 작업입니다. 마이그레이션 옵션을 자세히 알아보려면 Cloud Run에서 GKE로 마이그레이션 및 Kubernetes에서 Cloud Run으로 마이그레이션을 참고하세요.

워크로드에 맞는 런타임 환경을 선택할 때는 기술적 고려사항과 조직적 고려사항을 고려해야 합니다. 기술적 고려사항은 애플리케이션 또는 Google Cloud 런타임 환경의 특성입니다. 조직적 고려사항은 조직 또는 팀의 기술 외 특성으로, 결정에 영향을 미칠 수 있습니다.

기술적 고려사항

플랫폼 선택에 영향을 미치는 몇 가지 기술적 고려사항은 다음과 같습니다.

  • 제어 및 구성 가능성: 실행 환경의 제어 세부사항
  • 네트워크 트래픽 관리 및 라우팅: 네트워크를 통한 상호작용의 구성 가능성
  • 수평 및 수직 확장성: 동적으로 용량을 늘리거나 줄일 수 있습니다.
  • 스테이트풀(Stateful) 애플리케이션 지원: 영구 상태를 저장하는 기능
  • CPU 아키텍처: 다양한 CPU 유형을 지원합니다.
  • 가속기 오프로드 (GPU 및 TPU): 전용 하드웨어로 계산을 오프로드하는 기능입니다.
  • 메모리, CPU, 기타 리소스 용량이 높음: 소비되는 다양한 리소스의 수준입니다.
  • Kubernetes에 대한 명시적 종속 항목: Kubernetes API 사용에 관한 요구사항입니다.
  • 멀티테넌시를 위한 복잡한 RBAC: 풀링된 리소스 공유를 지원합니다.
  • 최대 컨테이너 작업 시간 초과 시간: 장기 실행 애플리케이션 또는 구성요소의 실행 시간입니다.

다음 섹션에서는 런타임 환경을 선택하는 데 도움이 되는 이러한 기술적 고려사항을 자세히 설명합니다.

제어 및 구성 가능성

Cloud Run에 비해 GKE Autopilot은 워크로드의 실행 환경을 더 세부적으로 제어할 수 있습니다. Kubernetes는 포드 컨텍스트 내에서 애플리케이션 요구사항을 충족하도록 조정할 수 있는 구성 가능한 기본 요소를 많이 제공합니다. 구성 옵션에는 권한 수준, 서비스 품질 매개변수, 컨테이너 수명 주기 이벤트의 맞춤 핸들러, 여러 컨테이너 간의 프로세스 네임스페이스 공유가 포함됩니다.

Cloud Run은 Cloud Run 서비스 객체 참조 YAML 및 Cloud Run 작업 객체 참조 YAML에 설명된 Kubernetes Pod API 노출 영역의 하위 집합을 직접 지원합니다. 이 참조 가이드를 사용하면 애플리케이션 요구사항과 함께 두 플랫폼을 평가할 수 있습니다.

Cloud Run 실행 환경의 컨테이너 계약은 비교적 간단하며 대부분의 제공 워크로드에 적합합니다. 그러나 계약에는 충족해야 하는 몇 가지 요구사항이 명시되어 있습니다. 애플리케이션이나 종속 항목이 이러한 요구사항을 충족할 수 없거나 실행 환경을 더 세부적으로 제어해야 하는 경우 Autopilot이 더 적합할 수 있습니다.

구성 및 관리에 소비하는 시간을 줄이려면 Cloud Run을 런타임 환경으로 선택하는 것이 좋습니다. Cloud Run은 Autopilot보다 구성 옵션이 적으므로 개발자 생산성을 극대화하고 운영 오버헤드를 줄이는 데 도움이 됩니다.

네트워크 트래픽 관리 및 라우팅

Cloud Run과 GKE Autopilot은 모두 Google Cloud Load Balancing과 통합됩니다. 그러나 GKE Autopilot은 서비스 간 통신을 위한 네트워킹 환경을 구성하기 위한 다양하고 강력한 프리미티브 집합도 제공합니다. 구성 옵션에는 클러스터 내에서 namespaces 및 네트워크 정책, 포트 재매핑, 기본 제공 DNS 서비스 검색을 사용하여 네트워크 레이어에서 세분화된 권한과 분리를 제공하는 기능이 포함됩니다. 또한 GKE Autopilot은 구성이 쉽고 유연한 Gateway API를 지원합니다. 이 기능은 클러스터의 서비스 간에 트래픽이 라우팅되는 방식을 강력하게 제어합니다.

Autopilot은 구성하기가 쉽기 때문에 네트워킹 상호 종속성이 높은 여러 서비스가 있거나 애플리케이션 구성요소 간에 트래픽이 라우팅되는 방식에 관한 복잡한 요구사항이 있는 경우 최적의 옵션이 될 수 있습니다. 이 패턴의 예는 상호의존의 복잡한 패턴을 가진 수많은 마이크로서비스로 분해된 분산 애플리케이션입니다. 이러한 시나리오에서는 Autopilot 네트워킹 구성 옵션을 사용하여 서비스 간의 상호작용을 관리하고 제어할 수 있습니다.

수평 및 수직 확장성

Cloud Run과 GKE Autopilot은 모두 서비스 및 작업의 수동 및 자동 수평 확장을 지원합니다. 수평 확장은 필요할 때 처리 성능을 높이고 필요하지 않을 때는 추가된 처리 성능을 삭제합니다. 일반적인 워크로드의 경우 Cloud Run은 일반적으로 GKE Autopilot보다 더 빠르게 확장하여 초당 요청 수가 급증하는 상황에 대응할 수 있습니다. 예를 들어 동영상 데모 '서버리스 컴퓨팅의 새로운 기능' Cloud Run이 0에서 10,000개가 넘는 인스턴스로 약 10초 만에 확장되는 모습을 보여줍니다. Autopilot을 사용하면 추가 비용으로 Kubernetes에서 수평 확장 속도를 높일 수 있습니다. 이를 통해 추가 컴퓨팅 용량을 프로비저닝할 수 있습니다.

애플리케이션에서 인스턴스를 더 추가하여 사용 가능한 리소스 수준을 높이는 방식으로 확장할 수 없는 경우 Autopilot이 더 적합할 수 있습니다. Autopilot은 수직 확장을 지원하여 애플리케이션의 실행 인스턴스 수를 늘리지 않고도 사용 가능한 처리 성능의 양을 동적으로 변경합니다.

Cloud Run은 애플리케이션이 사용되지 않을 때 애플리케이션을 0으로 자동으로 확장할 수 있으므로 비용 최적화에 중점을 둔 특정 사용 사례에 유용합니다. 애플리케이션을 0으로 확장할 수 있는 방식의 특성으로 인해 요청이 도착한 시점과 애플리케이션이 실행되고 요청을 처리할 수 있는 시점 사이의 시간을 최소화하기 위해 취할 수 있는 여러 최적화 단계가 있습니다.

스테이트풀(Stateful) 애플리케이션 지원

Autopilot은 자체 관리형 데이터베이스를 비롯한 다양한 스테이트풀 배포를 실행할 수 있는 영구 디스크로 지원되는 완전한 Kubernetes 볼륨 지원을 제공합니다. Cloud Run과 GKE Autopilot 모두 Filestore 및 Cloud Storage 버킷과 같은 다른 서비스에 연결할 수 있습니다. 또한 두 가지 모두 Cloud Storage FUSE를 사용하여 객체 저장소 버킷을 파일 시스템에 마운트하는 기능을 포함합니다.

Cloud Run은 메모리 내 파일 시스템을 사용하므로 영구 로컬 파일 시스템이 필요한 애플리케이션에는 적합하지 않을 수 있습니다. 또한 로컬 인메모리 파일 시스템은 애플리케이션의 메모리와 공유됩니다. 따라서 임시 파일 시스템과 애플리케이션 및 컨테이너 메모리 사용량 모두 메모리 한도를 초과하는 데 기여합니다. 크기 제한이 있는 전용 인메모리 볼륨을 사용하는 경우 이 문제를 방지할 수 있습니다.

Cloud Run 서비스 또는 작업 컨테이너에는 최대 작업 제한 시간이 있습니다. Autopilot 클러스터의 포드 내에서 실행되는 컨테이너는 포드 중단 예산 (PDB)으로 구성된 제약 조건에 따라 일정을 변경할 수 있습니다. 그러나 노드 자동 업그레이드 또는 축소 이벤트로 인한 제거로부터 보호되는 경우 포드는 최대 7일 동안 실행될 수 있습니다. 일반적으로 태스크 제한 시간은 Cloud Run의 일괄 워크로드에서 고려해야 할 가능성이 더 큽니다. 장기 실행 워크로드와 최대 작업 기간 내에 완료할 수 없는 일괄 작업의 경우 Autopilot이 가장 적합한 옵션일 수 있습니다.

CPU 아키텍처

모든 Google Cloud 컴퓨팅 플랫폼은 x86 CPU 아키텍처를 지원합니다. Cloud Run은 ARM 아키텍처 프로세서를 지원하지 않지만 Autopilot은 ARM 아키텍처에서 지원하는 관리형 노드를 지원합니다. 워크로드에 Arm 아키텍처가 필요한 경우 Autopilot을 사용해야 합니다.

가속기 오프로드

Autopilot은 예약된 리소스를 사용할 수 있는 기능을 비롯하여 GPU 사용 및 TPU 사용을 지원합니다. Cloud Run은 일부 제한사항이 있는 GPU 사용을 지원합니다.

메모리, CPU, 기타 리소스 요구사항이 높음

단일 Cloud Run 서비스 또는 작업 (단일 인스턴스)에서 사용할 수 있는 최대 CPU 및 메모리 리소스는 GKE Autopilot 리소스 요청 한도에 비해 제한적입니다. 워크로드의 특성에 따라 Cloud Run에는 사용 가능한 리소스를 제한하는 다른 한도가 있을 수 있습니다. 예를 들어 Cloud Run에서는 시작 시간 제한과 아웃바운드 연결 최대 수가 제한될 수 있습니다. Autopilot을 사용하면 일부 제한사항이 적용되지 않거나 허용되는 값이 더 높을 수 있습니다.

Kubernetes에 대한 명시적 종속 항목

일부 애플리케이션, 라이브러리 또는 프레임워크에는 Kubernetes에 대한 명시적 종속 항목이 있을 수 있습니다. Kubernetes 종속 항목은 다음 중 하나로 인해 발생할 수 있습니다.

  1. 애플리케이션 요구사항 (예: 애플리케이션이 Kubernetes API를 호출하거나 Kubernetes 커스텀 리소스를 사용함)
  2. 애플리케이션을 구성하거나 배포하는 데 사용되는 도구의 요구사항 (예: Helm)
  3. 서드 파티 크리에이터 또는 공급업체의 지원 요구사항

이러한 시나리오에서는 Cloud Run이 Kubernetes를 지원하지 않으므로 Autopilot이 타겟 런타임 환경입니다.

멀티테넌시를 위한 복잡한 RBAC

조직에 특히 복잡한 조직 구조 또는 다중 테넌시 요구사항이 있는 경우 Autopilot을 사용하여 Kubernetes의 역할 기반 액세스 제어 (RBAC)를 활용하세요. 더 간단한 방법으로 Cloud Run에 내장된 보안 및 분리 기능을 사용할 수 있습니다.

조직 고려사항

다음은 환경 선택에 영향을 미치는 몇 가지 조직적 고려사항입니다.

  • 광범위한 기술 전략: 조직의 기술 방향입니다.
  • Kubernetes 생태계 활용: OSS 커뮤니티 활용에 관심이 있음
  • 기존 내부 도구: 기존에 특정 도구를 사용하고 있습니다.
  • 개발팀 프로필: 개발자 기술 및 경험
  • 운영 지원: 운영팀의 기능 및 중점사항

다음 섹션에서는 환경을 선택하는 데 도움이 되는 이러한 조직적 고려사항을 자세히 설명합니다.

광범위한 기술 전략

조직이나 팀에서 특정 기술을 다른 기술보다 우선하는 전략에 동의했을 수 있습니다. 예를 들어 팀에 서버리스 또는 Kubernetes 중 가능한 경우 표준화하기로 한 합의가 있는 경우, 이 합의는 타겟 런타임 환경에 영향을 미치거나 지시할 수도 있습니다.

특정 워크로드가 전략에 지정된 런타임 환경에 적합하지 않은 경우 다음 중 하나 이상을 다음과 같은 주의사항과 함께 실행할 수 있습니다.

  • 워크로드 재구성 그러나 워크로드가 적합하지 않으면 성능, 비용, 보안 또는 기타 특성이 최적화되지 않을 수 있습니다.
  • 워크로드를 전략적 방향의 예외로 등록합니다. 그러나 예외를 과도하게 사용하면 이질적인 기술 포트폴리오가 생성될 수 있습니다.
  • 전략을 재고합니다. 하지만 이렇게 하면 진행을 방해하거나 차단할 수 있는 정책 오버헤드가 발생할 수 있습니다.

Kubernetes 생태계 활용

앞서 설명한 광범위한 기술 전략의 일환으로 조직 또는 팀은 성장하는 대규모 생태계로 인해 Kubernetes를 선택할 수 있습니다. 이 선택은 이전 섹션 Kubernetes에 대한 명시적 종속 항목에 설명된 대로 기술적 애플리케이션 종속 항목으로 인해 Kubernetes를 선택하는 것과 다릅니다. Kubernetes 생태계를 사용하는 경우 활발한 커뮤니티, 풍부한 서드 파티 도구, 강력한 표준 및 이식성을 중시합니다. Kubernetes 생태계를 활용하면 개발 속도를 높이고 TTM(time to market)을 줄일 수 있습니다.

기존 사내 도구

경우에 따라 조직 또는 팀에서 기존 도구 생태계를 사용하는 것이 유용할 수 있습니다 (모든 환경에 해당). 예를 들어 Kubernetes를 사용하는 경우 ArgoCD와 같은 배포 도구, Gatekeeper와 같은 보안 및 정책 도구, Helm과 같은 패키지 관리를 계속 사용할 수 있습니다. 기존 도구에는 조직 규정 준수 자동화에 관한 기존 규칙과 대체 타겟 환경에 구현하는 데 비용이 많이 들거나 긴 리드 타임이 필요한 기타 기능이 포함될 수 있습니다.

개발팀 프로필

애플리케이션 또는 워크로드 팀은 Kubernetes에 대한 이전 경험이 있어 Autopilot을 제공하는 팀의 속도와 기능을 가속화할 수 있습니다. 팀이 새 런타임 환경에 숙련되기까지 시간이 걸릴 수 있습니다. 운영 모델에 따라 업스킬링 기간 동안 플랫폼 신뢰성이 저하될 수 있습니다.

성장하는 팀의 경우 채용 능력이 조직의 플랫폼 선택에 영향을 줄 수 있습니다. 일부 시장에서는 Kubernetes 기술이 부족하여 채용 프리미엄이 적용될 수 있습니다. Cloud Run과 같은 환경을 선택하면 채용 절차를 간소화하고 예산 범위 내에서 팀을 더 빠르게 확장할 수 있습니다.

운영 지원

런타임 환경을 선택할 때는 SRE, DevOps, 플랫폼팀, 기타 운영팀의 경험과 역량을 고려하세요. 운영팀이 프로덕션 환경을 효과적으로 지원하는 기능은 안정성 관점에서 매우 중요합니다. 또한 운영팀이 사전 프로덕션 환경을 지원하여 다운타임, 수동 프로세스 사용, 번거로운 배포 메커니즘으로 인해 개발자 속도가 저하되지 않도록 하는 것도 중요합니다.

Kubernetes를 사용하는 경우 중앙 운영팀 또는 플랫폼 엔지니어링팀에서 Autopilot Kubernetes 업그레이드를 처리할 수 있습니다. 업그레이드는 자동으로 진행되지만 운영팀에서는 일반적으로 워크로드 중단을 최소화하기 위해 업그레이드를 면밀히 모니터링합니다. 일부 조직에서는 제어 영역 버전을 수동으로 업그레이드합니다. 또한 GKE Enterprise에는 여러 클러스터에서 애플리케이션 관리를 간소화하고 간소화하는 기능이 포함되어 있습니다.

Autopilot과 달리 Cloud Run은 지속적인 관리 오버헤드나 제어 영역 업그레이드가 필요하지 않습니다. Cloud Run을 사용하면 운영 프로세스를 간소화할 수 있습니다. 단일 런타임 환경을 선택하면 운영 프로세스를 더욱 간소화할 수 있습니다. 여러 런타임 환경을 사용하기로 선택한 경우 팀에 이러한 런타임 환경을 지원할 수 있는 역량, 기능, 관심이 있는지 확인해야 합니다.

선택

선택 절차를 시작하려면 다양한 이해관계자와 논의하세요. 각 애플리케이션에 대해 개발자, 운영팀, 중앙 기술 거버넌스 그룹의 대표, 내부 애플리케이션 사용자 및 소비자, 보안, 클라우드 금융 최적화팀, 조직 내 관련성이 높은 기타 역할 또는 그룹으로 구성된 작업 그룹을 구성합니다. 정보 수집 설문조사를 배포하여 애플리케이션 특성을 수집하고 세션 전에 결과를 공유할 수 있습니다. 필요한 이해관계자만 포함된 소규모 작업 그룹을 선택하는 것이 좋습니다. 모든 상담사가 모든 작업 세션에 참여하지 않아도 될 수 있습니다.

Autopilot 또는 Cloud Run 또는 둘 다에서 애플리케이션을 빌드하고 실행한 경험이 있는 다른 팀 또는 그룹의 담당자를 포함하는 것도 유용할 수 있습니다. 이 문서의 기술적 및 조직적 고려사항을 사용하여 대화를 안내하고 각 잠재적 플랫폼에 대한 애플리케이션의 적합성을 평가하세요.

몇 개월이 지난 후 새 환경에 애플리케이션을 배포한 결과에 따라 결정을 확인하거나 재검토할 수 있도록 체크인을 예약하는 것이 좋습니다.

다음 단계

참여자

저자: 헨리 벨 | 클라우드 솔루션 설계자

기타 참여자: