Nuxt マイクロサービスを 3つに分割した話 / Split A Nuxt Microservice to 3 Microservices

NuxtMeetUp#9 オールスターズ
https://nuxt-meetup.connpass.com/event/135514
#nuxtmeetup

Transcript

1. Nuxt マイクロサービスを 3つに分割した話 NuxtMeetUp#9 オールスターズ 2019/08/26 @_tanakaworld
2. About Me • Twitter: @_tanakaworld • GitHub: tanakaworld • Software Engineer (Frontend) ◦ CSTool ◦ MSTool
3. マイクロサービスを3つに分割した話 共通化 分割
4. 1つのアプリケーションを分割するための コンポーネント管理方法 共通化 http://bit.ly/2zkXMU1
5. 1. メルペイの管理画面 2. 背景 3. 方針 4. 配信環境のポイント 5. まとめ 今日は分割について話します 分割
6. メルペイの管理画面
7. メルペイの管理画面 CSTool MSTool Settings • Customer Support • お客さまの管理機能 • 登録情報 • 取引情報 • あと払い • クーポン • Merchant Support • 加盟店さまの管理機能 • 審査機能 • 店舗情報 • 取引情報 • オペレータ管理 • 権限
8. メルペイの管理画面 CSTool MSTool Settings • Customer Support • お客さまの管理機能 • 登録情報 • 取引情報 • あと払い • クーポン • Merchant Support • 加盟店さまの管理機能 • 審査機能 • 店舗情報 • 取引情報 • オペレータ管理 • 権限
9. 初期のアーキテクチャ API Gateway https://admin.xxx.com Nuxt (SSR) Nginx
10. デプロイフロー ••• ••• Build + Push Docker Image Deploy by Spinnaker GitHub Repository Nginx Nuxt (SSR) GKE Nginx Node.js
11. 分割に至る背景
12. プロダクトチームが2つに分離された • 当初は１つのプロダクトチームだった • CSTool、MSTool でプロダクトチームが分離された • 異なる PdM、Operation • やりたいこと・時期、プロジェクトの進め方が異なる
13. 様々な課題 • 一つのアプリケーションに複数チームからの要望が来る • 変更が互いに影響してしまう • 複数の機能開発が並行して進み、feature ブランチが混在 • Conflict してマージできなくなる（機能を隠すフラグまみれ） • 毎週１・２回リリース • QAコスト増大 • スケジュール調整が手間 •••
14. 分割の方針
15. 前提条件 • 独立した開発・リリースが行えること • メルペイ全体で技術的負債解消の時間を確保する方針に • 対応期間は２ヶ月 制約 • デザインは共通 → 共通 Component リポジトリを使う • 配信ドメインは変更しない • GCP Project は共通
16. プロダクトチーム軸 + 機能軸で分割 CSTool MSTool Common
17. 分割後のアーキテクチャ API Gateway https://admin.xxx.com /cs /ms other CS MS Common
18. request path でサービスを分岐 • SSR リクエスト /cs → CS /ms → MS / → Common • Assets 取得リクエスト /cs/assets → CS /ms/assets → MS /common/assets → Common
19. 1. pages に階層構造をつくる • e.g. https://admin.xxx.com/cs • 各 Nuxt アプリは他の Nuxt アプリと prefix が被らないようにする
20. 2. publicPath を変更 • https://nuxtjs.org/api/configuration-build/#publicpath • /_nuxt/aaaaa.js → /cs/assets/aaaaa.js // nuxt.config.ts if (process.env.NODE_ENV === 'production') { // default: '/_nuxt' config.build.publicPath = '/cs/assets/'; }
21. /cs でリクエストされた結果の HTML
22. 配信環境のポイント
23. 2段階リリース • Step1: Nginx で routing ◦ 新 Nuxt * 3、新 Nginx * 3 ◦ いつ API Gateway がリリースされてもいい状態にする • Step2: API Gateway で routing ◦ Step1 でリリースされた 新 Nginx に接続してもらう
24. Step1: Nginx で routing
25. Canary Release • ダウンタイムを極力短くするため • routing 設定に注意が必要 • SSR 時のリクエストと assets 取得の リクエストが同じ Nginx を通過すると は限らないので、それらを考慮する Old CS MS Common ••• /cs /ms Canary other
26. server { location /_nuxt/ { try_files $uri $uri/ @node; } location /cs { try_files $uri $uri/ @node-cs; } location /ms { try_files $uri $uri/ @node-ms; } location / { try_files $uri $uri/ @node-common; } } 新 Nginx の routing • SSR はすべて新 Nuxt へ routing • 旧 Nuxt の assets リクエストも routing する Old CS MS Common •••
27. server { location /cs/assets { try_files $uri $uri/ @node-cs; } location /ms/assets { try_files $uri $uri/ @node-ms; } location /common/assets { try_files $uri $uri/ @node-common; } location / { try_files $uri $uri/ @node; } } 旧 Nginx の routing • SSR は旧 Nuxt にのみ routing • 新 Nuxt の assets リクエストも routing する Old CS MS Common •••
28. 完了したら古い環境は停止 API Gateway Old CS MS Common ••• /cs /ms Canary other
29. Step2: API Gateway で routing
30. API Gateway のリリース API Gateway CS MS Common /cs /ms other
31. 旧 Nginx は停止 API Gateway CS MS Common /cs /ms other
32. まとめ
33. • プロダクトチームの粒度にあわせてマイクロサービスを分割 • request path に応じてマイクロサービスを分岐 まとめ API Gateway /cs /ms other
34. • Pros ◦ 独立して開発・運用・リリースができるようになった ◦ 同じドメインで複数 Nuxt アプリ ▪ 新しいマイクロサービスに横展開 ▪ 肥大化した機能を切り出す • Cons ◦ 共通化できていない対象の更新が 3倍 Pros / Cons
35. Thanks