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

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

Transcript

1. 0 新たなマイクロサービス取り組みの実例 株式会社一休 宿泊プロダクト開発部 バックエンド開発チーム 江口 潤 技術負債に立ち向かうエンジニアを助けるマイクロサービス化 一休の7年間の取り組み事例から紐解く成功と失敗を分けるポイント 2023/07/19
2. 1 株式会社一休 宿泊プロダクト開発部 バックエンド開発チーム 江口 潤 2022年1月に一休へ中途入社。宿泊予約サービスのバック エンド開発・運用及び、決済マイクロサービスの新規開発 に従事。 最近はインスタでプレーリードッグを見る事にはまってい ます。
3. 2 目次 • 決済プラットフォーム概要 • 技術選定 • 境界線をどこに引くか • 整合性を崩さない • 今後の展開
4. 決済プラットフォーム概要
5. 4 カード決済モジュールが３つ？
6. 5 一休サービス 決済プラットフォームサービス導入前 外部サービス GMO PG PAY.JP 決済モジュール モジュール① モジュール③ モジュール② レストラン予約 スパ予約 宿泊予約 決済予定 決済履歴 会計 類似の決済モジュールが乱立。 凝集度が低く各サービスに決済関連機能が漏洩し、 再利用するメリットが少ない。 新サービス追加の度に決済関連機能を開発。 決済予定 決済履歴 会計 決済予定 決済履歴 会計
7. 6 一休サービス 決済プラットフォーム 決済プラットフォームサービス導入後 外部サービス GMO PG PAY.JP 決済予定 決済履歴 会計 国内宿泊予約 レストラン予約 スパ予約 決済に関連する機能を集約。 再利用するメリットが多く、 新サービスの開発が容易。
8. 7 一休サービス 決済プラットフォーム まずは新規サービスへ決済プラットフォームを導入中 ふるさと納税 外部サービス GMO PG PAY.JP 国内宿泊予約 レストラン予約 スパ予約 新サービスA 新サービスB 決済予定 決済履歴 会計
9. 技術選定
10. 9 主要技術スタック フロントエンド バックエンド インフラ 柔軟にオートスケールされる Aurora Serverless v2を採用
11. 境界線をどこに引くか
12. 11 曖昧なドメイン境界（1/8） 一休サービス 予約 精算 決済プラットフォーム 決済予定 決済履歴 会計？ 会計は一見、決済プラットフォームの持ち物ではなさそう。
13. 12 曖昧なドメイン境界（2/8） 前提として、カード決済額は一休を一度経由し、 宿泊施設様へ振込がされる。 そのため、一休でお金の管理（会計管理）が発生。
14. 13 曖昧なドメイン境界（3/8） 決済プラットフォーム起点で債務が増加し、 一休サービス起点で債務が減少する。 この債務の増減を、決済プラットフォームと 一休サービスのどちらで管理すべきか？
15. 14 一休サービス 決済プラットフォーム 曖昧なドメイン境界（4/8） ふるさと納税 外部サービス GMO PG PAY.JP 国内宿泊予約 レストラン予約 スパ予約 新サービスA 新サービスB 会計 会計 会計 会計 会計 会計 各一休サービスに会計管理を任せる場合、 サービスを新しく作る度に同様の実装が 必要になってしまう。 決済予定 決済履歴 会計
16. 15 一休サービス 決済プラットフォーム 曖昧なドメイン境界（5/8） ふるさと納税 外部サービス GMO PG PAY.JP 国内宿泊予約 レストラン予約 スパ予約 新サービスA 新サービスB 会計 会計 会計 会計 会計 会計 会計管理も集約することで、 新規サービス開発が容易に。 決済予定 決済履歴 会計
17. 16 曖昧なドメイン境界（6/8） 経理業務として、最終的には会計データを会計システムに 連携している。 会計管理機能を各一休サービスに持たせると、 経理担当者もそれぞれの画面を操作する必要があって手間。
18. 17 曖昧なドメイン境界（7/8） 会計管理機能を決済プラットフォームに集約し、 経理担当者の手間を軽減。
19. 18 曖昧なドメイン境界（8/8） 一休サービス 予約 精算 決済プラットフォーム 決済予定 決済履歴 会計 結論、新サービス開発時のコストと経理担当者の負担軽減のため、 （決済に関わる）会計管理機能は決済プラットフォームに集約した。 ドメインを跨ぐ機能はプラットフォーム側に寄せた方が良さそう。
20. 19 どこまでを共通化すべきか（1/3） バッチ処理で決済が行われており、決済に失敗した場合に お客様へカード変更依頼メールをお送りする場合がある。 このメールも各一休サービスを介さず、 決済プラットフォームから直接送る案があった。
21. 20 どこまでを共通化すべきか（2/3） カード変更依頼のメールには、 一休サービスしかもっていない予約情報などを出したい。
22. 21 どこまでを共通化すべきか（3/3） 結論、決済プラットフォームからは通知をするのみとし、 メール送信は一休サービスで行うことにした。 ドメイン知識がない場合は処理を移譲したほうが良さそう。
23. 整合性を崩さない
24. 23 ざっくりシステム構成
25. 24 失敗したら自力でロールバック（補償トランザクション）
26. 25 バッチでも整合性をチェック 補償トランザクション失敗の可能性もあるため、 バッチによって二重で整合性を担保。
27. 今後の展開
28. 27 一休サービス 決済プラットフォーム 今後の展開 ふるさと納税 外部サービス 国内宿泊予約 レストラン予約 スパ予約 新サービスA 新サービスB GMO PG PAY.JP 決済業務をプラットフォームで一元管理するため、 既存サービスにも導入を進める予定。 決済予定 決済履歴 会計
29. 28 まとめ • 凝集度の高いマイクロサービスを作る • ドメインを跨ぐ機能はプラットフォームへ • ドメイン知識がなければ処理は移譲する • 補償トランザクションが失敗する可能性も考慮する