Cloud Run を中心としたWebアプリケーション構築事例 BigQueryとの統合解説 #serverlessdays #serverlesstokyo

クラメソZennチームで働いている和田といいます クラスメソッドへ入社 2016年2月 AWS EC2、Scala、Backend API サーバーレス（FaaSベース）アプリ開発 2018年7月 AWS Lambda、Node.js、Backend API, React SPA Zennをきっかけに Google Cloud の世界へ 2021年7月 Cloud Run、Next.js、Ruby on Rails、Zenn全般 福岡県北九州市出身です！

サーバーレスといえば…

サーバーレスといえば… API Gateway AWS Lambda DynamoDB

クラスメソッドでも お客様の課題解決に活用しています サーバーレスソリューションを駆使してきた アプリケーション開発メンバーに 「変化」を探るべく アンケートをとってみました

開発者へのアンケート AWS、Azure、Google Cloud 問わず Q1. これまでアプリ開発で使ってきたコンピューティングサービス Q2. これから使ってみたいコンピューティングサービス ※ クラウドプラットフォームやサービスを比較するものではありません

No content

No content

コメント紹介（一部） > LambdaのSnapStartも追い風となり、かつてはバットプ ラクティスだったLambdaにWebフレームワークのデプロイ が推奨される時代が来ていると感じています。 > APIGWやStepFunctionsを前段に置いて適切な粒度で処理 を区切れば多くの場合、コンピューティングはLambdaで問 題ないのかなと思っています。一方で、（中略）App Runner も主要な検討対象になってきたかなと思っています。 > 潮流的にFaaS->コンテナへの回帰を感じるが、FaaSは上記 の点でやはり優れたプラットフォームだと思う

サーバーレスの選択肢が確実に広がっている サーバーレスのどんな要素に我々は心打たれたのか？ 使った分だけ課金 素早い市場投入 無限のスケール これらの特性を取り入れたサービス・ソリューションが増えている コンテナもそのひとつ

「サーバーレスってこう」ではなく… Zennを動かしているのは： Cloud Run Cloud SQL BigQuery なにを考えて選んだか？結果どれくらいサーバーレスなのか？ 選択肢のひとつとしてポケットに入れていただきたい

Zenn / Cloud Run

とは Zennは「知見を共有するエンジニアに対価を」 というコンセプトでつくられた 技術情報共有コミュニティです。

3種類の投稿形式で、その時々に合った粒度で知見を残すことができます ひとまず 雑にメモ したい あのテーマ で誰かと 議論したい 最近学んだ あの話を記事 にしよう 労力が かかった分 有料で販売 しよう あの話を まとめて 本にしよう

No content

Webアプリフレームワーク + DB でシンプルに構築したい フレームワーク => Next.js と Ruby on Rails データベース 読み込みが多いワークロード ユーザーごとの投稿一覧を取得したり、新着順で投稿を取得したり Ruby on Rails の恩恵を受けられる => RDB（PostgreSQL）にきまり

デプロイ先どうするか Next.js や Rails を簡単にデプロイしたい Cloud Load Balancing App Engine Cloud SQL VMインスタンスではなくコンテナで運用したい ので Cloud Run へ移行した経緯あり https://zenn.dev/team_zenn/articles/migrate-appengine-to-cloudrun

No content

Web3層構成

Web3層構成でサーバーレス！？ 構成をシンプルに保ちつつも、ネットワークやインスタンスはあまり意識せずに済んでい る

ネットワーク Google Cloud のリソース群によりIAMによるアクセス制御が可能、ほとんど意識して いいない Serverless NEG Cloud SQL Auth Proxy Identity Aware Proxy 個々のリソースについてはぜひフリートークしましょう👍

インスタンス Cloud Run の力で意識せずに済んでいる 使用したリソースに対してのみ課金 RailsやNext.jsの恩恵を受けつつコンテナデプロイ ステートレス、エフェメラル、自動スケール

もちろん課題もある コールドスタート問題 非同期タスクの実行時間上限問題

変更デプロイ時のコールドスタート対策 リクエスト 現行リビジョン インスタンス1 現行リビジョン インスタンス2 現行リビジョン インスタンス1 現行リビジョン インスタンス2

変更デプロイ時のコールドスタート対策 リクエスト 現行リビジョン インスタンス1 現行リビジョン インスタンス2 現行リビジョン インスタンス1 現行リビジョン インスタンス2 gcloud run deploy backend-user-api --quiet --project=$PROJECT_ID --region=${_REGION} --image=$_ARTIFACT_REPOSITORY_IMAGE_TAG --service-account=$_CLOUD_RUN_SERVICE_ACCOUNT --add-cloudsql-instances=$_CLOUDSQL_INSTANCE_FULL_NAME --revision-suffix=${SHORT_SHA}-${_SHORT_BUILD_ID} --concurrency=1000 --cpu=1 --memory=4Gi --max-instances=150 --min-instances=2 --no-use-http2 --allow-unauthenticated --no-cpu-throttling --ingress=internal-and-cloud-load-balancing

変更デプロイ時のコールドスタート対策 現行リビジョン インスタンス1 現行リビジョン インスタンス2 新リビジョン インスタンス1 新リビジョン インスタンス2 現行リビジョン インスタンス1 現行リビジョン インスタンス2 新リビジョン インスタンス1 新リビジョン インスタンス2 コールド スタート gcloud run deploy backend-user-api --quiet --project=$PROJECT_ID --region=${_REGION} --image=$_ARTIFACT_REPOSITORY_IMAGE_TAG --service-account=$_CLOUD_RUN_SERVICE_ACCOUNT --add-cloudsql-instances=$_CLOUDSQL_INSTANCE_FULL_NAME --revision-suffix=${SHORT_SHA}-${_SHORT_BUILD_ID} --concurrency=1000 --cpu=1 --memory=4Gi --max-instances=150 --min-instances=2 --no-use-http2 --allow-unauthenticated --no-cpu-throttling --ingress=internal-and-cloud-load-balancing

変更デプロイ時のコールドスタート対策 リクエスト 現行リビジョン インスタンス1 現行リビジョン インスタンス2 現行リビジョン インスタンス1 現行リビジョン インスタンス2 gcloud run deploy backend-user-api --quiet --project=$PROJECT_ID --region=${_REGION} --image=$_ARTIFACT_REPOSITORY_IMAGE_TAG --service-account=$_CLOUD_RUN_SERVICE_ACCOUNT --add-cloudsql-instances=$_CLOUDSQL_INSTANCE_FULL_NAME --revision-suffix=${SHORT_SHA}-${_SHORT_BUILD_ID} --tag=latest --concurrency=1000 --cpu=1 --memory=4Gi --max-instances=150 --min-instances=2 --no-traffic --no-use-http2 --allow-unauthenticated --no-cpu-throttling --ingress=internal-and-cloud-load-balancing

変更デプロイ時のコールドスタート対策 リクエスト 現行リビジョン インスタンス1 現行リビジョン インスタンス2 現行リビジョン インスタンス1 現行リビジョン インスタンス2 gcloud run deploy backend-user-api --quiet --project=$PROJECT_ID --region=${_REGION} --image=$_ARTIFACT_REPOSITORY_IMAGE_TAG --service-account=$_CLOUD_RUN_SERVICE_ACCOUNT --add-cloudsql-instances=$_CLOUDSQL_INSTANCE_FULL_NAME --revision-suffix=${SHORT_SHA}-${_SHORT_BUILD_ID} --tag=latest --concurrency=1000 --cpu=1 --memory=4Gi --max-instances=150 --min-instances=2 --no-traffic --no-use-http2 --allow-unauthenticated --no-cpu-throttling --ingress=internal-and-cloud-load-balancing 新リビジョン インスタンス2 新リビジョン インスタンス1 latest latest

変更デプロイ時のコールドスタート対策 現行リビジョン インスタンス1 現行リビジョン インスタンス2 リクエスト 現行リビジョン インスタンス1 現行リビジョン インスタンス2 新リビジョン インスタンス2 新リビジョン インスタンス1 latest latest gcloud run services update-traffic backend-user-api --quiet --region=asia-northeast1 --to-revisions=latest=100

非同期タスクの実行時間対策（デフォルト10分） Markdown の一括変換 ⇒ 変換処理に破壊的変更を入れる場合などに、保存済みの記事を変換する

非同期タスクの実行時間対策（デフォルト10分） Markdown の一括変換 ⇒ 変換処理に破壊的変更を入れる場合などに、保存済みの記事を変換する 出典: https://en.wikipedia.org/wiki/Scheduling_(computing)#task_queue

ここまでのまとめ Zennは、サーバーレスの特性を意識しぎず、ビジネス・ワークロードに合ったアーキテク チャをシンプルに寄せて選択 Google Cloud の高抽象度なリソースのおかげで、サーバーレスの特性を享受してい る メリットのかわりに手間をかけているところもある どれくらいサーバーレスといえるのか？を最後にふりかえる

BigQuery

BigQuery: フルマネージドデータレイク Zennでの利用例をいくつか紹介します アクセスログ、BigQuery、Looker Studio アクセスログ、BigQuery、Cloud Armor Google Analytics4、BigQuery、Looker Studio 統計ダッシュボード

アクセスログ、BigQuery、Looker Studio Cloud Load Balancing Cloud Logging BigQuery Looker レイテンシ集計レポートを作成して潜在的なパフォーマンス問題がないか確認

アクセスログ、BigQuery、Cloud Armor Cloud Load Balancing Cloud Logging BigQuery 攻撃の疑いがあるとき、IPアドレスを特定してブロック Cloud Armor

Google Analytics4、BigQuery、Looker Studio BigQuery Looker PVなどのレポート Google Analytics4

アプリケーションとの統合例: 統計ダッシュボード ログインユーザーが表示できる 公開した記事の閲覧数などをみられる ログインユーザーの認証・認可 Google Analytics4 のイベントデータとCloud SQL のデータをどうにかJOINする必要がある 不特定多数のユーザーに呼ばれるため、クエリ課金 を回避したい

BigQuery BI Engine を使いました キャッシュ容量をあらかじめ購入し、キャッシュに入れ たいBigQueryのテーブルを指定する 1GBあたり約$36/月 キャッシュ内のデータに対するクエリには課金が発生し ない 統計ダッシュボードで利用するデータがすべてキャッ シュに収まれば…？ BigQueryクライアントからみたときの使い方は全く変 わらない BigQuery BI Engine PV table, master table BigQuery Zenn User Ruby on Rails Cloud Run

いかにキャッシュ領域に統計データをおさめるか スケジュールクエリで、PVイベントとマスタ（記事） データで必要なものだけ事前に集計、テーブルを 用意しておく それらのテーブルをBI Engineの対象にする BigQuery BI Engine PV table, master table BigQuery Zenn User Ruby on Rails Cloud Run スケジュール クエリ master table PV table

BigQueryのまとめ アプリケーションとは独立して利用できるケースと、アプリケーションと統合して利用する ケースを示した BigQuery はフルマネージドサービスで、クエリを使った分だけ課金される しかしZennの統計ダッシュボードでは使った分だけ課金だと青天井になる恐れがあった BI Engineを使い、コミットメント料金とすることで解決した データ容量の問題はエンジニアリングでカバー

Serverless

特性をどれくらい満たせているか 使った分だけ課金 素早い市場投入 スケーラビリティ

使った分だけ課金 一部のリソースでは定常課金あり（Cloud Load Balancing、Cloud SQL、 BigQuery BI Engine など） Cloud Run もコールドスタートを防ぐためにゼロスケールはせず、最低2台イン スタンスが立ち上がるよう設定 => 常に一定以上のアクセスがあるためその分の固定料金と思えば気にならない => 大事なのは、使った分だけ課金というよりは、月当たりのトータル金額

市場投入 最初のデプロイは時間がかかる が、Zennの場合は繰り返し変更をデリバリーするタイプ 変更容易性という点では助かっている ⇒ 典型的なWeb3層構成 Ruby on Rails + PostgreSQL（Cloud SQL） ⇒ ローカルでのテストが充実

スケーラビリティ Cloud Run は満たせる Cloud SQL は満たせない…？

スケーラビリティ Cloud Run は満たせる Cloud SQL は満たせない…？でもちょっと待って！

スケーラビリティ スケールを考えるシーンはふたつ １．スパイクアクセス => 特定の記事がバズったとき => 特定のレコードへのアクセスにはキャッシュが効く （DB、Rails） => Cloud Run さえスケールできていれば気にしすぎることはない ２．アクティブユーザーの増加 => Cloud SQL への負荷も予測できる => 手動での垂直スケール（メンテして性能強化）で対応

オンデマンド 課金特性 デプロイ特性 スケール特性 圧倒的初速 自動水平 エクストリームサーバーレス

オンデマンド コミットメント 課金特性 デプロイ特性 スケール特性 圧倒的初速 継続容易性 自動水平 手動垂直 エクストリームサーバーレス

オンデマンド コミットメント 課金特性 デプロイ特性 スケール特性 圧倒的初速 継続容易性 自動水平 手動垂直 Zenn

オンデマンド コミットメント 課金特性 デプロイ特性 スケール特性 圧倒的初速 継続容易性 自動水平 手動垂直 Zenn

オンデマンド コミットメント 課金特性 デプロイ特性 スケール特性 圧倒的初速 継続容易性 自動水平 手動垂直 Zenn

オンデマンド コミットメント 課金特性 デプロイ特性 スケール特性 圧倒的初速 継続容易性 自動水平 手動垂直 コスト効率、ビジネス効率が最大になるよう にサーバーレス特性を取り入れていく Zenn

まとめ サーバーレスの特性を備えた実行環境が選べるようになってきた 振り切った特性を最初に目指すよりは、まずビジネスに対するワークロードを考え、それ を満たせるシンプルなアーキテクチャを選択するほうが楽 その後、デリバリー速度、コスト効率が最大になるようにサーバーレス特性を取り入れて いく（場合によっては手間をかけるシーンも許容する） このようなアプリ構築も一つの手

No content