Cloud Run が GA になったから改めて色々見てみる

Published in

google-cloud-jp

11 min readDec 8, 2019

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 7日目の記事です。

本記事で触れるのは Fully managed 版の Cloud Run のみです 🙇

みなさん、こんにちは。Google Cloud の Kazuu( かずー ) です。2019 年 4 月 9 日に Fully managed 版の Cloud Run が Beta としてリリースされてから半年以上経ち、去る 2019 年 11 月 14 日にとうとう GA となりました㊗️

本記事では GA に至るまでにどんな機能が主に追加されてきたのかリリースノートの時系列で見ていきたいと思います。
Cloud Run の基本的なところを知りたいという方は Next Tokyo の動画や Cloud OnAir も併せてご覧ください。Cloud OnAir の資料はこちらです。

それでは見ていきましょう~ 💪

1.Cloud SQLサポート (2019.05.07)

Cloud Run で動作しているアプリケーションから Cloud SQL Proxy 経由で Cloud SQL に接続可能となりました。Cloud SQL Proxy を使うので Cloud SQL インスタンスには Public IP が必要なので注意が必要です。

利用イメージは以下のような感じです。サービスのデプロイ時に ”--add-cloudsql-instances” オプションで Cloud SQL の Connection Name を指定します。あとはアプリから Unix Socket 経由で Cloud SQL にアクセス出来ます。

Cloud Run のコンテナインスタンスは 1 つのリクエストの処理が終わってもコンテナインスタンスは削除されず続くリクエストの処理を行います。コネクションプールをグローバルスコープで作り再利用していくと、接続確立のオーバーヘッドが少なくなりレスポンスタイムの向上などが期待出来ます。

2. Per-service Identity (2019.06.07)

Cloud Run で利用できるサービスアカウントは Compute Engine のデフォルトサービスアカウントでしたが、サービス毎に使用するサービスアカウントを指定出来るようになりました。

利用イメージは以下のような感じです。サービスデプロイ時に ”--service-account ” オプションで使用するサービスアカウントを指定します。

上記図の通り Cloud Run で動作するアプリケーションから各 GCP サービスを利用する場合、Google Cloud Client Library を使うことが多いと思います。このクライアントは指定されたサービスアカウント基づき自動的に Credentials を取得し GCP サービスへアクセスします。

3. リージョン展開 (2019.07.10)

Cloud Run リリース当初は us-central1( アイオワ ) のみ利用可能でしたが、 asia-northeast1( 東京 ) , europe-west1( ベルギー ), us-east1( サウスカロライナ ) が追加となりました。
GAE では 1 つの GCP プロジェクト内で利用できるリージョンは 1 つでしたが、Cloud Run ではサービス毎にリージョンを指定して Cloud Run を利用可能です。

4. Labels (2019.09.10)

Cloud Run でラベルが使えるようになりました。この機能は Compute Engine などでも既にお馴染みの機能で Cloud Run の場合は各サービスに Key:Value のラベルを付けることが出来ます。
例えば以下のようなユースケースに使えます。

開発チーム毎にラベルを付けてコスト管理をしやすくする
prod, staging, dev, qa のような形で環境を識別する
Owner や State を識別する
Stackdriver Logging や Monitoring において、リソースのグルーピングをする

5. API サポート (2019.09.19)

Cloud Run のサービスのデプロイ等々が API 経由で行えるようになりました。Terraform でもサポートされてます。

6. Billable container instance time (2019.09.26)

Cloud Console から「課金対象のコンテナインスタンス時間」が確認出来るようになりました。これによって実際の課金額の計算が（少し）簡単になったかと思います。

「課金対象のコンテナインスタンス時間」とは 1 つの Cloud Run サービスで稼働する全てのコンテナインスタンスの Billable Time( 課金対象時間 )を纏めたものです。
課金対象となるのはコンテナインスタンスが開始されており最低でも 1 つのリクエストが処理されているタイミングとなります。なお、この値は 100 millisecond に繰り上げされます。

Cloud Run の料金については以下のテーブルをご覧ください。

課金の対象のリソースは CPU/Memory/Requests/Networking の計 4 つあります。上述の「課金対象のコンテナインスタンス時間」が関係するのは CPU と Memory となります。

ここでは参考に以下の条件で一ヶ月の利用料金を計算をしてみたいと思います。#計算をシンプルにするため無償枠は無視します 😇

Location: asia-northeast1
CPU allocated: 1
Memory allocated: 2GB
Concurrency: 20
Execution time per req: 200ms
Outbound network traffic per req: 64K
Request per month: 20,000,000 reqs

CPU 料金 : 20,000,000(reqs) / 20(Concurrency) * 0.2(200ms) * 0.00002400 = $4.8
Memory 料金 : 20,000,000 / 20 * 0.2 * 2(GB) * 0.00000250 = $2.0
Requests 料金 : 20,000,000/1,000,000(million req) * 0.4 = $8
Networking 料金 : 0.000064(GB) * 20,000,000 * 0.08(Asia-Asia nw price) = $102.4
合計 $117.2/month

ちなみにこの計算は各コンテナインスタンスが綺麗に同時に 20 のリクエストを処理することを前提にしてますので、実際にはもうちょっと掛かると思います。

計算結果を眺めてみると Networking の料金が大きいです。 egress にしか料金が掛からないので Cloud Run 上で動いているアプリケーションからのレスポンスのサイズ次第ということになります。
Web のサービスをホストするにしても静的なコンテンツは GCS や Firebase Hosting などを使って、Cloud Run ではサーバーサイドの API を提供するのみの利用としたり、 URL Query など使って極力レスポンスのサイズを小さくすると課金額を抑えることが出来そうです。

7 . Max instance setting (2019.10.01)

Cloud Run ではデフォルトで最大 1000 コンテナインスタンスまでスケールアウトしますが、サービスのデプロイまたはアップデート時に ”--max-instances” オプションでスケールアウト時の上限コンテナインスタンス数を指定出来ます。

サービスにおける最大同時リクエスト数は Concurrency * コンテナインスタンス数となりますので、上記 Service A の例では、最大同時リクエスト数 : 20 * 100 = 2,000 となります。
この値を超えてリクエストトラフィックが来た場合、Cloud Run では最大 60 秒間リクエストをキューイングし利用可能なコンテナインスタンスに転送します。利用可能なインスタンスが 60 秒間無かった場合にはステータスコード 429 でエラーを返します。

このオプションは例えば以下のようなユースケースで有用です。

コンテナインスタンス数を減らしてコストを削減したい (Cloud Runの場合 Concurrency があるので、コンテナインスタンス数を減らす＝コスト減に直接的にはなりませんが )
コンテナインスタンス数を抑えることで DB コネクション数上限を超えないようにしたい (E.g. Cloud SQL の場合、マシンスペック毎にコネクション数上限があります )

尚、公式ドキュメントにも記載がありますが、急なトラフィックスパイクがあった際には一時的に ”--max-instances” の値を超えてスケールアウトすることがあります。
またリビジョン毎に設定する値なので新しいリビジョンをデプロイした際にも一時的にコンテナインスタンス数が設定値を超えてしまうケースがあるので、DB コネクション数が上限を超えないようある程度余裕をみて値を決めた方が良さそうです。

8. SLA の設定 (2019.11.14)

2019.12.23 に SLA が改定され、Uptime Percentage 99.5 % > 99.95% となりました

GA になったということで金銭保証付きの SLA が設定されました。月ごとの Uptime Percentage が 99.95％(SLO) となります。

以下の定義が SLA に適用されます。

Backoff -Requirement:

エラーが発生した場合にクライアントが次のリクエストを投げる前に一定時間待つ責任があることを意味します。最初のエラーの後、 1 秒の最小 Backoff 間隔があり、連続するエラーごとに、backoff 間隔が最大 32 秒まで指数関数的に増加します。

Valid Request:

Cloud Run のドキュメントに準拠した通常はエラーなくレスポンスが返るリクエストです。

Error rate:

Cloud Run のインフラが原因で 5XX ステータスコードを返した Valid Request / 全 Valid Request です。 # ただし前述の Backoff -Requirement に適合しない場合はカウントされません。

Downtime:

Error rate が 10% を超えることを意味します。

Downtime period:

ダウンタイムが 1 分以上連続する期間です。 1 分未満または 1 分未満の断続的なダウンタイムは、ダウンタイム期間にはカウントされません。

Monthly Uptime Percentage:

1 か月の合計分数から、1 か月のすべてのダウンタイム期間 ( 分数 ) を引いたものを、1 か月の合計分数で割ったものです。

Financial Credit は以下の通りです。

如何でしたでしょうか？機能もだいぶ拡充して実際に本番利用して頂けるケースも私の観測範囲では増えてきたと思います。 VPC へのアクセスが出来なかったり、 GCLB が使えなかったり依然として課題はありますが、公式の Known Issues をよく見て頂ければこのあたりは今後に期待頂いて良いかと思います。

最後に知ってる人は知っている Cloud Run 関連で便利なサイトをご紹介します。

Awesome Cloud Run