今回は本当に直近のクラウドサービスで遊んでたら事故ったお話です。
導入：軽い気持ちで触った結果
AWS Lambdaに慣れていると、
GCPの Cloud Run も「サーバレスで安いだろう」と思ってしまう。
私もそうだった。
今回は検証目的で Cloud Run を少し触ってみて、特に本番運用するつもりもなく三日ほど放置していたところ、Billing を見て少しヒヤッとした。
「あれ、思ったより請求来てないか？」
GCPの請求額がいきなり5,747円！！！
CloudRunを触ったのはつい３日ほど前なんですが、ふと請求ダッシュボード見てびっくりした。
なんと、各日の使用料が以下の通り。。。
12月9日 755円
12月10日 2,272円
12月11日 2,567円
12月12日 153円
割引 -847円
できるだけGCPを無料プランに近い形でしっかりとサービスを使い倒したかったのに。
いい勉強代となりましたね。
さらに内訳は・・・
それでは深掘りしていく。
どんな内訳なのかを見ていきましょう
Worker Pools CPU 4,451円 （2527Seconds）
Worker Pools Memory 246円 （2527Seconds）
Jobs CPU 767円
Jobs Memory 43円
つまりCloudRunはJobを動かすのにWorkerというコンテナのベースが必要になり、その使用料がかかるというわけですね。GCPの方はまったく勉強していなかったのでこの点の理解が不足していましたね。
というわけで今回の請求内容まとめると
- Cloud Run
- 使用量：約250万秒（約3日）
- 費用：約5,700円
一見すると「そこまで高額ではない」が、３日目で気がついてよかったです。
一回飲みに行くと思えば気にならない金額ですが、気がつくのが月末だったら悪夢でしたね。
今回得られた教訓として
LambdaとCloud Runは思想が違う
Lambda感覚で設計せずに触った
Worker Pool を「常駐サーバ」と理解していなかった
Billing / Budget / Alert を後回しにした
とまぁ、これじゃ浅いのでもう少し踏み込んでみる。
根本的にLambdaとCloudRunってどう違うのか整理してみた。
AWS Lambdaはイベント駆動である
- 実行は関数単位
- 実行時間は最大15分
- 実行してない時間は課金されない
- 遊びで触っても事故りにくい設計
GCP Cloud Runはコンテナサービスである
- CPU割当が有効な間は課金される（リクエストがなくても）
- 常駐プロセスは普通に課金（常駐プロセスはHTTPリクエストも受け取れる）
- もはやVMと同じような感覚
Cloud Runは「サーバレス風」なだけで、
自由度と引き換えに責任が増えるサービスだが、「お遊びで軽く触るサービスではない」。
CloudRunはどんな時に向いているのか
マイクロサービスのWEBアプリやWEBを通じたAPI提供に向いている。
違いは以下のように整理できる。
| 観点 | Lambda | Cloud Run |
|---|---|---|
| 思想 | 関数 | サービス |
| 実行単位 | イベント | コンテナ |
| 常駐 | 不可 | 可 |
| 課金 | 安全 | 強力だが危険 |
| 遊び用途 | ◎ | △ |
ちなみに今回の教訓をベースに観点を変えると以下である。
| 観点 | Lambda | Cloud Run |
|---|---|---|
| 初期触りやすさ | ◎ | △ |
| 放置したときの安全性 | ◎ | × |
| 設計ミス時の請求耐性 | 高い | 低い |
| 本番向き | △ | ◎ |
| 遊び・検証 | 最強 | 危険 |
Cloud Runは悪なのか？
結論から言うと、全くそんなことはない。
ただし「設計前提」がLambdaとは真逆だった
- マイクロサービス
- API サーバ
- 本番運用
この領域では非常に強力。
もし最初から以下を実施していれば防げたことも事実だ。
もし最初から以下をやっていれば、今回の事故は防げた。
・Cloud Run 起動直後に Budget + Alert を設定
・CPU 常時割当をオフにする設計確認
・Job と Service の違いを理解してから作成
・「Lambda感覚」を捨ててから触る
まとめ
GCPはちゃんと設計して使う人には、とても正直だと思う。
今回の筆者の失敗が、同じように「Lambda脳」でGCPのCloudRunを触ろうとしている人の
ブレーキになれば幸いである。
