App Engine과 Cloud Run 비교

리전 ID

REGION_ID는 앱을 만들 때 선택한 리전을 기준으로 Google에서 할당하는 축약된 코드입니다. 일부 리전 ID는 일반적으로 사용되는 국가 및 주/도 코드와 비슷하게 표시될 수 있지만 코드는 국가 또는 주/도와 일치하지 않습니다. 2020년 2월 이후에 생성된 앱의 경우 REGION_ID.r이 App Engine URL에 포함됩니다. 이 날짜 이전에 만든 기존 앱의 경우 URL에서 리전 ID는 선택사항입니다.

리전 ID에 대해 자세히 알아보세요.

이 가이드는 App Engine에 익숙한 사용자를 대상으로 Cloud Run을 안내합니다. App Engine 표준 환경 또는 App Engine 가변형 환경에서의 마이그레이션을 준비할 수 있도록 서버리스 플랫폼 간의 중요한 유사점과 차이점을 다룹니다.

개요

Cloud Run은 10년 이상 App Engine을 실행한 경험을 기반으로 업그레이드된 최신 Google Cloud 서버리스입니다. Cloud Run은 App Engine 표준 환경과 거의 동일한 인프라에서 실행되므로 두 플랫폼 간에 많은 유사점이 있습니다.

Cloud Run은 App Engine 표준 환경과 App Engine 가변형 환경의 최고의 기능을 다양하게 통합하여 App Engine 환경을 개선하도록 설계되었습니다. Cloud Run 서비스는 App Engine 서비스와 동일한 워크로드를 처리할 수 있지만, Cloud Run을 사용하면 고객이 이러한 서비스를 훨씬 더 유연하게 구현할 수 있습니다. 이러한 유연성과 더불어 Google Cloud 및 타사 서비스와의 통합이 개선되어 Cloud Run은 App Engine에서 실행할 수 없는 워크로드를 처리할 수 있습니다.

비교 요약

App Engine과 Cloud Run 간에는 많은 유사점과 차이점이 있지만 이 개요에서는 Cloud Run을 시작하는 App Engine 고객과 가장 관련성이 높은 영역에 중점을 둡니다.

App Engine 표준 환경 App Engine 가변형 환경 Cloud Run

용어 애플리케이션 해당 사항 없음

서비스 서비스

버전 버전

URL 엔드포인트

앱 URL
(default 서비스) https://PROJECT_ID.REGION_ID.r.appspot.com 해당 사항 없음

서비스 URL https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com https://SERVICE_IDENTIFIER.run.app

버전/버전 URL https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com https://TAG---SERVICE_IDENTIFIER.run.app

확장

자동 확장 예 예 예

수동 확장 예 예 특정한 수동 확장 설정은 없지만 동일하게 최대 인스턴스를 최소 인스턴스와 동일하게 구성하여 동일한 동작을 복제할 수 있습니다.

Scale-to-zero 예 아니요 예

준비 요청 구성 가능 아니요 자동

유휴 인스턴스 제한 시간(마지막 요청 완료 후) 최대 15분 CPU 할당 설정에 따라 다릅니다. 항상 할당되는 CPU를 사용하여 App Engine 동작을 에뮬레이션합니다.

요청 제한 시간

자동 확장: 10분
수동/기본 확장: 24시간

60분

최대 60분까지 구성 가능(기본값: 5분)

배포

소스에서 배포 예 예

컨테이너 이미지 아니요 예(커스텀 런타임) 예

컴퓨팅 리소스

vCPU

인스턴스 클래스	vCPU*	메모리
F/B1	.25	384MB
F/B2	.5	768MB
F/B4	1	1.5GB
F/B4_1G	1	3GB
B8	2	3GB

* vCPU에 해당하는 수는 근사치입니다.

vCPU 최대 80개

vCPU 최대 8개

메모리 vCPU당 최대 6.5GB 최대 32GB

가격 책정 모델

요청별 비용 아니요 아니요(CPU가 항상 할당되는 경우)
예(요청 처리 중에만 CPU가 할당되는 경우)

유휴 최소 인스턴스 활성 인스턴스와 동일한 비용 유휴 최소 인스턴스의 비용 절감(청구 가능한 컨테이너 인스턴스 시간 참조)

약정 사용 할인(CUD) 아니요 예

보안

인그레스 설정 예 예 예

호출자 역할 아니요 예

IAP 예 예 Cloud Load Balancing을 사용하여 구성

방화벽 예 예 Google Cloud Armor를 사용하여 구성

연결

커스텀 도메인 예 예 Cloud Load Balancing을 사용하여 구성

VPC 연결(공유 VPC 포함) 예 해당 사항 없음 예

VPC 이그레스 설정 예 해당 사항 없음 예

멀티 리전 부하 분산 아니요 예

Google Cloud 서비스 액세스

Cloud SQL 예 예 예

Cloud 클라이언트 라이브러리 App Engine에서 Cloud 클라이언트 라이브러리를 사용하는 경우 Cloud Run으로 마이그레이션할 때 아무것도 변경할 필요가 없습니다. 클라이언트 라이브러리는 어디서나 작동하므로 애플리케이션의 이동성이 향상됩니다.

App Engine 기존 번들 서비스 예(Java, Python, Go, PHP만 해당) 아니요 아니요

리소스 모델

Cloud Run 리소스 모델은 App Engine과 매우 유사하지만 몇 가지 중요한 차이점이 있습니다.

Cloud Run에는 최상위 애플리케이션 리소스 또는 해당 default 서비스가 없습니다.
동일한 프로젝트의 Cloud Run 서비스를 다른 리전에 배포할 수 있습니다. App Engine에서 프로젝트의 모든 서비스는 동일한 리전에 있습니다.
Cloud Run은 Knative 리소스 모델과 일치하도록 버전(Version) 대신 버전(Revision)이라는 용어를 사용합니다.
Cloud Run 버전 이름은 SERVICE_NAME-REVISION_SUFFIX 형식을 사용합니다. 여기서 REVISION_SUFFIX는 자동 생성되거나 --revision-suffix=REVISION_SUFFIX 배포 플래그를 사용하여 설정됩니다.
Cloud Run 버전은 변경할 수 없습니다. 즉, App Engine 버전에서와 같이 이름을 재사용할 수 없습니다(--version=VERSION_ID 배포 플래그 사용).
Cloud Run 서비스 URL은 서비스를 처음 배포할 때 자동으로 생성되는 서비스 식별자를 기반으로 합니다. 서비스 식별자는 SERVICE_NAME-<auto-generated identifier> 형식을 사용합니다. 서비스 식별자는 고유하며 서비스의 수명 동안 변경되지 않습니다.
Cloud Run에서는 기본적으로 서비스 URL(SERVICE_IDENTIFIER.run.app)만 노출됩니다. 특정 버전을 처리하려면 트래픽 태그를 구성해야 합니다. App Engine에서는 서비스 및 버전 URL이 모두 자동으로 노출됩니다.

배포 및 구성

App Engine에서 대부분의 구성은 모든 배포에 포함되는 app.yaml에서 수행됩니다. 이렇게 간소화된 방식을 사용하려면 비용이 상승합니다. 즉, Admin API를 사용하여 일부 설정을 업데이트할 수 있지만 대부분의 변경사항을 적용하려면 서비스를 다시 배포해야 합니다.

Cloud Run에는 service.yaml 구성 파일이 있지만 app.yaml과 동일한 방식으로 사용되지 않습니다. 필수 요소 중 하나가 최종 컨테이너 이미지의 경로이므로 소스에서 배포할 때 Cloud Run service.yaml을 사용할 수 없습니다. 또한 service.yaml은 Knative 사양을 준수하며 Kubernetes 스타일 구성 파일에 익숙하지 않은 경우 읽기 어려울 수 있습니다. service.yaml을 사용하여 구성을 관리하는 방법에 대한 자세한 내용은 Cloud Run 문서를 참조하세요.

Cloud Run을 시작하는 App Engine 고객의 경우 gcloud CLI 배포 플래그를 사용하면 배포 시 App Engine 구성 관리와 훨씬 더 밀접하게 일치합니다.

Cloud Run에서 새 코드를 배포할 때 구성을 설정하려면 gcloud run deploy 플래그를 사용합니다.

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

모든 배포에서 구성 플래그를 사용할 필요는 없지만(구성 관리 참조) 구성 관리를 간소화하는 데 도움이 될 수 있습니다.

Cloud Run에서 gcloud run services update를 사용하여 소스 코드를 재배포하지 않고 구성을 업데이트할 수도 있습니다.

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Cloud Run 버전은 변경할 수 없으므로 이 명령어를 사용하면 업데이트된 구성으로 새 버전이 생성되지만 기존 버전과 동일한 컨테이너 이미지를 사용합니다.

구성 관리

App Engine 배포의 경우 모든 배포에 모든 설정을 제공해야 하며, 제공하지 않은 설정에는 기본값이 할당됩니다. 예를 들어 아래에 나와 있는 app.yaml 파일을 사용하는 버전에는 App Engine service-a를 사용합니다.

App Engine service-a version1	App Engine service-a version2
app.yaml
runtime: python39 service: service-a instance_class: F4	runtime: python39 service: service-a
적용된 구성
runtime: python39 service: service-a instance_class: F4 default values: .. ..	runtime: python39 service: service-a default values: instance_class: F1 .. ..

version1은 instance_class: F4로 구성되고 instance_class 값을 제공하지 않는 version2는 기본 instance_class: F1로 구성됩니다.

Cloud Run의 경우 제공된 모든 구성 설정이 적용되지만 제공되지 않는 경우에는 기존 값이 유지됩니다. 변경하려는 설정의 값만 제공하면 됩니다. 예를 들면 다음과 같습니다.

Cloud Run service-a revision1	Cloud Run service-a revision2
배포 명령어
gcloud run deploy service-a \ --cpu=4	gcloud run deploy service-a
적용된 구성
service: service-a vCPUs: 4 default values: .. ..	service: service-a vCPUs: 4 default values: .. ..

App Engine에서 구성 설정 없이 배포하면 모든 기본 설정을 사용하여 버전이 생성됩니다. Cloud Run에서 구성 설정 없이 배포하면 이전 버전과 동일한 구성 설정을 사용하여 버전이 생성됩니다. 구성 설정 없이 배포하는 Cloud Run 서비스의 첫 번째 버전의 경우 모든 기본 설정을 사용하여 버전이 생성됩니다.

구성 기본값

구성 설정	App Engine 표준 환경	App Engine 가변형 환경	Cloud Run
컴퓨팅 리소스	F1	vCPU 1개, .6GB	vCPU 1개, 512MB
최대 동시 실행(요청)	10	없음	80
요청 제한 시간	자동 확장: 10분 수동/기본 확장: 24시간	60분	5분
CPU 사용률 목표	60%	50%	60%
최대 인스턴스	없음	20	100
최소 인스턴스	0	2	0

진입점

소스에서 배포할 때 App Engine은 app.yaml의 entrypoint 속성에서 진입점 명령어를 읽습니다. 진입점이 제공되지 않으면 런타임별 기본값이 사용됩니다. Cloud Run은 소스에서 배포할 때 Google Cloud 빌드팩을 사용하며 일부 언어에는 기본 진입점이 없으므로 기본 진입점을 제공해야 합니다. 그렇지 않으면 빌드가 실패합니다. 예를 들어 Python 빌드팩에는 Procfile이 필요하거나 GOOGLE_ENTRYPOINT 빌드 환경 변수를 지정해야 합니다.

언어별 구성 요구사항은 빌드팩 문서를 참조하세요.

확장

Cloud Run 및 App Engine 표준 환경은 동일한 확장 인프라를 대부분 공유하지만 Cloud Run은 훨씬 더 빠르게 확장할 수 있도록 간소화되었습니다. 이러한 간소화의 일환으로 구성 가능한 설정은 다음으로 제한됩니다.

최대 동시 실행
최대 및 최소 인스턴스

Cloud Run 인스턴스의 경우 대상 CPU 사용률을 구성할 수 없으며 60%로 고정됩니다. 자동 확장에 대한 자세한 내용은 Cloud Run 문서를 참조하세요.

App Engine 가변형 환경은 Compute Engine 자동 확장 처리를 사용하므로 App Engine 표준 환경 및 Cloud Run과 확장 특성이 매우 다릅니다.

유휴 인스턴스 제한 시간

App Engine에서 유휴 인스턴스는 마지막 요청 처리가 완료된 후 최대 15분 동안 활성 상태로 유지됩니다. Cloud Run에서는 CPU 할당을 사용하여 이 동작을 구성할 수 있습니다. App Engine과 동일한 동작을 수행하려면 CPU 할당을 항상 할당되는 CPU로 설정합니다. 또는 요청 처리 중에만 할당되는 CPU를 사용하여 유휴 인스턴스를 즉시 종료합니다(대기 중인 요청이 없는 경우).

준비 요청

Cloud Run은 컨테이너 진입점 명령어를 사용하여 인스턴스를 자동으로 준비하므로, 준비 요청을 수동으로 사용 설정하거나 /_ah/warmup 핸들러를 구성할 필요가 없습니다. 인스턴스 시작 시 실행할 코드가 있는 경우 요청을 처리하기 전에 다음 중 하나를 수행할 수 있습니다.

정적 콘텐츠

App Engine 표준 환경에서는 Cloud Storage에서 제공하거나 핸들러를 구성하여 컴퓨팅 리소스를 사용하지 않고도 정적 콘텐츠를 제공할 수 있습니다. Cloud Run에는 정적 콘텐츠를 제공하는 핸들러 옵션이 없으므로 Cloud Run 서비스(동적 콘텐츠와 동일) 또는 Cloud Storage에서 콘텐츠를 제공할 수 있습니다.

Cloud Run 호출자 역할

또한 Cloud Run은 Identity and Access Management(IAM)로 서비스에 대한 액세스를 제어하는 기능을 제공합니다. 서비스의 IAM 정책 바인딩은 gcloud CLI, 콘솔 또는 Terraform을 사용하여 설정할 수 있습니다.

App Engine 동작을 복제하려면 인증되지 않은 요청을 허용하여 서비스를 공개하면 됩니다. 이는 배포 시 또는 기존 서비스에서 IAM 정책 바인딩을 업데이트하여 설정할 수 있습니다.

배포

--allow-unauthenticated 배포 플래그를 사용합니다.

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

기존 서비스

gcloud run services add-iam-policy-binding 명령어를 사용합니다.

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

여기서 SERVICE_NAME은 Cloud Run 서비스 이름입니다.

또는 서비스별로 구성 가능한 Cloud Run 호출자 IAM 역할을 부여하여 서비스에 대한 액세스 권한을 가진 사용자를 제어하도록 선택할 수 있습니다.

배포

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

여기서 SERVICE_NAME은 서비스 이름이고 MEMBER_TYPE은 주 구성원 유형입니다. 예를 들면 user:email@domain.com입니다.

MEMBER_TYPE에 사용 가능한 값 목록은 IAM 개념 페이지를 참조하세요.

기존 서비스

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

여기서 SERVICE_NAME은 서비스 이름이고 MEMBER_TYPE은 주 구성원 유형입니다. 예를 들면 user:email@domain.com입니다.

MEMBER_TYPE에 사용 가능한 값 목록은 IAM 개념 페이지를 참조하세요.

환경 변수 및 메타데이터

App Engine과 Cloud Run에는 모두 자동으로 설정되는 특정 환경 변수가 있습니다. 아래 표에는 App Engine 환경 변수와 이에 상응하는 Cloud Run 환경 변수가 나와 있습니다. Cloud Run은 App Engine에 비해 몇 가지 환경 변수만 구현하지만, 메타데이터 서버에서 사용 가능한 데이터는 대체로 동일합니다.

기본 환경 변수

App Engine 이름	Cloud Run 이름	설명
`GAE_SERVICE`	`K_SERVICE`	현재 서비스의 이름입니다. App Engine에서는 지정하지 않으면 `default`로 설정됩니다.
`GAE_VERSION`	`K_REVISION`	서비스의 현재 버전 라벨입니다.
`PORT`	`PORT`	HTTP 요청을 수신하는 포트입니다.
해당 사항 없음	`K_CONFIGURATION`	버전을 만든 Cloud Run 구성의 이름입니다.
`GOOGLE_CLOUD_PROJECT`	해당 사항 없음	애플리케이션과 연결된 Cloud 프로젝트 ID입니다.
`GAE_APPLICATION`		App Engine 애플리케이션 ID입니다. 이 ID는 유럽에 배포된 애플리케이션의 'e~'와 같이 '리전 코드~'로 시작됩니다.
`GAE_DEPLOYMENT_ID`		현재 배포 ID입니다.
`GAE_ENV`		App Engine 환경입니다. 표준 환경에서는 'standard'로 설정됩니다.
`GAE_INSTANCE`		서비스가 현재 실행되고 있는 인스턴스 ID입니다.
`GAE_MEMORY_MB`		애플리케이션 프로세스에 제공되는 메모리 양(MB)입니다.
`NODE_ENV`(Node.js 런타임에서만 사용 가능)		서비스가 배포되면 production으로 설정됩니다.
`GAE_RUNTIME`		app.yaml 파일에 지정된 런타임입니다.

일반적인 메타데이터 서버 경로

경로	설명	예시
`/computeMetadata/v1/project/project-id`	서비스가 속한 프로젝트의 프로젝트 ID입니다.	test_project
`/computeMetadata/v1/project/numeric-project-id`	서비스가 속한 프로젝트의 프로젝트 번호입니다.	12345678912
`/computeMetadata/v1/instance/id`	컨테이너 인스턴스의 고유 식별자입니다(로그에서도 확인 가능).	16a61494692b7432806a16 (영숫자 문자로 구성된 문자열)
`/computeMetadata/v1/instance/region` ** App Engine 가변형 환경에서는 사용할 수 없음	이 서비스의 리전이며 `projects/PROJECT_NUMBER/regions/REGION`을 반환합니다.	projects/12345678912/regions/us-central1
`/computeMetadata/v1/instance/service-accounts/default/email`	이 서비스의 런타임 서비스 계정 이메일입니다.	service_account@test_project.iam.gserviceaccount.com
`/computeMetadata/v1/instance/service-accounts/default/token`	이 서비스의 서비스 계정에 대한 OAuth2 액세스 토큰을 생성합니다. 이 엔드포인트는 `access_token` 속성과 함께 JSON 응답을 반환합니다.	{ "access_token":"<TOKEN>", "expires_in":1799, "token_type":"Bearer" }

다음 단계

빠른 시작: Cloud Run을 사용하여 웹 서비스 배포
내 앱이 Cloud Run에 적합한가요?
Cloud Load Balancing으로 App Engine 커스텀 도메인 마이그레이션
기타 리소스:
- Docker를 사용하여 App Engine에서 Cloud Run으로 마이그레이션(Python: codelab, 동영상, Java: codelab)
- 빌드팩을 사용하여 App Engine에서 Cloud Run으로 마이그레이션(Python: codelab, 동영상, Java: codelab)