サンフランシスコで開催されたGoogle Next 2019で、GoogleはCloud Runのベータ版移行を発表しました。実アプリケーションで試すには絶好の機会だと感じました。
画像提供:TriggerMesh — Multicloud Serverless Management Platform( http://triggermesh.com)
Google Cloud Runは、ステートレスなコンテナを自動でスケーリングするマネージドのコンピュートプラットフォームです。サーバーレスでインフラ管理を一切意識する必要がないため、最も重要な「優れたアプリケーションを作ること」に集中できます。Knativeをベースにしており、Cloud Runでフルマネージドにコンテナを動かすか、Cloud Run on GKEで自前のGoogle Kubernetes Engineクラスタ上で動かすかを手軽に選べます。
今回は、素のGKEクラスタ上で動かすサービスと、フルマネージド版のCloud Run、そして自前のGKEクラスタ上で動かすCloud Runの3パターンを比較してみたいと思いました。
Cloud Runのテストには、Banias( GitHub上のコード)を使うことにしました。これはOpinionated Serverless Event Analytics Pipelineです。Baniasは次の2つから構成されています。
フロントエンド — クライアントからすべてのイベントを受け取り、Pub/Subへ書き込みます。Goで実装されています。
バックエンド — Pub/Subのデータを検証・変換してBigQueryに書き込むGoogle Cloud Dataflowです。JavaとGoogle Dataflow SDKで実装されています。
BaniasをGoogle Cloud Runにデプロイする際、2つの問題にぶつかりました:
- Baniasは設定にViperを使っています。Viperは各環境変数にプレフィックスを付けますが、Cloud RunはPORTという環境変数を使うため、BANIAS_PORTではなくPORTを参照するようコードを修正する必要がありました。
- Cloud Runは1つのポートしかリッスンできません。BaniasはスクレイピングのためにPrometheusエンドポイントを公開していますが、これはCloud Runでは動作しませんでした。
Baniasを以下の複数の構成でインストールしました:
- GKEクラスタ(ノードはn1-standard-4)に「通常の」デプロイメントとして
- (同一のノード構成の)別クラスタでCloud Runを利用
- マネージド版のCloud Run
実験はまず、最初のリクエストが処理されるまでの時間(いわゆるコールドスタート)の計測から始めました:
- GKE 約0.008秒
- Cloud Run on GKE 約7秒
- Cloud Run マネージド 約7秒
負荷生成にはK6を使いました。Goで書かれた、開発者志向のオープンソース負荷テストツールです。テスト結果はInfluxDBに保存し、Grafanaで可視化することにしました。負荷生成は次のようにK6を実行して開始しました:
k6 run — out influxdb=http://x.x.x.x:8086/myk6db — u 2500 — duration 1m — rps 6000 test_file.js
GKE上のBanias
マネージド版Cloud Run上のBanias
自前のGKEクラスタ上のCloud RunでのBanias
結果を見ると、Cloud Runは高負荷時のスケーリングに苦戦しているのがわかります(同時実行数を80から1まで幅広く変えて試しましたが、結果は同じでした)。秒あたりのリクエスト数に上限を設け(無制限だと20K RPSに達します)、4k RPS程度に抑えると、Cloud Runでも問題なくさばけました。
Cloud Runへのworkloadsのデプロイ自体は非常に簡単ですが、現時点ではすべての種類のworkloadsや負荷を効率的に動かせるわけではなさそうです。
もっと記事を読みたい方は、ぜひブログをチェックするか、AvivのTwitterをフォローしてください。