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

Transcript

1. Masahiro Sano

   @kazegusuri

   Open SKT: メルペイ開発の裏側

   builderscon tokyo 2019

   

   1

   

   View Slide

2. 決済・金融サービス is hard

   2
   決済はお金のトランザクション管理が難しい

   そう思っていた時期が自分にもありました

   

   

   

   

   View Slide

3. 今日のテーマ

   3
   あんしん・あんぜんのために

   技術的に取り組んできたことを知ってもらう

   

   View Slide

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

   View Slide

5. アジェンダ

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

   View Slide

6. メルペイの概要

   6
   

   View Slide

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

   7
   

   View Slide

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

   View Slide

9. そもそもSKTって何？

   オンボーディングも兼ねた社員研修

   各システムの具体的な処理の流れ

   メルカリ・メルペイのアーキテクチャ

   開発体制や開発方法

   メルペイの目標やポリシー

   9
   

   View Slide

10. メルペイの開発で重要視していること

    インフラのように安定して信頼できるシステム

    サービス開発をメインにしない

    10
    

    View Slide

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

    11
    

    View Slide

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
    

    View Slide

13. アーキテクチャ

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

    View Slide

14. 4階層のアーキテクチャ

    Backend
    Service
    API
    Gateway
    API
    Service
    Client
    Client
 アプリ、加盟店等のパートナー様 

    API Gateway
 全てのリクエストがAPI Gatewayを通る 

    共通処理とルーティング 

    API Service
 クライアントからのリクエストとレスポンスの責任を持つ 

    裏側にある複数のマイクロサービスのアグリゲーション 

    Backend Service
 機能のロジックを実現する 

    14
    

    View Slide

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
    

    View Slide

16. API Service

    

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

    View Slide

17. Backend Service

    

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

    View Slide

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

    18
    

    View Slide

19. 決済サービスを中心とした決済システム

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

    View Slide

20. 分散システムにおけるトランザクション

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

    View Slide

21. トランザクション管理の課題

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

    View Slide

22. 共通モデル

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

    View Slide

23. Try/Confirm/Cancel

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

    View Slide

24. Try/Confirm/Cancelの例

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

    View Slide

25. 状態遷移によるトランザクションコーディネーション

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

    View Slide

26. 状態遷移の例

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

    View Slide

27. 決済と会計

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

    View Slide

28. 会計データの連携

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

    View Slide

29. リコンサイル

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

    View Slide

30. 会計データの連携

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

    View Slide

31. 精算

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

    View Slide

32. 精算

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

    View Slide

33. 不正検知

    33
    

    View Slide

34. お金に関わる不正検知

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

    View Slide

35. メルペイでのお金に関わる不正検知

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

    View Slide

36. AML・CFT

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

    View Slide

37. トランザクションモニタリング

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

    View Slide

38. トランザクションモニタリング

    決済
    サービス B Bridge
    Cloud
    Pub/Sub
    サービス A
    Transaction
    Check
    管理ツール FSA
    Kinesis
    Data Firehose
    Splunk
    Transaction
    Log
    Suspend
    Suspend
    Report
    Result
    38
    

    View Slide

39. 開発フロー

    39
    

    View Slide

40. 開発フロー

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

    View Slide

41. Design Doc

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

    View Slide

42. Development

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

    View Slide

43. Test

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

    View Slide

44. Test - QA

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

    View Slide

45. Test - 負荷テスト

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

    View Slide

46. Production Readiness Check (PRC)

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

    View Slide

47. SLO (Service Level Objective)

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

    View Slide

48. Release

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

    View Slide

49. Operations

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

    View Slide

50. めざしていくもの

    50
    

    View Slide

51. メルカリとメルペイの違い

    ● 最大化したい価値が異なる
    ● どちらもシステムをより安定化させたいのは同じ
    より高い信頼性

    その上で機能がある

    メルカリ

    守るべきものは守り

    強くチャレンジする

    メルペイ

    51
    

    View Slide

52. 業界全体のレベルをあげるために

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

    View Slide

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
    

    View Slide