Upgrade to Pro — share decks privately, control downloads, hide ads and more …

与信領域 Micro Service 小話 / Microservice Architecture in credit domain

与信領域 Micro Service 小話 / Microservice Architecture in credit domain

マイクロサービスの境界線を引くことの難しさ、面白さを、与信領域のシステム構成の変遷を追いながらざっくばらんにお話します。
------
Merpay Tech Fest 2022は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイの技術スタックに興味がある方々を対象に2022年8月23日(火)から8月25日(木)までの3日間、開催します。 Merpay Tech Festは事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りです。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介予定です。お楽しみに!

■イベント関連情報
- 公式ウェブサイト:https://events.merpay.com/techfest-2022/
- 申し込みページ:https://mercari.connpass.com/event/249428/
- Twitterハッシュタグ: #MerpayTechFest

■リンク集
- メルカリ・メルペイイベント一覧:https://mercari.connpass.com/
- メルカリキャリアサイト:https://careers.mercari.com/
- メルカリエンジニアリングブログ:https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント:https://twitter.com/mercaridevjp
- 株式会社メルペイ:https://jp.merpay.com/

mercari
PRO

August 25, 2022
Tweet

More Decks by mercari

Other Decks in Technology

Transcript

  1. 与信領域 Micro Service 小話 株式会社メルペイ giga, mitu, shuuk

  2. @giga Gaku Igarashi 株式会社メルペイ / PM 金融系エンジニア、外資コンサル、クラ ウド会計事業者を経て、メルペイ入社。 コンサル時代、日本の金融機関で初め てブロックチェーンを

    利 用 したポイント サービスを導 入。メルペイでは、与 信 事業のProduct Managerとして、新 たな世界づくりと信用創造に取り組ん でいる。 @mitu Mamrou Uehara 株式会社メルペイ / Backend / TL スマホ向けゲームのバックエンドエンジ ニアとしてキャリアをスタートし、新 規タ イトルの立ち上げ等の開発業務に従事 した後、2019年にOrigamiへ入 社。 2020年からはメルペイへ転籍し、与信 関連システムのテックリードとして開発 業務に取り組んでいる。 @shuuk Shu Kojima 株式会社メルペイ / ML / EM 受託開発の Webエンジニア経験後、 AIコンサルに転 職。その後メルペイに Data Analystとして入社し、 1年後に MLエンジニアにジョブチェンジ。 入 社 以来一貫して与信領域の分析・開発に 従 事している。現在は与 信 MLチーム のマネージャー。 
  3. セッションの質問について みなさまからの質問を受け付けています! YouTube チャット、 Twitter ハッシュタグ #MerpayTechFest を使ってください。

  4. 本日のテーマ 01 メルペイの与信領域のマイクロサービスの歴史を振り返る 02 マイクロサービスの境界線を引く難しさと面白さを語る 03 手探りの経験から得られた学びや今後の展望を伝える

  5. メルペイスマート払い, 定額払いについて

  6. メルペイスマート払いとは 「メルペイ」加盟店での商品購入代金を後払いできるサービス この利用限度枠を提供するのが与信領域の仕事

  7. メルペイスマート払いの変遷 2019.2-3 メルペイあと払い (2019.11メルペイ スマート払いにリブランディ ング) メルペイスマート払い(定額払い) 非接触型サービス iD決済 QRコード決済

    2019.4-5 ネット決済 2020.7 2020.9 「d払い」「メルペイ」の 共通QRコード 2021.3 バーチャルカード 2021.9 「認定包括信用購入あっせん業者(通称 AI与信)」を日本初取得 現在
  8. メルペイスマート払いのAI利用 (モデル例) 「未払い率」と「利用限度」 取引情報 適切な利用限度枠を提示 メルカリの過去情報からAIで未払い率を算出し、利用限度枠を 提示

  9. 一括清算と定額清算 利用分の清算方式は一括と定額が存在 清算方式 清算期日 CIC(※)連携 一括 利用の翌月に一括で清算 無し 定額 月々の支払金額に沿って毎月清算

    有り ※Credit Information Centerの略で、指定信用情報機関の一つ。全国のクレジット・ローンの情報を保持しており、定 額払いを提供するためには、指定信用情報機関のデータを参照することが法律で義務付けられている
  10. メルペイと与信領域の マイクロサービス

  11. そもそもMicro Serviceとは 決済 ・ビジネスドメインごとに分割された、独立にデプロイ可能なサービス群 ・サービス同士はネットワークを介して相互に通信し合う ・逆に一つのサービスで運用されているシステムをモノリスと言う 残高 iD決済 Code 決済

    送金 銀行接 続 メルペイのマイクロサービス群の一部のイメージ
  12. Why Micro Service? • サービス同士の独立性によるスケール性の確保 ◦ サービスごとの独立開発による並行開発の実現 ◦ 独立デプロイによるリリース調整のコスト削減 ◦

    チームごとに採用技術の裁量が増加 • 複雑なドメインの分割による開発の容易化 ◦ ドメインの量を一チームが責任を持てる粒度に分割できる ▪ 金融はドメインが複雑!
  13. CreditScore(ML) CreditLine(Backend) 与信領域のマイクロサービス構成(WIP含む) CreditScore ・モデル開発 ・信用度予測 ・信用度の流し込み ・利用限度枠の計算   (信用度/CIC照会結果)

    ・CIC照会依頼 DefferedPay(Backend) ※スマート払い申込み /利用等を管 理 ・利用限度枠の利用   (バリデーション) ・定額払い申込 ・CIC照会依頼 Spanner CreditInfo(Backend) CreditInfo ・CIC照会 CreditLine DeferredPay
  14. システムの変遷 〜それぞれの歴史のタイミングで 何が起きたのか?

  15. (再掲)メルペイスマート払いの変遷 2019.2-3 メルペイあと払い (2019.11メルペイ スマート払いにリブランディ ング) メルペイスマート払い(定額払い) 非接触型サービス iD決済 QRコード決済

    2019.4-5 ネット決済 2020.7 2020.9 「d払い」「メルペイ」の 共通QRコード 2021.3 バーチャルカード 2021.9 「認定包括信用購入あっせん業者(通称 AI与信)」を日本初取得 現在 2022.8
  16. メルペイあと払いリリース 2019.4-5~ ・ MLモデルを活用して信用度を算出するフローの創世期 ・ 当時は一括精算方式のみ ・ ユーザーごとの信用度から利用限度枠を計算

  17. DefferedPay(Backend) CreditScore(ML) メルペイあと払いリリース 2019.4-5~ CreditScore DeferredPay ・モデル開発 ・信用度予測 ・利用限度枠の計算 (バリデーション)

    ・利用限度枠の利用 定期バッチ Spanner ・利用限度枠の計算 ・利用限度枠の流し込み
  18. DefferedPay(Backend) CreditScore(ML) メルペイあと払いリリース 2019.4-5~ CreditScore DeferredPay ・モデル開発 ・信用度予測 ・利用限度枠の計算 (バリデーション)

    ・利用限度枠の利用 定期バッチ Spanner ・利用限度枠の計算 ・利用限度枠の流し込み モデルによって算出された信用度をベースに利 用限度枠を計算 定期バッチだけでは補正が難しい、リア ルタイムな判断が必要な条件を考慮 (不 正対策など)
  19. DefferedPay(Backend) CreditScore(ML) 当時の苦労話 CreditScore DeferredPay ・モデル開発 ・信用度予測 ・利用限度枠の計算 (バリデーション) ・利用限度枠の利用

    定期バッチ Spanner ・利用限度枠の計算 ・利用限度枠の流し込み ・リリース後の頻繁な利用限度枠の流し込み ・当初の想定以上の計算ロジックの複雑化 ➡ MLチームの工数を圧迫 ・バリデーションに必要な情報が他の マ イクロサービスに存在 ➡ キャパシティを考慮した設計
  20. メルペイスマート払い(定額払い)リリース 2020.7~ ・ 割賦販売法に準拠したフローが必須化(CIC照会) ・ 他社借入状況を考慮した利用限度枠計算が必須に

  21. メルペイスマート払い(定額払い)リリース 2020.7~ CreditScore(ML) CreditScore ・モデル開発 ・信用度予測 定期バッチ DefferedPay(Backend) DeferredPay ・利用限度枠の計算

    (バリデーション) ・利用限度枠の利用 ・定額払い申込 ・CIC照会依頼 Spanner CreditInfo(Backend) CreditInfo ・利用限度枠の計算(信用度) ・利用限度枠の流し込み ・CIC照会依頼 ・CIC照会 ・利用限度枠の計算(CIC照会結果)
  22. メルペイスマート払い(定額払い)リリース 2020.7~ CreditScore(ML) CreditScore ・モデル開発 ・信用度予測 定期バッチ ・利用限度枠の計算(信用度) ・利用限度枠の流し込み ・CIC照会依頼

    DefferedPay(Backend) DeferredPay ・利用限度枠の計算 (バリデーション) ・利用限度枠の利用 ・定額払い申込 ・CIC照会依頼 Spanner CreditInfo(Backend) CreditInfo ・CIC照会 ・利用限度枠の計算(CIC照会結果) 利用限度枠の計算を「信用度による計 算」と「CIC照会結果による計算」に分離 ※既存のアーキテクチャに依存 ※工数削減の意図 利用限度枠の計算を「信用度による計 算」と「CIC照会結果による計算」に分離 ※既存のアーキテクチャに依存 ※工数削減の意図 法令要件で、利用限度枠の 更新時および定額払い申込 時にCIC照会が必須に
  23. ・利用限度枠の計算(信用度) ・利用限度枠の流し込み ・CIC照会依頼 ・CIC照会 ・利用限度枠の計算(CIC照会結果) 暫定ML+Backendチーム(PJごと) 当時の苦労話 CreditScore(ML) CreditScore ・モデル開発

    ・信用度予測 定期バッチ DefferedPay(Backend) DeferredPay ・利用限度枠の計算 (バリデーション) ・利用限度枠の利用 ・定額払い申込 ・CIC照会依頼 Spanner CreditInfo(Backend) CreditInfo 大きなMLドメインと、暫定的とはいえ Backendドメインを仕入れないといけ ない認知負荷の増加 ドメインが複雑化し、MLだけでは運用が困難に… ➡PJごとにML+Backendの暫定的な  チームで対応 ➡オーナー不在による暫定的な対応  の増加 大きなCICドメインと、暫定的 とはいえMLドメインを仕入れ ないといけない認知負荷の増 加
  24. 現在(WIP含む) ・ 利用限度枠計算に責任を持つチームの組成 ・ 複雑化したロジック、ワークフローの整理

  25. CreditLine(Backend) 現在(WIP含む) CreditScore(ML) CreditScore ・モデル開発 ・信用度予測 ・信用度の流し込み DefferedPay(Backend) Spanner CreditInfo(Backend)

    CreditInfo ・CIC照会 CreditLine DeferredPay ・利用限度枠の計算   (信用度/CIC照会結果) ・CIC照会依頼 ・利用限度枠の利用   (バリデーション) ・定額払い申込 ・CIC照会依頼
  26. CreditLine(Backend) 現在(WIP含む) CreditScore(ML) CreditScore ・モデル開発 ・信用度予測 ・信用度の流し込み DefferedPay(Backend) Spanner CreditInfo(Backend)

    CreditInfo ・CIC照会 CreditLine DeferredPay モデル開発、利用限度枠計算、CIC照会 がそれぞれのチームにきちんと分散した 状態 モデル開発、利用限度枠計算、CIC照会 がそれぞれのチームにきちんと分散した 状態 モデル開発、利用限度枠計算、CIC照会 がそれぞれのチームにきちんと分散した 状態 ・利用限度枠の計算   (信用度/CIC照会結果) ・CIC照会依頼 ・利用限度枠の利用   (バリデーション) ・定額払い申込 ・CIC照会依頼
  27. 問題解決のためにやったこと ・ 現在の課題を正確に言語化してボトムアップ ・ 法令違反リスク、レピュテーションリスク、etc… ・ 多くのステークホルダーを巻き込み、組織的に物事を動かす ・ Biz、PM、EM、CTO、関係チームのTL、etc…

  28. 学びから得られたアンチパターン

  29. 学びから得られたアンチパターン 1. 開発領域・技術だけの境界線 ➡ ドメインは組織を横断して構成される。組織とセットで考える。 2. 締め切りドリブンによる境界線のズレ ➡ 絶対悪ではない。負債の解消とセットで受け入れることが必要。 3.

    ドメインのオーナー不在 ➡ 適切な管理チームがなければ新設するような組織的な意識。
  30. (Appendix)境界線を決める観点 • 境界線を決める観点は多岐に及ぶ ◦ ビジネスドメイン ◦ 利用技術 ◦ 対象ユーザー ◦

    SLA ◦ リスク規模 ◦ 規制・法令有無 ◦ 変更頻度 • 広い観点でpros/cons比較するのが大事 https://www.amazon.co.jp/dp/4820729632/
  31. 登壇者から一言

  32. ご清聴ありがとうございました!