Google Cloud Next Tokyo ‘23 に「 Cloud Run と HA VPN を使用したマルチクラウド環境での API 提供」で登壇しました

ビデオリサーチのニシです。

Google Cloud Next Tokyo '23は大盛況でしたね！

私も生成AI系のセッションをはじめ、様々なセッションを聴講し、多くを学ばせていただきました。

登壇時の様子

さて、前回の記事で登壇することをお伝えしましたが、体調を崩すことなく無事に登壇することができました。(写真は弊社のメンバーが撮影してくれました😊)

GoogleCloudNextTokyo23_Speaking

※当日の資料については、12月中旬ごろに公開予定とのことなので、公開されたら本記事にも公開先の情報をお伝えしたいと思います。

セッションを聴きに来てくださった皆様、ありがとうございました。

とても緊張しながらも、前半はなるべくゆっくりとお話しできたと思います。しかし、アーキテクチャの話になると早口になってしまうのが、いつもの自分だなぁ～、という感じでした😁

以下では、セッション当日にお話した技術的な話をピックアップして記載します。

Terraform Google Provider v4系と v5系の違い

今回作成した環境ではTerraform Google Provider v4系を使用していたため、Cloud Runのリソースで一部のannotationsをignoreしていました。

Terraform Google Provider v5系になると、labelsとannotationsは既存のリソースとTerraformで定義したリソースの情報をマージしてくれるようになります。

これにより、annotationsのignoreをしなくても良い感じに動作してくれそうです。

また、default_labelsが使えるようになったようです。これで共通のラベルを付けたいときに個々のリソースに記述する必要がなくなり、楽になりました。

Terraform Registry

Cloud Load Balancing のモード選択

今回はデプロイモードがグローバル外部、スキームがEXTERNAL_MANAGEDである外部アプリケーションロードバランサを選択しました。

要件的には、デプロイモードが従来、スキームがEXTERNALであっても良いのですが、先のことを考えたときに、重み付けによるトラフィック分割やリクエストのミラーリングなど、高度なトラフィック管理を備えていた方が便利そうであると思えましたので、グローバルでEXTERNAL_MANAGEDなロードバランサに決めました。

グローバル外部アプリケーションロードバランサのトラフィック管理の概要 | Load Balancing | Google Cloud

Cloud Armor をチューニングするときに参考にする情報

Cloud Armorの事前構成WAFルールを使っているので、WAFによる検知時にはGoogle Cloudのドキュメントをまずは見ます。大枠を理解するには分かりやすいのですが、具体的には？となるとちょっと難しいように感じました。

Google Cloud Armor の事前構成 WAF ルールの概要

そのようなときはOWASP ModSecurity Core Rule Setのリポジトリを活用しました。

検知時のidで検索すればどのようなルールに引っかかったのかがより分かりやすく、アプリケーションを改修するのか、ルールを除外するのかが考えやすかったです。

GitHub - coreruleset/coreruleset: OWASP CRS (Official Repository)

Artifact Registry に保管しているコンテナイメージの世代管理

Artifact Registryに保管しているコンテナイメージを削除せずに放っておくと少なからずコストがかかってしまうため、コンテナイメージの世代管理が必要となりますが、今回はgcloudコマンドを使って自前実装しています。

Artifact Registryに保管しているコンテナイメージを操作するには、gcloud artifacts dockerかgcloud artifacts filesが使えますが、gcloud artifacts dockerの方がdockerコマンドと似た体系になっているためおススメです。

gcloud artifacts files | Google Cloud CLI Documentation

pre-GAになっているクリーンアップポリシーがGAになったら自前実装しなくても良くなると思っています。

クリーンアップポリシーの設定 | Artifact Registry documentation | Google Cloud

Cloud Run のチューニング

Cloud Runの性能とコストのバランスを取るにはCPU、メモリ、インスタンスあたりの最大同時リクエスト数を決める必要があります。

CPU、メモリ、インスタンスあたりの最大同時リクエスト数を増やしてリクエストを集約した方が良いケースもあるのですが、実際どのぐらいのリクエストが受けられるのかにはミドルウェアの性能 (Pythonであれば、GunicornやUvicornです) によってしまいますし、初回リリースのタイミングでどのぐらいのリクエストが来るのかの想定にもよります。

これらを踏まえつつ、今回は負荷試験の結果も見てCPU 1 vCPU、メモリ 512 MiB、インスタンスあたりの最大同時リクエスト数 1としました。

インスタンスあたりの最大同時リクエスト数（サービス） | Cloud Run Documentation | Google Cloud

また、CPU、メモリ、ベースライン割り当てによってスケールできるインスタンス数が変わるため、気に留めておくと良いと思います。

インスタンスの最大数を設定する（サービス） | Cloud Run Documentation | Google Cloud