🗂️

Cloud Run サービスのリビジョンの基本

2023/12/07に公開

2023年は「Cloud Run を触って覚える」をテーマとした一人アドベントカレンダーを一人で開催しており、Cloud Run のさまざまな機能や、Cloud Run でよく使う構成などを実際の使い方と一緒にご紹介しています。

https://qiita.com/advent-calendar/2023/cloud-run

7日目は Cloud Run サービスのリビジョンについてご紹介します。Cloud Run のドキュメントを読むと "リビジョン" というワードが当然のように出てきますが、リビジョンとは何か、基本的な役割を解説します。

この記事ではリビジョンに焦点を当てて解説していますが、Cloud Run のリソースモデルのドキュメントではリソース全体について解説しています。こちらもあわせて読むとより理解できます。

https://cloud.google.com/run/docs/resource-model?hl=ja#revisions

Cloud Run の概要は技術評論社さまのブログ「gihyo.jp」に寄稿した記事で解説していますのでこちらもぜひご覧ください。

https://gihyo.jp/article/2023/10/modern-app-development-on-google-cloud-03

リビジョンとは?

リビジョンはデプロイごとに作られる、コンテナ インスタンスに設定する環境設定 (CPU やメモリ、コンカレンシーなど) やコンテナ イメージの設定のまとまりです。

リビジョンはデプロイのたびに作られ、1 つの Cloud Run サービス内に積み重なるように追加されていきます。また、一度作ったリビジョンは変更できません。変更が必要な場合は、新しいリビジョンを追加します。

リビジョン

リビジョンで設定できること

リビジョンでは次のような設定が行えます。

コンテナ イメージ

Cloud Run サービスとして実行するコンテナ インスタンスの元となるコンテナ イメージです。アプリケーションをコンテナ化したもの 1 つが必要ですが マルチ コンテナ を使う場合は 1 つのリビジョンに対して複数のコンテナ イメージを設定します。

コンテナ アプリケーション開発では、コンテナ イメージ自体も、アプリケーション コードの変更に応じて新しいコンテナ イメージを用意する形になります。Cloud Run サービスに使うことを考えると、アプリケーションをデプロイする場合はコンテナ イメージとリビジョンをセットで作る形が基本です。

環境設定

コンテナ イメージ以外には、コンテナ インスタンスの振る舞いを決める様々な環境設定が行えます。

  • 同時実行
  • CPU 制限
  • メモリ制限
  • リクエスト タイムアウト
  • シークレット
  • 環境変数
  • 実行環境
  • HTTP/2
  • ラベル
  • サービス アカウント
  • Cloud SQL 接続
  • VPC 接続

リビジョンとトラフィック

トラフィックが発生したら (実際にリクエストが来たら)、リビジョンがどのように作用するか見ていきましょう。

Cloud Run サービスを作成すると、HTTPS でアクセス可能なエンドポイントが用意されます。このエンドポイントにアクセスすると、Cloud Run サービスへのトラフィックが発生します。

トラフィックが発生すると、Cloud Run サービスはトラフィックを処理するコンテナ インスタンスを立ち上げる必要があります。このときに、指定されたリビジョンを使ってコンテナ インスタンスを立ち上げます。デフォルトでは、デプロイ操作によって最後に追加されたリビジョンが使われます。

リビジョンとトラフィック

トラフィック分割

トラフィックを複数のリビジョンに分割することもできます。例えば次のようにリビジョン A とリビジョン B で 50% ずつ指定した場合、トラフィックは半々に分散されます。

トラフィック分割

トラフィック分割の機能は、カナリアリリースなどのようなデプロイ戦略で役立ちます。

https://cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration?hl=ja

カナリアリリースについては Cloud Deploy を併用する方法がおすすめです。

https://cloud.google.com/deploy/docs/deployment-strategies/canary?hl=ja

タグ付きリビジョン

リビジョンにはタグを付けることができ、タグを付けると専用の URL が付与されます。実際のトラフィックが流れるように割り当てられていない場合でも、この URL にアクセスすると特定のリビジョンに常にアクセスできるようになります。Blue / Green デプロイや、本番環境にデプロイしたあとトラフィックを流し始める前に一旦確認する場合などに有用な機能です。

Blue / Green デプロイの手順については下記のブログが参考になります。

https://cloud.google.com/blog/ja/products/serverless/cloud-run-now-supports-gradual-rollouts-and-rollbacks?hl=ja

リビジョン タグを活用したプル リクエスト プレビューに関する参考記事

Cloud Run のドキュメントには Cloud Build を使って GitHub のプル リクエストごとのプレビュー環境を作るチュートリアルを公開しています。

https://cloud.google.com/run/docs/tutorials/configure-deployment-previews?hl=ja

ちょうど Google Cloud Japan アドベントカレンダー 2023 (通常編) でプル リクエストごとの確認環境を作る方法を解説した記事を公開しています。この記事では Cloud Deploy や GitHub Actions を組み合わせた、プル リクエストごとの環境を運用も踏まえた上で構築する方法を解説しています。

https://zenn.dev/google_cloud_jp/articles/f7469868d64802

まとめ

この記事ではリビジョンに焦点を当てて紹介しました。これできっと、Cloud Run のドキュメントを読んで「リビジョン」というワードが出てきても怖くないはず!

基本的にはデプロイ コマンドを叩くなどの方法でリビジョンを自動的にアップデートしていくことはできるので、それだけでもシンプルなデプロイ フローが実現できます。その上で、リビジョン タグを活用したプル リクエスト専用のプレビューなどのような、次のステップとしての応用もしやすいです。リビジョンの様々な機能も、ぜひ活用していってください。

Google Cloud Japan

Discussion