技術書典で購入しましたCloud Run書籍レビューです。

https://techbookfest.org/product/jQP5REJPx6pwMFEyx8QHPN

第1章 Cloud Runとは

ECS Fargate、App Runner、Cloud Runを比較して、Cloud Runの構成シンプルさ、スケールで軍配があがることが書かれている

ECS Fargateのターゲット追跡、ターゲットトラッキングについて書かれていますが、ターゲット追跡以外に、ステップスケーリングの手段もあります。ステップスケーリングだと、CPU負荷等が高まったときにタスク数を複数増やせますが、リクエストをうけつけるまで2〜3分のラグはあるので、スパイクには耐えられない。

第2章 とりあえず触ってみよう

Cloud Run serviceを、Google Cloudのコンソールから作る方法について書かれています。

第3章　Cloud Runによるシステムデザイン

Cloud Run serviceを、Google Cloudのコンソールから作る方法について書かれています。

 

第3章　Cloud Runによるシステムデザイン

 

すべてのCloud Runは、HTTPのエンドポイントを持ちます。

Cloud TaskもHTTP EndpointでCloud Run エンドポイントを叩くことも可

 

一例として、Google WorkflowはHTTP エンドポイントをつなぎ合わせてワークフローを構成できる。

https://cloud.google.com/blog/ja/products/serverless/announcing-direct-vpc-egress-for-cloud-run

 

認証を利用して、特定Service Accountからの通信のみ許可することも可能。

Serverless VPC Connectorの欠点を網羅した、Direct VPC EgressでVPC内部通信も可能。

 Direct VPC Egressのmax instanceのQuotaに注意。

Cloud SQLへの通信、Auth Proxyで、TLSで暗号化できるとはいえ、データベース側がパブリックIP付与するので、データベースパブリック露呈してくなければ、Direct VPC Egressでプライベート通信がいいように思えます。

第4章　プロダクションレディな設計

サービスアカウントキーが漏洩したら、セキュリティ事故に繋がる可能性があるので、キー発行はせず、github actionからGoogle Cloudのサービスにアクセス手段は、Workload identify Federationを推奨。

Cloud Deployは、Skaffoldをベースにしたツールなので、Cloud Runだけでなく、GKEへのデプロイにも対応しています。

Cloud loggingからLog SinkでCloud Storageにも送ることガ可能

Cloud Run serviceには、Compute Engineのデフォルトサービスアカウントが付与されますが、Cloud Run serviceごとにService Acccountを分けたほうがいい。AWSだと、IAM Roleに相当します。

コンテナセキュリティについては、Cloud Runだけでなく他のGoogle Cloudのコンテナサービスにも応用できると思います。

コンテナのCPU負荷は60%前後を維持するのがよさそうか。

Cloud DeployでCPU Brustなどを定義するには、annotationsを定義します。

https://cloud.google.com/run/docs/reference/yaml/v1

Cloud Runに関することが設計思想をふくめて、もりだくさんに書かれている書籍になります。