最近の Cloud Run のアップデートまとめ

サーバーレスサービスで人気の Cloud Run ですが、ここ2~3ヶ月のアップデートでさらに便利になったことをご存じでしょうか？
この記事では、そういった新機能が開発や運用にどのように役立つのか、注目すべきポイントを押さえながら紹介していきます。

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

1つ目は、2024/10/01に GA された「サービスレベルの最小インスタンス数」です。
これまではリビジョンレベルで最小インスタンス数を設定することができ、デプロイすることで反映できました。
しかし、サービスレベルで設定できるようになったことで、デプロイすることなく最小インスタンス数を反映することが可能になりました。
最小インスタンスを頻繁に変更するような運用などで、シームレスに変更ができるのは魅力ですね。
リビジョンレベルの最小インスタンス数と組み合わせることもできますが、制御が複雑になるため避けることが推奨されています。

なお、トラフィック分割を利用する場合は、その比率に基づいてインスタンス数が割り当てられます。
例えば、サービスレベルの最小インスタンス数が10で、50 対 50のトラフィック分割を行っている場合、それぞれのリビジョンに最小インスタンス数5が割り当てられます。

以下でユースケースごとの細かい挙動が紹介されていますので、是非参考にしてください。
トラフィック分割でサービスレベルの最小インスタンス数を使用する

②カスタム組織ポリシー

2つ目は、2024/10/21に GA された「カスタム組織ポリシーの適用」です。
そもそも組織のポリシーとは、Google Cloud の各サービスに対して、組織レベル、フォルダレベル、プロジェクト レベルで適用できる事前に定義された制約です。
また、組織ポリシーの特定のフィールドをカスタマイズすることでより詳細に制御でき、これをカスタム組織ポリシーと呼んでいます。

Cloud Run では、Cloud Run Admin API を使用してカスタム組織ポリシーの制約をYAML形式で記述できます。
例として、サービスを内部に設定する、全てのコンテナにカスタムメモリ上限を適用する、GA 以外のリリースステージを排除する、というような制約を設けることができます。

↓サービスを内部に設定する場合のYAML記述例

name: organizations/ORGANIZATION_ID/customConstraints/custom.ingressInternal
resourceTypes:
- run.googleapis.com/Service
methodTypes:
- CREATE
- UPDATE
condition: "'run.googleapis.com/ingress' in resource.metadata.annotations && resource.metadata.annotations['run.googleapis.com/ingress'] == 'internal'"
actionType: ALLOW
displayName: IngressInternal
description: Require ingress to be set to internal.

適用したカスタム組織ポリシーに違反した場合は、制約 ID と違反したカスタム制約の説明が含まれたエラーログが出力されますので、アラートを出したりして検知しやすいこともメリットの1つですね。

また、2024/12/09には Cloud Run と併せて利用することが多い Serverless VPC Access Connector でも本機能が GA されています。

③インメモリボリューム

3つ目は、2024/11/12に GA された「インメモリボリューム」です。
Cloud Run のボリュームマウントの選択肢には以下がありますが、インメモリボリュームはこれまでプレビューリリースの状態でした。

• Cloud Storage ボリューム
• NFS ボリューム
• インメモリボリューム
• その他（NBD、9P、CIFS / Samba、Ceph）のネットワークファイルシステム

一時的なデータの保管など、外部ストレージを使わずに済む場面で活用しやすいボリュームタイプのため、さらに Cloud Run が使いやすくなったのではないでしょうか。
詳しい使い方については、以下のブログで紹介されていますので是非参考にしてください。
Cloud Runユーザー必見！インメモリボリュームの使い方と注意点

なお、本機能は Cloud Run Service、jobs の両方で利用できます。

④Cloud Run jobs のタスク タイムアウト

4つ目は、2024/11/25にプレビューリリースされた「Cloud Run jobs のタスク タイムアウト」です。
Cloud Run jobs のタスク実行時間が、これまでの最長24時間から最大168時間（7日間）に大幅延長されました。
かなり長時間の対応が可能になったことで、驚いた方も多いのではないでしょうか。

これにより、長時間かかるバッチ処理や大規模なデータ変換などでも、Cloud Batch を使わずに対応できる幅が大きく広がったため、コスト効率良く運用することができます。
また、タイムアウト制限を気にしながら処理を分割したり、ワークアラウンドを検討する手間が不要になるため運用管理の効率化が期待できます。

シンプルながらとても良いアップデートだと思いました。

⑤Cloud Run jobs のサイドカーコンテナ

最後に、2025/01/15にプレビューリリースされた「Cloud Run jobs のサイドカーコンテナ」を紹介します。
これまではCloud Run Service でのみ提供されていた機能ですが、とうとう jobs にも実装されました。
基本的な考え方は Service と変わりませんので、以下のようなユースケースが挙げられます。

• メトリクス、ログ収集、パフォーマンスモニタリング
• 並行処理（メインコンテナの補助）
• サービスメッシュ構成
• 認証認可

Cloud Run jobs で、より多様な使い方ができるようになったことが実感できるアップデートでした。

終わりに

最近アップデートされた Cloud Run の機能について、気になるものをピックアップして紹介しました。
ここで紹介した以外にも細かいアップデートもありますので、気になる方はリリースノートをチェックしてみると、思わぬ発見があるかもしれません。
また、Cloud Run 全体だけでなく jobs のアップデートも頻繁に行われており、ますます需要が高まっているように感じました。
4月の Google Cloud Next 25 でも、さらに新しい機能が発表されることを期待したいですね。