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

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

59c0cc69a8ad4ca8d26d752b3b795b55?s=128

kazegusuri

August 30, 2019
Tweet

Transcript

  1. 4.

    @kazegusuri • Merpay Backend Engineer • Architect Team 2015/11 2017/01

    2018/01 SRE & Platform Platform Payment & Architect 4
  2. 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
  3. 14.

    4階層のアーキテクチャ
 Backend Service API Gateway API Service Client Client
 アプリ、加盟店等のパートナー様

    
 API Gateway
 全てのリクエストがAPI Gatewayを通る 
 共通処理とルーティング 
 API Service
 クライアントからのリクエストとレスポンスの責任を持つ 
 裏側にある複数のマイクロサービスのアグリゲーション 
 Backend Service
 機能のロジックを実現する 
 14
  4. 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
  5. 16.

    API Service
 
 Backend Service API Gateway API Service Client

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

    Backend Service
 
 Backend Service API Gateway API Service Client

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

    トランザクション管理の課題
 複雑な支払方法 • 複数の支払手段 (メルペイ残高, ポイント, コンビニ, ATM, キャリア決済...) •

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

    共通モデル
 プリミティブな操作 • お金は加算と減算で操作できる • 加算は常に成功する • 減算は不可能なときがある(残高不足など) リトライと冪等性 •

    どんなエラーがでても基本的にリトライする • 冪等性を担保して二重処理されないようにする • 継続不可能なときのみ処理をやめる 22
  9. 24.

    Try/Confirm/Cancelの例
 決済 残高 ポイント 1. Try(成功) 決済 残高 ポイント 2.

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

    状態遷移の例
 Start Try 残高 Try ポイント Confirm 残高 Confirm ポイント

    Succeed Cancel 残高 Failed ※ お金の移動先は省略 26
  11. 27.

    決済と会計
 決済とは口座間のお金の移動 • 移動なので全体で見るとプラスマイナスゼロ • 決済サービスで一貫して管理 • 決済以外も含めて全てのお金を扱う操作が対象 会計とはお金の移動に意味をつけること •

    お金の移動ログ + 意味 で集計 • 移動ログを決済サービスが会計サービスに集約 • 意味はビジネスに依存するので各マイクロサービスが付与 27
  12. 28.

    会計データの連携
 決済 銀行 残高 あと払い 会計 NFC コード払い ネット決済 メルカリ

    Account Account Account キャンペーン 管理ツール Balance Sheet Transaction Log Accounting Details 28
  13. 30.

    会計データの連携
 決済 銀行 残高 あと払い 会計 NFC コード払い ネット決済 メルカリ

    Account Account Account キャンペーン 管理ツール Balance Sheet Accounting Reconcilation Transaction Reconcilation Balance Reconcilation 30
  14. 32.

    精算
 決済 銀行 残高 あと払い 会計 NFC コード払い ネット決済 メルカリ

    精算 Account Account Account キャンペーン 管理ツール settlement 32
  15. 34.

    お金に関わる不正検知
 不正検知のポイント • ログイン • 入金 • 出金 今までのメルカリ •

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

    AML・CFT
 AML・CFT • マネーロンダリング及びテロ資金供与対策 • 金融庁からガイドラインがでている 疑わしい「取引」を見つけ出す • トランザクションモニタリング •

    「疑わしい取引」を検知・報告・対策できるようにする 疑わしい「人」を見つけ出す • 個々のお客様に対して本人確認とリスク評価を行う • リスクに応じて取引を停止したりする必要がある 36
  17. 38.

    トランザクションモニタリング
 決済 サービス B Bridge Cloud Pub/Sub サービス A Transaction

    Check 管理ツール FSA Kinesis Data Firehose Splunk Transaction Log Suspend Suspend Report Result 38
  18. 40.

    開発フロー
 Design Doc Dev Test Readiness Check Release Ops •

    フロー自体はメルカリと共通 • メルペイでは各フェイズで追加のルールを設けている • より厳しいルールが求められるため 40
  19. 41.

    Design Doc
 Design Doc Dev Test Readiness Check Release Ops

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

    Development
 Design Doc Dev Test Readiness Check Release Ops •

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

    Test
 Design Doc Dev Test Readiness Check Release Ops •

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

    Production Readiness Check (PRC)
 Design Doc Dev Test Readiness Check

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

    SLO (Service Level Objective)
 • サービスの安定性の指標としてSLOを重視 • メルペイとしてSLOの期待を守ることを必須にしている • 期待が高すぎる場合はSLOを下げる、低すぎる場合はあげる

    • 期待はあっているのにSLOを下回る場合は改善する 標準的なSLOの例 • API単位で99%のlantecyが xxx ms以内 • APIのエラー率が 0.1%以下 47
  25. 48.

    Release
 Design Doc Dev Test Readiness Check Release Ops •

    リリース可能と判断されたイメージのみがデプロイ可能 • カナリアリリースによる段階的デプロイ 目的 • 意図しないものをリリースできないように • 万が一の問題の最小化 メルカリとの違い • 特になし 48
  26. 49.

    Operations
 Design Doc Dev Test Readiness Check Release Ops •

    マイクロサービスの運用は全て開発チーム自身が行う • アラートを受けるのも開発チーム 目的 • 権限の最小化、権限の分離のため メルカリとの違い • 本番環境に直接アクセスできるのはSREのみ(audit有) 49
  27. 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