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