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

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