Open SKT: メルペイ開発の裏側 / builderscon tokyo 2019 Open SKT

by kazegusuri

Slide 1

Slide 1 text

Masahiro Sano  @kazegusuri  Open SKT: メルペイ開発の裏側  builderscon tokyo 2019    1 

Slide 2

Slide 2 text

決済・金融サービス is hard  2 決済はお金のトランザクション管理が難しい  そう思っていた時期が自分にもありました       

Slide 3

Slide 3 text

今日のテーマ  3 あんしん・あんぜんのために  技術的に取り組んできたことを知ってもらう 

Slide 4

Slide 4 text

@kazegusuri ● Merpay Backend Engineer ● Architect Team 2015/11 2017/01 2018/01 SRE & Platform Platform Payment & Architect 4

Slide 5

Slide 5 text

アジェンダ  メルペイの概要 1 全体のアーキテクチャの概要 2 決済システムの一貫性管理 3 不正検知 4 開発フロー 5 5

Slide 6

Slide 6 text

メルペイの概要  6

Slide 7

Slide 7 text

2019年2月非接触型サービス「iD」に対応 2019年4月複数回のお買い物をあとからまとめて支払える「メルペイあと払い」開始 2019年5月 ECサイトでも「メルペイ」が利用できるネット決済提供開始 2019年3月大手チェーンや中・小規模店舗で QR・バーコード決済に対応全国135万か所 (iOS/Android) iD コード払いあと払いネット決済メルペイの概要  7

Slide 8

Slide 8 text

メルペイのサービス規模マイクロサービスアーキテクチャ 40以上のマイクロサービス 2019 3Qで 1444億円以上を取り扱うメルカリの決済基盤(USのメルカリ事業も含む数字 ) 200万人以上の利用者（メルペイ「電子マネー」の登録を行ったユーザーの累計。コード払いは除く） 8

Slide 9

Slide 9 text

そもそもSKTって何？  オンボーディングも兼ねた社員研修  各システムの具体的な処理の流れ  メルカリ・メルペイのアーキテクチャ  開発体制や開発方法  メルペイの目標やポリシー  9

Slide 10

Slide 10 text

メルペイの開発で重要視していること  インフラのように安定して信頼できるシステム  サービス開発をメインにしない  10

Slide 11

Slide 11 text

全体のアーキテクチャ概要  11

Slide 12

Slide 12 text

アーキテクチャ  API Gateway Authority API Service X API Service Y Google Cloud Load Balancer Service A Service B Google Kubernetes Engine Service C Web Service Z Cloud Spanner Project A Cloud Spanner Cloud Pub/Sub Project B Project GKE 12

Slide 13

Slide 13 text

アーキテクチャ  マイクロサービスの階層化 1マイクロサービス, 1 Namespace & 1 Project 共通のGKEクラスター 13

Slide 14

Slide 14 text

4階層のアーキテクチャ  Backend Service API Gateway API Service Client Client  アプリ、加盟店等のパートナー様   API Gateway  全てのリクエストがAPI Gatewayを通る   共通処理とルーティング   API Service  クライアントからのリクエストとレスポンスの責任を持つ   裏側にある複数のマイクロサービスのアグリゲーション   Backend Service  機能のロジックを実現する   14

Slide 15

Slide 15 text

API Gateway  Backend Service API Gateway API Service Client インターネットからのリクエストを安全に内部に届ける ● TLS終端 + DDoS対策 (CDN, Google Cloud Load Balancing) ● Request/Response buﬀering + Timeout ● AuthN/AuthZ (認証認可プラットフォーム) ● アクセスログ (データプラットフォーム) Why ● 外部からのアクセスが最も重要 ● 適切に扱うのが難しいため共通で処理 15

Slide 16

Slide 16 text

API Service    Backend Service API Gateway API Service Client クライアントとのメッセージに責任を持つ ● リクエストバリデーション ● バックエンドマイクロサービスのアグリゲーション ● クライアントの互換性、ABテスト ● 必要十分なレスポンス Why ● 外部からのアクセスが最も重要 ● 適切に扱うのが難しいため共通で処理 16

Slide 17

Slide 17 text

Backend Service    Backend Service API Gateway API Service Client 担当ドメインに特化した機能の提供 ● クライアント(リクエスト元)のコンテキストに依存しない機能 ● 内部の実装のみを意識する ● リクエストの認可はクライアントのコンテキストに応じて行う Why ● 開発をドメインで閉じて行えるように 17

Slide 18

Slide 18 text

決済システムの一貫性管理  18

Slide 19

Slide 19 text

決済サービスを中心とした決済システム  決済銀行残高あと払い会計 NFC コード払いネット決済メルカリ精算 Account Account Account キャンペーン管理ツール 19

Slide 20

Slide 20 text

分散システムにおけるトランザクション  難しい ● システムの数や状態が増えると単純に行うのは難しい ● アドホックにデータ補正(バッチ処理)も可能だが… ● 既知の手法(2PC,XA)や、分散コーディネーションもある多様なシステム構成 ● システム間で協調するのは難しい(チームが異なる) ● 外部システムもある ● 中央でのトランザクション管理の方向へ 20

Slide 21

Slide 21 text

トランザクション管理の課題  複雑な支払方法 ● 複数の支払手段 (メルペイ残高, ポイント, コンビニ, ATM, キャリア決済...) ● 支払い手段の組み合わせ(残高+ポイント, 残高+ポイント+コンビニ) ● 今後も更に複雑化する可能性が高いエラー処理も含めたモデルの一般化が必須 ● エラー処理を例外として扱わない ● アドホックなエラー処理は複雑性が爆発的にあがる 21

Slide 22

Slide 22 text

共通モデル  プリミティブな操作 ● お金は加算と減算で操作できる ● 加算は常に成功する ● 減算は不可能なときがある(残高不足など) リトライと冪等性 ● どんなエラーがでても基本的にリトライする ● 冪等性を担保して二重処理されないようにする ● 継続不可能なときのみ処理をやめる 22

Slide 23

Slide 23 text

Try/Confirm/Cancel  減算のインターフェイス ● いきなり操作を確定させると都合が悪いことがある ● 全てのシステムで減算ができることを確認してから確定したい ● Try: 減算が成功するかどうかの確認と確保 ● Conﬁrm: 確保しておいたものを確定 ● Cancel: 確保しておいたものを開放 23

Slide 24

Slide 24 text

Try/Confirm/Cancelの例  決済残高ポイント 1. Try(成功) 決済残高ポイント 2. Try(成功) 決済残高ポイント 3. Confirm(成功) 3. Confirm(成功) 決済残高ポイント 1. Try(成功) 決済残高ポイント 2. Try(失敗) 決済残高ポイント 3. Cancel(成功) 全てのTryが成功一部のTryが失敗(ロールバック) ※ お金の移動先は省略 24

Slide 25

Slide 25 text

状態遷移によるトランザクションコーディネーション  状態遷移モデル ● 処理の種類によって何をどの順番で行うか確定できる ● あらゆる処理(システム)は意図せず途中で落ちることがある ● 処理単位で状態を定義してどこまで処理が進んだかを記憶 ● 途中で落ちても再開するだけで良いロールバックも状態遷移で定義 ● 途中で継続不可能(Tryが失敗)した場合も遷移先が異なるだけ ● Cancelを行う状態を定義して一貫したモデルで扱う 25

Slide 26

Slide 26 text

状態遷移の例  Start Try 残高 Try ポイント Confirm 残高 Confirm ポイント Succeed Cancel 残高 Failed ※ お金の移動先は省略 26

Slide 27

Slide 27 text

決済と会計  決済とは口座間のお金の移動 ● 移動なので全体で見るとプラスマイナスゼロ ● 決済サービスで一貫して管理 ● 決済以外も含めて全てのお金を扱う操作が対象会計とはお金の移動に意味をつけること ● お金の移動ログ + 意味で集計 ● 移動ログを決済サービスが会計サービスに集約 ● 意味はビジネスに依存するので各マイクロサービスが付与 27

Slide 28

Slide 28 text

会計データの連携  決済銀行残高あと払い会計 NFC コード払いネット決済メルカリ Account Account Account キャンペーン管理ツール Balance Sheet Transaction Log Accounting Details 28

Slide 29

Slide 29 text

リコンサイル  データの整合性を確認すること ● 会計データが完全な状態だということを保証する ● 各マイクロサービスと会計システム間バランスシート ● 会計上でAさんは◯年△月□日X時Y分Z秒時点でいくらもっているか ● 各口座で実際にその時点の残高が正しいか確認する 29

Slide 30

Slide 30 text

会計データの連携  決済銀行残高あと払い会計 NFC コード払いネット決済メルカリ Account Account Account キャンペーン管理ツール Balance Sheet Accounting Reconcilation Transaction Reconcilation Balance Reconcilation 30

Slide 31

Slide 31 text

精算  不確定なデータから確定済みデータを作ること ● パートナーの残高は決済ごとに常に変動するが未確定データ ● 手数料計算や決済を特定のタイミングで確定させる必要がある ● 確定することで支払い可能なお金になる 31

Slide 32

Slide 32 text

精算  決済銀行残高あと払い会計 NFC コード払いネット決済メルカリ精算 Account Account Account キャンペーン管理ツール settlement 32

Slide 33

Slide 33 text

不正検知  33

Slide 34

Slide 34 text

お金に関わる不正検知  不正検知のポイント ● ログイン ● 入金 ● 出金今までのメルカリ ● ログイン: アカウント保護のため注力 ● 入金: 該当するものがない(不正取引は別途注力) ● 出金: 売上金の振込が重要 ※ もちろん広い意味で不正対策はこれだけではありません 34

Slide 35

Slide 35 text

メルペイでのお金に関わる不正検知  (ニア)リアルタイムな不正検知が重要 ● 店舗でのお金が利用可能になったことで問題発生までが短い (出金) ● 入金方法の追加(銀行など) ● 総合的なお金の流れの不正を検知する必要がある本人確認が重要 ● お客さまが誰なのかを正確に知る必要がある ● 反社会的勢力の排除 ● 犯罪収益移転防止法(犯収法)準拠の本人確認 35

Slide 36

Slide 36 text

AML・CFT  AML・CFT ● マネーロンダリング及びテロ資金供与対策 ● 金融庁からガイドラインがでている疑わしい「取引」を見つけ出す ● トランザクションモニタリング ● 「疑わしい取引」を検知・報告・対策できるようにする疑わしい「人」を見つけ出す ● 個々のお客様に対して本人確認とリスク評価を行う ● リスクに応じて取引を停止したりする必要がある 36

Slide 37

Slide 37 text

トランザクションモニタリング  ● ルールベースと機械学習ベースの両方で行っている ● 決済サービスの処理をPubSubで受け取っているルールベース ● Splunkを利用 ● 即時利用停止や目視での停止 ● 金融庁へのレポーティング 37

Slide 38

Slide 38 text

トランザクションモニタリング  決済サービス B Bridge Cloud Pub/Sub サービス A Transaction Check 管理ツール FSA Kinesis Data Firehose Splunk Transaction Log Suspend Suspend Report Result 38

Slide 39

Slide 39 text

開発フロー  39

Slide 40

Slide 40 text

開発フロー  Design Doc Dev Test Readiness Check Release Ops ● フロー自体はメルカリと共通 ● メルペイでは各フェイズで追加のルールを設けている ● より厳しいルールが求められるため 40

Slide 41

Slide 41 text

Design Doc  Design Doc Dev Test Readiness Check Release Ops ● 開発を行う前にドキュメントを書き、チーム間でレビューする ● 新しいマイクロサービス、機能開発時に行う目的 ● 事前にリスクを洗い出す(セキュリティ, リーガル, 会計) ● チーム間での情報共有メルカリとの違い ● アーキテクト, SRE, セキュリティ, 関連チームからのレビュー必須 41

Slide 42

Slide 42 text

Development  Design Doc Dev Test Readiness Check Release Ops ● マイクロサービスの開発 ● 特に制約は無く割と自由(もちろんコードレビューやテストは必須) メルカリとの違い ● (あえていえば) コストをかけてもより安全よりに ● 一貫性と例外処理は高い水準で要求 ● 意識的な話が強いのでSLOでの考え方に寄せていくべき 42

Slide 43

Slide 43 text

Test  Design Doc Dev Test Readiness Check Release Ops ● QA, セキュリティテスト, 負荷テスト目的 ● リリース前に複数の観点で問題がないかを確認する ● リリース判断のための証跡を残すメルカリとの違い ● 第三者がテスト結果を検証(説明)可能な状態にする 43

Slide 44

Slide 44 text

Test - QA  テストの観点 ● マイクロサービスのAPI視点でのテスト ● クライアント視点でのテストテスト方法 ● マニュアルテストと自動テスト ● Postman から Go へ移行中 44

Slide 45

Slide 45 text

Test - 負荷テスト  実施と結果 ● 負荷試験環境で実施する ● 目標性能を出せるかどうか、スケールするかどうかを確認 ● 目標性能を出すための環境構成を記録見積もり ● 新規機能はリリース前に負荷試験が必須 ● 目標性能の見積もりとその数値の根拠を残す 45

Slide 46

Slide 46 text

Production Readiness Check (PRC)  Design Doc Dev Test Readiness Check Release Ops ● プロダクションレベルの品質にするためのチェック項目 ● SLOなどもここで定義目的 ● ベースラインの品質を保証するためメルカリとの違い ● 大きなリリースでは経営判断も別途行う 46

Slide 47

Slide 47 text

SLO (Service Level Objective)  ● サービスの安定性の指標としてSLOを重視 ● メルペイとしてSLOの期待を守ることを必須にしている ● 期待が高すぎる場合はSLOを下げる、低すぎる場合はあげる ● 期待はあっているのにSLOを下回る場合は改善する標準的なSLOの例 ● API単位で99%のlantecyが xxx ms以内 ● APIのエラー率が 0.1%以下 47

Slide 48

Slide 48 text

Release  Design Doc Dev Test Readiness Check Release Ops ● リリース可能と判断されたイメージのみがデプロイ可能 ● カナリアリリースによる段階的デプロイ目的 ● 意図しないものをリリースできないように ● 万が一の問題の最小化メルカリとの違い ● 特になし 48

Slide 49

Slide 49 text

Operations  Design Doc Dev Test Readiness Check Release Ops ● マイクロサービスの運用は全て開発チーム自身が行う ● アラートを受けるのも開発チーム目的 ● 権限の最小化、権限の分離のためメルカリとの違い ● 本番環境に直接アクセスできるのはSREのみ(audit有) 49

Slide 50

Slide 50 text

めざしていくもの  50

Slide 51

Slide 51 text

メルカリとメルペイの違い  ● 最大化したい価値が異なる ● どちらもシステムをより安定化させたいのは同じより高い信頼性  その上で機能がある  メルカリ  守るべきものは守り  強くチャレンジする  メルペイ  51

Slide 52

Slide 52 text

業界全体のレベルをあげるために  メルペイの事例を公開 ● 透明性と信頼性の向上 ● 他社が参考にできるように ● 逆に他社の事例を参考にして発展させていきたい各社が協力してレベルをあげていく必要がある ● 一部の会社がしっかりできていれば良いという状況ではない ● もちろんメルペイが他社より優れているわけではない 52

Slide 53

Slide 53 text

参考リンク  ● マイクロサービス ○ Merpay Microservices on Microservices Platform (Tech Blog) ○ メルペイにおけるマイクロサービスの構築と運用 (CloudNative Days Tokyo 2019) ● 決済システム ○ マイクロサービスにおける決済トランザクション管理 (Tech Blog) ○ メルペイにおけるお客さま残高の管理手法 (Tech Blog) ● AML/CFT ○ メルペイのAML/CFTシステムを支える技術 (Tech Blog) ○ AMLチームがどのようにメルペイのデータを Splunkに集め活用しているか (Tech Blog) 53