勝手に！深堀り！Cloud Run worker pools / Deep dive Cloud Run worker pools

Transcript

1. 深堀り！
 Cloud Run Worker Pools 
 Synspective 新井 雅也
 勝手に！

2. 新井 雅也 Synspective Inc. プリンシパルエンジニア 
 
 現在は衛星の開発・運用を手掛けるスタートアップ企業にて、 
 クラウドを中心とした技術力を活かしつつ、宇宙業界の発展に尽力し ている。クラウド関連の技術書を多数執筆。 
 
 好きなサービス: GKE、Cloud Run 
 趣味：Red Bull(日課)、LEGO、読書、キャンプ、植物収集、 
 　　　世界遺産巡り(世界遺産検定1級保持) 
 msy78

3. ⚠ Disclaimer ⚠
 本発表資料は2025年4月24日時点における 
 Google Cloud アップデート状況に基づいて作成しています 

4. まずは Google Cloud Next 2025 で発表された 
 GKE & Cloud Run 関連の 
 アップデートのおさらいから 

5. Google Cloud Next 2025 期間中に発表された 
 GKE 関連アップデート一言サマリ 
 GKE Inference Gateway 
 Performance HPA profile 
 Container-optimized Autopilot 
 プレビュー 
 ・LLM推論ワークロード向け負荷分散機能 
 ・LLM固有のメトリクスに基づいてルーティング 
 ・GKE水平スケールの判断に必要な計算が高速化 
 （従来比の3倍） 
 ・Autopilotリソース最適化を標準GKEクラスターに適用可能 
 ・利用できるのは2025Q3から(予定) 
 GA
 ロードマップ 

6. Google Cloud Next 2025 期間中に発表された 
 Cloud Run 関連アップデート一言サマリ 
 Cloud Run IAP built-in 
 Cloud Run GPU 
 Cloud Run Worker Pools 
 Cloud Run Health for regional failover 
 VPC egressの改善 
 Cloud Run Threat Detection 
 プレビュー 
 ・ロードバランサ不要でIAPが適用可能 
 GA
 ・その名の通り、Cloud RunでGPUが利用可能 
 ・Tokyoリージョンは未サポート 
 プレビュー 
 ・service/jobsとは異なる新しい実行モデル 
 ・詳細はのちほど 
 
 GA
 ・確保が必要なサブネットIPアドレス数が半減(4倍→2倍) 
 ・Cloud Run jobsでも利用可 
 プレビュー 
 ・Security Command Centerとの統合 
 ・ランタイム攻撃や脆弱性等を検知 
 プレビュー 
 ・マルチリージョンにおけるフェイルオーバーサポート 
 ・startupProbeのシグナルとServerless NEGの連携 

7. 詳細はGoogle Cloud Next 25 
 サマリーセッション資料（日本語）にて詳しく解説されています。 
 
 https://cloud.google.com/resources/content/intl/ja-jp/nextlv25-jp-recap

8. さて、改めて本日のテーマは 

9. Google Cloud Next 2025 期間中に発表された 
 Cloud Run 関連アップデート一言サマリ 
 Cloud Run IAP built-in 
 Cloud Run GPU 
 Cloud Run Worker Pools 
 Cloud Run Health for regional failover 
 VPC egressの改善 
 Cloud Run Threat Detection 
 プレビュー 
 ・ロードバランサ不要でIAPが適用可能 
 GA
 ・その名の通り、Cloud RunでGPUが利用可能 
 ・Tokyoリージョンは未サポート 
 プレビュー 
 ・service/jobsとは異なる新しい実行モデル 
 ・詳細はのちほど 
 
 GA
 ・確保が必要なサブネットIPアドレス数が半減(4倍→2倍) 
 ・Cloud Run jobsでも利用可 
 プレビュー 
 ・Security Command Centerとの統合 
 ・ランタイム攻撃や脆弱性等を検知 
 プレビュー 
 ・マルチリージョンにおけるフェイルオーバーサポート 
 ・startupProbeのシグナルとServerless NEGの連携 

10. Cloud Run Worker Poolsとは？ 

11. Cloud Run Worker Poolsとは？ 
 ※Google Cloud Next 2025: What’s new in Cloud Run (https://www.youtube.com/watch?v=PWPvX25R6dM)より一部参照

12. Cloud Run Worker Poolsとは？ 
 ※Google Cloud Next 2025: What’s new in Cloud Run (https://www.youtube.com/watch?v=PWPvX25R6dM)より一部参照

13. Cloud Run Worker Poolsとは？ 
 ★ service / jobs とは異なる新しい実行モデル 
 ★ HTTP エンドポイントは不要
 ★ 常駐稼働型 でアイドル時のコスト発生を低減 
 ★ CPU 使用率等に応じた自動スケーリング or 手動スケーリング
 ◦ 常駐稼働型に適したスケーリング 
 ★ ユースケースとしては、Pub/Sub のサブスクライバー、
 Kafka コンシューマー処理、GitHub / GitLab によるホストランナー等

14. Cloud Run Worker Poolsとは？ 
 ★ 現在はPrivate Previewステータス 
 ◦ 特定のユーザー向けにのみ限定公開
 ◦ Public Previewの最終段階でフィードバックを収集している状況
 
 ★ ドキュメントも非公開
 

15. Cloud Run Worker Poolsとは？ 
 ★ 現在はPrivate Previewステータス 
 ◦ 特定のユーザー向けにのみ限定公開
 ◦ Public Previewの最終段階でフィードバックを収集している状況
 
 ★ ドキュメントも非公開
 
 現時点で情報が限定的なた め、公開情報ベースで 
 「勝手に」 深堀りします

16. そもそも “ Worker Pool ”とはなにか？ 

17. そもそも “ Worker Pool ”とはなにか？ 
 そうだ、
 Gemini 2.5 に 
 聞いてみよう 

18. そもそも “ Worker Pool ”とはなにか？ 

19. そもそも “ Worker Pool ”とはなにか？ 

20. そもそも “ Worker Pool ”とはなにか？ 

21. そもそも “ Worker Pool ”とはなにか？ 

22. 一定のWorkerが
 常に常駐起動している
 そもそも “ Worker Pool ”とはなにか？ 

23. Task Queueに
 Taskが蓄積
 そもそも “ Worker Pool ”とはなにか？ 

24. Task Queueに蓄積したTasksを Workerが次々と捌いていく
 そもそも “ Worker Pool ”とはなにか？ 

25. Task Queueに蓄積したTasksを Workerが次々と捌いていく
 そもそも “ Worker Pool ”とはなにか？ 
 Workerを常駐させることによって、 
 割り当てたリソースの範囲で 
 効率よく処理が可能となる 

26. さて、ここでいくつか疑問が。 

27. 疑問1: Cloud Run serviceでも代替できるのでは？ 

28. 疑問1: Cloud Run serviceでも代替できるのでは？ 

29. 疑問2: Cloud Run jobsでも代替できるのでは？ 

30. 疑問2: Cloud Run jobsでも代替できるのでは？ 

31. 疑問2: Cloud Run jobsでも代替できるのでは？ 

32. 疑問3: GKEでも代替できるのでは？ 

33. 疑問3: GKEでも代替できるのでは？ 

34. ここまでの疑問をいったん整理 

35. ここまでの疑問をいったん整理 
 🤔 Cloud Run serviceでも代替できるのでは？ 
 🤔 Cloud Run jobsでも代替できるのでは？ 
 🤔 GKEでも代替できるのでは？ 

36. これらの疑問に対して、 
 登場背景を深堀りをしていきましょう 

37. ここまでの疑問をいったん整理 
 🤔 Cloud Run serviceでも代替できるのでは？ 
 🤔 Cloud Run jobsでも代替できるのでは？ 
 🤔 GKEでも代替できるのでは？ 

38. 疑問1: Cloud Run serviceでも代替できるのでは？ 
 結論として、 代替はできるが、多数制約がある 
 （Cloud Run serviceで実現可能であれば、そもそもWorker Poolsが登場していない） 

39. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 

40. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 
 ★ 当初のCloud Run ServiceにはCPU利用に厳しい制限 があった
 ◦ Cloud Run serviceはRequest＆Response型のサービス 
 ◦ Response後はCPUがスロットリングされ、利用が厳しく制限 
 ◦ そもそも、HTTP Request&Responseがないと、CPUが利用できない 
 ▪ HTTPエンドポイントを必要としないWorkerとしては不向き 
 
 

41. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 
 ★ 当初のCloud Run ServiceにはCPU利用に厳しい制限 があった
 ◦ Cloud Run serviceはRequest＆Response型のサービス 
 ◦ Response後はCPUがスロットリングされ、利用が厳しく制限 
 ◦ そもそも、HTTP Request&Responseがないと、CPUが利用できない 
 ▪ HTTPエンドポイントを必要としないWorkerとしては不向き 
 
 
★ 「Always on CPU」の登場によりHTTPリクエストに依らず、CPU利用が可能 に
 ◦ インスタンスが存在している間は、CPUの割当が可能 
 ◦ ただし、HTTPリクエストが発生しないと、約15分でインスタンスが終了 
 ▪ インスタンス最小数(--min-instances)を1以上にすれば、 
 常駐可能なWorkerが実現できそう
42. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 

43. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 

44. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 

45. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 

46. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 

47. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 

48. Cloud Run service のおさらい 
 疑問1: Cloud Run service でも代替できるのでは？ 
 なんとなく、Cloud Run serviceで Worker Pools実装できそうなのでは？
49. 疑問1: Cloud Run service でも代替できるのでは？ 
 ・HTTPリッスンしないと、そもそもCloud Run serviceが起動できない
 ・Cloud Run serviceのHTTPエンドポイントのセキュリティ対策が必要
 制約1: Worker としては不要な HTTP リッスンの実装が必要 

50. 制約1: Worker としては不要な HTTP リッスンの実装が必要 
 疑問1: Cloud Run service でも代替できるのでは？ 
 ・HTTPリッスンしないと、そもそもCloud Run serviceが起動できない
 ・Cloud Run serviceのHTTPエンドポイントのセキュリティ対策が必要

51. 制約2: インスタンス常時起動で コストが常に発生 する
 疑問1: Cloud Run service でも代替できるのでは？ 
 ・Always on CPUにより、コストモデルがリクエスト課金からインスタンス課金に変わる

52. 制約2: インスタンス常時起動で コストが常に発生 する
 疑問1: Cloud Run service でも代替できるのでは？ 
 ・Always on CPUにより、コストモデルがリクエスト課金からインスタンス課金に変わる

53. 制約2: インスタンス常時起動で コストが常に発生 する
 疑問1: Cloud Run service でも代替できるのでは？ 
 ・Always on CPUにより、コストモデルがリクエスト課金からインスタンス課金に変わる

54. 制約3: タスクの処理負荷状況のみ でスケールが機能しない 
 疑問1: Cloud Run service でも代替できるのでは？ 
 ・リクエスト数、CPU使用率、インスタンス数を加味して自動でスケール判定 
 ・Taskが蓄積しても、HTTPリクエストが発生しない限りスケールしない可能性あり 

55. 制約3: タスクの処理負荷状況のみ でスケールが機能しない 
 疑問1: Cloud Run service でも代替できるのでは？ 
 ・リクエスト数、CPU使用率、インスタンス数を加味して自動でスケール判定 
 ・Taskが蓄積しても、HTTPリクエストが発生しない限りスケールしない可能性あり 

56. ここまでの疑問をいったん整理 
 󰢃 Cloud Run service でも代替できるのでは？ 
 🤔 Cloud Run jobs でも代替できるのでは？ 
 🤔 GKEでも代替できるのでは？ 
 → 代替はできるが、 不要な HTTP リッスンの実装とセキュリティ対策、 
 　 常時コストの発生、スケーリングの制約観点 から最適とは言えない。 

57. ここまでの疑問をいったん整理 
 󰢃 Cloud Run service でも代替できるのでは？ 
 🤔 Cloud Run jobs でも代替できるのでは？ 
 🤔 GKEでも代替できるのでは？ 
 → 代替はできるが、 不要な HTTP リッスンの実装とセキュリティ対策、 
 　 常時コストの発生、スケーリングの制約観点 から最適とは言えない。 

58. 疑問1: Cloud Run jobsでも代替できるのでは？ 
 結論として、 代替は適切ではない 
 （Cloud Run jobs のユースケースに適合しない） 

59. Cloud Run jobs のおさらい 
 疑問2: Cloud Run jobs でも代替できるのでは？ 

60. Cloud Run jobs のおさらい 
 疑問2: Cloud Run jobs でも代替できるのでは？ 
 ★ HTTPリクエストは不要でCPUの割り当てが可能
 ◦ アプリ側で不要なHTTPリッスン実装は不要となる

61. Cloud Run jobs のおさらい 
 疑問2: Cloud Run jobs でも代替できるのでは？ 

62. Cloud Run jobs のおさらい 
 疑問2: Cloud Run jobs でも代替できるのでは？ 

63. Cloud Run jobs のおさらい 
 疑問2: Cloud Run jobs でも代替できるのでは？ 
 Cloud Run serviceと比較して、 HTTPリッスン実装不要だし、いけそう？
64. そもそも永続的な常駐処理に適していない 
 疑問2: Cloud Run jobs でも代替できるのでは？ 
 ・基本ユースケースとしては、ワンタイムで処理毎に起動する
 ・処理完了後にインスタンスが終了するため、Task処理継続に都度起動が必要
 

65. そもそも永続的な常駐処理に適していない 
 疑問2: Cloud Run jobs でも代替できるのでは？ 
 ・基本ユースケースとしては、ワンタイムで処理毎に起動する
 ・処理完了後にインスタンスが終了するため、Task処理継続に都度起動が必要
 

66. そもそも永続的な常駐処理に適していない 
 疑問2: Cloud Run jobs でも代替できるのでは？ 
 ・基本ユースケースとしては、ワンタイムで処理毎に起動する
 ・処理完了後にインスタンスが終了するため、Task処理継続に都度起動が必要
 

67. スケーリングの トリガー実装が難しい 
 疑問2: Cloud Run jobs でも代替できるのでは？ 
 ・Task量に応じて自前で実装するか、事前に余剰分を起動させる必要がある
 

68. スケーリングの トリガー実装が難しい 
 疑問2: Cloud Run jobs でも代替できるのでは？ 
 ・Task量に応じて自前で実装するか、事前に余剰分を起動させる必要がある
 

69. ここまでの疑問をいったん整理 
 󰢃 Cloud Run service でも代替できるのでは？ 
 󰢃 Cloud Run jobs でも代替できるのでは？ 
 🤔 GKEでも代替できるのでは？ 
 → 代替はできるが、 不要な HTTP リッスンの実装とセキュリティ対策、 
 　 常時コストの発生、スケーリングの制約観点 から最適とは言えない。 
 → 常駐処理というユースケースに適さない 

70. ここまでの疑問をいったん整理 
 󰢃 Cloud Run service でも代替できるのでは？ 
 󰢃 Cloud Run jobs でも代替できるのでは？ 
 🤔 GKEでも代替できるのでは？ 
 → 代替はできるが、 不要な HTTP リッスンの実装とセキュリティ対策、 
 　 常時コストの発生、スケーリングの制約観点 から最適とは言えない。 
 → 常駐処理というユースケースに適さない 

71. 疑問3: GKEでも代替できるのでは？ 
 結論として、 代替はできる 

72. 疑問3: GKEでも代替できるのでは？ 
 ★ すでにGKE中心のワークロードなら何ら問題なし 
 ◦ GKE上でDeployment + HPA構成でWorker Poolsを構成可能
 
 ★ Cloud Run中心のアーキテクチャでは、オーバーエンジニアリング 
 ◦ Worker Pools導入のためだけに、新規GKE立てるのは、
 導入・運用コスト的にも見合わないケースがほとんど
 ◦ それならCloud Run serviceでなんとか頑張るはず....

73. ここまでの疑問をいったん整理 
 󰢃 Cloud Run service でも代替できるのでは？ 
 󰢃 Cloud Run jobs でも代替できるのでは？ 
 󰢃 GKEでも代替できるのでは？ 
 → 代替はできるが、 不要な HTTP リッスンの実装とセキュリティ対策、 
 　 常時コストの発生、スケーリングの制約観点 から最適とは言えない。 
 → 常駐処理というユースケースに適さない 
 → 代替はできる。一方、Cloud Run 中心のアーキテクチャでは 
 　オーバーエンジニアリングとなる可能性 

74. Cloud Run Worker Poolsとは？ 
 再掲

75. Cloud Run Worker Poolsとは？ 
 ※Google Cloud Next 2025: What’s new in Cloud Run (https://www.youtube.com/watch?v=PWPvX25R6dM)より一部参照
 再掲
 コスト・スケールの観点で最適化、 
 HTTPエンドポイント不要 常駐型の新しいモデル
76. Cloud Run Worker Poolsとは？ 
 ※Google Cloud Next 2025: What’s new in Cloud Run (https://www.youtube.com/watch?v=PWPvX25R6dM)より一部参照
 再掲
 コスト・スケールの 観点で最適化 
 常駐型の 
 新しいモデル 
 GPU 対応も加味すると、Cloud Run は Google Cloud 上で
 あらゆるワークロードに対応可能な一級市民 
 として進化していく方向性が垣間見れる

77. まとめ

78. まとめ
 ★ Cloud Run Worker Poolsはservice / jobsとは異なる新しい実行モデル 
 ★ 常駐稼働型 でアイドル時のコスト発生を低減 
 ★ Cloud Run はあらゆるワークロードに対応していく方向に

79. ご清聴いただきありがとうございました。