新規プロダクト開発に伴う既存マイクロサービスのリアーキテクティングとその後

メルペイが2021年にリリースした少額融資サービス「メルペイスマートマネー」の開発プロジェクト立ち上げ時において、既存の「あと払い」サービスの持つ一部機能を流用することで開発コストを削減し短期間でのリリースを目指す検討が行われていました。
本講演では、このプロジェクトにおいて、マイクロサービス単位を設計するにあたりどのようなプロセスで意思決定を行い、結果的にどのような方法を採用したか、また段階的なリアーキテクティングを通じて得られた知見等についてお話します。

Transcript

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