📈

Cloud Run のインスタンスあたりの最大同時リクエスト数 (コンカレンシー) を負荷テストで確認する

2023/12/09に公開

2023年は「Cloud Run を触って覚える」をテーマとした一人アドベントカレンダーを一人で開催しており、Cloud Run のさまざまな機能や、Cloud Run でよく使う構成などを実際の使い方と一緒にご紹介しています。

https://qiita.com/advent-calendar/2023/cloud-run

9日目はスケーリングに関する機能についてご紹介します。Cloud Run サービスに対して負荷テスト ツールを使って実際に負荷をかけながら確認していきます。負荷テスト ツールには「Locust」を使います。GKE Autopilot を使った構築方法は次の記事を参照してください。

https://zenn.dev/google_cloud_jp/articles/cloudrun-loadtest

Cloud Run の概要は技術評論社さまのブログ「gihyo.jp」に寄稿した記事で解説していますのでこちらもぜひご覧ください。

https://gihyo.jp/article/2023/10/modern-app-development-on-google-cloud-03

インスタンスあたりの最大同時リクエスト数 (コンカレンシー)

1 つのコンテナ インスタンスが受け付けることができる最大リクエスト数を設定することができます。ドキュメントや説明スライドによっては Concurrency やコンカレンシーと表記されていることもあります(この記事では読みやすさの観点から以降はコンカレンシーと表記します)。

https://cloud.google.com/run/docs/about-concurrency?hl=ja

デフォルトでは 80 が設定されています。この設定の場合、1 つのコンテナ インスタンスが同時に 80 までのリクエストを処理することができます。

コンカレンシー

コンカレンシーの動作を確認する

サンプルの Cloud Run サービスのコンカレンシーの設定を変更し、Locust から負荷をかけてスケーリングの状態を確認してみましょう。まずはコンカレンシーを 50 に設定します。

コンカレンシーの設定

Locust からは秒間約 450 リクエスト (450 RPS) のリクエストを送ります。

Locust の画面

Cloud Run サービスには、ほぼ同じ程度の秒間リクエストが届いていることが確認できます。

秒間リクエスト数の確認

450 RPS のとき、コンカレンシーが 50 の場合は 1 つのコンテナ インスタンスが同時に 50 リクエストを処理できる計算です。1 リクエストに対するレイテンシが短ければ秒間処理できるリクエスト数は増えますので、実際のコンテナ インスタンス数は少なく済む場合が多いです。

コンテナ インスタンス数の確認

最大同時リクエスト数は、概ね 50 前後であることが確認できます。

コンテナ インスタンス数の確認

コンカレンシーを減らしてみましょう。10 に設定してみます。

コンカレンシーの変更

リビジョンのデプロイが完了後、再度負荷をかけてみると、最大同時リクエスト数が 10 前後になっていることが確認できます。

コンテナ インスタンス数の確認

コンテナ インスタンス数は、先ほどよりも増えていることが確認できました。

コンテナ インスタンス数の確認

CPU 負荷によってスケールする

次のドキュメントにも記載のある通り、コンカレンシーを高い数値に設定したとしても、CPU 負荷が 60% に達した際には最大同時リクエスト数に満たない場合でもスケールします。

https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja

コンカレンシーを最大の 1000 に設定し、再度負荷をかけてみます。

コンカレンシーの変更

コンカレンシーのメトリクスを見てみると 200 前後であることが確認できました。この Cloud Run サービスの設定においてはコンテナ インスタンスあたりの実際の最大同時リクエスト数は 200 程度であることが分かりました(もちろん、後述の CPU とメモリを上げることで処理可能な同時リクエスト数を増やすことはできます)。

コンカレンシーの確認

CPU 上限とメモリ上限

1 つあたりのコンカレンシーをもっと上げたい場合は CPU 上限とメモリ上限の設定を上げることも可能です。

CPU上限 を 8 に、メモリ上限を 4 GiB に設定し、さきほどと同じくコンカレンシーを 1000 に設定します。

CPU の変更

コンカレンシーのメトリクスを見てみると、Locust から負荷をかけている RPS 相当が処理できていることが分かります。

コンカレンシーの確認

必要なコンテナ インスタンスの台数も 1 つになりました。

コンテナ インスタンス数の確認

特にコールドスタートの時間が長いアプリケーションの場合は、スケールの頻度が少なくなるように、CPU とメモリを高めに設定し、コンカレンシーも高めに設定します。

最大インスタンス数

最大インスタンス数を設定することにより、スケールするコンテナ インスタンスの数を制限することができます。

最大インスタンス数

次のようなケースで役立ちます。

  • 費用をコントロールしたい
  • アプリケーションがアクセスするデータベースへの負荷をコントロールしたい

最大インスタンス数に達し、かつ同時リクエスト数がコンカレンシーの設定値を上回る状態が続く場合リクエストは最大 10 秒間キューに入れられます。その間に既存のインスタンスの処理が完了した際はキューに入っているリクエストを処理しますが、時間内にリクエスト処理が可能なインスタンスがない場合は 429 エラーになります。

https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja#exceed-max

まとめ

Cloud Run はスケーラビリティに優れたサービスですが、コンカレンシーを調整することでよりコスト効率的に利用することができます。適切な設定はアプリケーションに必要な CPU やメモリなどのスペック、コールド スタートの有無なども関わってきますので、負荷テストで確認をしながら適切な設定値を探っていくと良いと思います。

下記ドキュメントのコンカレンシーを最適化するヒントも参考にしてください。

https://cloud.google.com/run/docs/tips/general?hl=ja#optimize_concurrency

Google Cloud Japan

Discussion