Zennを支える Google Cloud の技術

by Yusuke Wada

Slide 1

Slide 1 text

#zenn

Slide 2

Slide 2 text

クラメソ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全般北九州市出身です！みんなでアプリたくさんつくろう

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

公開した知見に対して、対価が得られる、本が販売できる点が特徴です

Slide 6

Slide 6 text

私たちのビジョン Zennがなければ生まれなかったものを私たちはZennがあったからこそ生まれたプロダクトや仕事、つながりを増やしたいと考えています。Zennがなければ誰かの頭に留まっていた知見がたくさん公開されるような場所にしたいのです。知見が投稿され続ける場所にするには、時間と労力をかけて執筆したユーザーが「書いてよかった」「また書こう」と思える仕組みを作る必要があります。まだ自分たちの理想はまったくと言っていいほど実現できていませんが、試行錯誤を繰り返しながら「また書こう」と思えるようなサービスを作っていきたいと考えています。

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

in Action

Slide 12

Slide 12 text

Zennは、いろいろなサービスに支えられています決済: Stripe メール送信: SendGrid CDNとOG画像: Cloudinary 出金: Amazonギフト券屋台骨は Google Cloud AWS に比べるとアプリ開発のファーストチョイスになりにくいイメージが、蓋を開けてみるとスタンダードなWebアプリを作るのに最適まである（感想）

Slide 13

Slide 13 text

3つの切り口でZennを支えるGoogle Cloudの技術を紹介アプリケーションサーバーとして使う CI/CDするモニタリングで活用する今日の目標アプリ開発者にとって体験の良い機能が揃っているので、少しでも知ってほしい Google Cloud を使う仲間が増えてほしい

Slide 14

Slide 14 text

凝縮版事例で公開していますクラメソ google cloud 事例

Slide 15

Slide 15 text

アプリケーションサーバーとしての Google Cloud 1

Slide 16

Slide 16 text

Webアプリを動かす上で必要になるものロードバランサー HTTPサーバーアプリケーションサーバー DBサーバー

Slide 17

Slide 17 text

Webアプリを動かす上で必要になるものロードバランサー HTTPサーバーアプリケーションサーバー DBサーバー Cloud Load Balancing Cloud Run Cloud SQL

Slide 18

Slide 18 text

典型的な構成をモダンなプラットフォームでシンプルな構成で、かなりのところまで戦える => Zenn は500万PV以上/月だが、性能不足で問題になったことはないビジネスとともに成長する予定が少しでもあるならば、間違いない構成のひとつモダン: ビジネスに応じてアプリをスケールさせる時、人間の手間が小さいこと

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

ピックアップ: Cloud Run 超絶優秀アプリを早く市場投入する vs アプリをスケールするはトレードオフになりがち Cloud Run はコンテナイメージからデプロイでき、デフォルト設定でも勝手にスケールしてくれる開発者が気をつけること: アプリをステートレスに保つデータベースのコネクションプール枯渇と外部サービスのレートに気をつけるコストに気をつける

Slide 21

Slide 21 text

ピックアップ: Cloud Scheduler シンプルな cron サービスだが一時停止や即時実行が画面から行える点が好み

Slide 22

Slide 22 text

ピックアップ: Cloud Scheduler サービスアカウント認証により、Cloud Run の URLを公開することなく実行可能

Slide 23

Slide 23 text

ピックアップ: Cloud Scheduler サービスアカウント認証により、Cloud Run の URLを公開することなく実行可能

Slide 24

Slide 24 text

利用例: Cloud Scheduler Amazonギフト券の発行 - 毎月15日に実行 - 15 of month xx:00 販売した本やバッジの売上をユーザーごとに集計し、ギフト券を発行する

Slide 25

Slide 25 text

ピックアップ: Cloud Tasks タスクキューサービスだが、タスクはURLをパラメータとしてもつ => アプリとしてはエンドポイントを用意すればOK

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

利用例: Cloud Tasks Markdown の一括変換 => 変換処理に破壊的変更を入れる場合などに、保存済みの記事を変換する出典: https://en.wikipedia.org/wiki/Scheduling_(computing)#task_queue

Slide 28

Slide 28 text

応用例: Cloud Scheduler + Cloud Tasks 年に一度の Recap メール送信 => 大量のバッチ処理を、任意のタイミングで実行する出典: https://en.wikipedia.org/wiki/Scheduling_(computing)#task_queue Cloud Scheduler エンキュー処理

Slide 29

Slide 29 text

ここが好きだよ Cloud Tasks 開発者としては API エンドポイントを用意すれば良い（デキュー処理は不要）少量のタスクを処理する実装を行うその少量のタスクに対しての冪等な処理が求められる大きなタスクを部分タスクに分解する処理が求められる（エンキュー） => ここまでやるとどんなサイズの問題も分解して対応可能 => 外部サービスの負荷に考慮してスループットの調整が可能サービスを使うように実装したら、様々なワークロードに応用できる

Slide 30

Slide 30 text

まとめモダン: ビジネスに応じて自動スケールするとき、人間の手間が小さいこと典型的なWeb3層構成が組みやすく、デフォルト構成でもスケールする Cloud Run、Cloud Tasks、Cloud Shceduler の組み合わせで相当範囲のワークロードをカバーできる安い（Pay-as-you-go）ネットワークレイヤを意識することがほぼないハードリミットが少なく、スケールを任せているとコストも増大する点に注意

Slide 31

Slide 31 text

CI/CDプラットフォームとしての Google Cloud 2

Slide 32

Slide 32 text

なぜ CI/CD？「はじめやすい」プラットフォームはたくさんあります。しかし、われわれ社会人の戦いはむしろ初回リリース以降にあるモダン≒ビジネスへの追従性だとすると、CI/CDは直結する技術要素参考：エリート DevOps チームであることを Four Keys プロジェクトで確認開発者にとって、ビジネスへ寄与しやすい技術要素がCI/CD

Slide 33

Slide 33 text

Zenn は GitHub Actions + Cloud Build lint + fomat RSpec vitest Cypress Rails 用トリガー Next.js 用トリガー DBマイグレーション用トリガー Cloud Run Cloud Run Cloud Shell Cloud Shell Cloud Shell Cloud SQL

Slide 34

Slide 34 text

GitHub Actions ZennのコアとなるNext.jsおよびRuby on Rails は同一リポジトリで管理 GitHub Actionsはこれらのコード検査が主な仕事 mainブランチへマージOKか（=リリースOKか）を判断する材料を提供するデプロイ成果物の生成は行わない Google Cloud や他 SaaSのシークレットは持ち込まない方針 Rails: Rubocop, RSpec Next.js: eslint, prettieer, tsc --noEmit, vitest, bundle-analyzer E2E: Cypress

Slide 35

Slide 35 text

ピックアップ: Cloud Build Cloud Build トリガーと YAML ファイルがワンセットになっているトリガーで起動条件を決め、YAMLファイルに従って処理が進行する YAMLファイルではステップごとにイメージを指定し、コマンドを実行できる

Slide 36

Slide 36 text

利用例: Cloud Build で Cloud Run へのデプロイ Ruby on Rails の場合起動条件 => GitHub リポジトリのmainブランチへのpush/merge YAML ⇒ コンテナイメージのビルド（dockerコマンド） => Cloud Run の新しいリビジョンの作成（gcloudコマンド） ⇒ 新しいリビジョンへトラフィックを流すためのコマンドをSlackに送信 ⇒ そのコマンドを Cloud Shell で手動実行

Slide 37

Slide 37 text

Slackに流れてきたコマンドを Cloud Shell で実行 Cloud Shell

Slide 38

Slide 38 text

利用例: Cloud Build で本番DB マイグレーション Cloud SQL へつなぐには Proxy が必要だが、exec-wrapper イメージで解決

Slide 39

Slide 39 text

先日、この話をクラメソの社内勉強会で展開しました

Slide 40

Slide 40 text

ピックアップ: 改善アドバイス要約:

Slide 41

Slide 41 text

ピックアップ: 改善アドバイス要約: 手作業を徹底的になくせ

Slide 42

Slide 42 text

ピックアップ: 改善アドバイス要約: 手作業を徹底的になくせ CI/CDに人の手が絡むとデプロイのボトルネックになるので全自動が望ましい

Slide 43

Slide 43 text

ピックアップ: 改善アドバイス要約: 手作業を徹底的になくせ CI/CDに人の手が絡むとデプロイのボトルネックになるので全自動が望ましい例えば… - Cloud Shell でコマンドを実行するステップを組み込んでしまう - 新しいバージョンに30%だけトラフィックを流す - メトリクスを収集し、10分間500エラーが発生していなければ100%にする - リリース完了 ⇒ 課題はあるが（レイアウトの変更など）、さらに人の手を減らしていきたい

Slide 44

Slide 44 text

モニタリングを支える Google Cloud 3

Slide 45

Slide 45 text

セオリーの少ないモニタリングここでいうモニタリングは、プロダクトの健康状態をチェックし、インシデントが起きた場合に対応するどこまでやれば十分かはプロダクトによるしかし、以下は共通のはず: プロダクトの健康状態、とくに「レイテンシ」は体験に直結するどれだけデプロイ前を充実させても、不測の事態は必ず起きるインシデント後、ふりかえりができることが望ましい

Slide 46

Slide 46 text

小さなチームでのオススメの考え方これだけは守りたいメトリクスを多くても2〜3個決めて観測アクセスログをBigQuery（データレイク）へ貯めておく観測・対応・分析をワンセットのアクションにできるよう充実させる最初から重厚にやりすぎると：アラートが多く疲れる何が大事なのかがわかりづらくなるモニタリング専門家以外手を付けられなくなる ⇒ 大事なものを守るためインクリメンタルに周辺を充実させる ⇒ モニタリングを充実させることに理由ができる

Slide 47

Slide 47 text

利用例: 稼働時間チェックレイテンシがトップページで5秒以上かかるようだとなにかあると仮定稼働時間チェックを追加

Slide 48

Slide 48 text

利用例: アクセスログのログルーティングロードバランサーでアクセスログをCloud Loggingへ収集できるさらに Cloud Logging から BigQuery へログを転送する機能があるこれらを組み合わせることでアクセスログをBigQueryでクエリ可能に

Slide 49

Slide 49 text

ある日、この稼働時間チェックでインシデントが発生

Slide 50

Slide 50 text

Cloud Run の CPU利用率が100%に

Slide 51

Slide 51 text

記事がバズったことによるバースト？バーストならば特定の記事へアクセスが集中するはずそこで、アクセスログをためている BigQuery で集中している記事を探すアクセス集中している記事が見当たらないここで攻撃を疑い、IPアドレスごとのリクエスト数を集計することに

Slide 52

Slide 52 text

DDoS攻撃をうけていた平常時インシデント発生時

Slide 53

Slide 53 text

Cloud Armor を導入し、IPアドレスをブロックこのあとすぐに過負荷は落ち着き、平常を取り戻した

Slide 54

Slide 54 text

このインシデントをうけてやったことアクセス過多でも捌けるように Cloud Run の最大インスタンス数を増やした Cloud Run インスタンス数の急激な増加でアラートを出すように単位時間あたりのアクセス数をIPアドレスで集計できるようクエリを保存社内で知見として共有

Slide 55

Slide 55 text

まとめ Zennの場合大事なことを決めて、小さく始めるモニタリングの設定はWebブラウザコンソールで十分（厳密にしすぎない）そのかわり、なにか項目を入れたり外したりしたときは経緯を共有すると良い

Slide 56

Slide 56 text

おわりに

Slide 57

Slide 57 text

Zennを支えるGoogle Cloudでした開発者がビジネスへ寄与するためのひととおりのツールが揃っているサービスグロースを意識した機能・思想が多くちりばめられている印象シンプルなアプリをモダンに動かしたいとき、有力な選択肢になるはずです

Slide 58

Slide 58 text

Zennを支えるGoogle Cloudでした開発者がビジネスへ寄与するためのひととおりのツールが揃っているサービスグロースを意識した機能・思想が多くちりばめられている印象シンプルなアプリをモダンに動かしたいとき、有力な選択肢になるはずですアプリサーバー CI/CD モニタリング・BI