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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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の連携  

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Cloud Run Worker Poolsとは？  

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

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が実現できそう

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Cloud Run service のおさらい   疑問1: Cloud Run service でも代替できるのでは？   なんとなく、Cloud Run serviceで Worker Pools実装できそうなのでは？

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Cloud Run jobs のおさらい   疑問2: Cloud Run jobs でも代替できるのでは？   Cloud Run serviceと比較して、 HTTPリッスン実装不要だし、いけそう？

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

Cloud Run Worker Poolsとは？   再掲 

Slide 75

Slide 75 text

Cloud Run Worker Poolsとは？   ※Google Cloud Next 2025: What’s new in Cloud Run (https://www.youtube.com/watch?v=PWPvX25R6dM)より一部参照  再掲  コスト・スケールの観点で最適化、   HTTPエンドポイント不要常駐型の新しいモデル

Slide 76

Slide 76 text

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 上で  あらゆるワークロードに対応可能な一級市民   として進化していく方向性が垣間見れる 

Slide 77

Slide 77 text

まとめ 

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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