MTC2018 - どうして僕らは決済処理をマイクロサービス化しようとしているのか

Speaker: 斎藤 祐一郎

メルカリの売上金も電子マネーとして使えるようになるメルペイ。
もちろんメルカリでの買い物でも使える予定ですが、そこで問題となったのがメルカリ上での決済処理。
増築に増築を重ねたモノリシックなプログラムが、新しい決済手段の導入の前に立ちはだかります。
そこで、私達はGO BOLDにMicroservice化で解決しようとしていますが、その中で認められた問題点と解決策を示していきます。

0) なぜMicroservices化に踏み切ったのか
1) 複雑に絡み合ったswitch文となった業務フローを読み解く
2) 分散トランザクションで発生するであろうエラーとの戦い
3) 実際の移行実行の段取りとそのハードル

Transcript

1. どうして僕らは決済処理を
   マイクロサービス化しようとしているのか
   斎藤 祐一郎
   Software Engineer (Backend)
   

   View Slide

2. どうして僕らは
   決済処理をマイクロサービス化
   しようとしているのか
   

   View Slide

3. 分散
   移行
   現状
   把握
   

   View Slide

4. 決済
   事業
   疎結合
   保守性
   

   View Slide

5. Software Engineer
   Backend
   Yuichiro Saito
   

   View Slide

6. なぜMicroservices化に踏み切ったのか
   

   View Slide

7. 建て増しを重ねた温泉旅館のよう
   =
   

   View Slide

8. 成長の足かせになる可能性があった
   特に決済処理においては
   ● スケールしない既存の決済処理
   ● 一方で新しい電子決済を加えなければならない
   ● 限られた人しか決済処理を理解していない
   

   View Slide

9. 複雑に絡み合ったswitch文となった
   業務フローを読み解く
   

   View Slide

10. まずは
    ● 支払手段の増え方の様子をご覧ください
    (擬似コードです)
    

    View Slide

11. View Slide

12. View Slide

13. View Slide

14. View Slide

15. これにメルペイの電子決済のcase文を増やすの？
    

    View Slide

16. 問題点
    ● 現状の決済処理の構
    造はスケールしない
    ● 開発中の電子決済
    サービスとの間で
    疎な結合を取る必要が
    出てきた
    解決策
    ● 疎結合化に伴いgrpcの
    インタフェイスを用いた
    Microservice化
    ● 決済処理を再実装
    (PaymentService)
    ● 組織構造も同時に疎に
    していく
    

    View Slide

17. リファクタリ
    ング
    Microservices
    解決策
    選択！
    etc...
    

    View Slide

18. 得られた効果
    ● 保守性が向上
    ● 責務の分離が図れた
    ● 決済手段を容易に増やせるようになった
    ● 同時に決済処理の再実装を行うことで決済処理の
    理解者が増えた
    

    View Slide

19. 分散トランザクションで発生する
    であろうエラーとの戦い
    

    View Slide

20. View Slide

21. 喜ぶのはまだ早い！
    ここでもう一度
    ● 現在の決済処理を見てみましょう
    

    View Slide

22. 失敗したらrollback、
    これだけでよかった。
    

    View Slide

23. 決済がMicroservices化すると
    ● 分散トランザクションになる
    

    View Slide

24. 問題1
    ● 処理の結果はそれぞれのシステムで独立である
    

    View Slide

25. payment->consume()
    は独立した処理として
    実行される。
    もしここでポイント決済と
    カード決済などを同時に
    行うとき、
    どちらかで失敗すると正し
    い結果にならない。
    

    View Slide

26. View Slide

27. 解決策1: 分ける
    1. 支払枠を押さえる
    2. 支払い能力が担保された状態で
    購入処理を続ける
    3. 問題なければ支払確定
    4. 問題があれば支払枠を開放
    処理は冪等性を担保
    

    View Slide

28. 問題2
    ● PaymentServiceに一部障害が起きたら
    

    View Slide

29. payment->consume()
    がもたついたら
    この処理が始まらない
    

    View Slide

30. View Slide

31. 解決策2: ステートマシン
    特徴
    ● 非同期に処理が可能。呼び出し
    元を待たせない。
    ● 失敗時も再キューイングして自動
    リトライ。可用性が高い。
    ● 復帰不能な失敗は状態を巻き戻
    しできる。
    また、決済手段の追加も逐次可能と
    なっている。
    再試行 再試行
    成功
    補償
    トランザクション
    ポイント消
    費
    カード
    決済
    成功
    開始
    失敗
    

    View Slide

32. 会計システムへの影響をいかに減らすか
    

    View Slide

33. 忘れてないですか
    

    View Slide

34. 1. 決済システム移行時
    は記録は現システム
    と新システムで並行
    書き込み。
    2. PaymentServiceに
    完全移行し次第、並
    行書き込みは終了。
    PaymentServiceの
    み。
    決済
    事業者
    Payment
    Service
    現システム 完了
    DB
    DB
    Pub/
    Sub
    

    View Slide

35. おわりに
    

    View Slide

36. 保守性の向上
    →
    

    View Slide

37. 責務が分割されたことにより、開発及び保守が容
    易になる。
    責務の分割
    柔軟な拡張
    属人性排除
    システム拡張に伴い組織構造から再編すること
    で、それぞれが疎に組み合わせられる。
    再設計・再実装・文書化を通じて、属人性を排除し
    ていく。
    

    View Slide

38. 分散トランザクションの性質を理解して実装
    元の状態に戻せる方法を担保する
    

    View Slide

39. 並行書き込みで
    会計システムの移行に備える
    

    View Slide

40. リリースまで追い込み中！
    画像提供 いらすとや:https://www.irasutoya.com/
    

    View Slide

41. View Slide