App Engine と Cloud Run の比較

このガイドでは、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 の使用を開始する場合に最も関連性の高い領域を取り上げます。

リソースモデル

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 と https://SERVICE_NAME-PROJECT_NUMBER.REGION.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 を以下に示す します。

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

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 サービスの最初のリビジョンでは、構成を設定せずにデプロイすると、すべてのデフォルト設定を使用してリビジョンが作成されます。

構成のデフォルト

entrypoint

ソースからデプロイする場合、App Engine は app.yaml の entrypoint 属性からエントリポイント コマンドを読み取ります。エントリポイントが指定されていない場合は、ランタイム固有のデフォルトが使用されます。Cloud Run は、ソースからのデプロイ時に Google Cloud の Buildpacks を使用します。一部の言語にはデフォルトのエントリ ポイントがありません。つまり、エントリ ポイントを指定しないとビルドは失敗します。たとえば、Python Buildpack には、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、Console、Terraform を使用して設定できます。

App Engine の動作を複製するには、未認証のリクエストを許可してサービスを公開します。これは、デプロイ時または既存の Service の IAM ポリシー バインディングを更新することで設定できます。

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

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

または、サービスごとに構成可能な 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"

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

環境変数とメタデータ

App Engine と Cloud Run にはどちらも、特定の環境変数が自動的に設定されます。次の表に、App Engine の環境変数とそれに対応する Cloud Run の環境変数を示します。Cloud Run は App Engine と比較して少数の環境変数のみを実装していますが、メタデータ サーバーから利用可能なデータはほぼ同じです。

デフォルトの環境変数

一般的なメタデータ サーバーのパス

次のステップ

• クイックスタート: Cloud Run を使用してウェブサービスをデプロイする
• アプリは Cloud Run に適していますか？
• App Engine のカスタム ドメインを Cloud Load Balancing に移行する
• その他のリソース:
  • Docker を使用して App Engine から Cloud Run に移行する（Python: codelab、動画、Java: codelab）
  • Buildpack を使用して App Engine から Cloud Run に移行する（Python: codelab、動画、Java: codelab）