Tweet
Tweet

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

Slide 59

Slide 59 text

参考書籍

Slide 60

Slide 60 text

No content