Zenn
Open57

CloudRun

merutinmerutin

https://cloud.google.com/run/docs/migrate/from-kubernetes?hl=ja

merutinmerutin

わかりやすい

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

merutinmerutin

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

merutinmerutin

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

merutinmerutin

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

merutinmerutin

Cloud Run が TLS を管理し、WebSocket、HTTP/2（エンドツーエンド）、gRPC（エンドツーエンド）をサポートします。

WebSocketもいけるの便利だな

merutinmerutin

Cloud IAM を使用してアクセス ポリシーを指定する。
上り（内向き）設定を使用してネットワーク アクセスを制限する。これは、VPC と内部サービスからの内部トラフィックのみを許可する場合に便利です。
Cloud Identity-Aware Proxy（IAP）で認証されたユーザーのみを許可する。

作成の画面からだとIAMのみに見えたけど、結構色々あるのね

merutinmerutin

Transport Layer Encryption（TLS）

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

merutinmerutin

Ingressコンテナは1つ、自分たちがデプロイするコンテナはいっぱい

Ingressはコンテナの前段にいるもので、1対1対応しているっぽい

merutinmerutin

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

merutinmerutin

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

merutinmerutin

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

merutinmerutin

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

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

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

merutinmerutin

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

Error: Page not found

merutinmerutin

CloudRunに 外部アプリケーション ロードバランサからのトラフィックを許可する という設定があったので許可してみる

merutinmerutin

つながった。設定周りで意識することが少なくて便利だな

merutinmerutin

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

merutinmerutin

tutorialをやってみる
https://cloud.google.com/sql/docs/mysql/connect-instance-cloud-run?hl=ja#go

merutinmerutin

なんでこれ、パスワードを直接入れているんだろうか。。

merutinmerutin

デプロイ周りの話
https://belonginc.dev/members/ryu/posts/try-terraform-cloud-run

merutinmerutin

初回のリソース作成はterraform、普段のデプロイはgcloudのコマンドを使うことを想定しているっぽい

merutinmerutin

CloudRunじゃないけど、LBからCloudRunを向けるときの複数サービスのやり方

defaultService: service
name: path-matcher-1
routeRules:
- matchRules:
  - prefixMatch: /terraform
  priority: 1
  routeAction:
    weightedBackendServices:
    - backendService: service
      weight: 100
    urlRewrite:
      pathPrefixRewrite: /
merutinmerutin

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

https://cloud.google.com/run/docs/container-contract?hl=ja

merutinmerutin

リクエストの処理中にのみ CPU を割り当てるように設定されたサービスの場合、Cloud Run はリクエストの処理中にのみ CPU 使用率に基づいてインスタンス数を自動スケーリングします。

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

https://cloud.google.com/run/docs/configuring/cpu-allocation?hl=ja
そういえばこんな設定も。ただ、それなりに動作している場合は常に割り当てをしていた方が安いらしい

merutinmerutin

現在、[リクエストの処理中にのみ CPU を割り当てる] を使用していて、次のような場合は、[CPU を常に割り当てる] のほうが経済的です。

Cloud Run サービスが、現在の多くのリクエストを一定の速度で処理している。
インスタンス数の指標で、アイドル状態のインスタンスが多くない。