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

与信領域 Micro Service 小話 / Microservice Architectu...

mercari
August 25, 2022

与信領域 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

August 25, 2022
Tweet

More Decks by mercari

Other Decks in Technology

Transcript

  1. @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チーム のマネージャー。 
  2. メルペイスマート払いの変遷 2019.2-3 メルペイあと払い (2019.11メルペイ スマート払いにリブランディ ング) メルペイスマート払い(定額払い) 非接触型サービス iD決済 QRコード決済

    2019.4-5 ネット決済 2020.7 2020.9 「d払い」「メルペイ」の 共通QRコード 2021.3 バーチャルカード 2021.9 「認定包括信用購入あっせん業者(通称 AI与信)」を日本初取得 現在
  3. 一括清算と定額清算 利用分の清算方式は一括と定額が存在 清算方式 清算期日 CIC(※)連携 一括 利用の翌月に一括で清算 無し 定額 月々の支払金額に沿って毎月清算

    有り ※Credit Information Centerの略で、指定信用情報機関の一つ。全国のクレジット・ローンの情報を保持しており、定 額払いを提供するためには、指定信用情報機関のデータを参照することが法律で義務付けられている
  4. Why Micro Service? • サービス同士の独立性によるスケール性の確保 ◦ サービスごとの独立開発による並行開発の実現 ◦ 独立デプロイによるリリース調整のコスト削減 ◦

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

    ・CIC照会依頼 DefferedPay(Backend) ※スマート払い申込み /利用等を管 理 ・利用限度枠の利用   (バリデーション) ・定額払い申込 ・CIC照会依頼 Spanner CreditInfo(Backend) CreditInfo ・CIC照会 CreditLine DeferredPay
  6. (再掲)メルペイスマート払いの変遷 2019.2-3 メルペイあと払い (2019.11メルペイ スマート払いにリブランディ ング) メルペイスマート払い(定額払い) 非接触型サービス iD決済 QRコード決済

    2019.4-5 ネット決済 2020.7 2020.9 「d払い」「メルペイ」の 共通QRコード 2021.3 バーチャルカード 2021.9 「認定包括信用購入あっせん業者(通称 AI与信)」を日本初取得 現在 2022.8
  7. DefferedPay(Backend) CreditScore(ML) メルペイあと払いリリース 2019.4-5~ CreditScore DeferredPay ・モデル開発 ・信用度予測 ・利用限度枠の計算 (バリデーション)

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

    定期バッチ Spanner ・利用限度枠の計算 ・利用限度枠の流し込み ・リリース後の頻繁な利用限度枠の流し込み ・当初の想定以上の計算ロジックの複雑化 ➡ MLチームの工数を圧迫 ・バリデーションに必要な情報が他の マ イクロサービスに存在 ➡ キャパシティを考慮した設計
  9. メルペイスマート払い(定額払い)リリース 2020.7~ CreditScore(ML) CreditScore ・モデル開発 ・信用度予測 定期バッチ DefferedPay(Backend) DeferredPay ・利用限度枠の計算

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

    DefferedPay(Backend) DeferredPay ・利用限度枠の計算 (バリデーション) ・利用限度枠の利用 ・定額払い申込 ・CIC照会依頼 Spanner CreditInfo(Backend) CreditInfo ・CIC照会 ・利用限度枠の計算(CIC照会結果) 利用限度枠の計算を「信用度による計 算」と「CIC照会結果による計算」に分離 ※既存のアーキテクチャに依存 ※工数削減の意図 利用限度枠の計算を「信用度による計 算」と「CIC照会結果による計算」に分離 ※既存のアーキテクチャに依存 ※工数削減の意図 法令要件で、利用限度枠の 更新時および定額払い申込 時にCIC照会が必須に
  11. ・利用限度枠の計算(信用度) ・利用限度枠の流し込み ・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ドメインを仕入れ ないといけない認知負荷の増 加
  12. CreditLine(Backend) 現在(WIP含む) CreditScore(ML) CreditScore ・モデル開発 ・信用度予測 ・信用度の流し込み DefferedPay(Backend) Spanner CreditInfo(Backend)

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

    CreditInfo ・CIC照会 CreditLine DeferredPay モデル開発、利用限度枠計算、CIC照会 がそれぞれのチームにきちんと分散した 状態 モデル開発、利用限度枠計算、CIC照会 がそれぞれのチームにきちんと分散した 状態 モデル開発、利用限度枠計算、CIC照会 がそれぞれのチームにきちんと分散した 状態 ・利用限度枠の計算   (信用度/CIC照会結果) ・CIC照会依頼 ・利用限度枠の利用   (バリデーション) ・定額払い申込 ・CIC照会依頼
  14. (Appendix)境界線を決める観点 • 境界線を決める観点は多岐に及ぶ ◦ ビジネスドメイン ◦ 利用技術 ◦ 対象ユーザー ◦

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