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 は、Google Cloud サーバーレスの最新の進化であり、10 年を超える期間にわたって App Engine を実行してきた経験を基盤にしています。Cloud Run は App Engine スタンダード環境とほぼ同じインフラストラクチャで実行されるため、この 2 つのプラットフォームには多くの類似点があります。

Cloud Run は、App Engine のエクスペリエンスを改善するために設計されており、App Engine スタンダード環境と App Engine フレキシブル環境の両方の多くの最良の機能が組み込まれています。Cloud Run サービスは App Engine サービスと同じワークロードを処理できますが、Cloud Run はこれらのサービスをより柔軟に実装できます。この柔軟性に加え、Google Cloud とサードパーティ サービスの両方の統合により、Cloud Run は App Engine で実行できないワークロードを処理することもできます。

比較の概要

App Engine と Cloud Run には多くの類似点と相違点がありますが、この概要では、App Engine をご利用のお客様が Cloud Run の使用を開始する場合に最も関連性の高い領域を取り上げます。

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

スケーリング

自動スケーリング
手動スケーリング 特定の手動スケーリングの設定はありませんが、最小インスタンス数に等しい最大インスタンス数を構成することで同じ動作を複製できます。
ゼロへのスケーリング ×
ウォームアップ リクエスト 構成可能 × 自動
アイドル インスタンスのタイムアウト(最後のリクエストが終了した後) 最長 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 に相当する概算値
最大 80 vCPU 最大 8 vCPU
メモリ vCPU あたり最大 6.5 GB 最大 32 GB

料金モデル

リクエストごとの料金 × ×(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 のみ) × ×

リソースモデル

App Engine と Cloud Run のリソースモデルの図

Cloud Run のリソースモデルは、App Engine と非常に類似していますが、重要な違いがいくつかあります。

  • Cloud Run には、最上位の Application リソースや、対応する default サービスがありません。
  • 同じプロジェクト内の Cloud Run サービスは、異なるリージョンにデプロイできます。App Engine では、プロジェクト内のすべてのサービスが同じリージョンにあります。
  • Cloud Run では、Knative リソースモデルに合わせてバージョンではなくリビジョンという用語を使用します。
  • Cloud Run のリビジョン名では SERVICE_NAME-REVISION_SUFFIX の形式を使用します。ここで、REVISION_SUFFIX は自動生成されるか、--revision-suffix=REVISION_SUFFIX デプロイフラグを使用して設定されます。
  • Cloud Run のリビジョンは不変です。つまり、App Engine のバージョンのように--version=VERSION_ID デプロイフラグを使用して名前を再利用することはできません。
  • Cloud Run サービス URL は、サービスの最初のデプロイ時に自動的に生成されるサービス ID に基づいています。サービス ID の形式は SERVICE_NAME-<auto-generated identifier> です。サービス ID は一意であり、サービスの存続期間中は変更されません。
  • 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 のドキュメントをご覧ください。

App Engine をご利用のお客様が Cloud Run を初めて使用する場合は、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 バージョン 1 App Engine service-a バージョン 2
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
..
..

version1instance_class: F4 で構成されており、instance_class の値が指定されていない version2 はデフォルトの instance_class: F1 で構成されています。

Cloud Run では、指定された構成設定が適用されますが、指定がない場合は既存の値を維持します。変更する設定の値を指定するだけで済みます。次に例を示します。

Cloud Run サービス(リビジョン 1) Cloud Run サービス(リビジョン 2)
デプロイ コマンド

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 1 vCPU、0.6 GB 1 vCPU、512 MB
最大同時実行数(リクエスト) 10 なし 80
リクエストのタイムアウト
  • 自動スケーリング: 10 分
  • 手動 / 基本スケーリング: 24 時間
60 分 5 分
CPU 使用率の目標値 60% 50% 60%
最大インスタンス数 なし 20 100
最小インスタンス数 0 2 0

エントリポイント

ソースからデプロイする場合、App Engine は app.yamlentrypoint 属性からエントリポイント コマンドを読み取ります。エントリポイントが指定されていない場合は、ランタイム固有のデフォルトが使用されます。Cloud Run は、ソースからのデプロイ時に Google Cloud の Buildpack を使用します。一部の言語にはデフォルトのエントリ ポイントがありません。つまり、エントリ ポイントを指定しないとビルドは失敗します。たとえば、Python Buildpack には、Procfile か、GOOGLE_ENTRYPOINT ビルド環境変数を指定する必要があります。

言語固有の構成要件については、Buildpack に関するドキュメントを参照してください。

スケーリング

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 の動作を複製するには、未認証のリクエストを許可してサービスを公開します。これは、デプロイ時または既存の Service の 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 EngineCloud 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"
}

次のステップ