こんにちは、クラウドエースでバックエンドエンジニアをしている吉崎です。

フルマネージドのコンテナ実行基盤である Cloud Run の startup CPU boost という機能をご存知でしょうか。
2022/9/14 にプレビュー版としてリリースされた機能です。

Cloud Run では、コンテナインスタンスが起動するときに時間がかかってしまうコールドスタートという問題があります。

Cloud Run は、課金の面で親切なゼロスケール(インスタンス数=0→ 無課金)が出来ますが、この場合、リクエストを受けて始めてインスタンスが起動します。
また、最小のインスタンス数を 1(=常時 1 インスタンスを起動) 以上にしておいたとしても、リクエストが増えるなどして追加のインスタンスが起動する場合があります。
これらの場合にコールドスタートが発生し、リクエスト処理、ひいてはレスポンスが返ってくるまでに時間がかかってしまいます。

startup CPU boost は、起動時に割り当てる cpu の数を一時的に増加させ、コールドスタートを改善する機能です。

本稿では、コンテナインスタンスの起動に時間がかかりがちな Java を始め、いくつかの言語のコンテナイメージを使い起動がどのぐらい早くなるのか試してみます。

前提

• 使用したコンテナイメージ

  検証に用いたソースは、Google Cloud 公式ドキュメントにある Hello World サービス です。
  この中から、Go, Java, Node.js, Python のコンテナを作成します。

• コンテナの情報

  言語ごとに以下の通りとなっています。
  Java のイメージサイズが最も大きく、次いで Node.js、Go、Python となっています。
  なお、今回はすべてのコンテナの CPU 上限（割り当てる cpu の数)を 1 に設定しました。

  言語	イメージサイズ	CPU 上限
  Go	59.3MB	1
  Java	256.5MB	1
  Node.js	90.3MB	1
  Python	49.6MB	1

  ブーストの上限は下表の通り設定した CPU の上限に依存しますので、今回だと CPU 上限を 1 に設定したため、ブースト後(起動中)の CPU は 2 となります。

  CPU 上限	ブースト後の CPU
  0-1	2 <-今回はコレ
  2	4
  4	8
  6	8
  8	8

• 計測方法

  Cloud Scheduler から非ブースト版サービス、ブースト版サービスそれぞれに 30 分置きにリクエストを投げ、コンテナインスタンス起動にかかる時間を計測します。

  30 分置きとしているのは、コンテナインスタンスが確実に停止し、次回リクエストによってインスタンスが起動することを保証するためです。(15 分の場合は一部コンテナで正しくレイテンシが取得出来ませんでした)

  リクエストは 1 日程度送り続け、その平均を見ることでブーストによる効果を観察します。

  ※監視には、 Cloud Monitoring の run.googleapis.com/container/startup_latencies という指標を用いました。この指標は、コンテナの起動にかかった時間を示すものです。

さっそく結果

Java

8s 程度から 4s 程度になっており、レイテンシが約 50%削減したと言えそうです。
なお、付録として本稿の末尾に CPU を 4 に設定(8 にブースト)した場合の結果も載せていますが、割り当てコア数と起動時間は正比例しません。

Node.js

Java ほど大きな差は出ていませんが、7, 8%の効果が見られます。

Python

後半に大きく二本のグラフが乖離していますが、ほぼ差はないと言えそうです。

Go

元々コンテナイメージのサイズが小さく、起動にかかるレイテンシも短い Go ですが、全体的に 15%ほどの効果が見られました。

結論

こちらの公式ブログにあるように、確かに Java のコンテナの場合に特にブースト効果が大きく見られるようです。

しかし、helloworld コンテナであってもブースト後で 4 秒かかるため、通常の Java アプリケーションでより早くリクエストを処理する必要がある場合は最小インスタンスを 1 以上にしたり、スケールアウトの発生しにくい設定にしたりすると良いと思います。

ちなみに、スケールアウトは CPU、メモリ、同時リクエスト数によって決まりますので、ご参考までに。

付録

java-boost サービスの CPU を 4 (ブースト後の CPU は 8)に変えたときのレイテンシです。

色の違いが分かりにくいですが、紫の線が 1 CPU、赤茶色の線が 4 CPU を設定したときのレイテンシです。
データポイントが少ないせいもあるかもしれませんが、非ブーストとブーストの差ほどはないものの、さらにレイテンシが小さくなっていることが分かります。