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

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

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

851704b2aa97d2117dc89bf60a2cd272?s=128

tanakaworld

August 26, 2019
Tweet

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つに分離された • 当初は1つのプロダクトチームだった • CSTool、MSTool でプロダクトチームが分離された • 異なる PdM、Operation •

    やりたいこと・時期、プロジェクトの進め方が異なる
  13. 様々な課題 • 一つのアプリケーションに複数チームからの要望が来る • 変更が互いに影響してしまう • 複数の機能開発が並行して進み、feature ブランチが混在 • Conflict

    してマージできなくなる(機能を隠すフラグまみれ) • 毎週1・2回リリース • QAコスト増大 • スケジュール調整が手間 •••
  14. 分割の方針

  15. 前提条件 • 独立した開発・リリースが行えること • メルペイ全体で技術的負債解消の時間を確保する方針に • 対応期間は2ヶ月 制約 • デザインは共通

    → 共通 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