Cloud Runの「サービス」と「リビジョン」のスケーリング設定：違いと使い分け

Cloud Runの大きな特徴の一つは、柔軟なデプロイとスケーリング機能です。
しかし、設定画面を見ていると、「サービスのスケーリング」と「リビジョン スケーリング」という似たような言葉が出てきて、混乱する方もいるかもしれません。

今回は、この2つのスケーリング設定が何を示しているのか、そしてどのように使い分けるべきかを解説していきます。

Cloud Runにおける「サービス」と「リビジョン」の基本

まず、Cloud Runの基本的な概念である「サービス」と「リビジョン」について再確認しましょう。

サービス (Service)

外部からアクセス可能なURLを持つ、Cloud Runアプリケーションの最上位の論理的なまとまりです。

常に最新のリビジョンにトラフィックをルーティングしたり、複数のリビジョン間でトラフィックを分割したりする役割を担います。

ウェブサイトのURL（例: my-api.run.app）に相当します。

リビジョン (Revision)

特定のコンテナイメージ、環境変数、CPU/メモリ割り当て、同時実行数など、サービスのある時点での具体的な構成を指します。

サービス設定を変更してデプロイするたびに、新しいリビジョンが作成されます。

各リビジョンには、固有の（外部から直接アクセスできない）タグURLが存在します。

「サービスのスケーリング」と「リビジョン スケーリング」の違い

Cloud RunのコンソールUIを見ると、スケーリングに関する設定が、主に「サービスレベル」と「リビジョンレベル」の2つの場所で提供されていることが分かります。

それぞれの設定が適用される範囲とタイミングが異なります。

1. サービスのスケーリング設定 (Service-level scaling)

これは、Cloud Runサービス全体の挙動に影響を与えるスケーリング設定です。現在、UI上では最小インスタンス数（Min instances）のみがサービスレベルで設定可能になっています。

対象となる設定:

最小インスタンス数 (Min instances): Cloud Runサービス全体として、常に稼働させておくコンテナインスタンスの最小数。

特性:

• この設定は、どのリビジョンにトラフィックがルーティングされているかに関わらず、サービス全体に適用されます。
• 例えば、サービスレベルで最小インスタンス数を1に設定した場合、サービスが持つどのリビジョンがアクティブであっても、常に最低1つのインスタンスが稼働を維持します。
• 新しいリビジョンをデプロイしても、このサービスレベルの最小インスタンス設定はそのまま引き継がれます。

目的:

• コールドスタート対策: サービス全体のコールドスタートを抑制したい場合に設定します。これにより、サービスが常に最低限のリソースを確保し、どのリビジョンが呼び出されても高速に応答できるようにします。
• シンプルさ: サービス全体の挙動を統一したい場合に便利です。

---

2. リビジョン スケーリング設定 (Revision-level scaling)

これは、**特定の「リビジョン」**の挙動に影響を与えるスケーリング設定です。Cloud Runで新しいリビジョンをデプロイする際、この設定を行います。

対象となる設定:

• 最小インスタンス数 (Min instances): そのリビジョン固有の、常に稼働させておくコンテナインスタンスの最小数。
• 最大インスタンス数 (Max instances): そのリビジョンがスケールアウトできるインスタンスの最大数。

特性:

• これらの設定は、そのリビジョンがアクティブである間のみ適用されます。
• 例えば、Aリビジョンで最大インスタンス数を5、Bリビジョンで最大インスタンス数を10と設定できます。
• トラフィックを分割して複数のリビジョンにルーティングしている場合、それぞれのリビジョンは独自のスケーリング設定に従って動作します。

目的:

• 段階的ロールアウト (Canary Deployment): 新しいリビジョン（カナリア版）をデプロイする際、そのリビジョンだけに特化したスケーリング設定（例: 最大インスタンス数を低く設定して影響を限定するなど）を適用できます。
• A/Bテスト: 異なる性能のリビジョンでテストを行う際に、それぞれのリビジョンに最適なスケーリング設定を適用できます。
• 特定の古いリビジョンの維持: 過去のリビジョンを、デバッグ目的などでわずかなインスタンス数で維持したい場合に便利です。

---

サービスレベルとリビジョンレベルの設定の相互作用

Google Cloudの公式ドキュメントによると、以下の重要な相互作用があります。

サービスレベルの最小インスタンス数:

• サービスレベルで最小インスタンス数を設定すると、トラフィックがルーティングされているすべてのリビジョンに対して、そのインスタンスをウォームに保とうとします。
• ただし、もし特定のリビジョンに「リビジョンレベルの最小インスタンス数」が設定されている場合、そのリビジョンの設定が優先されます。そして、そのリビジョンはサービスレベルの最小インスタンス数とは別にカウントされます。
• 簡単に言えば、サービス全体で「最低1台は動いていてほしい」というニーズを満たしつつ、特定の重要なリビジョンは「絶対2台は動いていてほしい」という設定もできる、ということです。

どちらの設定を使うべきか？

• 新規デプロイ時: 基本的に、リビジョン スケーリング設定（最大インスタンス数、同時実行数、CPU割り当てなど）を使用して、サービス全体として望ましいデフォルトのスケーリング挙動を設定します。
• サービス全体のコールドスタート対策: もし、サービス全体としてコールドスタートを避けたい場合は、サービスレベルの最小インスタンス数を設定します。
• トラフィック分割やA/Bテスト: 複数のリビジョンを同時に運用し、それぞれに異なるパフォーマンス要件やコスト制限を設けたい場合は、リビジョン スケーリング設定を活用します。例えば、新しいテスト版リビジョンには低い最大インスタンス数を設定して、予期せぬ負荷やコストを防ぐことができます。

まとめ

Cloud Runの「サービスのスケーリング」と「リビジョン スケーリング」は、アプリケーションの運用フェーズで便利なツールとなります。

• サービスのスケーリング: サービス全体に適用される、主に最小インスタンス数の設定（サービス全体のコールドスタート対策）。
• リビジョン スケーリング: 各デプロイバージョン（リビジョン）に固有のスケーリング設定（最大インスタンス数、同時実行数、CPU割り当てなど）であり、トラフィック分割時に特に威力を発揮します。