Cloud Runの仕組み、料金体系

[kechigon]

Why

デプロイ先のことをよく知っておく必要がある。

What

ドキュメントをまとめる。

[kechigon]

料金

https://cloud.google.com/run/pricing?hl=ja

使用したリソースに対してのみ課金されます（100 ミリ秒単位で切り上げ）

同時実行の設定に一度に 1 つ以上のリクエストを設定すると、割り当てられた CPU とメモリを複数のリクエストで共有できます。

アウトバウンド インターネット データ転送にはプレミアム ネットワーク サービス ティアが使用されます。これには Google Cloud ネットワーキング料金[1]が適用されます。これには、北米内で 1 か月あたり 1 GiB の無料データ転送枠が含まれます。

Virtual Private Cloud ネットワークへのデータ転送は、VM からのデータ転送として課金され、Virtual Private Cloud のデータ転送料金で課金されます。サーバーレス VPC アクセス コネクタでは、実行に必要なコンピューティングに対しても料金が発生します。サーバーレス VPC アクセスの料金をご覧ください。

同じリージョン内の Google Cloud リソースへのデータ転送（Cloud Run サービスから別の Cloud Run サービスへのトラフィックなど）は無料です。Media CDN、Cloud CDN、Cloud Load Balancing へのデータ転送は無料です。

確約利用割引: 確約利用割引を購入することで、Cloud Run の継続使用の費用を抑えることができます[2]。たとえば、Cloud Run サービスに常に 1 つ以上のアクティブなインスタンスがある場合は、少なくともこの量をコミットすることで、コストを削減できます。Cloud Run は、過去の使用状況に基づいて確約利用割引の推奨事項を自動的に作成します。

まだアクセスは少ないので、割り当てを一定にしなくてよさそう。

リクエストの処理中にのみ CPU が割り当てられたサービスに対する課金対象インスタンス時間
デフォルトでは、Cloud Run はインスタンスに割り当てられた CPU とメモリが次の場合にのみ課金されます。

• インスタンスが起動中。
• インスタンスが正常にシャットダウンしている（SIGTERM シグナルを処理している）。
• インスタンスによって 1 つ以上のリクエストが処理されています。 次の図のように、請求対象のインスタンス時間は、最初のリクエストの処理が始まってから、最後のリクエストの処理が完了するまでです。

インスタンスの最小数を設定すると、それらのインスタンスがリクエストを処理していないときは、異なる「アイドル」レートで課金されます。[3]上記の表をご覧ください。

[1] tokyo rigion では1TBi当たりだいたい$0.15
[2] 一定期間使用を確約することで17%引き https://zenn.dev/team_zenn/articles/zenn-used-cud
[3] おそらく常時割り当てになる。

[kechigon]

アーキテクチャ

https://blog.g-gen.co.jp/entry/cloud-run-explained

Kubernetes 上にサーバーレスなコンピューティング基盤を構築できるオープンソースソフトウェアの Knative がベースとなっています

Cloud Run サービス (services)

Cloud Run サービスでは、コンテナイメージをデプロイするだけで、コンテナの実行環境（コンテナインスタンス）とリクエストを受信する HTTPS エンドポイントが提供されます。

リクエストを受けてレスポンスを返す、ウェブサイトや API バックエンドなどのユースケースに用いられます。

Cloud Run ジョブ (jobs)

Cloud Run ジョブでは、コンテナインスタンスを使用して、ユーザーが作成したコードを HTTP リクエスト起点ではない ジョブ として実行することができます

サービスの冗長性

Cloud Run サービスは特定のリージョンに作成され、冗長性とフェイルオーバーのため、リージョン内の複数のゾーンに自動的に複製されます。

デプロイ元のコンテナイメージ

サーバーレス CI / CD プラットフォームである Cloud Build を使用することで、Git リポジトリへの push をトリガーとして、Cloud Run への継続的なデプロイを実現することも可能です

コンテナの要件

• コンテナイメージ内の実行可能ファイルは、Linux 64 ビット用にコンパイルする必要がある。
• リクエストの送信先ポート（デフォルトのポートは 8080 ）で 0.0.0.0 のリクエストをリッスンする必要がある。
• リクエストを受信してからリクエストのタイムアウト設定で指定された時間内に、レスポンスを返す必要がある。

トラフィック移行とロールバック

新しいリビジョンを作成した際に、既存のリビジョンに対する全てのトラフィックを即座に移行するか、段階的に移行するかを選択することができます。

また、複数のリビジョンでトラフィックを分割したり、古いリビジョンにロールバックしたりできます（参考）。

エンドポイント

デフォルトでは、Cloud Run サービスには *.run.app ドメインの一意のサブドメインがサービスの HTTPS エンドポイントとして提供されます。

グローバル外部 HTTPS ロードバランサ または Firebase Hosting を利用することで、カスタムドメインを設定することもできます（参考）。

コンテナインスタンスの最大・最小数

動的スケーリングの最大・最小インスタンス数をあらかじめ設定することができます。

最大インスタンス数はデフォルトが 100、上限は 1000 で 上限の引き上げ も可能となっています。

最小インスタンス数はデフォルトで 0 となっており、リクエストがないときはインスタンス数が 0 になるまでスケールインします。

インスタンス数が 0 の状態で Cloud Run サービスに対するリクエストがあった場合、インスタンスを起動する時間ぶん、処理の遅延が発生します（コールドスタート）。

そこで、最小インスタンス数を 1 以上 にすることにより、コンテナインスタンスのウォーム状態 (いつでも呼び出し可能な状態) を維持し、リクエストをすぐに処理することが可能になります。

最小インスタンス数が 1 以上の場合、指定した数のコンテナインスタンスがアイドル状態で常に起動しており、リクエストを処理していないときでも、アイドル状態のインスタンスの料金が発生します。

アイドル状態のインスタンスの料金は、実際にリクエスト処理をしているときの料金よりも安く設定されています ( 料金表 ) 。

Startup CPU boost

ゼロスケールからのコンテナ起動や、リクエスト数が上昇してスケールアップする際のコンテナ起動を高速化するために Startup CPU boost 機能が存在します。
https://blog.g-gen.co.jp/entry/cloudrun-cpu-startup-boost#Startup-CPU-boost-%E3%81%A8%E3%81%AF

CPU・メモリ

サービスのデプロイ時に Cloud Run のコンテナインスタンス 1 つに割り当てる CPU の数とメモリ容量の上限を設定できます。デプロイ後も変更が可能です。

CPU の数に応じて、割り当てることができるメモリ容量の幅が決まります。

• 参考 : CPU 制限
• 参考 : メモリ上限を構成する

今現在の割り当て

    Memory:          512Mi
    CPU:             1000m

リクエストのタイムアウト

Cloud Run サービスのエンドポイントで受信したリクエストの処理に使用できる時間を設定できます。

デフォルトは 300秒 で、1~3600秒 の範囲で設定することができます。

• 参考 : リクエスト タイムアウトの設定（サービス）

コンテナインスタンスあたりの同時リクエスト最大数

1つのコンテナインスタンスが処理できる同時リクエストの数を設定できます。

デフォルトは 80 で、1~1000 の範囲で設定することができます。

• 参考 : インスタンスあたりの最大同時リクエスト数（サービス）

CPU を常に割り当てる Cloud Run サービス

Cloud Run では、CPU を常に割り当てる Cloud Run サービス として構成することで、リクエストがない場合でもコンテナインスタンスに CPU を割り当て、短期のバックグラウンドタスクや非同期処理タスクを実行することができます。

コンテナ実行環境 (世代)

Cloud Run のコンテナ実行環境として、第 1 世代 と 第 2 世代 が選択できます。
デフォルトの設定では、Cloud Run サービスには第 1 世代の実行環境が使用されるようになっています。

トラフィックが増えるまで第一世代でよさそう。

サービス連携 (トリガー)

Cloud Run サービスでは、クライアントからの HTTPS リクエスト経由の呼び出しのほか、gRPC や WebSocket を使用した通信や、他の Google Cloud サービスからの呼び出しをサポートしています。

Google Cloud のサービスからの呼び出しは、Pub/Sub、Cloud Scheduler、Cloud Tasks、Eventarc、Workflows などが利用できます。

• 参考 : HTTPS リクエストによる呼び出し
• 参考 : Pub/Sub の push によるトリガー

Cloud Run サービスに対する接続

デフォルトの設定では、ネットワークレベルでは任意のアクセス元から Cloud Run サービスにアクセスすることが可能です。

上り（内向き）設定 を変えることで、ネットワークアクセス元について 3 段階の制限をかけることが可能です。

• 参考 : Cloud Run での上り（内向き）の制限

Cloud Run サービスから VPC ネットワークへの接続

GKE のクラスタ等とは異なり、Cloud Run サービスは VPC ネットワークの外に作成されるため、デフォルトでは VPC 内のリソースに Private IP (内部 IP) でアクセスすることができません。

サーバーレス VPC アクセス を使用することで、コネクタインスタンスを経由して Cloud Run サービスを VPC ネットワークに接続することができます

非公開サービスの認証

アプリケーションのレベルでは、Cloud Run サービスはデフォルトで非公開としてデプロイされます。

公開アクセスの許可

デプロイしたサービスが公開 API やウェブサイトの場合は 公開アクセスを許可 します。

コンソールや CLI から allUser メンバータイプ に対して Cloud Run 起動元（roles/run.invoker） ロールを割り当てるだけで、未認証のサービス呼び出しを許可することができます。

• 参考 : 公開（未認証）アクセスを許可する

ユーザー認証

サービスに対して、許可されたエンドユーザーのみにアクセスを制限する場合、Identity Platformを使用します。

Compute プロダクトの考え方

Cloud Run は柔軟性と運用負荷において、Compute プロダクト内でも 中間の位置 にあります。

Cloud Run と Compute Engine の違い

Compute プロダクトの中で最高の柔軟性があり、他のプロダクトにデプロイできるものは GCE にデプロイすることも可能です。

その代わり GCE では、仮想マシンの OS から上にあるものはすべてユーザーが構築・管理する必要があります。

また Cloud Run のようなサーバーレスアーキテクチャではないため、仮想マシンの実行中は何も処理をしていなくても課金され続けます

Cloud Run と Google Kubernetes Engine の違い

• リクエストがないとき GKE は 0 までスケールインできない。 Cloud Run ではできる
• GKE は複雑な構成が可能 (マイクロサービス) 。 Cloud Run でデプロイできるのは 1 つのコンテナイメージのみ
• GKE は VPC 内で動作するため、VPC 内 のリソースとの直接接続が容易。Cloud Run では VPC 内のリソースと通信するためにはサーバーレス VPC アクセスなどの設定が必要

Cloud Run と App Engine の違い

• GAE ではデプロイに必要なのはコードと構成ファイルのみであり、Cloud Run よりも実行環境の柔軟性が劣る代わりに、容易にアプリケーションを実行することができる。
• GAE では Identity Aware Proxy (IAP) による認証がサポートされている。Cloud Run でも IAP を使用することができるが、Serverless NEG に紐づける必要があり、そのフロントエンドとして使用するロードバランサ分の料金がかかる。
• また、フレキシブル環境の GAE のみのデメリットとして、VM ベースの実行環境のためスケーリングが遅い、0 までスケールインできないなどがあります。
• 料金はCloud Runのほうが基本的には安い(https://cloud.google.com/appengine/migration-center/run/compare-gae-with-run?hl=ja#pricing-model)

Cloud Run と Cloud Functions の違い

コードのみで容易にデプロイでき単純な処理をさせるのに向いているのが Cloud Functions 。実行環境の柔軟性が高く、長時間に渡る複雑な処理もさせることができるのが Cloud Run といえます。

Cloud Run for Anthos

Anthos は Kubernetes によってインフラレイヤを抽象化することにより、Google Cloud 以外の各種クラウドプラットフォームやオンプレミス上でもコンテナアプリケーションを同じように構築・運用することができる Google Cloud のサービスです。

Anthos では「オンプレミス」「AWS」「Google Cloud」などの各プラットフォーム上に存在する Kubernetes クラスタを、Google Cloud Console の単一のインターフェースで管理することができます。

Cloud Run for Anthos は Anthos が提供するサービスの 1 つであり、Anthos クラスタに対して Google マネージドの Knative を構築することによって、Cloud Run によるサーバーレスなコンテナ実行を利用することができるようになります（参考）。

通常の Cloud Run では実現できない以下のようなユースケースに対応可能となります。

• サーバーレス VPC アクセスを使用しない VPC ネットワークへの接続
• 1 つのサービスで複数の種類のコンテナを実行
• GPU を利用したハイパフォーマンス処理の実行

[kechigon]

kanative

https://cloud.google.com/knative?hl=ja

Cloud Run で始めた後で Cloud Run for Anthos に移動したり、自分の Kubernetes クラスタで始めた後で Cloud Run に移行したりすることも簡単です。

新規リビジョンの段階的な公開

プラグイン可能: ご自身のロギングとモニタリング プラットフォームに接続

https://knative.dev/docs/concepts/#what-is-knative

Knative Serving は、オブジェクトのセットを Kubernetes カスタム リソース定義 (CRD) として定義します。これらのリソースは、サーバーレス ワークロードがクラスター上でどのように動作するかを定義および制御するために使用されます。

images/object_model.png)

サービス：service.serving.knative.devリソースは、ワークロードのライフサイクル全体を自動的に管理します。他のオブジェクトの作成を制御し、アプリがサービスの更新ごとにルート、設定、新しいリビジョンを持つようにします。サービスは、トラフィックを常に最新リビジョンまたは固定リビジョンにルーティングするように定義できます。
ルート:route.serving.knative.dev リソースは、ネットワーク エンドポイントを 1 つ以上のリビジョンにマップします。トラフィックは、部分トラフィックや名前付きルートなど、いくつかの方法で管理できます。
設定：configuration.serving.knative.devリソースは、デプロイに必要な状態を維持します。コードとコンフィギュレーションをきれいに分離し、Twelve-Factor Appの方法論に従います。設定を変更すると、新しいリビジョンが作成されます。
リビジョン：revision.serving.knative.devリソースは、ワークロードに加えられた各変更のコードと設定のポイントインタイムスナップショットです。リビジョンは不変のオブジェクトで、有用な限り保持できます。Knative Servingのリビジョンは、トラフィックに応じて自動的に増減できます。