リージョン 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 | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 用語 | Application（アプリケーション） | なし | |||||||||||||||||||
| サービスの | サービスの | ||||||||||||||||||||
| バージョン | リビジョン | ||||||||||||||||||||
URL エンドポイント |
|||||||||||||||||||||
| アプリの URL （ default サービス） |
https://PROJECT_ID.REGION_ID.r.appspot.com
|
なし | |||||||||||||||||||
| Service 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 の動作をエミュレートする | |||||||||||||||||||
| リクエストのタイムアウト |
|
60 分 | 最大 60 分を構成可能（デフォルト: 5 分） | ||||||||||||||||||
デプロイメント |
|||||||||||||||||||||
| ソースから | ○ | あり | |||||||||||||||||||
| コンテナ イメージ | × | ○（カスタム ランタイム） | あり | ||||||||||||||||||
コンピューティング リソース |
|||||||||||||||||||||
| 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 のみ） | × | × | ||||||||||||||||||
リソースモデル
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: |
version1 は instance_class: F4 を使用して構成されていますが、instance_class の値が指定されていない version2 はデフォルトの instance_class: F1 で構成されています。
Cloud Run では、指定された構成設定が適用されますが、指定がない場合は既存の値を維持します。変更する設定の値を指定するだけで済みます。次に例を示します。
| Cloud Run service-a リビジョン 1 | Cloud Run service-a リビジョン 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、6 GB | 1 vCPU、512 MB |
| 最大同時実行数（リクエスト） | 10 | なし | 80 |
| リクエストのタイムアウト |
|
60 分 | 5 分 |
| CPU 使用率の目標値 | 60% | 50% | 60% |
| 最大インスタンス数 | なし | 20 | 100 |
| 最小インスタンス数 | 0 | 2 | 0 |
entrypoint
ソースからデプロイする場合、App Engine は app.yaml の entrypoint 属性からエントリポイント コマンドを読み取ります。エントリポイントが指定されていない場合は、ランタイム固有のデフォルトが使用されます。Cloud Run は、ソースからのデプロイ時に Google Cloud の Buildpacks を使用します。一部の言語にはデフォルトのエントリ ポイントがありません。つまり、エントリ ポイントを指定しないとビルドは失敗します。たとえば、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 ハンドラを構成する必要はありません。インスタンスの起動時に（リクエストを処理する前に）実行するコードがある場合は、スタートアップ プローブまたは liveness プローブの構成を参照してください。
静的コンテンツ
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 ポリシー バインディングを更新することで設定できます。
配備
--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" } |