Zennを支える Google Cloud の技術

Zennの裏側では、Next.jsとRuby on Rails 2種類のアプリケーションサーバーが動作しており、どちらも Cloud Run で運用しています。

Google Cloud では、Cloud Run をはじめアプリケーションの開発から運用までをワンストップで担えるサービスが充実しています。このセッションでは、Zennのバックエンドに焦点を当て、Google Cloudをどのように活用しているかの他、CI/CDをどのように回しているか、機能開発の是非をどう判断しているかを説明します。

アプリケーション開発のサイクルをZennを例に解説することで、皆様にとって少しでも手を動かすきっかけとなることを期待しています

Transcript

1. #zenn
2. クラメソ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全般 北九州市出身です！ みんなでアプリたくさんつくろう
3. 　　　　 とは Zennは「知見を共有するエンジニアに対価を」 というコンセプトでつくられた 技術情報共有コミュニティです。
4. 3種類の投稿形式で、その時々に合った粒度で知見を残すことができます ひとまず 雑にメモ したい あのテーマ で誰かと 議論したい 最近学んだ あの話を記事 にしよう 労力が かかった分 有料で販売 しよう あの話を まとめて 本にしよう
5. 公開した知見に対して、対価が得られる、本が販売できる点が特徴です
6. 私たちのビジョン Zennがなければ 生まれなかったものを 私たちはZennがあったからこそ生まれたプロダクトや仕事、 つながりを増やしたいと考えています。Zennがなければ誰か の頭に留まっていた知見がたくさん公開されるような場所に したいのです。 知見が投稿され続ける場所にするには、時間と労力をかけて 執筆したユーザーが「書いてよかった」「また書こう」と思 える仕組みを作る必要があります。 まだ自分たちの理想はまったくと言っていいほど実現できて いませんが、試行錯誤を繰り返しながら「また書こう」と思 えるようなサービスを作っていきたいと考えています。
11. in Action
12. Zennは、いろいろなサービスに支えられています 決済: Stripe メール送信: SendGrid CDNとOG画像: Cloudinary 出金: Amazonギフト券 屋台骨は Google Cloud AWS に比べるとアプリ開発のファーストチョイスになりにくいイメージ が、蓋を開けてみるとスタンダードなWebアプリを作るのに最適まである（感想）
13. 3つの切り口でZennを支えるGoogle Cloudの技術を紹介 アプリケーションサーバーとして使う CI/CDする モニタリングで活用する 今日の目標 アプリ開発者にとって体験の良い機能が揃っているので、少しでも知ってほしい Google Cloud を使う仲間が増えてほしい
14. 凝縮版 事例で公開しています クラメソ google cloud 事例
15. アプリケーションサーバーとしての Google Cloud 1
16. Webアプリを動かす上で必要になるもの ロードバランサー HTTPサーバー アプリケーション サーバー DBサーバー
17. Webアプリを動かす上で必要になるもの ロードバランサー HTTPサーバー アプリケーション サーバー DBサーバー Cloud Load Balancing Cloud Run Cloud SQL
18. 典型的な構成をモダンなプラットフォームで シンプルな構成で、かなりのところまで戦える => Zenn は500万PV以上/月だが 、性能不足で問題になったことはない ビジネスとともに成長する予定が少しでもあるならば、間違いない構成のひとつ モダン: ビジネスに応じてアプリをスケールさせる時、人間の手間が小さいこと
20. ピックアップ: Cloud Run 超絶優秀 アプリを早く市場投入する vs アプリをスケールする はトレードオフになりがち Cloud Run はコンテナイメージからデプロイでき、デフォルト設定でも勝手にス ケールしてくれる 開発者が気をつけること: アプリをステートレスに保つ データベースのコネクションプール枯渇と外部サービスのレートに気をつける コストに気をつける
21. ピックアップ: Cloud Scheduler シンプルな cron サービスだが一時停止や即時実行が画面から行える点が好み
22. ピックアップ: Cloud Scheduler サービスアカウント認証により、Cloud Run の URLを公開することなく実行可能
23. ピックアップ: Cloud Scheduler サービスアカウント認証により、Cloud Run の URLを公開することなく実行可能
24. 利用例: Cloud Scheduler Amazonギフト券の発行 - 毎月15日に実行 - 15 of month xx:00 販売した本やバッジの売上をユーザーごとに集計し、ギフト券を発行する
25. ピックアップ: Cloud Tasks タスクキューサービスだが、タスクはURLをパラメータとしてもつ => アプリとしてはエンドポイントを用意すればOK
27. 利用例: Cloud Tasks Markdown の一括変換 => 変換処理に破壊的変更を入れる場合などに、保存済みの記事を変換する 出典: https://en.wikipedia.org/wiki/Scheduling_(computing)#task_queue
28. 応用例: Cloud Scheduler + Cloud Tasks 年に一度の Recap メール送信 => 大量のバッチ処理を、任意のタイミングで実行する 出典: https://en.wikipedia.org/wiki/Scheduling_(computing)#task_queue Cloud Scheduler エンキュー処理
29. ここが好きだよ Cloud Tasks 開発者としては API エンドポイントを用意すれば良い（デキュー処理は不要） 少量のタスクを処理する実装を行う その少量のタスクに対しての冪等な処理が求められる 大きなタスクを部分タスクに分解する処理が求められる（エンキュー） => ここまでやるとどんなサイズの問題も分解して対応可能 => 外部サービスの負荷に考慮して スループットの調整が可能 サービスを使うように実装したら、様々なワークロードに応用できる
30. まとめ モダン: ビジネスに応じて自動スケールするとき、人間の手間が小さいこと 典型的なWeb3層構成が組みやすく、デフォルト構成でもスケールする Cloud Run、Cloud Tasks、Cloud Shceduler の組み合わせで相当範囲のワーク ロードをカバーできる 安い（Pay-as-you-go） ネットワークレイヤを意識することがほぼない ハードリミットが少なく、スケールを任せているとコストも増大する点に注意
31. CI/CDプラットフォームとしての Google Cloud 2
32. なぜ CI/CD？ 「はじめやすい」プラットフォームはたくさんあります。しかし、われわれ社会 人の戦いはむしろ初回リリース以降にある モダン≒ビジネスへの追従性だとすると、CI/CDは直結する技術要素 参考：エリート DevOps チームであることを Four Keys プロジェクトで確認 開発者にとって、ビジネスへ寄与しやすい技術要素がCI/CD
33. 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
34. 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
35. ピックアップ: Cloud Build Cloud Build トリガーと YAML ファイルがワンセットになっている トリガーで起動条件を決め、YAMLファイルに従って処理が進行する YAMLファイルではステップごとにイメージを指定し、コマンドを実行できる
36. 利用例: Cloud Build で Cloud Run へのデプロイ Ruby on Rails の 場合 起動条件 => GitHub リポジトリ のmainブランチへのpush/merge YAML ⇒ コンテナイメージのビルド（dockerコマンド） => Cloud Run の新しいリビジョンの作成（gcloudコマンド） ⇒ 新しいリビジョンへトラフィックを流すためのコマンドをSlackに送信 ⇒ そのコマンドを Cloud Shell で手動実行
37. Slackに流れてきたコマンドを Cloud Shell で実行 Cloud Shell
38. 利用例: Cloud Build で 本番DB マイグレーション Cloud SQL へつなぐには Proxy が必要だが、exec-wrapper イメージで解決
39. 先日、この話をクラメソの社内勉強会で展開しました
40. ピックアップ: 改善アドバイス 要約:
41. ピックアップ: 改善アドバイス 要約: 手作業を徹底的になくせ
42. ピックアップ: 改善アドバイス 要約: 手作業を徹底的になくせ CI/CDに人の手が絡むとデプロイのボトルネックになるので全自動が望ましい
43. ピックアップ: 改善アドバイス 要約: 手作業を徹底的になくせ CI/CDに人の手が絡むとデプロイのボトルネックになるので全自動が望ましい 例えば… - Cloud Shell でコマンドを実行するステップを組み込んでしまう - 新しいバージョンに30%だけトラフィックを流す - メトリクスを収集し、10分間500エラーが発生していなければ100%にする - リリース完了 ⇒ 課題はあるが（レイアウトの変更など）、さらに人の手を減らしていきたい
44. モニタリングを支える Google Cloud 3
45. セオリーの少ないモニタリング ここでいうモニタリングは、 プロダクトの健康状態をチェックし、インシデントが起きた場合に対応する どこまでやれば十分かはプロダクトによる しかし、以下は共通のはず: プロダクトの健康状態、とくに「レイテンシ」は体験に直結する どれだけデプロイ前を充実させても、不測の事態は必ず起きる インシデント後、ふりかえりができることが望ましい
46. 小さなチームでのオススメの考え方 これだけは守りたい メトリクスを多くても2〜3個決めて観測 アクセスログをBigQuery（データレイク）へ貯めておく 観測・対応・分析をワンセットのアクションにできるよう充実させる 最初から重厚にやりすぎると： アラートが多く疲れる 何が大事なのかがわかりづらくなる モニタリング専門家以外手を付けられなくなる ⇒ 大事なものを守るためインクリメンタルに周辺を充実させる ⇒ モニタリングを充実させることに理由ができる
47. 利用例: 稼働時間チェック レイテンシがトップページで5秒以上かかるようだとなにかあると仮定 稼働時間チェックを追加
48. 利用例: アクセスログのログルーティング ロードバランサーでアクセスログをCloud Loggingへ収集できる さらに Cloud Logging から BigQuery へログを転送する機能がある これらを組み合わせることでアクセスログをBigQueryでクエリ可能に
49. ある日、この稼働時間チェックでインシデントが発生
50. Cloud Run の CPU利用率 が100%に
51. 記事がバズったことによるバースト？ バーストならば特定の記事へアクセスが集中するはず そこで、アクセスログをためている BigQuery で集中している記事を探す アクセス集中している記事が見当たらない ここで攻撃を疑い、IPアドレスごとのリクエスト数を集計することに
52. DDoS攻撃をうけていた 平常時 インシデント発生時
53. Cloud Armor を導入し、IPアドレスをブロック このあとすぐに過負荷は落ち着き、平常を取り戻した
54. このインシデントをうけてやったこと アクセス過多でも捌けるように Cloud Run の最大インスタンス数を増やした Cloud Run インスタンス数の急激な増加でアラートを出すように 単位時間あたりのアクセス数をIPアドレスで集計できるようクエリを保存 社内で知見として共有
55. まとめ Zennの場合 大事なことを決めて、小さく始める モニタリングの設定はWebブラウザコンソールで十分（厳密にしすぎない） そのかわり、なにか項目を入れたり外したりしたときは経緯を共有すると良い
56. おわりに
57. Zennを支えるGoogle Cloudでした 開発者がビジネスへ寄与するためのひととおりのツールが揃っている サービスグロースを意識した機能・思想が多くちりばめられている印象 シンプルなアプリをモダンに動かしたいとき、有力な選択肢になるはずです
58. Zennを支えるGoogle Cloudでした 開発者がビジネスへ寄与するためのひととおりのツールが揃っている サービスグロースを意識した機能・思想が多くちりばめられている印象 シンプルなアプリをモダンに動かしたいとき、有力な選択肢になるはずです アプリサーバー CI/CD モニタリング・BI
59. 参考書籍