リージョン 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 の動作をエミュレートする | |||||||||||||||||||
| リクエストのタイムアウト |
|
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 サービス（リビジョン 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 |
| リクエストのタイムアウト |
|
60 分 | 5 分 |
| CPU 使用率の目標値 | 60% | 50% | 60% |
| 最大インスタンス数 | なし | 20 | 100 |
| 最小インスタンス数 | 0 | 2 | 0 |
エントリポイント
ソースからデプロイする場合、App Engine は app.yaml の entrypoint 属性からエントリポイント コマンドを読み取ります。エントリポイントが指定されていない場合は、ランタイム固有のデフォルトが使用されます。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 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 に適していますか？
- App Engine のカスタム ドメインを Cloud Load Balancing に移行する
- その他のリソース: