[GCP]Cloud Run services

公式ドキュメントをベースに自分の言葉でまとめた記事。
初稿は1,2年前に限定共有で作成し、継ぎ足し継ぎ足しで書いてきたので、ちょっとおかしい点あるかもしれませんがご了承ください。

注意
Cloud Run jobsはまた別のGCPサービスです。

1. 概要

フルマネージドでサーバレスなコンテナサービス。Kubernetesの機能を気軽に利用できる。
主な用途はAPI, Webアプリケーション、ストリーミング。
Webサーバの役割(HTTP/gRPC対応)はCloud Runが吸収してくれる。
デプロイは数秒で完了、スケーリングもいい感じに自動でやってくれる

リソースモデル

出典: リソースモデル

リビジョンとそれらを束ねるサービスから成り立つ。外部からはサービスに対してアクセスする形になる。

サービス

外部から通常利用するエンドポイントURLが発行され、複数のリビジョンを束ねる単位。
外部からは、サービスにリクエストが届いて、リビジョンにトラフィックが振り分けられるという形。

リビジョン

コンテナイメージをサービスへデプロイする際に作成されるもの。
「コンテナ化するイメージ・コンピューティングリソース・スケーリング等の設定であり、サービスのバージョン」である。
リビジョンのくくりで、コンテナのインスタンスがスケーリングされる。

トラフィックの制御

各リビジョンに対して、サービスへのトラフィック(外部からのトラフィック)を何％流すかという設定ができる。
これによりトラフィックをリビジョン間で分割しながら段階的にロールアウトするといったこともできる。

タグ付きURL

リビジョンにはタグを付与することができる。
タグを付与するとタグ含みのエンドポイントURLが発行される(タグ付きURL)。
タグ付きURLは、サービスへのトラフィックを新しいリビジョンにルーティングしなくても利用できる。
ルーティング前に新しいタグ付きリビジョンでテストして問題ない → そのリビジョンを正式にトラフィック100%でルーティングしてリリースするということができる(ブルーグリーンデプロイ)。

オートスケーリングのロジック

スケーリングのロジックの詳細はわからないが、そのトリガーとなる要素は公開されている。

2. 制限事項

コンテナサービスとしてCloud Runを利用する上での主な制限事項。
公開するサービスの要件にこれらが邪魔になってしまうのであれば、k8sの知識が必要になる分ハードルは高くなるがGKEを使うことを検討した方がよい。

コンテナイメージ内の実行ファイルのフォーマット

• Linux x86_64(amd64)

コンテナ内アプリケーションのリッスンポート

• 外部から渡されたリクエストを処理するためにCloud Runの環境変数PORTに設定している値をリッスンする必要がある。デフォルト値は8080。

Cloud Runからのレスポンスタイムアウト

• デフォルト5分、Max60分で設定可能。タイムアウト時は504エラーになる

Cloud Runから外部へのリクエストタイムアウト

• VPCへのリクエスト: 10分
• インターネットへのリクエスト: 20分

コンテナ内のファイル保存

• ファイルシステムはインメモリであり、コンテナが停止すると書き込まれたデータは破棄される

1コンテナインスタンスあたり1コンテナしかデプロイできない
- Cloud RunはGKEのようなコンテナオーケストレーションツールではない
(マルチコンテナ構成が2023年11月よりGAになった)

1コンテナインスタンスあたりのスペック
(第2世代の場合)

CPU(コア数)	メモリ
1	512MB〜4GB
2,3	1GB〜8GB
4,5	2GB〜16GB
6,7	4GB〜32GB
8	4GB〜32GB

1コンテナインスタンスあたりの同時リクエスト受付数

• デフォルト値80、最大1000まで設定可能

1リビジョンのコンテナインスタンス数のオートスケーリング設定可能幅

• 最小: 0
• 最大: リージョン単位でベースの値が定められている。Googleにお願いして上限突破可能

リビジョンインスタンスのオートスケーリング設定で細かく条件を設定できない
先述の通り、詳細なロジックは不明である。

3. 設定項目

Cloud Run servicesにサービスを追加する際に、開発者が設定することになる項目。

• サービス名
• サービスを作成するリージョン
• サービスの説明
• サービスへのアクセスに関する制限(外部から完全にOK/LBを介する/内部リソースからのみ、IAM認証ユーザー/全ユーザー)
• リビジョンへのトラフィック制御方法(100%最新のリビジョンへ流す or 指定した複数のリビジョンへ流す)
• リビジョンのテンプレート設定(以下)
  • リビジョン名
  • リビジョンのインスタンス数の範囲(オートスケール)
  • リビジョンから別のGCPリソースへのトラフィックの転送方法
  • レスポンスタイムアウト値
  • 他のGCPリソースを操作する際のサービスアカウント
  • 1リビジョンが管理するコンテナの設定(複数コンテナを設定可能ではある)
  • コンテナ化するイメージのURL
  • エントリポイントの実行コマンド
  • エントリポイントに渡す引数
  • 環境変数のリスト(Secretの値も環境変数として読み込ませることが可能)
  • CPU数(メモリ設定と相互に制約あり)
  • メモリ容量(CPU数設定と相互に制約あり)
  • 常時CPUを割り当てさせるか(コールドスタート拒否するか)
  • コールドスタートに備えたCPUブースト設定するか
  • コンテナへ転送するポートのプロトコル(HTTP or HTTP2)とポート番号
  • コンテナの死活監視の設定
  • マウントする他リソースのストレージ

4. 使ってみたその1

「Cloud Run に Go サービスをデプロイする」をベースに、「Goサービスのソースコードからのデプロイ」をしてみる

前提

• Macでの作業である
• GitHubアカウントがある
• 「Google Cloudの無料トライアル」に申し込みが完了しており、「Google Cloudコンソール」へログイン済みである

4.1. 動作確認用のGoogle Cloudプロジェクトを作成する

①グローバルナビゲーションのプルダウン(My First Projectと書かれているところ)を押下
②「プロジェクトの選択」ダイアログで「新しいプロジェクト」を押下

③任意のプロジェクト名を入力して「作成」を押下

→通知で緑のチェックがつけば作成完了

4.2. Google Cloud CLIをインストールする

以下に従ってインストールする

メモ

Pick cloud project to use:

では、4.1.で作ったプロジェクトの番号を入力する。
プロジェクトIDはグローバルナビゲーションのプルダウン押下で表示される「プロジェクトの選択」ダイアログで確認可能

4.3. 動作確認用のGoモジュールを作成

以下を参考に、動作確認用のGoモジュールを作成する

①GitHubへ「cloud_run_test」という名前のリポジトリを作成
②git cloneしてローカルリポジトリを作成
③ローカルリポジトリの作業用ディレクトリでmain.go作成(中身はこれをコピペ)
④go mod init github.com/<オーナー名>/cloud_run_testしてgo.modファイルを作成

4.4. ソースコードからのデプロイをする

①cd <作業用ディレクトリのパス>で4.3.で作成したGoモジュールの作業用ディレクトリへ移動する
②gcloud run deployでソースコードからのデプロイを実行する(色々問われるので回答して続けていく)

• Service name: Cloud Runへ作成するサービス名をどうするか → 任意。デフォルトのままでいい
• Please specify a region: Cloud Runサービスのリージョンをどうするか → 任意。とりあえず3番の東京リージョンに
• API [artifactregistry.googleapis.com] not enabled on project []. Would you like to enable and retry (this will take a few minutes)?: Artifact RegistryのAPIが、デプロイ対象のGoogle Cloudプロジェクトで有効化されていない。有効化して続行するか → Y
• Allow unauthenticated invocations to []: 未認証の呼び出しを許可するか → y
• API [cloudbuild.googleapis.com] not enabled on project []. Would you like to enable and retry (this willtake a few minutes)?: Cloud BuildのAPIがデプロイ対象のGoogle Cloudプロジェクトで有効化されていない。有効化して続行するか → y

このコマンドの実行により、実際には以下のような感じで処理されていくっぽい(ちょっと違う部分はあるかも)

→完了すると以下のようにターミナル表示される

Building using Buildpacks and deploying container to Cloud Run service [<②で設定したCloud Runサービス名>] 
in project [<Google Cloud プロジェクトID>] region [<②で設定したリージョン>]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/xxxxxxxxxxxx
  xxxxxxxxxxxx?project=<Google Cloud プロジェクト番号>].
  ✓ Creating Revision... Revision deployment finished. Checking container health.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [<②で設定したCloud Runサービス名>] revision [<②で設定したCloud Runサービス名>-xxxxx-xxxxx] has been deployed and is serving 100 percent of traffic.
Service URL: https://<②で設定したCloud Runサービス名-xxxxxxxxx-an.a.run.app

※Building Containerのときに、Cloud Buildに行くとビルド進捗が確認できる

表示されているURLをブラウザで開くと以下のように表示される

!!!注意!!!

• Cloud Storageに保存されるソースコード
• Artifact Registryに保存されるコンテナイメージ

それぞれで料金がかかるので、動作確認後はそれぞれ削除しておいた方がよい

5. 使ってみたその2

既存コンテナイメージを使ったCloud Runサービスの作成をしてみた。
以下の手順は、クイックスタート: Cloud Run にデプロイするに基づいて、Artifact Registryに存在するコンテナイメージからサービスを作成する例.

①グローバルナビゲーションのプルダウンを押下して、4.1.で作成したプロジェクトを選択する
②グローバルナビゲーションの検索ボックスから「Cloud Run」のコンソールへ移動する
③「サービスの作成」を押下する

④以下それぞれ埋めて「作成」を押下する

項目	設定値	補足
デプロイ方式	既存のコンテナイメージから1つのリビジョンをデプロイする + サンプルコンテナでテスト押下
サービス名	cloud-run-test	今回のモジュール名と一致させてるだけ
リージョン	asia-northeast1(東京)	任意。
CPUの割り当てと料金	リクエストの処理中にのみCPUを割り当てる
自動スケーリング	最小:0 最大:100
Ingress	すべてのトラフィックを許可する
認証	未認証の呼び出しを許可

→「サービスの詳細」画面へ遷移するので、全項目に緑のチェックがつくまで待つ

6. Cloud Runサービスの設定

TODO: 以下についてそれぞれどういうことになるのかまとめたい

■CPU割当と料金
- リクエストの処理中にのみ CPU を割り当てる(課金はリクエスト単位であり、またコンテナ インスタンスがリクエストを処理した場合にのみ発生します。
- CPU を常に割り当てる(コンテナ インスタンスのライフサイクル全体に対して課金されます。

■自動スケーリング
- 1に設定すると「コールドスタートが減少します」って何？

■Ingress
- すべてのトラフィックを許可する
- 内部トラフィックと Cloud Load Balancing からのトラフィックを許可する
- 内部トラフィックのみを許可する

■認証
- 未認証の呼び出しを許可(公開する API またはウェブサイトを作成する場合は、このチェックボックスをオンにします。
- 認証が必要(Cloud IAM を使用して承認済みユーザーを管理します。

7. gcloud run deployコマンドについての所感

「gcloud run deploy」コマンドでフルに引数を指定すると、以下のようなことが一気にできる

ソースコードの圧縮 + Cloud Storageへのアップロード
→ Cloud Build を使ったコンテナイメージのビルド & Artifact RegistryへイメージをPUSH
→ イメージをCloud Run servicesへデプロイ(リビジョンのテンプレート設定変更・作成 & インスタンス化)

リビジョンのテンプレート設定には、コンテナのCPUやメモリといったインブラリソースの設定も含まれている。
これを変更できてしまう。
Terraformを利用するなどして、インフラを一元的管理しているような場合は、バッティングしてしまうため注意が必要。

8. デフォルトのサービスアカウント

リビジョンにおいて、明示的にサービスアカウントを設定しなくてもデフォルトのサービスアカウントが設定される。
このデフォルトのサービスアカウントはかなり多くの操作ができる権限を持っている。
セキュリティ的には、公式からの案内にもある通り、権限をちゃんとしぼったサービスアカウントを別途用意してやる方がよさそう。

9. 参考

Cloud Runの概要の理解に

Cloud Run + αで構成するシステムの図がとてもわかりやすい

Cloud Run + Cloud Spannerのおすすめ構成がのってる

※CEDECでの公演とあわせると、補足説明があってもっとわかりやすい

---