Cloud Runの料金体系についての疑問
Cloud Runサービスには2種類の料金体系があります。
- リクエストベース（デフォルト）
- インスタンスベース
デフォルトのリクエストベースの料金体系はおなじみです。webサーバを構成するCloud Runサービスの機能とも一致していて、わかりやすいのですね。
一方でインスタンスベースの料金体系はどういう状況で使うべきなのかずっと理解できませんでした。
インスタンスベースの料金体系
この疑問については偶然ですが、ブログ記事「新しい CPU 割り当てコントロールにより Cloud Run 上でさらに多様なワークロードを実行」を見つけて理解できました。
2021/09/28とちょっと古い記事なので、時期的にはCloud Runにはまだサービスしかありません。Jobsはまだリリースされていません。Cloud Functionsはまだ第1世代のみで、Cloud Runとは独立したプロダクトという位置づけでした。
結論ですが、ユースケースとしてはCloud Runサービスでサブスレッドを使って非同期処理を実行する場合を考慮したものでした。Cloud Runサービスではメインスレッドでリクエストを受信後、そのメインスレッドでレスポンスを返すと処理が終了したものと判断されます。そしてリクエストを処理していないインスタンスは、その後一定時間新たなリクエストが割り当てられないと、スケールインしてスピンダウンする対象となります。
ここでリクエスト開始～レスポンスを返すまでの間にサブスレッドを生成し、そのサブスレッドでメインスレッドよりも時間のかかる処理を行う実装を行っているとします。メインスレッドがレスポンスを返してしまった時点で、プラットフォーム（Cloud Runサービス）からは 処理中のリクエスト数=0 と見えてしまい、インスタンスのスピンダウンが起きます。この時点でまだサブスレッドは実行中だと、完了前に強制終了させられることになります。
これを避けるために上記の記事にあるように、CPUの常時割り当ての機能が追加されたということです。最小インスタンス数の設定と組み合わせることで、インスタンスの強制終了によるサブスレッドの停止を回避できます。そしてそれに対応する料金体系がインスタンスベースということでした。
歴史は繰り返す?
App Engineでも同じ問題は起きていましたね。App Engineだけ使う場合はサブスレッドを諦めて、タスクキューで解決していました。
Cloud RunでもCloud Tasksと組み合わせれば同様の方法で回避可能です。
より新しいソリューション
現在では非同期処理を実装するためには、BatchやCloud Run Jobsが用意されています。これらはスレッドだけでなくタスクでも並列処理を実装できます。タスクの方がCPU・メモリリソースを分け合わないので、実装やパフォーマンスチューニングは簡単です。起動に時間がかかりますが。