Cloud Functions(2nd gen)と Cloud Run の関係性を知る
はじめに
こんにちは、クラウドエース SRE ディビジョン の小堀内です。
最近は、Cloud Run に関するブログ記事を書いたり、Cloud Firestore へのドキュメント追加、Firebase Authentication へのユーザー追加等をトリガーとしたサービスを Cloud Functions にデプロイしたりしていました。
そこで今回は、似ているプロダクトである Cloud Functions(2nd gen)と Cloud Run の関係性について理解を深めるために本記事を執筆することにしました。
Cloud Functions(2nd gen)とは?
まず、本段落を述べるにあたり、Cloud Functions には 1st gen と 2nd gen という 2 つの世代が存在します。
私は本記事を執筆するまで 1st gen しか使用したことがありませんでした。
そもそも Cloud Functions とは?
AWS の Lambda に該当するプロダクトであり、次のような特徴があります。
- サーバーレス
- インフラの管理やスケーリングを自動的に行ってくれるため、開発者はコードの記述に集中できる
- スケーラビリティ
- 需要に応じて自動的にスケールアップ・ダウンする
- 他の Google Cloud プロダクトとの連携
- Firebase や Cloud Storage、Cloud Firestore など、他の Google Cloud プロダクトとの連携が可能
※ 連携するためのイベントトリガーの一覧については、Cloud Functions トリガー を参照してください。
- Firebase や Cloud Storage、Cloud Firestore など、他の Google Cloud プロダクトとの連携が可能
1st gen(第 1 世代) と 2nd gen(第 2 世代)の違い
公式ドキュメント 1st gen と 2nd gen の比較表に分かりやすくまとめられています。
2nd gen(第 2 世代)の特徴
比較表を踏まえ、2nd gen の特徴を整理してみると次のものが挙げられます。
- リクエストのタイムアウト
- HTTP でトリガーされるサービスは最大60分のタイムアウトが可能
- インスタンスのサイズ
- 最大 16 GiB RAM(4 vCPU)までの大きなインスタンスが利用可能
- 同時実行
- インスタンスあたり最大 1,000 件の同時リクエストが可能
- トラフィック分割
- トラフィックを分割する機能が利用可能
- イベントタイプ
- Eventarc でサポートされているすべてのイベントタイプが利用可能
- CloudEvents のサポート
- すべての言語ランタイムで CloudEvents が利用可能
Cloud Run とは?
- サーバーレス の コンピューティングサービス
- 自動スケーリング機能
- コンテナーイメージのビルド と Cloud Run へのデプロイ
- HTTP リクエストに対応
概要については、以前私が書いた記事で述べています。Cloud Run のドキュメントを参照してください。
さらに、詳しい内容が知りたい場合は、2 つのプロダクトの関係性を知る
Cloud Functions(2nd gen)と Cloud Run のプロダクト概要について説明しました。
次は、これら2種類のプロダクトにどのような関係性があるのか理解を深めていきたいと思います。
実は Cloud Functions(2nd gen) は...
Cloud Run の上に構築されています。
検証
Cloud Functions(2nd gen)が Cloud Run 上で動いているということは、
何らかのサービスを Cloud Functions(2nd gen)へデプロイした場合、そのサービスは Cloud Run のコンソール上にも表示されるのでは?
というふうに考えました。
それでは、検証していきましょう。
1. デプロイ対象のサービスを作成
まずは、HTTP リクエストをトリガーとして、クライアントに 'Hello, World!' というメッセージを返す単純なサービスを作成します。
package helloworld
import (
"fmt"
"net/http"
"github.com/GoogleCloudPlatform/functions-framework-go/functions"
)
func init() {
functions.HTTP("HelloGet", helloGet)
}
// helloGet is an HTTP Cloud Function.
func helloGet(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello, World!")
}
2. Cloud Functions(2nd gen) へサービスをデプロイ
次に、1. で作成したサービスを Cloud Functions(2nd gen)へデプロイします。
gcloud functions deploy go-http-function-v2 \
--gen2 \
--runtime=go120 \
--region=asia-northeast1 \
--source=. \
--entry-point=HelloGet \
--trigger-http \
--allow-unauthenticated
3. Cloud Functions コンソールを確認
デプロイ完了後、Cloud Functions のコンソールを確認してみます。
4. Cloud Run コンソールを確認
最後に、Cloud Run のコンソールも確認してみます。
すると、2nd gen のサービスが表示されていることがわかります。
本当に Cloud Functions(2nd gen)は Cloud Run の上で動いていました。
結局 Cloud Functions(2nd gen)と Cloud Run どっちを選ぶ?
Cloud Functions(2nd gen)は実際には Cloud Run の上に構築されているため、機能的には両者の違いはほとんど見られません。
そのため、プロダクト使用者の好みや特定の要件に依存すると考えています。
また、個人的には次のように考えています。
- 開発の容易さを求める場合は Cloud Functions
- デプロイとスケーリングに柔軟性を持たせたい場合は Cloud Run
プロダクト | トリガータイプ | デプロイ単位 | ローカル開発 | 価格 |
---|---|---|---|---|
Cloud Functions(2nd gen) | HTTP リクエスト イベントトリガー |
関数 | 関数フレームワークを使用 | 使用量に応じて課金 |
Cloud Run | HTTP リクエスト イベントトリガー |
コンテナー | ローカルでのコンテナー実行 | 使用量に応じて課金 |
Discussion