このガイドでは、関数のデプロイに関する最新のオプションと元のオプションを比較します。 Google Cloud このページは、以前に Cloud Functions API で関数を作成し、Cloud Run Admin API に移行するユーザーを対象としています。このページでは、コンセプト、構成、デプロイ、トリガーと再試行など、いくつかの領域における主な違いについて説明します。
比較
Cloud Run functions には次の 2 つのバージョンがあります。
Cloud Run functions。次のいずれかの方法で作成できます。
- Cloud Run Admin API(推奨): この API を使用して作成された関数(Google Cloud コンソール、
gcloud run
、REST API、Terraform など)は、Cloud Run にサービスとしてデプロイされます。 - Cloud Functions v2 API: この API を使用して作成された関数(
gcloud functions
、REST API、Terraform など)は、Cloud Run Admin API と Cloud Functions v2 API で管理できます。この API を使用する場合は、関数のデプロイ時にトリガーを指定します。Cloud Run Admin API 環境でのみ管理できるように v2 API 関数をデタッチする方法について学びます。
- Cloud Run Admin API(推奨): この API を使用して作成された関数(Google Cloud コンソール、
Cloud Run functions(第 1 世代)(旧称: Cloud Functions(第 1 世代)): イベント トリガーと構成の柔軟性が制限された関数の元のバージョンです。
関数を Cloud Run に直接デプロイすると、関数はコンテナとして自動的にビルドされ、Cloud Run サービスとしてデプロイされます。
コンセプト
次の表に、関数の概念的な違いを示します。
Cloud Run 関数 | Cloud Run functions(第 1 世代) | |
---|---|---|
旧サービス名 | Cloud Functions(第 2 世代) | Cloud Functions(第 1 世代) |
リソースモデル | 関数は、ソースコードからデプロイされる Cloud Run サービスです。 | 関数がソースコードからデプロイされる |
関数の種類の用語 |
|
|
割り当てられた HTTPS URL | run.app Cloud Functions v2 API で作成された関数にも cloudfunctions.net エンドポイントがあります。 |
cloudfunctions.net |
イメージ レジストリ | Artifact Registry のみ | Artifact Registry または Container Registry(非推奨) |
デプロイの IAM ロール |
|
|
内部インフラストラクチャ | Cloud Run | Google 社内 |
料金モデル | Cloud Run の料金 | Cloud Run functions(第 1 世代)の料金 |
構成
Cloud Run は、関数をコンテナにビルドし、サービスとしてデプロイします。関数を Cloud Run にデプロイすると、関数の動作を完全にアクセスして制御できます。たとえば、ダイレクト VPC を有効にしたり、GPU を構成したり、ボリューム マウントを使用したりできます。
次の表に、関数の構成の違いを示します。
Cloud Run 関数 | Cloud Run functions(第 1 世代) | |
---|---|---|
リクエストのタイムアウト |
|
|
インスタンスのサイズ | 最大 16 GiB の RAM(4 vCPU) | 最大 8 GB の RAM(2 vCPU) |
同時実行 | 関数インスタンスあたり最大 1,000 件の同時リクエスト | 関数インスタンスごとに 1 件の同時リクエスト |
トラフィック分割 | サポート対象 | 非対応 |
デプロイ
2024 年 8 月以降、Cloud Run を使用して、Cloud Functions v2 API で作成された関数をデプロイして管理できます。この変更により、以下のことが可能になります。
- ランタイム ID やビルド構成などの関数メタデータは、Cloud Run サービス定義に保存されます。
- Cloud Run Admin API を使用して関数を安全に編集できます。
- Cloud Run サービス定義を関数の信頼できる情報源として使用できます。
ただし、Cloud Run Admin API で作成された関数は、Cloud Functions API で変更できません。
次の表に、関数の作成、デプロイ、編集、管理方法の違いを示します。
Cloud Run 関数 | Cloud Run functions(第 1 世代) | |
---|---|---|
Google Cloud コンソール | Cloud Run | Cloud Run functions(第 1 世代) |
Cloud SDK |
|
|
REST API |
|
|
Terraform |
|
トリガーと再試行
次の表に、関数のトリガーと再試行を比較します。
Cloud Run 関数 | Cloud Run functions(第 1 世代) | |
---|---|---|
関数をトリガーして呼び出す | Cloud Run Admin API で作成された関数の場合は、Google Cloud コンソールまたは gcloud CLI を使用して関数をデプロイした後に、関数のデプロイの一部としてトリガーを指定します。 Cloud Functions v2 API で作成された関数の場合、トリガーは関数のデプロイの一部として指定します。 |
トリガーは関数のデプロイ時に指定します。 |
イベントタイプ | Eventarc でサポートされているすべてのイベントタイプをサポート(Cloud Audit Logs を介した 90 以上のイベントソースを含む)。 | 7 つのソースからのイベントの直接サポート。 |
再試行数 | Cloud Run Admin API で作成された関数の場合は、Eventarc で再試行ポリシーを更新し、Pub/Sub でデッドレター トピックを構成します。 Cloud Functions v2 API で作成された関数の場合、 --retry フラグを使用して関数のデプロイの一部として再試行を指定します。
|
再試行は、--retry フラグを使用して関数のデプロイの一部として指定します。 |
関数を切断する
Cloud Functions v2 API(gcloud functions
、REST API、Terraform など)を使用して作成された関数は、既存の API 環境から切断できます。関数を切断すると、Cloud Run Admin API を使用してのみ関数を管理できます。これは、ワークロードを Assured Workloads の run.googleapis.com
API 境界内に維持する必要がある場合や、ワークロードで Cloud Run SKU を使用するようにする場合に必要になることがあります。詳細については、Cloud Functions v2 API ドキュメントの関数を管理するをご覧ください。
次のステップ
- Cloud Run で関数をデプロイするのスタートガイドを試す。