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

Transcript

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

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

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

4. @kazegusuri • Merpay Backend Engineer • Architect Team 2015/11 2017/01 2018/01 SRE & Platform Platform Payment & Architect 4
5. アジェンダ
 メルペイの概要 1 全体のアーキテクチャの概要 2 決済システムの一貫性管理 3 不正検知 4 開発フロー 5 5
6. メルペイの概要
 6
7. 2019年2月 非接触型サービス「iD」に対応 2019年4月 複数回のお買い物をあとからまとめて支払える 「メルペイあと払い」開始 2019年5月 ECサイトでも「メルペイ」が利用できる ネット決済提供開始 2019年3月 大手チェーンや中・小規模店舗で QR・バーコード決済に対応 全国135万か所 (iOS/Android) iD コード払い あと払い ネット決済 メルペイの概要
 7
8. メルペイの サービス規模 マイクロサービスアーキテクチャ 40以上のマイクロサービス 2019 3Qで 1444億円以上を取り扱う メルカリの決済基盤(USのメルカリ事業も含む数字 ) 200万人以上の利用者 （メルペイ「電子マネー」の登録を行ったユーザーの累計。 コード払いは除く ） 8
9. そもそもSKTって何？
 オンボーディングも兼ねた社員研修
 各システムの具体的な処理の流れ
 メルカリ・メルペイのアーキテクチャ
 開発体制や開発方法
 メルペイの目標やポリシー
 9
10. メルペイの開発で重要視していること
 インフラのように安定して信頼できるシステム
 サービス開発をメインにしない
 10
11. 全体のアーキテクチャ概要
 11
12. アーキテクチャ
 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
13. アーキテクチャ
 マイクロサービスの階層化 1マイクロサービス, 1 Namespace & 1 Project 共通のGKEクラスター 13
14. 4階層のアーキテクチャ
 Backend Service API Gateway API Service Client Client
 アプリ、加盟店等のパートナー様 
 API Gateway
 全てのリクエストがAPI Gatewayを通る 
 共通処理とルーティング 
 API Service
 クライアントからのリクエストとレスポンスの責任を持つ 
 裏側にある複数のマイクロサービスのアグリゲーション 
 Backend Service
 機能のロジックを実現する 
 14
15. API Gateway
 Backend Service API Gateway API Service Client インターネットからのリクエストを安全に内部に届ける • TLS終端 + DDoS対策 (CDN, Google Cloud Load Balancing) • Request/Response buffering + Timeout • AuthN/AuthZ (認証認可プラットフォーム) • アクセスログ (データプラットフォーム) Why • 外部からのアクセスが最も重要 • 適切に扱うのが難しいため共通で処理 15
16. API Service
 
 Backend Service API Gateway API Service Client クライアントとのメッセージに責任を持つ • リクエストバリデーション • バックエンドマイクロサービスのアグリゲーション • クライアントの互換性、ABテスト • 必要十分なレスポンス Why • 外部からのアクセスが最も重要 • 適切に扱うのが難しいため共通で処理 16
17. Backend Service
 
 Backend Service API Gateway API Service Client 担当ドメインに特化した機能の提供 • クライアント(リクエスト元)のコンテキストに依存しない機能 • 内部の実装のみを意識する • リクエストの認可はクライアントのコンテキストに応じて行う Why • 開発をドメインで閉じて行えるように 17
18. 決済システムの一貫性管理
 18
19. 決済サービスを中心とした決済システム
 決済 銀行 残高 あと払い 会計 NFC コード払い ネット決済 メルカリ 精算 Account Account Account キャンペーン 管理ツール 19
20. 分散システムにおけるトランザクション
 難しい • システムの数や状態が増えると単純に行うのは難しい • アドホックにデータ補正(バッチ処理)も可能だが… • 既知の手法(2PC,XA)や、分散コーディネーションもある 多様なシステム構成 • システム間で協調するのは難しい(チームが異なる) • 外部システムもある • 中央でのトランザクション管理の方向へ 20
21. トランザクション管理の課題
 複雑な支払方法 • 複数の支払手段 (メルペイ残高, ポイント, コンビニ, ATM, キャリア決済...) • 支払い手段の組み合わせ(残高+ポイント, 残高+ポイント+コンビニ) • 今後も更に複雑化する可能性が高い エラー処理も含めたモデルの一般化が必須 • エラー処理を例外として扱わない • アドホックなエラー処理は複雑性が爆発的にあがる 21
22. 共通モデル
 プリミティブな操作 • お金は加算と減算で操作できる • 加算は常に成功する • 減算は不可能なときがある(残高不足など) リトライと冪等性 • どんなエラーがでても基本的にリトライする • 冪等性を担保して二重処理されないようにする • 継続不可能なときのみ処理をやめる 22
23. Try/Confirm/Cancel
 減算のインターフェイス • いきなり操作を確定させると都合が悪いことがある • 全てのシステムで減算ができることを確認してから確定したい • Try: 減算が成功するかどうかの確認と確保 • Confirm: 確保しておいたものを確定 • Cancel: 確保しておいたものを開放 23
24. Try/Confirm/Cancelの例
 決済 残高 ポイント 1. Try(成功) 決済 残高 ポイント 2. Try(成功) 決済 残高 ポイント 3. Confirm(成功) 3. Confirm(成功) 決済 残高 ポイント 1. Try(成功) 決済 残高 ポイント 2. Try(失敗) 決済 残高 ポイント 3. Cancel(成功) 全てのTryが成功 一部のTryが失敗(ロールバック) ※ お金の移動先は省略 24
25. 状態遷移によるトランザクションコーディネーション
 状態遷移モデル • 処理の種類によって何をどの順番で行うか確定できる • あらゆる処理(システム)は意図せず途中で落ちることがある • 処理単位で状態を定義してどこまで処理が進んだかを記憶 • 途中で落ちても再開するだけで良い ロールバックも状態遷移で定義 • 途中で継続不可能(Tryが失敗)した場合も遷移先が異なるだけ • Cancelを行う状態を定義して一貫したモデルで扱う 25
26. 状態遷移の例
 Start Try 残高 Try ポイント Confirm 残高 Confirm ポイント Succeed Cancel 残高 Failed ※ お金の移動先は省略 26
27. 決済と会計
 決済とは口座間のお金の移動 • 移動なので全体で見るとプラスマイナスゼロ • 決済サービスで一貫して管理 • 決済以外も含めて全てのお金を扱う操作が対象 会計とはお金の移動に意味をつけること • お金の移動ログ + 意味 で集計 • 移動ログを決済サービスが会計サービスに集約 • 意味はビジネスに依存するので各マイクロサービスが付与 27
28. 会計データの連携
 決済 銀行 残高 あと払い 会計 NFC コード払い ネット決済 メルカリ Account Account Account キャンペーン 管理ツール Balance Sheet Transaction Log Accounting Details 28
29. リコンサイル
 データの整合性を確認すること • 会計データが完全な状態だということを保証する • 各マイクロサービスと会計システム間 バランスシート • 会計上でAさんは◯年△月□日X時Y分Z秒時点でいくらもっているか • 各口座で実際にその時点の残高が正しいか確認する 29
30. 会計データの連携
 決済 銀行 残高 あと払い 会計 NFC コード払い ネット決済 メルカリ Account Account Account キャンペーン 管理ツール Balance Sheet Accounting Reconcilation Transaction Reconcilation Balance Reconcilation 30
31. 精算
 不確定なデータから確定済みデータを作ること • パートナーの残高は決済ごとに常に変動するが未確定データ • 手数料計算や決済を特定のタイミングで確定させる必要がある • 確定することで支払い可能なお金になる 31
32. 精算
 決済 銀行 残高 あと払い 会計 NFC コード払い ネット決済 メルカリ 精算 Account Account Account キャンペーン 管理ツール settlement 32
33. 不正検知
 33
34. お金に関わる不正検知
 不正検知のポイント • ログイン • 入金 • 出金 今までのメルカリ • ログイン: アカウント保護のため注力 • 入金: 該当するものがない(不正取引は別途注力) • 出金: 売上金の振込が重要 ※ もちろん広い意味で不正対策はこれだけではありません 34
35. メルペイでのお金に関わる不正検知
 (ニア)リアルタイムな不正検知が重要 • 店舗でのお金が利用可能になったことで問題発生までが短い (出金) • 入金方法の追加(銀行など) • 総合的なお金の流れの不正を検知する必要がある 本人確認が重要 • お客さまが誰なのかを正確に知る必要がある • 反社会的勢力の排除 • 犯罪収益移転防止法(犯収法)準拠の本人確認 35
36. AML・CFT
 AML・CFT • マネーロンダリング及びテロ資金供与対策 • 金融庁からガイドラインがでている 疑わしい「取引」を見つけ出す • トランザクションモニタリング • 「疑わしい取引」を検知・報告・対策できるようにする 疑わしい「人」を見つけ出す • 個々のお客様に対して本人確認とリスク評価を行う • リスクに応じて取引を停止したりする必要がある 36
37. トランザクションモニタリング
 • ルールベースと機械学習ベースの両方で行っている • 決済サービスの処理をPubSubで受け取っている ルールベース • Splunkを利用 • 即時利用停止や目視での停止 • 金融庁へのレポーティング 37
38. トランザクションモニタリング
 決済 サービス B Bridge Cloud Pub/Sub サービス A Transaction Check 管理ツール FSA Kinesis Data Firehose Splunk Transaction Log Suspend Suspend Report Result 38
39. 開発フロー
 39
40. 開発フロー
 Design Doc Dev Test Readiness Check Release Ops • フロー自体はメルカリと共通 • メルペイでは各フェイズで追加のルールを設けている • より厳しいルールが求められるため 40
41. Design Doc
 Design Doc Dev Test Readiness Check Release Ops • 開発を行う前にドキュメントを書き、チーム間でレビューする • 新しいマイクロサービス、機能開発時に行う 目的 • 事前にリスクを洗い出す(セキュリティ, リーガル, 会計) • チーム間での情報共有 メルカリとの違い • アーキテクト, SRE, セキュリティ, 関連チームからのレビュー必須 41
42. Development
 Design Doc Dev Test Readiness Check Release Ops • マイクロサービスの開発 • 特に制約は無く割と自由(もちろんコードレビューやテストは必須) メルカリとの違い • (あえていえば) コストをかけてもより安全よりに • 一貫性と例外処理は高い水準で要求 • 意識的な話が強いのでSLOでの考え方に寄せていくべき 42
43. Test
 Design Doc Dev Test Readiness Check Release Ops • QA, セキュリティテスト, 負荷テスト 目的 • リリース前に複数の観点で問題がないかを確認する • リリース判断のための証跡を残す メルカリとの違い • 第三者がテスト結果を検証(説明)可能な状態にする 43
44. Test - QA
 テストの観点 • マイクロサービスのAPI視点でのテスト • クライアント視点でのテスト テスト方法 • マニュアルテストと自動テスト • Postman から Go へ移行中 44
45. Test - 負荷テスト
 実施と結果 • 負荷試験環境で実施する • 目標性能を出せるかどうか、スケールするかどうかを確認 • 目標性能を出すための環境構成を記録 見積もり • 新規機能はリリース前に負荷試験が必須 • 目標性能の見積もりとその数値の根拠を残す 45
46. Production Readiness Check (PRC)
 Design Doc Dev Test Readiness Check Release Ops • プロダクションレベルの品質にするためのチェック項目 • SLOなどもここで定義 目的 • ベースラインの品質を保証するため メルカリとの違い • 大きなリリースでは経営判断も別途行う 46
47. SLO (Service Level Objective)
 • サービスの安定性の指標としてSLOを重視 • メルペイとしてSLOの期待を守ることを必須にしている • 期待が高すぎる場合はSLOを下げる、低すぎる場合はあげる • 期待はあっているのにSLOを下回る場合は改善する 標準的なSLOの例 • API単位で99%のlantecyが xxx ms以内 • APIのエラー率が 0.1%以下 47
48. Release
 Design Doc Dev Test Readiness Check Release Ops • リリース可能と判断されたイメージのみがデプロイ可能 • カナリアリリースによる段階的デプロイ 目的 • 意図しないものをリリースできないように • 万が一の問題の最小化 メルカリとの違い • 特になし 48
49. Operations
 Design Doc Dev Test Readiness Check Release Ops • マイクロサービスの運用は全て開発チーム自身が行う • アラートを受けるのも開発チーム 目的 • 権限の最小化、権限の分離のため メルカリとの違い • 本番環境に直接アクセスできるのはSREのみ(audit有) 49
50. めざしていくもの
 50
51. メルカリとメルペイの違い
 • 最大化したい価値が異なる • どちらもシステムをより安定化させたいのは同じ より高い信頼性
 その上で機能がある
 メルカリ
 守るべきものは守り
 強くチャレンジする
 メルペイ
 51
52. 業界全体のレベルをあげるために
 メルペイの事例を公開 • 透明性と信頼性の向上 • 他社が参考にできるように • 逆に他社の事例を参考にして発展させていきたい 各社が協力してレベルをあげていく必要がある • 一部の会社がしっかりできていれば良いという状況ではない • もちろんメルペイが他社より優れているわけではない 52
53. 参考リンク
 • マイクロサービス ◦ 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