CloudRun

ちょっと違う


わかりやすい
Cloud Run の主要なリソースはサービスです。Cloud Run サービスは、Pod オートスケーラーと一意のエンドポイントが組み込まれた Kubernetes Deployment のような高度な抽象化とみなすことができます。Kubernetes の Pod は、Cloud Run のインスタンスに対応します。Kubernetes Deployment は Cloud Run サービスに変換することをおすすめします(一度に 1 つのサービスに変換してください)。Kubernetes HorizontalPodAutoscaler と Kubernetes Service の一部の構成を Cloud Run サービスに統合することもできます。

Cloud SQL 接続がデフォルトであるのね。ふむふむ

CPUの数が1以下の場合、同時リクエストが1になるらしい。すごい仕様だ

認証
IAMを使った認証ができるらしい。外部からのアクセスを許可しない場合に利用しそう。
LBを使う場合はどうなるんだろう

Cloud Run が TLS を管理し、WebSocket、HTTP/2(エンドツーエンド)、gRPC(エンドツーエンド)をサポートします。
WebSocketもいけるの便利だな

Cloud IAM を使用してアクセス ポリシーを指定する。
上り(内向き)設定を使用してネットワーク アクセスを制限する。これは、VPC と内部サービスからの内部トラフィックのみを許可する場合に便利です。
Cloud Identity-Aware Proxy(IAP)で認証されたユーザーのみを許可する。
作成の画面からだとIAMのみに見えたけど、結構色々あるのね

Transport Layer Encryption(TLS)
コンテナ内部はHTTP/1前提になっているのね。grpcは別だけど、まああんまり使ったことないからいいや

Ingressのコンテナがあるのね。

Ningxがメインのコンテナなのね
ingressコンテナっていうのは、外部の公開しているポートのコンテナってニュアンスっぽい

terraformのサンプルがあるのうれしいですね

トラフィックの急増やシステム メンテナンスなどの一部のケースでは、Cloud Run が短期間に最大インスタンス数を超えるインスタンスを作成することがあります。

サンプルのコンテナで起動してみる

IAM認証が必要な場合に直接リンクを踏むとForbiddenが発生する

手前にロードバランシングを追加する

設定するものは多いものの、バックエンドとしてCloudRunを指定する

なんかエラーでた
An active proxy-only subnetwork is required in the same region and VPC as the forwarding rule.

- サーバーレス ネットワーク エンドポイント グループ
- バックエンド サービス
- プロキシ専用サブネット
を作成する必要がある

作成完了画面は割とあっさり

LB通してもForbiddenは変わらず。インターネット通しているからかな

内部のネットワークに絞ったものを作成してみる。
当然、作成したもののページは表示されず
Error: Page not found

LB側にCloudRunの説明があった

まとまっていてわかりやすい

LBのターゲットごとに指定するバックエンドセキュリティポリシーでは、rate limitなどを設定できる

これ忘れてた

deployのパターン。
gcloud run deploy
は知らなかった。便利だわ

tutorialをやってみる

デプロイ周りの話

上記記事内で言及されていた内容

CloudRunじゃないけど、LBからCloudRunを向けるときの複数サービスのやり方
defaultService: service
name: path-matcher-1
routeRules:
- matchRules:
- prefixMatch: /terraform
priority: 1
routeAction:
weightedBackendServices:
- backendService: service
weight: 100
urlRewrite:
pathPrefixRewrite: /

Cloud Run は、コンテナ イメージのローカルコピーを保存して、コンテナの起動時に非常に高速に読み込みを行う。
知らなかった。勉強になる

そういや、Boostがあるのか

パフォーマンスチューニングDeepDive

スケールアウト中など、新しいインスタンスが起動されると、少なくともこのサービスのコンテナ インスタンスの平均起動時間の間はリクエストが保留されます。これには、ゼロからのスケーリングなど、リクエストでスケールアウトが開始されるタイミングも含まれます。
起動時間が 10 秒未満の場合、リクエストは最大で 10 秒間保留されます。
起動プロセスにインスタンスがなく、リクエストがスケールアウトを開始しない場合、リクエストは最大で 10 秒間保留されます。

リクエストの処理中にのみ CPU を割り当てるように設定されたサービスの場合、Cloud Run はリクエストの処理中にのみ CPU 使用率に基づいてインスタンス数を自動スケーリングします。
CPU を常に割り当てるように設定されたサービスの場合、Cloud Run は、コンテナ インスタンスのライフサイクル全体で CPU 使用率に基づいてインスタンス数を自動スケーリングします。ただし、ゼロへのスケーリングとゼロからのスケーリングの場合は、リクエストのみを使用します。
そういえばこんな設定も。ただ、それなりに動作している場合は常に割り当てをしていた方が安いらしい

現在、[リクエストの処理中にのみ CPU を割り当てる] を使用していて、次のような場合は、[CPU を常に割り当てる] のほうが経済的です。
Cloud Run サービスが、現在の多くのリクエストを一定の速度で処理している。
インスタンス数の指標で、アイドル状態のインスタンスが多くない。

CPUを常に割り当てって後からできた機能なのね

イメージ ストリーミング

v1とv2の違い

実行環境について

gcloud deployのコマンドで複数起動しているコンテナのデプロイをしてみた。
gcloud run deploy backend-for-test --image=asia-northeast1-docker.pkg.dev/xxxx
メインのコンテナのimageのみが更新されて、ほかは変更がないことを確認した。
コマンドのリファレンスにもそれっぽいことは書いてあり、指定してない場合はprimary ingress containerになるとのこと。primaryとは?という感じだが、おそらく最初に指定されている要素っぽい。
The following flags apply to a single container. If the --container flag is specified these flags may only be specified after a --container flag. Otherwise they will apply to the primary ingress container.