Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Zennを支える Google Cloud の技術

Zennを支える Google Cloud の技術

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

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

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

Yusuke Wada

March 27, 2023
Tweet

More Decks by Yusuke Wada

Other Decks in Technology

Transcript

  1. クラメソ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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  8. 凝縮版
    事例で公開しています

    クラメソ google cloud 事例

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. 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 full-size slide

  26. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  48. おわりに

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  51. 参考書籍

    View full-size slide