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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

7. View Slide

8. View Slide

9. View Slide

10. View Slide

11. in Action
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

19. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

26. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

50. Cloud Run の CPU利用率 が100%に
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

56. おわりに
    

    View Slide

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

    View Slide

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

    View Slide

59. 参考書籍
    

    View Slide

60. View Slide