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_NAME-PROJECT_NUMBER.REGION.run.app
  • https://SERVICE_IDENTIFIER.run.app
バージョン/リビジョンの URL https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://TAG---SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://TAG---SERVICE_IDENTIFIER.run.app

スケーリング
自動スケーリング ○ ○ ○
手動スケーリング ○ ○ ○
ゼロへのスケーリング ○ × ○
ウォームアップ リクエスト 構成可能 × 自動
アイドル インスタンスのタイムアウト（最後のリクエストが終了した後） 最長 15 分 課金の設定によって異なります。App Engine の動作をエミュレートするにはインスタンス ベースの課金を使用します。
リクエストのタイムアウト
  • 自動スケーリング: 10 分
  • 手動 / 基本スケーリング: 24 時間
 60 分 最長 60 分を構成可能（デフォルト: 5 分）

デプロイ
ソースから ○ ○
コンテナ イメージ × ○（カスタム ランタイム） ○
サイドカー コンテナ × ○ サイドカーはメインコンテナと並行して実行され、ウェブ リクエストを処理します。
ヘルスチェック 自動。App Engine がインスタンスに対して readiness チェックと liveness チェックを行います。 構成可能。Cloud Run のリソース構成で、startup プローブと liveness プローブを明示的に定義し、プローブの種類（TCP、HTTP、gRPC）、パス、ポート、初期遅延、実行間隔、タイムアウト、成功判定のしきい値、失敗判定のしきい値などの詳細を指定できます。

コンピューティング リソース
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
GPU × ○ Cloud Run インスタンスごとに 1 つの GPU を構成できます。
ボリュームのマウント × ○ コンテナのファイル システムに直接 Cloud Storage バケットをマウントできます。

料金モデル
リクエストごとの料金 × ×（インスタンス ベースの課金を使用する場合）
○（リクエスト ベースの課金を使用する場合）
アイドル状態の最小インスタンス数 アクティブなインスタンスと同じ費用 アイドル状態の最小インスタンスの費用を削減（課金対象のコンテナ インスタンス時間を参照）
確約利用割引（CUD） × ○
インスタンス ベースの課金（インスタンスの 1 時間あたりの費用） F4/B4 インスタンス: $0.2
  • vCPU: $0.0526
  • メモリ: $0.0071
    		•
    • vCPU: $0.0648
    • メモリ: $0.0072

    セキュリティ
    上り（内向き）設定 ○ ○ ○
    呼び出し元のロール × ○
    IAP ○ ○ ○
    ファイアウォール ○ ○ Google Cloud Armor を使用して構成する
    Secret Manager ○（Cloud クライアント ライブラリを使用） ○ 各シークレットをボリュームとしてマウントするか、環境変数を使用してシークレットを渡すことができます。

    接続
    カスタム ドメイン ○ ○ ○
    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 と 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 を以下に示します。

    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
    ..
    ..

    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
    リクエストのタイムアウト
    • 自動スケーリング: 10 分
    • 手動 / 基本スケーリング: 24 時間
    		 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 に関するドキュメントを参照してください。

    ヘルスチェック

    App Engine では、ヘルスチェックはほぼ自動で行われ、プラットフォームによって管理されます。App Engine は、liveness チェックと readiness チェックの両方を実施して、インスタンスが動作可能でトラフィックを処理する準備ができているかどうかを判断します。インスタンスがこれらの自動チェックに継続して失敗すると、App Engine はそのインスタンスを終了し、サービスを継続できるように新しいインスタンスに置き換えます。

    Cloud Run では、startup プローブと liveness プローブを構成できるため、より細かい制御が可能です。これらのプローブを使用することで、何を正常なインスタンスとみなすかを定義できます。これは、複雑なマイクロサービスにとって非常に重要です。

    Cloud Run では、次のプローブを構成できます。

    • コンテナが起動してトラフィックを処理できる状態になったことを判断するための startup プローブ。startup プローブを構成すると、起動が成功するまでは liveness チェックが無効になり、liveness プローブがアプリケーションの起動を妨げないようにできます。

    • コンテナを再起動すべきタイミングを判断する liveness プローブ。たとえば、アプリケーションが動いてはいるものの、デッドロックなどで処理が進まなくなった状態を検知できます。そのような状態のコンテナを再起動すれば、バグがあってもアプリケーションの可用性を確保できます。

    詳細については、サービスにコンテナのヘルスチェックを構成するをご覧ください。

    スケーリング

    Cloud Run と App Engine スタンダード環境は似たようなスケーリング インフラストラクチャを共有していますが、Cloud Run はより高速なスケーリングやとゼロへのスケーリング機能を実現するために最適化されています。その結果、構成できる項目は App Engine より少なくなっています。この最適化により、構成可能な項目は次のものに限定されています。

    Cloud Run のインスタンスでは、CPU 使用率の目標値は構成できず、60% に固定されています。詳細については、Cloud Run サービスでのインスタンスの自動スケーリングについてをご覧ください。

    App Engine のフレキシブル環境は Compute Engine のオートスケーラーを利用しているため、App Engine のスタンダード環境や Cloud Run とはスケーリングの特徴が大きく異なります。

    スケーリング制御を App Engine から Cloud Run に移行する

    このセクションでは、既存の App Engine スケーリング構成を Cloud Run にマッピングする方法について説明します。

    最小インスタンス数（ウォームアップ）

    常に最小数のインスタンスをウォーム状態にしておき、通常のトラフィックに対応してコールドスタートを避けるようにします。

    構成環境 設定
    App Engine スタンダード環境 min_instances: N
    App Engine フレキシブル環境 automatic_scaling:
      min_num_instances: N
    Cloud Run サービスレベル: scaling.min_instance_count: N
    リビジョン レベル: template.scaling.min_instance_count: N

    移行戦略: ウォームアップ用の最小インスタンス数はサービス単位で設定します。特定のリビジョンにトラフィックを割り当てる場合は、リビジョン単位の設定がサービス単位のデフォルト設定より優先されます。この設定を使用すると、新しいリビジョンを本番環境に反映する前に、異なる最小インスタンス数でテストすることができます。

    最大インスタンス数

    総インスタンス数の上限を設定して、コストを抑えたり、ダウンストリームの依存関係を保護したりします。

    構成環境 設定
    App Engine スタンダード環境 max_instances: N
    App Engine フレキシブル環境 automatic_scaling:
      max_num_instances: N
    Cloud Run サービスレベル: scaling.max_instance_count: N
    リビジョン レベル: template.scaling.max_instance_count: N

    移行戦略: サービスレベルでグローバル上限を設定します。Cloud Run は、サービスレベルとリビジョン レベルの設定のうち小さい方を適用します。詳細については、サービスの最大インスタンス数を設定するをご覧ください。

    同時実行

    1 つのインスタンスが処理できるリクエスト数の上限を定義します。

    構成環境 設定
    App Engine スタンダード環境 max_concurrent_requests: N
    App Engine フレキシブル環境 automatic_scaling:
      target_concurrent_requests: N
    Cloud Run template.maxInstanceRequestConcurrency: N

    移行戦略: 次の 2 つの移行戦略のいずれかに従います。

    • Cloud Run のインスタンス容量のデフォルト値である 80 から開始し、負荷テストを実施して、Cloud Run 上のアプリケーションで安定して処理できる同時実行数の上限を確認します。この値を調整することは、Cloud Run でのパフォーマンスとコストを最適化する効果的な方法です。テスト結果に基づいて、値を 80 から下げて調整してください。詳細については、インスタンスあたりの最大同時リクエスト数を設定するをご覧ください。

    • App Engine スタンダード環境で使っていた既存の構成値（デフォルトはインスタンスあたり 10 個の同時リクエスト）を使用します。これは、アプリケーションで実際に動作が確認されている安全な方法です。ただし、この方法ではオートスケーラーが負荷処理に必要な数よりも多くのインスタンスを作成してしまう可能性があるため、Cloud Run のインスタンスが十分に活用されず、コストが高くなる可能性があります。

    CPU 使用率

    CPU 負荷が特定のしきい値を超えたときにスケーリングします。

    構成環境 設定
    App Engine スタンダード環境 target_cpu_utilization: 0.X
    App Engine フレキシブル環境 automatic_scaling:
      cpu_utilization:
      target_utilization: N
    Cloud Run 同等のものはありません（約 60% に固定）。

    移行戦略: この値は構成できません。Cloud Run のオートスケーラーは、アクティブなインスタンスで約 60% の CPU 使用率を維持します。App Engine とは異なり、Cloud Run はリクエストの処理中にのみ CPU を割り当て、それ以外の場合はゼロにスロットリングします。App Engine スタンダード環境では、構成したスケーリングの種類に関係なく、インスタンスに常に CPU が利用可能になるように保証されます。

    アプリケーションがリクエストの間にバックグラウンド作業（基本スケーリングまたは手動スケーリングでのバックグラウンド スレッドの使用など）を行う場合は、Cloud Run でインスタンス ベースの課金を設定して、バックグラウンド プロセスのタスクが停止されないようにします。

    同時実行の使用率

    アプリケーションが同時実行の上限に達したときに、同時実行使用率に基づいてスケーリングします。

    構成環境 設定
    App Engine スタンダード環境 target_throughput_utilization: 0.X
    App Engine フレキシブル環境 利用不可
    Cloud Run template.maxInstanceRequestConcurrency 設定のチューニングを検討する

    移行戦略: Cloud Run のオートスケーラーは、インスタンスあたりの同時リクエスト数を maxInstanceRequestConcurrency 値の 60% に維持しようとします。この値を設定すると、スケールアップ イベントをトリガーする目標スループットを暗黙的に定義したことになります。

    レイテンシ

    スケーリングを開始するトリガーとして、ユーザーの待機時間枠を定義します。App Engine は、リクエストのキューイングに部分的に対応しています。

    構成環境 設定
    App Engine スタンダード環境 min_pending_latency と max_pending_latency
    App Engine フレキシブル環境 利用不可
    Cloud Run 完全に同じものはない

    移行戦略: Cloud Run は、リクエストのキューイングとレイテンシの急増が始まる前に自動スケーリングを行います。レイテンシが急増する場合は、template.maxInstanceRequestConcurrency の値を調整して、より速くスケールアウトできるように検討してください。

    アイドル状態のインスタンス

    目的: App Engine では、アイドル状態のインスタンス設定によって、事前にウォームアップされたアイドル状態のインスタンスのプールが管理されます。このプールは、トラフィックの急増を吸収し、コストを制御する役割があります。

    構成環境 設定
    App Engine スタンダード環境 min_idle_instances: N
    または
    max_idle_instances: N
    App Engine フレキシブル環境 利用不可
    Cloud Run 完全に同じものはない

    移行戦略: Cloud Run では、アイドル状態の最小インスタンス数と最大インスタンス数を個別に設定することはできません。Cloud Run でインスタンスをウォーム状態に保ち、トラフィックの急増に即座に対応できるようにし、Cloud Run でのコールド スタートを軽減するには、scaling.min_instance_count 設定を使用します。これにより、常に指定した最小数のコンテナが稼働することが保証されます。詳細については、Cloud Run サービスでのインスタンスの自動スケーリングについてをご覧ください。

    アイドル インスタンスのタイムアウト

    App Engine では、最後のリクエストから約 15 分間、アイドル状態のインスタンスが存続します。Cloud Run は、課金設定を使用してこの動作を制御します。

    App Engine のように、リクエスト処理の外でも CPU が割り当てられる課金動作を実現するには、Cloud Run でインスタンスベースの課金を使用してください。

    あるいは、リクエスト ベースの課金を使用して、リクエストの処理中にのみ CPU が割り当てられるようにします。この設定では、インスタンスは最後のリクエストから最大 15 分間存続しますが、そのアイドル時間中に CPU がスロットリングされます。

    基本スケーリング

    構成環境 設定
    App Engine スタンダード環境 basic_scaling: max_instances: N
    App Engine フレキシブル環境 利用不可
    Cloud Run デフォルトの自動スケーリング。
    scaling.min_instance_count: 0
    scaling.max_instance_count: N

    App Engine スタンダード環境で basic_scaling 設定を設定すると、リクエストを受信したときにインスタンスが作成され、一定期間アクティビティがないとゼロにスケーリングされます。Cloud Run では、min-instances を 0 に設定して自動スケーリングを使用することで、同じ挙動を実現できます。

    手動スケーリング

    インスタンスの数を固定して実行し、自動スケーリングを無効にします。

    構成環境 設定
    App Engine スタンダード環境 manual_scaling: instances: N
    App Engine フレキシブル環境 manual_scaling: instances: N
    Cloud Run scalingMode: MANUAL
      manualInstanceCount: N

    移行戦略: Cloud Run には、手動スケーリングに直接相当する設定があります。Cloud Run のサービスレベルでスケーリング モードを MANUAL に設定し、manualInstanceCount を使用して実行するインスタンスの正確な数を指定します。これは、自動スケーリングを完全に無効にするのと同じ効果があります。詳細については、Cloud Run の手動スケーリングをご覧ください。

    クールダウン期間

    スケールアップが発生した後に別のイベントが発生するまでのクールダウン期間を設定します。

    構成環境 設定
    App Engine スタンダード環境 利用不可
    App Engine フレキシブル環境 automatic_scaling:
      cool_down_period_sec: N
    Cloud Run 完全に同じものはない

    移行戦略: 必要ありません。Cloud Run は需要と使用率に基づいて自動スケーリングを行うため、手動でクールダウン期間を構成しなくても効率的に対応するように設計されています。

    ウォームアップ リクエスト

    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 で使用できる値の一覧については、プリンシパル ID をご覧ください。

    既存のサービス

    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 で使用できる値の一覧については、プリンシパル ID をご覧ください。

    環境変数とメタデータ

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

    デフォルトの環境変数

    App Engine の名前 {[cloud_run_name]} の名前 説明
    GAE_SERVICE K_SERVICE 現在のサービスの名前。App Engine では、指定しない場合は「default」に設定されます。
    GAE_VERSION K_REVISION サービスの現在のバージョン ラベル。
    PORT PORT HTTP リクエストを受信するポート。
    なし K_CONFIGURATION リビジョンを作成した Cloud Run 構成の名前。
    GOOGLE_CLOUD_PROJECT なし アプリケーションに関連付けられた Google 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"
    }

    次のステップ