Notionで作るWebサイト「MuuMuu Sites」の裏側

Transcript

1. 1 Notionで作るWebサイト 「MuuMuu Sites」の裏側 きのすけ (⻄⽥ 貴之) ホスティング事業部 事業開発チーム 2023.12.13
2. 2 ⾃⼰紹介 ホスティング事業部 事業開発チーム 2020年 中途⼊社 きのすけ kinosuke01 • Webアプリケーションエンジニア • バックエンドの開発がメインですが、 職種を越境してフルサイクルな動きをしがち。 • ディレクターや デザイナーとわいわい仕事しています。 • X(Twitter) : @kinosuke01
3. 3 アジェンダ • MuuMuu Sitesというサービスをリリースしました。 • 新しいサービス、裏側の仕組み気になりますよね。 • 今回は、そういった好奇⼼を少しでも満たせれば。
4. 4 アジェンダ 1. MuuMuu Sites の 紹介 2. MuuMuu Sites の 設計 3. ⼯夫した点 3.1. jobの死活監視 3.2. サイト公開フロー
5. 1. MuuMuu Sites の 紹介 5
6. MuuMuu Sites の 紹介 6 MuuMuu Sites ってなに？ Notionに書いたページに 独⾃ドメインをあてて デザインをカスタマイズして Webサイトとして 公開できるサービス
7. MuuMuu Sites の 紹介 7 MuuMuu Sites ってなに？ - 補⾜ • ドメインの購⼊管理ができるサービス 「ムームードメイン」 の 1機能として提供 • 必要な費⽤は「ドメインの取得更新費」のみ ドメインがあれば無料でサイトが作成可能 • 読みは「ムームーサイト」
8. MuuMuu Sites の 紹介 8 1. ムームードメインでドメインを取得 2. Notionにコンテンツを書く 3. MuuMuu Sites でWebサイトを作成 使い⽅
9. MuuMuu Sites の 紹介 9 • MuuMuu Sitesで案内に従って選択肢から選ぶだけ MuuMuu SitesでWebサイトを作成 ドメインを 選ぶ 公開する Notionページ を選ぶ サイトの テーマを選ぶ Notion連携 ＼！完成！／
10. MuuMuu Sites の 紹介 10 設定項⽬が厳選されているので、選択肢から選ぶだけで 「あ、これもいいな」と思えるサイトに。 デザインのカスタマイズ
11. 2. MuuMuu Sites の 設計 11
12. MuuMuu Sites の 設計 12 Notion API ホスティングサーバ ページの情報を取得 取得したデータから サイトデータ (html,cssなど)を生成 生成したファイルを ホスティングサーバに アップロード Webサイトとして 閲覧できる
13. MuuMuu Sites の 設計 13 サイト公開フロー - 概略 ⼩さくて読めないので 次のスライド以降でわけて説明
14. 14 MuuMuu Sites の 設計
15. 15 MuuMuu Sites の 設計
16. 16 MuuMuu Sites の 設計
17. 17 MuuMuu Sites の 設計 サイト公開 - 概略 • サイト公開に⾄るまで、このフローを何回も繰り返し動かしている • たとえば • DNS設定とVirtualHostの設定 → 処理終了 → 再度動かす → http疎通チェック → NG → 処理終了 → 再度動かす → http疎通チェック → NG → 処理終了 → 再度動かす → http疎通チェック → OK → 証明書発⾏へ進む
18. MuuMuu Sites の 設計 18 サイト作成API - 概略 WebAPI Job
19. MuuMuu Sites の 設計 19 サイト作成API - 概略 WebAPI Job サイトビルド＆デプロイ リクエスト
20. MuuMuu Sites の 設計 20 サイト作成API - 概略 WebAPI Job WebAPIで受けた ビルド＆デプロイリクエストは RedisStreamsを流れます
21. MuuMuu Sites の 設計 21 サイト作成API - 概略 WebAPI Job メッセージを受け取ったら、 Next.jsアプリケーションを 外部コマンドで起動し、 静的サイトをビルドします。 Next.jsアプリケーションは 内部でNotionAPIを呼び出し ビルドに必要な情報を取得します。
22. MuuMuu Sites の 設計 22 サイト作成API - 概略 WebAPI Job ⽣成された静的サイトのファイルを、ホスティングサーバへデプロイします。
23. MuuMuu Sites の 設計 23 サイト作成API - 概略 WebAPI Job 新しいサイトのデプロイを検知したら、 ユーザにその案内を表⽰します。
24. 3. ⼯夫した点 - jobの死活監視 24
25. ⼯夫した点 25 • WebAPIは、ヘルスチェック⽤のエンドポイント⽣やしておけば • jobの場合は？ ◦ 「正常に動作している」という状態をどう表現する？ ◦ それをどのようにしてPod外から監視するか？ jobの死活監視どうする？
26. ⼯夫した点 26 • 「正常に動作している」という状態をどう表現する？ ◦ jobは定期的にRedisStreamsからメッセージを読み取っている ◦ 読み取る直前にRedisにホスト名をキーにした値をsetする (Heart Beatをsetする) ◦ その値はTTLつきとする (たとえば180秒とか) • 定期的な読み取りがストップしていた場合、HeatBeatが揮発する • HeartBeatがある状態を正常、ない場合を異常と扱う jobの死活監視はこうした
27. ⼯夫した点 27 • それをどのようにしてPod外から監視するか？ ◦ jobと同じプロセス内でexpressでhttpサーバを起動 ◦ ヘルスチェック⽤のエンドポイントを準備 ▪ HeartBeatの有無によって、 レスポンスのステータスコードを変える(200 or 500) • これを、k8sのDeploymentのLivenessの設定に⼊れておく jobの死活監視はこうした
28. 3. ⼯夫した点 - サイト公開フロー 28
29. MuuMuu Sites の 設計 29 まず思い出してほしい - サイト公開フロー サイト公開に⾄るまで、このフロー を何回も繰り返し動かしている たとえば DNS設定とVirtualHostの設定 → 処理終了 → 再度動かす → http疎通チェック → NG → 処理終了 → 再度動かす → http疎通チェック → NG → 処理終了 → 再度動かす → http疎通チェック → OK → 証明書発⾏へ進む
30. ⼯夫した点 30 • サイト公開フローは5分に1回のバッチ処理で実⾏している • しかしそれだと無駄が多い側⾯がある ◦ 例）サーバ証明書の発⾏リクエストが実⾏ → 1分後にhttps疎通できるようになった → でも、https疎通チェックと次のアクションの実⾏は4分後... この4分間無駄に待たされるのはどうなの？ サイト公開フローをいい感じに連投したい - 課題
31. ⼯夫した点 31 • バッチ処理とは別ラインで、サイト公開処理を実⾏するようにした • 「MuuMuu Sites」のコンパネ開きっぱなしのとき、 定期的(⼗数秒おき)にXHRで公開処理を実⾏するAPIを叩いている。 • これにより、5分を待たずとも公開処理を先に進めることができている。 （※他にもやりようはあったのだけど、諸般の事情でそうした） サイト公開フローをいい感じに連投したい - こうしてみた
32. ⼯夫した点 32 • もちろんそうすることで新たな問題も。 • 同じサイトの公開処理が並列で実⾏されうるので、 レースコンディション発⽣による、データの不整合など発⽣しないか。 レースコンディション - 新たな問題
33. ⼯夫した点 33 • シンプルに排他制御を設けて対応。 ◦ 公開処理を実⾏する前に、サイト単位で公開処理をロックする。 ◦ ロック中に他のプロセスがサイトの公開処理を実⾏した場合、 何もせずに終了する。 ◦ 公開処理が終了したらロック解除。 • 排他制御はDBを⽤いて実現。 レースコンディション - こう対応した
34. ⼯夫した点 34 レースコンディション - こう対応した ロック処理の実装 (をかなり簡略化したもの)
35. ⼯夫した点 35 • ポイント： Transaction内でREAD時にレコードロックをかけることで、 ロック処理⾃体のレースコンディションも防⽌している。 レースコンディション - こう対応した
36. ⼯夫した点 36 Transactionとロック読み取りがないと、こんなケースがありうる レースコンディション - こう対応した プロセスA (バッチ) プロセスB (XHR) muu_sites_publish_processes レコードを取得 muu_sites_publish_processes レコードを取得 is_locked == 0 だから ロックかかってないと判断し処理継続 is_locked == 0 だから ロックかかってないと判断し処理継続 is_locked = 1 として更新（=ロックする） メイン処理を実⾏ is_locked = 1 として更新（=ロックする） メイン処理を実⾏してしまう
37. ⼯夫した点 37 Transactionとロック読み取りがあると安⼼ レースコンディション - こう対応した プロセスA (バッチ) プロセスB (XHR) トランザクション開始 トランザクション開始 muu_sites_publish_processes レコードを取得 ([DB]ロック読み取り) is_locked == 0 だから [APP]ロックかかってないと判断し処理継続 is_locked = 1 として更新（=[APP]ロックする） トランザクション終了 メインの処理を実⾏ muu_sites_publish_processes レコードを取得 is_locked == 1 なので[APP]ロックありと判断 トランザクション終了 [APP]ロックありなので、メイン処理はスキップ Aのトランザクション内で [DB]レコードロックがかけられているので、 Aのトランザクションが終了するまで 取得できない
38. まとめ 38
39. まとめ 39 みなさんの好奇⼼を多少満たすことは できたでしょうか。 サービスに興味がありましたら、 ぜひ「ムームーサイト」で 検索してみてください。
40. 40 ありがとうございました!