はじめに
当該記事はラスベガスで行われていた Google Cloud Next 2025 の Day3 の Enterprise-grade security and scale for serverless workloads with Cloud Run に関する記事となります。
概要
Cloud Run がエンプラにも採用されるようになってきたとのことで、エンプラ向けのアップデートを中心に紹介し、エンプラ環境で動かすにあたり、決め手となったポイント、どういった部分を満たしたから採用したのか、などをまとめて紹介します。
直近のエンプラ向けアップデート
AI 関連
Vertex AI との連携
Vertex AI でホストしているモデルに対して容易にアクセス可能となり、Cloud Run から Gemini の呼び出しが行えます。昨今、生成 AI での利用が増えていることからできるようになった機能のようです。
参考：https://cloud.google.com/run/docs/integrate/vertex-ai?hl=ja
Cloud Run での GPU 利用
Cloud Run で GPU 利用が可能になりました。こちらでも記載しましたが、What’s new Cloud Run のセッションで、Wayfair 社のユーザがアップロードした画像と、既存のシステムにある商品内の画像で比較し、一番近いものを表示及び提案する機能の、画像をベクトル値に計算する処理で使われていまして、決して学習のみで使われるものではなく、サービスで使えるアイディアが大事だな、と痛感しました。今後も GPU を利用した仕組みがでてきそうです。
参考：https://cloud.google.com/run/docs/configuring/services/gpu?hl=ja
Cloud Storage FUSE
Cloud Storage を Cloud Run でマウントできるようになりました。これにより、イメージ内に無いファイルへのアクセスや、巨大な AI モデルなどへのアクセスが、行いやすくなりました。
参考：https://cloud.google.com/run/docs/configuring/services/cloud-storage-volume-mounts?hl=ja
ネットワーク機能の強化
Direct VPC egress
Cloud Run が直接 VPC 内の IP アドレスを取得し、VPC 内リソースへのアクセスが可能になりました。IP アドレスの消費量も4倍から2倍になり、利用しやすさが向上しました。また、Cloud Run Jobs でも利用可能とのことです。利用にあたっては以下の通り、制限がいくつかあるので、そこは事前に確認しておきたいですね。
参考：https://cloud.google.com/run/docs/configuring/vpc-direct-vpc?hl=ja
IAP
Cloud Run 単体で IAP を行うことが可能になりました。これにより、認証を含めた管理画面の接続などを Load Balancer なしで組み込むことが可能です。
参考：https://cloud.google.com/iap/docs/enabling-cloud-run?hl=ja
カスタム制約
作成する Cloud Run service に対して、内部の接続のみ許可を必須にしたり、liveness probe の有効化を必須にしたりということが可能となり、これが不要な NW への公開を行わないようにするために重要な制約となります。
参考：https://cloud.google.com/run/docs/securing/custom-constraints?hl=ja
セキュリティ機能の向上
Cloud Run Threat Detection
Cloud Run へのリモートアクセス試行や一般的なランタイム攻撃(悪意のあるURL、予期しない子シェルなど)を継続的に監視し、脅威検出機能が組み込まれました。Mandiant と Gemini AI の脅威インテリジェンスを活用し、攻撃を検出すると 統合された Security Command Center へ通知されます。これによりコンテナ上で運用中のセキュリティ問題の検出が Google Cloud のサービスで可能となります。
参考：https://cloud.google.com/security-command-center/docs/use-cloud-run-threat-detection?hl=ja
自動ベースイメージ更新
Cloud Run のコンテナイメージのパッチを自動で適用します。なお、ベースイメージは Buildpack で Build した場合に適用されるイメージのみが対象となるため、自分で Build する場合には、Buildpack ベースイメージを利用するか、マルチステージビルドしベースイメージとして利用する必要があります。
参考：https://cloud.google.com/run/docs/configuring/services/automatic-base-image-updates?hl=ja
マルチステージ展開
マルチリージョンでの自動フェイルオーバー
マルチリージョンで構成された Load Balancer にぶら下がっている Cloud Run サービスがあり、1つのリージョンでサービスダウンがヘルスチェックで検知された場合、別の Cloud Run サービスへ自動で切り替わることができます。今までは手動での切替か自動で切り替えるための仕組みが必要でしたので、期待する機能となります、こちらまだ公開されておりませんが、近日公開予定となります。
事例
ANZ銀行の Kubernetes から Cloud Run へ移行した事例についてお話いただきました。
概要
Kubernetes はインフラの制御と大きなオープンソースコミュニティという利点がありましたが、学習コスト、クラスターの管理とアップグレード、リソースの最適化、規制の厳しい金融環境におけるネットワークとコンプライアンスの複雑さといった課題があったとのこと。開発者がインフラ管理ではなく、機能開発に集中できるソリューションを求めていたところ、 Cloud Run に出会い、課題事項を解消できることから導入するに至ったとのことで、詳細についてお話しされておりました。
エンプラ対応までの遷移
初期の Cloud Run は、セキュリティ体制、プライベートネットワーク接続、ユースケースが限られていましたが、2020年から2023年にかけて、VPC アクセスコネクタ、VPC Service Controls、カスタマー管理の暗号化キー（CMEK）、常時 CPU、サイドカー、Cloud Run Jobs などの機能が追加され、エンプラ対応が進み、特に GRPC が大きなアップデートだったとお話しされておりました。
最終的な比較としては以下の通り。
導入による効果
現在の活用数
1600超えのサービスを利用しているとのこと。
また非常に印象的だったのですが、プッシュ通知のサービスで、自動スケーリングを活用し、毎日1億件のリクエストを処理しているとのことでした。
以下の点で効果があったとお話しされておりました。
- 開発生産性の向上
- 内部開発者プラットフォームの導入によりアプリケーションを構築、デプロイできるようになったこと
- インフラコスト削減
- CUD (確約利用割引)を活用
- Direct VPC egress 導入による、インスタンス利用料の削減
- 予期しないコストの急増を防ぐための監視導入
- ゼロスケールの活用
- アプリケーションのデプロイとスケーリングの簡素化
- 自動スケーリングで大量のトラフィックがさばけている
- 管理、セキュリティ、NW の専門性が低減され、マネージドの要素に任せられた
- マルチリージョンにおける以前の複雑構成から脱却しシンプルな構成でマルチリージョンを実現
特に Kubernetes の複雑な構成からシンプルな構成になり、Cloud Run ではスケーリング能力、マルチリージョンにおいてもシンプルな構成である点など、かなり高評価されているように見受けられました。また、現状のアップデートに伴い、更に導入を取り組まれており、今後も、Cloud Run Worker Pool の利用や、自動でのマルチリージョン切り替えなど導入していくようなお話がありました。
まとめ
Cloud Run の様々なアップデートによって、エンタープライズに向けても十分活用できるものになってきたということがよくわかりました。記載されているような Direct VPC egress の対応や、CUD (確約利用割引)の活用、ゼロスケールなど、エンタープライズでなくても、状況に応じて十分検討ないし導入が進められることが多く詰め込まれていたと思います。個人的には、Cloud Run を採用する理由でインフラの容易制がありながら、強力なスケール能力により十分高負荷なサービスに耐えうるものであることが確信に変わりました。また、セキュリティ面でも厳しい要件を満たすことができることがわかったので、それらを活用し、今後提案やアーキテクチャを検討するうえで、今回の情報を活かしながら自信をもって Cloud Run に取り組んでいきたいと思います。
簡単30秒