新たなマイクロサービス取り組みの実例

2023/7/19のTECH PLAYでの発表資料です。
https://techplay.jp/event/908123

Transcript

1. 0
   新たなマイクロサービス取り組みの実例
   株式会社一休
   宿泊プロダクト開発部
   バックエンド開発チーム
   江口 潤
   技術負債に立ち向かうエンジニアを助けるマイクロサービス化
   一休の7年間の取り組み事例から紐解く成功と失敗を分けるポイント
   2023/07/19
   

   View Slide

2. 1
   株式会社一休
   宿泊プロダクト開発部
   バックエンド開発チーム
   江口 潤
   2022年1月に一休へ中途入社。宿泊予約サービスのバック
   エンド開発・運用及び、決済マイクロサービスの新規開発
   に従事。
   最近はインスタでプレーリードッグを見る事にはまってい
   ます。
   

   View Slide

3. 2
   目次
   ●
   決済プラットフォーム概要
   ●
   技術選定
   ●
   境界線をどこに引くか
   ●
   整合性を崩さない
   ●
   今後の展開
   

   View Slide

4. 決済プラットフォーム概要
   

   View Slide

5. 4
   カード決済モジュールが３つ？
   

   View Slide

6. 5
   一休サービス
   決済プラットフォームサービス導入前
   外部サービス
   GMO PG
   PAY.JP
   決済モジュール
   モジュール①
   モジュール③
   モジュール②
   レストラン予約
   スパ予約
   宿泊予約
   決済予定 決済履歴 会計
   類似の決済モジュールが乱立。
   凝集度が低く各サービスに決済関連機能が漏洩し、
   再利用するメリットが少ない。
   新サービス追加の度に決済関連機能を開発。
   決済予定 決済履歴 会計
   決済予定 決済履歴 会計
   

   View Slide

7. 6
   一休サービス 決済プラットフォーム
   決済プラットフォームサービス導入後
   外部サービス
   GMO PG
   PAY.JP
   決済予定
   決済履歴
   会計
   国内宿泊予約
   レストラン予約
   スパ予約
   決済に関連する機能を集約。
   再利用するメリットが多く、
   新サービスの開発が容易。
   

   View Slide

8. 7
   一休サービス 決済プラットフォーム
   まずは新規サービスへ決済プラットフォームを導入中
   ふるさと納税
   外部サービス
   GMO PG
   PAY.JP
   国内宿泊予約
   レストラン予約
   スパ予約
   新サービスA
   新サービスB
   決済予定
   決済履歴
   会計
   

   View Slide

9. 技術選定
   

   View Slide

10. 9
    主要技術スタック
    フロントエンド バックエンド インフラ
    柔軟にオートスケールされる
    Aurora Serverless v2を採用
    

    View Slide

11. 境界線をどこに引くか
    

    View Slide

12. 11
    曖昧なドメイン境界（1/8）
    一休サービス
    予約
    精算
    決済プラットフォーム
    決済予定
    決済履歴
    会計？
    会計は一見、決済プラットフォームの持ち物ではなさそう。
    

    View Slide

13. 12
    曖昧なドメイン境界（2/8）
    前提として、カード決済額は一休を一度経由し、
    宿泊施設様へ振込がされる。
    そのため、一休でお金の管理（会計管理）が発生。
    

    View Slide

14. 13
    曖昧なドメイン境界（3/8）
    決済プラットフォーム起点で債務が増加し、
    一休サービス起点で債務が減少する。
    この債務の増減を、決済プラットフォームと
    一休サービスのどちらで管理すべきか？
    

    View Slide

15. 14
    一休サービス 決済プラットフォーム
    曖昧なドメイン境界（4/8）
    ふるさと納税
    外部サービス
    GMO PG
    PAY.JP
    国内宿泊予約
    レストラン予約
    スパ予約
    新サービスA
    新サービスB
    会計
    会計
    会計
    会計
    会計
    会計 各一休サービスに会計管理を任せる場合、
    サービスを新しく作る度に同様の実装が
    必要になってしまう。
    決済予定
    決済履歴
    会計
    

    View Slide

16. 15
    一休サービス 決済プラットフォーム
    曖昧なドメイン境界（5/8）
    ふるさと納税
    外部サービス
    GMO PG
    PAY.JP
    国内宿泊予約
    レストラン予約
    スパ予約
    新サービスA
    新サービスB
    会計
    会計
    会計
    会計
    会計
    会計 会計管理も集約することで、
    新規サービス開発が容易に。
    決済予定
    決済履歴
    会計
    

    View Slide

17. 16
    曖昧なドメイン境界（6/8）
    経理業務として、最終的には会計データを会計システムに
    連携している。
    会計管理機能を各一休サービスに持たせると、
    経理担当者もそれぞれの画面を操作する必要があって手間。
    

    View Slide

18. 17
    曖昧なドメイン境界（7/8）
    会計管理機能を決済プラットフォームに集約し、
    経理担当者の手間を軽減。
    

    View Slide

19. 18
    曖昧なドメイン境界（8/8）
    一休サービス
    予約
    精算
    決済プラットフォーム
    決済予定
    決済履歴
    会計
    結論、新サービス開発時のコストと経理担当者の負担軽減のため、
    （決済に関わる）会計管理機能は決済プラットフォームに集約した。
    ドメインを跨ぐ機能はプラットフォーム側に寄せた方が良さそう。
    

    View Slide

20. 19
    どこまでを共通化すべきか（1/3）
    バッチ処理で決済が行われており、決済に失敗した場合に
    お客様へカード変更依頼メールをお送りする場合がある。
    このメールも各一休サービスを介さず、
    決済プラットフォームから直接送る案があった。
    

    View Slide

21. 20
    どこまでを共通化すべきか（2/3）
    カード変更依頼のメールには、
    一休サービスしかもっていない予約情報などを出したい。
    

    View Slide

22. 21
    どこまでを共通化すべきか（3/3）
    結論、決済プラットフォームからは通知をするのみとし、
    メール送信は一休サービスで行うことにした。
    ドメイン知識がない場合は処理を移譲したほうが良さそう。
    

    View Slide

23. 整合性を崩さない
    

    View Slide

24. 23
    ざっくりシステム構成
    

    View Slide

25. 24
    失敗したら自力でロールバック（補償トランザクション）
    

    View Slide

26. 25
    バッチでも整合性をチェック
    補償トランザクション失敗の可能性もあるため、
    バッチによって二重で整合性を担保。
    

    View Slide

27. 今後の展開
    

    View Slide

28. 27
    一休サービス 決済プラットフォーム
    今後の展開
    ふるさと納税
    外部サービス
    国内宿泊予約
    レストラン予約
    スパ予約
    新サービスA
    新サービスB
    GMO PG
    PAY.JP
    決済業務をプラットフォームで一元管理するため、
    既存サービスにも導入を進める予定。
    決済予定
    決済履歴
    会計
    

    View Slide

29. 28
    まとめ
    ●
    凝集度の高いマイクロサービスを作る
    ●
    ドメインを跨ぐ機能はプラットフォームへ
    ●
    ドメイン知識がなければ処理は移譲する
    ●
    補償トランザクションが失敗する可能性も考慮する
    

    View Slide