G-genの佐々木です。当記事では Google Cloud の Cloud Run functions（旧 Cloud Functions）について解説します。

Cloud Run functions の基本

Cloud Run functions とは

Cloud Run functions（旧 Cloud Functions）とは Google Cloud（旧称 GCP）が提供するサーバーレスのコンピューティングサービスです。ユーザーがサーバーやコンテナをプロビジョニング、管理することなくクラウド上でコードを実行することができます。いわゆる FaaS（Function as a Service） と呼ばれるプロダクトです。

HTTP リクエストをトリガにして起動する HTTP 関数 や、特定のイベントが発生するとコードが実行される イベントドリブン関数 としてデプロイでき、トリガとなるイベントによって Web API やリアルタイム ETL 処理、定期実行タスクなど様々な使い道があります。

Cloud Run functions の最長実行時間は、 HTTP 関数で60分間、イベントドリブン関数で10分間です。またCloud Run functions（第1世代）の場合は関数の種類に関わらず最大9分間であり、短い処理の実行が想定されています。

他のクラウドベンダーの類似サービスとして AWS の AWS Lambda 、 Microsoft Azure の Azure Functions などがあります。

Cloud Run functions には第1世代と第2世代があり、現在では後発の第2世代が推奨されます。Cloud Run functions 第2世代では基盤となる仕組みとして Google Cloud のサーバーレスコンテナ実行サービスである Cloud Run が使われています。

参考 : Cloud Run functions overview

リブランディング

2024年8月22日（日本時間）、Cloud Functions は Cloud Run functions としてリブランディングされました。これに伴い、名称は以下のようになりました。

旧称	新名称
Cloud Functions（第1世代）	Cloud Run functions（第1世代）
Cloud Functions（第2世代）	Cloud Run functions

当記事では便宜上、従来 Cloud Functions（第2世代）と呼ばれていたものを「Cloud Run functions（第2世代）」と記載している箇所があります。

リブランディングについては、以下の記事も参照してください。

blog.g-gen.co.jp

サーバーレス

Cloud Run functions はいわゆる サーバーレス（Serverless） なコンピューティングサービスです。

Serverless という語は「サーバーのない」という意味になりますが、実際には Google の各リージョンのデータセンターにサーバーが存在しています。ここでのサーバーレスとは、ユーザーが「サーバーの存在を意識することなく」コードを実行できることを意味します。

Cloud Run functions では、サーバーのプロビジョニング、スケールアップ、メンテナンス等の管理を全て Google に任せ、ユーザーはその上で動かすコードの開発のみに集中することができます。

ユーザーがコードをデプロイした後、その実行がトリガーされると、実行環境が即座にプロビジョニングされ、また必要に応じて自動でスケーリングします。

サポートされている言語

2024年8月現在、Cloud Run functions では以下の言語（ランタイム）がサポートされています。

Node.js
Python
Go
Java
Ruby
PHP
.NET Core

最新のサポート状況については、以下の公式ドキュメントをご参照ください。

参考 : Cloud Run functions execution environment

ユースケース

Cloud Run functions のユースケースを紹介します。公式ドキュメントにも代表的なものがいくつか紹介されているので、併せてご確認ください。

以下はPub/Subトリガーの関数を用いた、Compute Engineインスタンスの自動停止・起動の仕組みとなります。

Cloud Schedulerでcronを設定し、指定した時間にPub/Subに対してメッセージをパブリッシュします。
Pub/Subにメッセージがパブリッシュされると、Pub/SubトリガーによりCloud Run functions関数が呼び出されます。
Cloud Run functions関数のコードからCompute Engine APIを呼び出し、Compute Engineインスタンスを停止もしくは起動します。

上記の処理の中で、ユーザーが行わなければならないのはコードの記述と各サービスの設定のみとなっており、各サービスの設定は慣れていれば30分もかからないくらい簡単なものとなっています。

このような非常に少ない手間で決められた処理を実行することができる点が、Cloud Run functions の魅力です。

関数の種類

2種類の関数

Cloud Run functions にデプロイしたコード（これ以降は Google のドキュメントに倣い、「関数」と表記します）の実行をトリガーするイベントとして、大きく分けて HTTP トリガーとイベントトリガーの2種類があります。

HTTP トリガー

HTTP トリガーでは、関数をデプロイした際に発行されるエンドポイント URL に対して、 HTTP リクエストが送信されることで関数が実行されます。

HTTP の呼び出しは同期的で、関数の実行結果は HTTP リクエストのレスポンスとして呼び出し元に返されます。

イベントトリガー

イベントトリガーでは HTTP トリガーのような URL は発行されず、関数が存在するプロジェクト内のイベントに応答する形で実行されます。代表的なものとしては以下のトリガーがあります。

トリガー名	説明
Eventarc トリガー	Cloud Run functions（第2世代）では原則、イベントドリブン関数は Eventarc トリガーとして実装されます。第1世代では利用できません。
Pub/Sub トリガー	Pub/Sub トピックにパブリッシュされたメッセージによって関数がトリガーされます。
Cloud Storage トリガー	Cloud Storage オブジェクトの作成、更新、削除などのイベントによって関数がトリガーされます。
Cloud Firestore トリガー	Firestore ドキュメントの作成、更新、削除などのイベントによって関数がトリガーされます。第1世代のみ。

Cloud Storage のイベントをトリガにして起動する Cloud Run functions について以下の記事で取り上げていますので、ご参照ください。

blog.g-gen.co.jp

ロギング

Cloud Run functions では標準出力に出力されたテキストデータは、自動的に Cloud Logging に送出され、コンソール画面や API コールで取り出せるようになります。

Python を例に取ると print() や logger で出力された文字列が、自動的に Cloud Logging に送られます。

しかしこの方法ですと Cloud Logging 上でログレベル表記に反映されないなどの問題があります。

Cloud Run functions (Python) におけるロギングについて記載した以下の記事も、ご参照ください。

blog.g-gen.co.jp

Cloud SDK の利用

Cloud SDK のユースケース

Cloud Run functions の最も多いユースケースの一つは、Functions 内で Cloud SDK を用いて他の Google Cloud API を呼び出して操作を行うことです。

例えば、以下の記事のように、 Compute Engine API をコールして VM のバックアップを自動化すること等が考えられます。他にも Cloud Storage のオブジェクトを操作することなども一般的に行われています。Cloud Fucntions と Cloud SDK は切っても切れない関係性にあると言えます。

blog.g-gen.co.jp

Cloud SDK の認証

Google Cloud API をコールするには認証・認可が必要です。

Cloud Run functions に サービスアカウント というプログラム専用の Google アカウントをアタッチすることができます。

Cloud Funcitons で Cloud SDK を実行すると、自分にアタッチされているサービスアカウントの認証情報で API コールを実行してくれます。

モジュールの依存関係

Cloud Run functions のプログラムから、Cloud SDK を始めとしたランタイム組み込みではないモジュールを呼び出すときは、依存関係にあるモジュールをデプロイパッケージに含ませる必要があります。

利用例が多い Python を例に取ると、以下の2つの方法があります。

main.py と同じディレクトリに requirements.txt ファイルを配置する (デプロイ時に自動的にインストールされる)
zip 化したデプロイパッケージに依存関係ファイルを含ませる

Cloud Run functions のランタイムにはデフォルトで組み込まれているパッケージもあり、各言語ごとに異なります。詳細は、以下のドキュメントをご参照ください。

参考 : Python での依存関係の指定
- 各言語ごとのドキュメントは左部メニューから遷移可能

料金

第1世代

第1世代の料金の基本

Cloud Run functions (第1世代) の料金は以下の項目によって決まります。（公式ドキュメント）

関数の呼び出し回数
関数の実行時間
データ転送料金（関数によって送信ネットワークリクエストが作成された場合）
関数のイメージの保存（Container Registry利用料）

それぞれ安価かつ月ごとの無料枠も存在するため、先のユースケースで紹介したような使い方であれば、ほとんど、あるいは全く課金されることなく使用することができるでしょう。

関数の呼び出し回数

関数を実行した回数に応じた課金となります。

呼び出し回数（1ヶ月あたり）	料金（100万回あたり）
最初の200万回	無料
200万回を超えた分	$0.40

呼び出し料金は1回あたり$0.0000004円と非常に安価であり、そのうえ1ヶ月のうち最初の200万回は無料で呼び出すことが可能です。

関数の実行時間

関数の呼び出しから完了までの時間に応じた課金となります。

Cloud Run functionsでは関数のデプロイの際、関数が使用できるメモリ容量を7段階から指定することができます。

指定したメモリ容量に応じてvCPUが割り当て られ、また単価も高くなります。

また、リージョンごとに Tier 1 と Tier 2 に料金設定が分かれており asia-northeast1 (東京リージョン) は Tier 1 となります (参考) 。

メモリ	vCPU	料金/100 ms（Tier 1 料金）	料金/100 ms（Tier 2 料金）
128 MB	.083 vCPU (200MHz)	$0.000000231	$0.000000324
256 MB	0.167 vCPU (400MHz)	$0.000000463	$0.000000648
512 MB	0.333 vCPU (800MHz)	$0.000000925	$0.000001295
1,024 MB	0.583 vCPU (1.4GHz)	$0.000001650	$0.000002310
2,048 MB	1 vCPU (2.8GHz)	$0.000002900	$0.000004060
4,096 MB	2 vCPU (4.8GHz)	$0.000005800	$0.000008120
8192 MB	2 vCPU (4.8GHz)	$0.000006800	$0.000009520

こちらの無料枠は少々分かりづらいのですが、メモリの使用時間とvCPUの使用時間に分かれており、以下のようになっています。

1ヶ月あたり400,000 GB秒（GB秒 = 1GBのメモリを使用した場合の1秒）のメモリ使用
1ヶ月あたり200,000 GHz 秒（GHz秒 = 1GHzのCPUを使用した場合の1秒）のvCPU使用

データ転送料金

関数から外に送られるデータのサイズに応じて課金されます。ただし同一リージョン内の Google API に対する送信は無料です。別リージョンの API を呼んだり、インターネットへ通信をするサイズに課金されます。

タイプ	料金/GB
送信データ	$0.12
受信データ	無料
同じリージョン内のGoogle APIへの送信データ	無料

こちらは、1ヶ月あたり5GBのデータ送信までが無料枠となっています。

関数のイメージの保存

関数はデプロイされると Container Registry または Artifact Registry にコンテナイメージとして保存されるため、保存したイメージの容量分だけ課金されます。デフォルトではイメージファイルが Container Registry に保存されます。

1GBあたり Container Registry の場合は$0.026/月、 Artifact Registry の場合は$0.10/月（こちらは0.5GBまで無料）です。

料金例

試しに、以下の条件で料金を計算してみます。

計算にはGoogle Cloud Pricing Calculatorを使用します。

関数の呼び出し回数 → 300万回 / 月
関数の実行時間 → 1,000ms / 回
関数に割り当てるメモリ容量 → 256 MB
Google Cloudのリージョン内で完結する処理（asia-northeast1を使用）

この条件では、1ヶ月あたり $ 4.40 となります。

第2世代

第2世代の料金の基本

Cloud Run functions（第2世代）は Cloud Run を基盤としているため、Cloud Run の料金が適用されます。

実行時間ごとの料金 (CPU/Memory) + リクエスト数ごとの料金 + データ転送料金 + イメージの保存料金がかかる点で、原則は第1世代と同じです。

vCPU は毎月最初の 180,000 vCPU 秒、メモリは最初の 360,000 GiB 秒、リクエスト数は毎月 200 万リクエストまでが無料枠として用意されています。

また第2世代ではイメージの保存に Container Registry は使われず、 Artifact Registry の保管料金が適用されます。

料金例

第1世代の料金例と同条件で試算してみます。

関数の呼び出し回数 → 300万回 / 月
関数の実行時間 → 1,000ms / 回
関数に割り当てるメモリ容量 → 256 MB
Google Cloudのリージョン内で完結する処理（asia-northeast1を使用）

この条件では、1ヶ月あたり $0.40 となります。

制限

基本編の締めとして Cloud Run functions を利用する際の制限事項についても軽く触れておきたいと思います。

Cloud Run functions の制限事項はいくつかありますが、その中から特に重要なものだけ抜粋します。

制限対象	上限	備考
最長実行時間 (HTTP 関数)	9分 (第1世代) / 60分 (第2世代)	上限を過ぎた場合は関数がタイムアウトとして強制終了されます。
最長実行時間 (イベントドリブン関数)	9分 (第1世代) / 9分 (第2世代)	同上
最大同時実行数	3,000	同じ関数を同時に実行できる数
最大呼び出しレート	1,000 / 秒	同じ関数が秒間あたりに応じられるリクエストレート

重要なポイントとして Cloud Run functions の最大実行時間は、第1世代で 9 分 、第2世代で 10 分 (イベントドリブン関数) / 60分 (HTTP 関数) です。このことから Cloud Run functions は 処理時間が長いバッチ処理には向かない ことが分かります。そのような場合は Cloud Run 等、別のサービスを検討することになります。

Cloud Run functionsを徹底解説！

Cloud Run functions の基本

Cloud Run functions とは

リブランディング

サーバーレス

サポートされている言語

ユースケース

関数の種類

2種類の関数

HTTP トリガー

イベントトリガー

ロギング

Cloud SDK の利用

Cloud SDK のユースケース

Cloud SDK の認証

モジュールの依存関係

料金