GCP Cloud Run を使ってみた

これまでのインフラの課題

API サーバを作るとき、インフラの選択肢はいくつかあると思います。 どれも、それぞれ短所があります。

仮想サーバを用意する場合

  • 管理やスケーリングを自分でやる必要がある

Lambda などのクラウドファンクションを使う場合

  • デバッグが辛い
  • 移行性が低い
  • 言語やライブラリ等に制約がある
  • RDB と相性が悪い

Fargate などのフルマネージドコンテナサービスを使う

  • 使っていないときも課金される

Cloud Run のメリット

GCP の Cloud Run は、仮想マシンを使ったサーバフル運用の利点と、 Lambda などを使ったサーバレスの利点をどちらも享受できるサービスです。

ざっくりで言うと、Docker で書ける Lambda という印象です。

Cloud Run は、前述のデメリットを全て解消しています。

管理やスケーリングを自分でやる必要がある

=> コンテナの数が増えることで、自動的にスケールします。コンテナが動作するインフラはフルマネージドなので、ユーザは何も考える必要がありません。また、スケールする閾値も設定できます。

デバッグが辛い

=> Docker なので、ローカルでの開発やデバッグは今までどおり行えます。

使用できるライブラリに制約がある

=> Docker なので、基本的に制約はありません。

RDB と相性が悪い

=> 1 つのコンテナあたり最大で 80 までのリクエストを扱う、といった設定ができます。1 コンテナあたり SQL サーバへの接続は基本的に 1 つなので、Lambda のように SQL サーバとの接続が量産されてしまうことがありません。

使っていないときも課金される

=> 使っていないときはコンテナ数が 0 になり、完全に停止します。再び接続があれば、新たにコンテナが起動します。ちなみに、Node.js+Postgres で作った API サーバのブートアップタイムは 1 秒以下でした。

料金

ちなみに料金のほうは、「リクエストの処理に費やした時間」に対し、使用した CPU やメモリの使用量を掛けあわせて算出するようです。「コンテナが起動している時間」ではないのがミソです。

image

pricing

ざっくり、50 時間程度までは無料のようなので、1 リクエスト 5 ミリ秒で処理するサーバなら、50*3600*1000/5 = 月間 3600 万リクエストまでは OK という感じでしょうか。デフォルトで 1000request/100sec のクオータがかかっていることもあり、個人のサービスで無料枠を超えることはあまりなさそうですね。

所感

Dockerfile さえ作っておけば、あとは何も考えなくていいという、超お手軽なインフラサービスといえます。比較的小規模な Web システムや、PoC、趣味のサービスなどは、本当にこれ一本でいいんじゃないかと思いました。

ちなみに、簡単な設定をするだけで独自ドメインで HTTPS 通信を終端できます。勝手にスケールするうえに、ロードバランサーも不要です。最高ですね。

Django や Rails などもステートレスであれば動きますし、マイクロサービスとは元より非常に相性がいいのではないでしょうか。Next.js や Nuxt.js をサーバサイドレンダリングモードで動かしつつ、運用費は限りなく無料にする、というようなことも可能だと思います。

ちなみに、下記のサービスは私の作成したデモサービスで、 もともと API も DB も Kubernetes 上で動かしていましたが、 この度、Cloud Run(API) + Cloud SQL(DB) の構成に変更してみました。

https://travelr.yuuniworks.com/(2022/12にてサービス終了)

特に何も変化はありませんが、構成が超シンプルになりました。 また、Kubernetes のクラスタ代が月 5000 円くらいかかってたのが、 DB 代の 1000 円だけですむようになりました。