Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Cloud Runマネージドに適したアプリケーションを考える
Search
chimame
October 18, 2020
Programming
1
330
Cloud Runマネージドに適したアプリケーションを考える
GDG DevFest 2020
chimame
October 18, 2020
Tweet
Share
More Decks by chimame
See All by chimame
知って得する@cloudflare_vite-pluginのあれこれ
chimame
1
150
Boost Your Web Performance with Hyperdrive
chimame
1
310
RemixでVersion skewに立ち向かう
chimame
2
1.2k
私がエッジを使う理由
chimame
10
4.1k
GraphQL Server on Edge after that
chimame
1
1.5k
Accelerating App Dev with Cloudflare Workers
chimame
1
450
GraphQL Server on Edge
chimame
12
6k
エッジで輝くフロントエンド
chimame
11
6.7k
Cloudflare Workersと状態管理
chimame
4
1.8k
Other Decks in Programming
See All in Programming
コーディングは技術者(エンジニア)の嗜みでして / Learning the System Development Mindset from Rock Lady
mackey0225
2
570
Claude Codeで実装以外の開発フロー、どこまで自動化できるか?失敗と成功
ndadayo
2
1.3k
AI時代のドメイン駆動設計-DDD実践におけるAI活用のあり方 / ddd-in-ai-era
minodriven
23
9k
モバイルアプリからWebへの横展開を加速した話_Claude_Code_実践術.pdf
kazuyasakamoto
0
260
Microsoft Orleans, Daprのアクターモデルを使い効率的に開発、デプロイを行うためのSekibanの試行錯誤 / Sekiban: Exploring Efficient Development and Deployment with Microsoft Orleans and Dapr Actor Models
tomohisa
0
210
MCPで実現するAIエージェント駆動のNext.jsアプリデバッグ手法
nyatinte
6
840
管你要 trace 什麼、bpftrace 用下去就對了 — COSCUP 2025
shunghsiyu
0
470
GitHub Copilotの全体像と活用のヒント AI駆動開発の最初の一歩
74th
8
3.2k
Langfuseと歩む生成AI活用推進
licux
3
300
Flutter로 Gemini와 MCP를 활용한 Agentic App 만들기 - 박제창 2025 I/O Extended Seoul
itsmedreamwalker
0
150
物語を動かす行動"量" #エンジニアニメ
konifar
14
5.4k
Understanding Ruby Grammar Through Conflicts
yui_knk
1
120
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
How to train your dragon (web standard)
notwaldorf
96
6.2k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Thoughts on Productivity
jonyablonski
69
4.8k
Designing Experiences People Love
moore
142
24k
The Pragmatic Product Professional
lauravandoore
36
6.8k
Done Done
chrislema
185
16k
Become a Pro
speakerdeck
PRO
29
5.5k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Transcript
Cloud Runマネージドに適 したアプリケーションを考え る 2020/10/18 GDG DevFest 2020
Cloud Run利点・注意点 Agenda 自己紹介 まとめ
Whoa! 名前: rito 職業: Webエンジニア (アプリケーションエンジニア) 分野: Ruby on Rails,
Nodejs, React, Docker, AWS, GCP 所属: Ateam Finergy Inc. コミュニティ: GDG Osaka Rails follow-up Osaka Osaka Web Developers Meetup twitter: @chimame_rt GitHub: chimame
Cloud Run Develop and deploy highly scalable containerized applications on
a fully managed serverless platform.
ざっくりCloud Runのお さらい
“Cloud Run はマネージド型のコンピューティング プラット フォームで、ウェブ リクエストまたは Pub/Sub イベント経由で 呼び出し可能なステートレス コンテナを実行できます。
https://cloud.google.com/run/docs?hl=ja Cloud Runとは? 6
• コンテナイメージで起動 • コンテナ実行はサーバレスな実行も可能 • 処理はhttpリクエストもしくはPub/Subからのみ実行可 能 平たく言うと 7
Cloud Runマネージドはサーバレスでかつ、 コンテナによるランタイム環境を生成可能 8
Cloud Runの利点 Benefits of using Cloud Run
10 コンテナ実行を前提としてるので
freedom of language freedom of framework 言語やフレームワークはもちろんバージョンなどのコンテナで動作するなら どんなものでも選択可能
12 マネージドであるがゆえに
トラフィックによりスケーリングを 自動で行ってくれる。
14 様々なサービスとの連携も
Cloud Run Cloud SQL Cloud Memorystore Cloud VPC Cloud Scheduler
Cloud Tasks Cloud Load Balancing Cloud Storage ※beta
弊社サービスで実際に運用してみた注意点 16 https://www.navinavi-hoken.com/ https://navinavi-shoken.com/
Cloud Runの注意点 Cavert of using Cloud Run
オートスケーリング問題
Cloud Runのオートスケールは以下の条件に基づく(※) • リクエストの処理に必要な CPU の量 • 同時実行の設定 • コンテナ
インスタンスの最大数の設定 1つ目のCPUの量というのが意外と厄介ではある。残り2つに ついては設定次第なのでもう少し説明する ※ https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja Cloud Runのオートスケールの条件 19
1コンテナに投げることが できる同時リクエスト数 同時実行の設定とは 同時リクエスト数を超える とスケールする
コンテナインスタンスの最大数の設定とは コンテナのスケールの最 大数を設定できる ・・・
• 最小コンテナ数は指定できない なのでアクセスが0の状態が一定時間続くとコンテナ数は最 小の0まで落ちる 更にマネージドならではの条件として 22
23 Q: 以上の条件から以下1日単位の リクエスト数の場合はどうなるか?
24
25 最大時と最小時にかなりの差がある
26 A: リクエストの最小から最大に向けて コンテナがスケールする
Q: Cloud Runって自動でスケーリングして くれるから問題ないのでは? 27
A: 半分は正解。半分は間違い。 28
• スケールはスケールが必要となった リクエストが派生 した段階 で行われる • スケールが必要となった リクエストはスケールするコ ンテナで処理 される
言うなればコンテナがリクエストを受け入れる(起動)状態に なる前からリクエストは待たされる Cloud Runのオートスケール時の動作 29
スケールが必要な リクエストが発生 スケールするのにコンテナの 起動時間も含めてリクエストを 待機させる コンテナの起動時間までリクエストを待たせるのでRuby on Railsはイン タプリタ言語かつ重量系フレームワークであるため起動するのに早くても 10秒程度かかるためなかなか厳しい
Q: コンテナ同時リクエストを多く受け入れたらス ケールが抑えられるので大丈夫なのでは? 31
A: リクエスト数だけがスケール条件じゃない 32
Cloud Runのオートスケールは以下の条件に基づく(※) • リクエストの処理に必要な CPU の量 • 同時実行の設定 • コンテナ
インスタンスの最大数の設定 1つ目のCPUの量というのが意外と厄介ではある。残り2つに ついては設定次第なのでもう少し説明する ※ https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja Cloud Runのオートスケールの条件(再掲載 33
Cloud Runのオートスケールは以下の条件に基づく(※) • リクエストの処理に必要な CPU の量 • 同時実行の設定 • コンテナ
インスタンスの最大数の設定 1つ目のCPUの量というのが意外と厄介ではある。残り2つに ついては設定次第なのでもう少し説明する ※ https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja Cloud Runのオートスケールの条件(再掲載 34
要約:リクエストを受けれるコンテナでもCPUが忙し そうにしてたらスケールする 35
36 同じ条件で負荷をかけてもCPU効率がい い方がスケールする コンテナのCPUコア2にして同条件で負荷実験を実施
スケーリング問題の 対処
対策1: そもそもリアルタイム処理には使わず 非同期処理にのみ組み込む
コンテナさえ用意すれば実行できるサーバレスアーキテクチャの 利点だけ使うと割り切って、リアルタイムは別アーキテクチャで 組む 【メリット】 • スケールの問題はほぼ関係なくなる 【デメリット】 • サービス全体を見るとアーキテクチャが多岐に渡る可能が 出てくる
スケールが問題になるならリアルタイムには使わない と割り切る案
対策2: 起動速度が爆速アプリケーションにす る
なんといってもこれがスケールする場合のクリティカルパスな のでそれを解決する案 【メリット】 • これさえ解決すればこの問題はすべて解決する 【デメリット】 • 使用言語およびフレームワークでは解決できない • 解決というのはどこまでのレイテンシーを許容するか定
義が必要 一番の根本原因となっているスケール速度 ≒アプリケーション起動速度を改善する案
対策3: Cloud Runに仕事をさせない
例えば動的な処理以外に静的なものもレスポンスさせないこ とや、動的なものでもCDNでキャッシュさせる等 【メリット】 • スケール数は抑えられる 【デメリット】 • スケール数は抑えられるがスケール自体は抑えれない • インフラ構成も含めてしっかりとした設計が必要
そもそもCloud Runに仕事をさせずに極力仕事を減 らす案
対策4: Cloud Run for Anthosを使用する
最大アクセス数を捌くためのコンテナ数を事前に用意する。それ をするためにCloud Run for Anthosを使用する 【メリット】 • スケール数をほぼ抑えることが可能 • GKEを使用することになるので常時起動のJobなども定義が
可能 【デメリット】 • GKEが必要となりKubernetesの知識が若干必要となる • マネージドに比べるとサービス初期などは費用が割高にな る スケールさせる必要がある場合を非常時とし、 通常時はスケールさせない案
対策5: マネージド版でも最小コンテナ数を指 定する(β機能)
None
Cloud Run for Anthosと同様にマネージド版でも最小インスタン ス数を指定してオートスケールを抑える案 【メリット】 • スケール数をほぼ抑えることが可能 【デメリット】 •
常時インスタンスを立ち上げている状態となるので起動中 はずっと費用がかかることになる(Cloud Runマネージド版 のリクエスト時間分の課金ではなくなる) マネージドでも最小インスタンス数を指定することがで きるようになる
対策6: DNSラウンドロビンを使い複数の Cloud Runサービスを1つのアプリケー ションとして使う
稼働時間チェックなどで定期的にリクエストを送り コールドスタンバイにしない Monitoring1 (Uptime check) service1 Monitoring2 (Uptime check) service2
Monitoring3 (Uptime check) service3 example.com DNSラウンドロビンをさせて最小コンテナ数≒ サービスとして定義する
1サービスで最小コンテナ数を指定できないなら最小コンテナ数 分のサービスで1エンドポイントのアクセスを捌いて擬似的に最 小コンテナを設定する案 【メリット】 • マネージドのいいとこは生かしたまま解決が可能 【デメリット】 • DNSラウンドロビンで実現が可能か不明 DNSラウンドロビンで不可能な場合はEdgeコンピューティン
グにて処理をうまいこと実装する必要がある コンテナ最小数≒サービス数としてスケールを抑える 方法案(ただし試してない)
まとめ STAY 適したアプリケーションや 構成をしっかり考えること インフラ管理は すごい楽 GOOD! 今回は触れてないけど非同期処 理も色々あるので注意が必要 STAY
マネージドな分アンコントローラブル な部分もある BAD
Thanks! Does anyone have any questions? rito@chimame