メルペイが2021年にリリースした少額融資サービス「メルペイスマートマネー」の開発プロジェクト立ち上げ時において、既存の「あと払い」サービスの持つ一部機能を流用することで開発コストを削減し短期間でのリリースを目指す検討が行われていました。 本講演では、このプロジェクトにおいて、マイクロサービス単位を設計するにあたりどのようなプロセスで意思決定を行い、結果的にどのような方法を採用したか、また段階的なリアーキテクティングを通じて得られた知見等についてお話します。
新規プロダクト開発に伴う既存マイクロサービスのリアーキテクティングとその後株式会社メルペイ 小川 雄大#Forkwell_DeepDive
View Slide
小川 雄大 (Katsuhiro Ogawa)株式会社メルペイEngineering Head of Credit Design2008年 アシアル / Software Engineer2011年 クロコス / Co-Founder / Architect2014年 ヤフー / Manager / Software Engineer2015年 Ancar / CTO2018年 メルカリ / Software Engineer2自己紹介@fivestrfivestarfivestar.bsky.social
信用を創造して、なめらかな社会を創るMISSION3
4● 「与信事業」の担当部門としてミッションにもある「信用を創造」の中核を担う● 「あと払い」や「メルペイスマートマネー」といった信用情報を活用したサービスの提供を行っている● メルペイではマイクロサービスアーキテクチャを採用して り、Credit Designチームとしても様々なマイクロサービス(MS)を運用しているメルペイ Credit Designチーム
メルペイスマートマネー開発プロジェクトの発足マイクロサービス構成案の検討開発ロードマップの策定1235今回の話の流れ
メルペイスマートマネー開発プロジェクトの発足6
7● 2021年にリリースした少額融資サービス○ メルカリアプリで借入・返済 可能○ メルカリの利用実績等にもとづ 金利や利用限度額 決まる● 約1年の開発期間を経てリリース○ よそ要件定義・設計に5ヶ月、開発・QA6ヶ月● サービス提供にあたり貸金業の登録を受けている「メルペイスマートマネー」プロジェクト※利用限度額は20万円。金利・利用限度額は「メルカリ」に ける利用実績等により所定の審査を行い決定。20歳未満、70歳超の 客さまは利用不可。
8プロジェクト立ち上げ当初● 貸金事業を開始すること 決まる○ 「あと払い」で培った与信のナレッジを活用した新たな与信事業○ Tech Lead(TL)としてアサインされる● 開発にあたり「既存のあと払いの返済の仕組みを活用することで開発コストを圧縮で ない 」という提案 された○ 毎月の返済手段として銀行 らの自動引落し よび残高チャージによる手動返済機能を提供したい○ あと払いに既に同じ仕組み あるため使い回すこと で ない
9「あと払い」の返済機能● あと払いは決済 ら返済まで様々な機能 １つのMSに集約されている○ プロダクトや開発チームも大 なっていたため以前 ら返済機能をMSとして独立させること アイディアとしてあげられていた● そうした背景を踏まえ、エンジニアチーム内でマイクロサービスの構成案を検討してい ことに
マイクロサービス構成案の検討10
11● 貸金業法にもとづ 様々な規制等 あり、割賦販売法よりも法要件に関する考慮点複雑になりそうなこと 見込まれていた○ この時点では要求自体まだ議論中だ 、まずは基本的な少額融資サービスの提供を目指す方針(契約、借入、返済)● あと払いでは2020年に定額払いという大規模な開発プロジェクト 行われた後で、それに伴うアーキテクチャのアップデートプロジェクト 進行中だった○ 2017年にリリースしたメルカリ月イチ払いを前身とするプロダクトということもあり様々な負債 積り重なっていた状況で不具合も頻発している状況だった検討にあたって論点となる要素 (1)
● 自動引落しをあと払いと貸金で同じ日に実行したい場合に銀行へのリクエスト数単純に増加する恐れ ある○ APIのキャパシティの問題で並列数にキャップ ある状態● 延滞中の自動充当に ける制御の問題○ 返済期限をす ている請求に対して、売上金 ら自動で返済に充てる仕組み あり、あと払いと貸金間での優先順位の制御 必要12検討にあたって論点となる要素 (2)
13マイクロサービス構成案の検討● ここでの検討対象は主にコア機能のBackendシステム○ 与信自体はMLチームで別途実装しBackendと連携する● エンジニアチームでPros/Consを並べな ら取りうる手段の洗い出しを行う○ A〜Dの4つの構成案 候補としてあ る
Pros● スコープ 明確になるため設計 しやすいCons● 充当の優先順位等、プロダクト横断の制御 困難● 返済機能の実装 あと払いと重複する14A - 貸金MSとしてすべて実装するlendingすべての貸金機能を新規MSに実装
15B - あと払いMSに貸金の仕組みを実装するPros● 返済機能を一本化で る● 返済以外にも様々な既存実装を使い回せるためオーバーヘッド 最小化で るCons● 肥大化による運用コストやインシデントリスクの増加● MS名と責務のミスマッチ 生じる貸金機能を既存あと払いMS上に実装deferred-paylendinginvoice
16C - 貸金MSを導入する 返済はあと払いMSを活用Pros● スコープ 明確になるため設計 しやすい● 返済機能を一本化で るCons● MS間の通信 発生するため設計コスト 高い● 一部MS名と責務のミスマッチ 生じるlendingdeferred-pay貸金機能を新規MSに実装する返済機能は既存MS上で統合invoice
17D - 貸金MSと返済MSを切り分けて実装する(あと払いMSの返済機能は初期リリースではそのまま)Pros● 理想形である返済機能 独立した形をつ れるCons● 新規MSを複数開発することになり設計・開発コスト 高い● 返済機能の実装 あと払いと重複するlending deferred-payinvoice貸金機能を新規MSに実装し返済機能も別の新規MSとして実装する(あと払いの返済は将来的に統合を目指す)返済MSに機能集約する構成が理想形
開発ロードマップの策定18
19初期リリース ら理想形までの開発ロードマップのプランニング運用リスク観点 ら、重複実装 生じるAとDは初期リリース時の選択肢 ら除外したい(開発チームとしての希望)あと払いに全部実装(B) → 貸金MSを独立(C) → 返済MSを独立(D)1あと払いに全部実装(B) → 貸金MS/返済MSをそれぞれ独立(D)2貸金MSを実装、あと払いの返済機能を流用(C) → 返済MSを独立(D)3返済機能の重複管理を避けたパターンに絞って3つの候補(①②③)を洗い出す
次の観点で整理1. 設計のしやすさ2. 実装のしやすさ3. 運用・コードの品質維持のしやすさ4. QAのしやすさ5. 将来も踏まえたトータルの工数感20開発ロードマッププランのPros/Consの検討
21経営陣も交えて検討を進める● 開発ロードマップの検討 らはVP of Product Engineeringも交え、経営陣とも目線を揃えな ら進めた○ ビジネス的な優先順位、他プロジェクトとの関係性、開発チームとしてのサステイナビリティなど様々な観点 らレビューし不確実性を減らしてい● 開発チームの素直な考えも伝える○ 「Trust & Openness」というメルペイのカルチャー
22どのアプローチ 最短リリース可能 ？● A(貸金MSにすべて実装)とその他を比べてどう○ コピペしま ればすべて新規実装にで るA 最短でリリース可能ではない という検討もした○ 返済機能の重複実装による銀行接続の負荷問題や、充当等のサービス横断の制御といった随的に考慮しなければならないこと 論点 残ってしまう○ 結果的に既存コードへの追加開発も必要になる見込みのため、余計に開発コストりそうという判断
23開発ロードマップの決定方針 決まったので、不確実性を減らすべ 様々な検討を実施していあと払いに全部実装(B) → 貸金MSを独立(C) → 返済MSを独立(D)1あと払いに全部実装(B) → 貸金MS/返済MSをそれぞれ独立(D)2貸金MSを実装、あと払いの返済機能を流用(C) → 返済MSを独立(D)3B(あと払いMSに追加)はいずれの観点でも難易度 高 ①②は却下し③で決定する
● あと払いMS○ あと払いの利用・請求○ 定額払いの契約管理● 貸金MS○ 貸金の利用・請求○ 貸金の契約管理● 返済MS○ 請求ベースの返済基盤24あと払い・貸金・返済の3つのMSに分割した場合の各MSの責務整理
25ドメインモデルの整理● あと払いMSのドメインモデルのうち、返済MS 有するべ 機能・モデルは何 検討○ 返済に関連するエンティティをプロパティレベルで整理し、貸金にも適用で るモデルにアップデート● APIやバッチ処理についても、MSの責務に基づ よそどこにどのようなもの あれば成立する PoCを行い可能な限り不確実性を減らす● ここまでの成果物はあ までADRの範疇○ これらの方針を前提として、要件定義や設計を進めた
26リリースまで● 大規模なプロジェクトとなった 、様々なステークホルダーとの綿密なコミュニケーションを行い不確実性と向 合いな ら進めたことで、 よそ計画通りにリリースに至れた● こうした動 評価されてMVP受賞した「振り返りを活 したプロジェクト推進を」エンジニアリング面でリードし続けた私 メルペイMVPを受賞するまで | mercan (メルカン)
● メルペイスマートマネーのリリース後、別のプロジェクトと関連付けてあと払いMS上にある返済機能のMS独立を実施○ 2023年5月にマイグレーション 完了○ あと払いMS上に残ったコードの削除等はステップを分割して今後実施予定27返済MSの独立とデータマイグレーションThe Journey of Invoice Microservice: From Birth to Independence | Mercari Engineering
アーキテクチャ拡張の段階的なアプローチを模索するビジネス的なトレードオフも踏まえ、マイグレーションを前提とした段階的な戦略を立てることでコンセンサスも得やす なり、プロジェクトの難度も抑えやす なる同期コミュニケーションを活用しスムーズな意思決定を検討フェーズに いて1人で結論を求めようとせず、チームやステークホルダと課題を共有し議論ベースで検討することで多様な視点に基づ 意思決定を可能にしてい意思決定の過程を記録に残す(ADRを書く文化をつくる)特に大 なプロジェクトに いての進め方の記録 残っているとその開発チームだけでな 他のプロジェクトチームにとっても参考になるため組織全体の学びに繋 ってい28学びまとめ123
fivestar
whywaita
colopl
torounit
gl_tsukasa
hk_shino
shimacos
bengo4com
miyake
soracom
kobayang
.png){kind=icon}
pharma_x_tech
coe
cromwellryan
colly
ufuk
afnizarnur
ddemaree
jnunemaker
ammeep
kevinliebholz
robhawkes
orderedlist
tanoku
phodgson