クライアント・サーバサイドに分散する�計算ロジックのマイクロサービス化

Go HAGIWARA (Oklahomer)

2023-02-28 mercari.go #21

自己紹介

• Oklahomer (Go HAGIWARA)
• https://github.com/oklahomer
• https://twitter.com/oklahomers
• 2022 年 3 月入社
• Transaction team
• 2023~ Logistics team
• Backend Engineer

アジェンダ

​

支払い金額の計算とは

各プラットフォームによる実装

そこから生じる課題

解決策

割と複雑な支払額計算

• 支払い金額を求めるのに必要な要素
• 商品の値段
• 部分・すべて利用するポイント
• 部分・すべて利用するメルペイ残高
• 支払い方法毎の手数料
• 適用できるクーポン

割と複雑な支払額計算

​

• 支払い金額を求めるのに必要なロジック
• 最初の「提案」時の適用優先順位
• ポイント・残高の過不足分の計算
• 各種手数料の算出
• クーポン適用後の再計算
• そこまで複雑ではなさそうだが、、、

割と複雑な支払額計算

​

• さまざまなシナリオ
• ポイントの部分利用とクーポンで計算後、クーポンを解除した場合
• ポイントの残りから自動的に補填？
• 支払い金額に上乗せ？
• 支払手段が未設定で、ポイントやクーポンでは不足があるとき
• 支払額の計算を進めつつ、設定を促すフローにするには、、、
• チャージ払いの表現とフローは？
• チャージと支払いの仕組みは別れているが、 UI/UX は密結合

各プラットフォームでの実装

• プラットフォーム
• iOS
• Android
• Web
• API サーバ

各プラットフォームでの実装

​

• 課題
• 全プラットフォームでのメンテナンスコスト
• 開発
• QA
• リリース時期の調整
• iOS/Android アプリの強制アップデート

​

​

ビジネス上の要求に、柔軟に迅速に対応できない

RFS�Robust Foundation for Speed

https://engineering.mercari.com/blog/entry/20220908-robust-foundation-for-speed-series-present-and-future/

新しいアーキテクチャ

新しいアーキテクチャ

• 計算ロジックをサーバ側で実装・提供
• ロジックは一元管理
• ドメイン知識も一元管理
• アップデートが容易
• 新しいマイクロサービスとして
• 既存実装とのしがらみが少ない
• 状態を持たない
• 再利用しやすい

新しいアーキテクチャ

​

• マイクロサービス作成・運用の知見を最大活用
• CUEを使用したKubernetesマニフェスト管理
• Microservice 設計・運用にかんする社内ドキュメント
• Production Readiness Level の基準
• CI/CD
• モニタリング項目
• etc…
• 社内共通のひな形レポジトリ
• 上記ベストプラクティスの実践

新しいアーキテクチャ

​

• 所感
• ドキュメントとひな形レポジトリのサポート
• アプリケーションロジックの開発に集中できる
• 反面、運用寄りの知見が貯まらないのでは？
• チェックリストを通じた学習
• Slack チャンネルでのサポート
• 他サービスの知見
• プラットフォームチームのサポート

まとめ

支払い金額の計算は、細かな条件が割と複雑

それを各プラットフォームで実装していた状況

独立したマイクロサービス利用への移行

豊富なドキュメントとひな形レポジトリによる強力なサポート

ありがとうございました！

採用ページ：https://apply.workable.com/mercari/j/6CE6CC3467/