이 문서는 기술적 및 조직적 고려사항에 따라 애플리케이션 요구사항을 평가하고 Cloud Run과 Google Kubernetes Engine(GKE) Autopilot 중에서 선택하는 데 도움이 됩니다. 이 문서는 워크로드에 사용할 Google Cloud 대상 컨테이너 런타임 환경을 선택해야 하는 클라우드 설계자를 대상으로 합니다. 여기서는 사용자가 Kubernetes 및 Google Cloud에 익숙하고 Cloud Run, Cloud Run Functions 또는 AWS Lambda와 같은 클라우드 서버리스 런타임 환경에 대해 어느 정도 알고 있다고 가정합니다.
Google Cloud는 다양한 기능을 갖춘 여러 런타임 환경 옵션을 제공합니다. 다음 다이어그램은 Google Cloud 관리형 제품의 범위를 보여줍니다.
다이어그램에 표시된 항목은 다음과 같습니다.
가장 높은 수준으로 관리되는 런타임 환경(이 가이드에서 중점적으로 설명할 환경):
이러한 옵션은 Google에서 관리하며 기본 컴퓨팅 인프라를 사용자가 관리할 수 없습니다.
가장 낮은 수준으로 관리되는 런타임 환경:
- GKE Standard - 엔터프라이즈 워크로드에 최적화되어 있으며 최대 단일 클러스터를 15,000개 노드까지 확장할 수 있습니다.
- Compute Engine - 머신러닝(ML) 및 고성능 컴퓨팅(HPC) 워크로드를 위한 가속기 최적화 A3 가상 머신 제품군이 포함되어 있습니다.
이러한 옵션은 컴퓨팅 기능의 기반이 되는 가상 머신(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은 일반적으로 장기 실행 워크로드 또는 스테이트풀(Stateful) 워크로드를 지원합니다.
런타임 환경 선택
일반적으로 워크로드의 특성이 관리형 플랫폼에 적합한 경우 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: 풀링된 리소스 공유를 지원합니다.
- 최대 컨테이너 태스크 제한 시간: 장기 실행 애플리케이션 또는 구성요소의 실행 시간입니다.
다음 섹션에서는 런타임 환경을 선택하는 데 도움이 되는 이러한 기술적 고려사항을 자세히 설명합니다.
제어 및 구성 가능성
GKE Autopilot은 Cloud Run보다 워크로드의 실행 환경을 더 세부적으로 제어할 수 있습니다. 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은 서비스 간 통신을 위한 네트워킹 환경을 구성하는 데 필요한 다양하고 강력한 프리미티브 집합도 제공합니다. 구성 옵션에는 네트워크 계층에서 네임스페이스 및 네트워크 정책을 사용하여 세분화된 권한과 분리, 포트 재매핑, 클러스터 내에 기본 제공되는 DNS 서비스 검색이 포함됩니다. 또한 GKE Autopilot은 고도로 구성 가능하고 유연한 Gateway API를 지원합니다. 이 기능은 클러스터의 서비스 간에 트래픽이 라우팅되는 방식을 강력하게 제어합니다.
Autopilot은 고도로 구성 가능하기 때문에 네트워킹 상호 종속성이 높은 서비스가 여러 개 있거나 애플리케이션 구성요소 간에 트래픽이 라우팅되는 방식에 관한 복잡한 요구사항이 있는 경우 최적의 옵션이 될 수 있습니다. 이 패턴의 예로는 수많은 마이크로서비스로 분해되어 상호의존성 패턴이 복잡한 분산 애플리케이션이 있습니다. 이러한 시나리오에서는 Autopilot 네트워킹 구성 옵션을 사용하여 서비스 간의 상호작용을 관리하고 제어할 수 있습니다.
수평 및 수직 확장성
Cloud Run과 GKE Autopilot은 모두 서비스 및 작업의 수동 및 자동 수평 확장을 지원합니다. 수평 확장은 필요할 때 처리 역량을 높이고 필요하지 않을 때는 추가된 처리 역량을 없앱니다. 일반적인 워크로드에서 Cloud Run은 일반적으로 GKE Autopilot보다 더 빠르게 수평 확장하여 초당 요청 수가 급증하는 상황에 대응할 수 있습니다. 예를 들어 동영상 데모 '서버리스 컴퓨팅의 새로운 기능'은 Cloud Run가 약 10초 만에 0개 인스턴스에서 10,000개가 넘는 인스턴스로 확장되는 모습을 보여줍니다. Autopilot의 경우 추가 비용으로 Kubernetes의 수평 확장 속도를 높이기 위해 추가 컴퓨팅 용량을 프로비저닝할 수 있습니다.
애플리케이션에서 인스턴스를 더 추가하여 사용 가능한 리소스 수준을 높이는 방식으로 확장할 수 없는 경우 Autopilot이 더 적합할 수 있습니다. Autopilot은 애플리케이션의 실행 인스턴스 수를 늘리지 않고도 사용 가능한 처리 역량의 양을 동적으로 변경하는 수직 확장을 지원합니다.
Cloud Run은 애플리케이션이 사용되지 않을 때 애플리케이션을 복제본 0개로 자동으로 축소할 수 있으므로 비용 최적화에 특별히 중점을 둔 특정 사용 사례에 유용합니다. 애플리케이션이 0으로 축소되는 방식의 특성으로 인해 요청이 도착한 시점과 애플리케이션이 실행되고 요청을 처리할 수 있는 시점 사이의 시간을 최소화하기 위해 수행할 수 있는 여러 최적화 단계가 있습니다.
스테이트풀(Stateful) 애플리케이션 지원
Autopilot은 자체 관리형 데이터베이스를 비롯한 다양한 스테이트풀(Stateful) 배포를 실행할 수 있는 Persistent Disk가 지원되는 완전한 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 종속 항목은 다음 중 하나로 인해 발생할 수 있습니다.
- 애플리케이션 요구사항(예: 애플리케이션이 Kubernetes API를 호출하거나 Kubernetes 커스텀 리소스를 사용함)
- 애플리케이션을 구성하거나 배포하는 데 사용되는 도구의 요구사항(예: Helm)
- 서드 파티 크리에이터 또는 공급업체의 지원 요구사항
이러한 시나리오에서는 Cloud Run이 Kubernetes를 지원하지 않으므로 Autopilot이 대상 런타임 환경입니다.
멀티테넌시를 위한 복잡한 RBAC
조직에 특히 복잡한 조직 구조 또는 멀티테넌시 요구사항이 있는 경우 Kubernetes의 역할 기반 액세스 제어(RBAC)를 활용할 수 있도록 Autopilot을 사용하세요. 더 간단한 방법으로는 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 또는 둘 다에서 애플리케이션을 빌드하고 실행한 경험이 있는 다른 팀 또는 그룹의 담당자를 포함하는 것도 유용할 수 있습니다. 이 문서의 기술적 및 조직적 고려사항을 대화의 가이드로 사용하고 각 잠재적 플랫폼에 대한 애플리케이션의 적합성을 평가하세요.
몇 개월이 지난 후 새 환경에 애플리케이션을 배포한 결과에 따라 결정을 확인하거나 재검토할 수 있도록 체크인을 예약하는 것이 좋습니다.
다음 단계
- GKE Autopilot 빠른 시작 및 Cloud Run 실습을 통해 이러한 런타임 환경에 대해 자세히 알아보세요.
- Cloud Run에서 GKE로의 마이그레이션 및 Kubernetes에서 Cloud Run으로의 마이그레이션에 대해 자세히 알아보세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
작성자: 헨리 벨 | 클라우드 솔루션 설계자
기타 참여자:
- 마르코 페라리 | 클라우드 솔루션 설계자
- 개리 싱 | 아웃바운드 제품 관리자
- 마리디 (라주) 마카라주 | 지원 기술 책임자
- 파라그 도시 | 주요 엔터프라이즈 설계자
- 다니엘 스태머 | Digital Natives 고객 엔지니어
- Steren Giannini | 그룹 제품 관리자
- 빅터 살베이 | 선임 제품 관리자
- 윌리엄 데니스 | 그룹 제품 관리자