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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

技術選定

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

境界線をどこに引くか

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

整合性を崩さない

Slide 24

Slide 24 text

23 ざっくりシステム構成

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

今後の展開

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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