0 歴史あるプロダクトにマイクロサービスを導⼊するプロセス 2024/09/18

1 ⾃⼰紹介 - 2021年2⽉に⼀休に⼊社、⼀休.comの開発に 従事 - ⼀休.com ふるさと納税の新規開発に参加 - プロダクトを離れ、マイクロサービス担当と して⼀休ポイントサービス∕会員サービスの 開発、導⼊に携わっています 菊地 彩夏 Kikuchi Ayaka

2 本⽇のアジェンダ 1. プロダクトの歴史から⾒る⼀休の課題 2. 既存プロダクトにマイクロサービスを導⼊するプロセス 3. マイクロサービス導⼊の事例紹介 4. まとめ

3 1. プロダクトの歴史から⾒る⼀休の課題

4 プロダクトの歴史から⾒る⼀休の課題 2000 2006 2011 会員 ポイント 決済 会員 ポイント 決済 会員 ポイント 決済 共通的な機能が各プロダクトにべた書き ⇒プロダクトエンジニアの範疇が広い 全プロダクトが共通データにアクセス ⇒１つのプロダクトのミスが全プロダクト に波及するリスクが⾼まる

5 プロダクトの歴史から⾒る⼀休の課題 2000 2006 2011 2022 2024 会員 ポイント 決済 会員 ポイント 決済 会員 ポイント 決済 共通的な機能が各プロダクトにべた書き ⇒プロダクトエンジニアの範疇が広い 全プロダクトが共通データにアクセス ⇒１つのプロダクトのミスが全プロダクト に波及するリスクが⾼まる 新規プロダクト開発のたびに 負債が増えていく負のループへ ⇒プロダクト⽴ち上げコストが⾼い体質 ⇒共通データにアクセスするという  インフラ的制約が課される 2023

6 会員‧ポイント‧決済のマイクロサービス化へ 2000 2006 2011 2022 2024 会員サービス 2023 ポイントサービス 決済サービス

7 会員‧ポイント‧決済のマイクロサービス化へ 2000 2006 2011 2022 2024        会員サービス 2023       ポイントサービス        決済サービス 2022〜 新規プロダクト開発について マイクロサービス導⼊が完了 プロダクト⽴ち上げ時の ⾼コスト体質が改善できました 済

8 会員‧ポイント‧決済のマイクロサービス化へ 2000 2006 2011 2022 2024               会員サービス 2023              ポイントサービス               決済サービス 次は既存プロダクトに マイクロサービスを導⼊へ 今⽇は⼀休.com レストランに ポイントサービス、会員サービスを 導⼊したときの話をしたいと思います！

9 2. 既存プロダクトにマイクロサービスを導⼊するプロセス

10 ⼀休.comレストランへのマイクロサービス導⼊に⽴ちはだかった課題 過去の機能が削除されておらず マイクロサービスの置き換え対象の特定が 困難 導⼊の前に デッドコード削除‧ 既存実装の調査 を⾏うことに

11 既存プロダクトにマイクロサービスを導⼊するプロセス STEP １．デッドコード削除‧現⾏仕様の調査 - デッドコードを削除（2か⽉で10機能/4,700⾏削除） - コードベースが⾒通しやすくなった - 実際に⼿を動かしたことで、実装のキャッチアップがスムーズになった

12 既存プロダクトにマイクロサービスを導⼊するプロセス STEP １．デッドコード削除‧現⾏仕様の調査 - デッドコードを削除（2か⽉で10機能/4,700⾏削除） - コードベースが⾒通しやすくなった - 実際に⼿を動かしたことで、実装のキャッチアップがスムーズになった - マイクロサービスに切り替える実装に他プロダクトとの仕様ずれを発⾒した - 調査の結果、不必要な仕様差分であることがわかった - カスタマーサポート部に確認したところ、プロダクト間の仕様差分をふまえて    問い合わせ対応をしているため業務が煩雑になっている状態だった - プロダクト間の仕様ずれがシステム外の業務負荷をあげてしまっていた

13 既存プロダクトにマイクロサービスを導⼊するプロセス STEP １．デッドコード削除‧現⾏仕様の調査 - デッドコードを削除（2か⽉で10機能/4,700⾏削除） - マイクロサービスに切り替える実装に他プロダクトとの仕様ずれを発⾒した - 調査の結果、不必要な仕様差分であることがわかった - カスタマーサポート部に確認したところ、プロダクト間の仕様差分を把握したうえで 問い合わせ対応をしているため業務がややこしくなっている状態だった ⼀休では、既存プロダクトにマイクロサービスを導⼊することで 「仕様の共通化によるシステム外の業務負荷（認知コスト）の解消」 という価値を得ることができた - 関係各部署（カスタマーサポート部、営業部）と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった STEP ２．マイクロサービス化部分の不必要な仕様ずれの調整 - 関係者（カスタマーサポート部、営業部）と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった

14 既存プロダクトにマイクロサービスを導⼊するプロセス STEP １．デッドコード削除‧現⾏仕様の調査 - デッドコードを削除（2か⽉で10機能/4,700⾏削除） - マイクロサービスに切り替える実装に他プロダクトとの仕様ずれを発⾒した - 調査の結果、不必要な仕様差分であることがわかった - カスタマーサポート部に確認したところ、プロダクト間の仕様差分を把握したうえで 問い合わせ対応をしているため業務がややこしくなっている状態だった ⼀休では、既存プロダクトにマイクロサービスを導⼊することで 「仕様の共通化によるシステム外の業務負荷（認知コスト）の解消」 という価値を得ることができた - 関係各部署（カスタマーサポート部、営業部）と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった STEP ２．マイクロサービス化部分の不必要な仕様ずれの調整 - 関係各部署（カスタマーサポート部、営業部）と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった 当初想定していなかった成果 ⼀休では、既存プロダクトにマイクロサービスを導⼊することで 「仕様の共通化によるシステム外の認知コストの削減」という 価値を得ることができた

15 既存プロダクトにマイクロサービスを導⼊するプロセス STEP １．デッドコード削除‧現⾏仕様の調査 - デッドコードを削除（2か⽉で10機能/4,700⾏削除） - マイクロサービスに切り替える実装に他プロダクトとの仕様ずれを発⾒した - 調査の結果、不必要な仕様差分であることがわかった - カスタマーサポート部に確認したところ、プロダクト間の仕様差分を把握したうえで 問い合わせ対応をしているため業務がややこしくなっている状態だった ⼀休では、既存プロダクトにマイクロサービスを導⼊することで 「仕様の共通化によるシステム外の業務負荷（認知コスト）の解消」 という価値を得ることができた - 関係各部署（カスタマーサポート部、営業部）と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった STEP ２．マイクロサービス化部分の不必要な仕様ずれの調整 - 関係各部署（カスタマーサポート部、営業部）と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった 当初想定していなかった成果 ⼀休では、既存プロダクトにマイクロサービスを導⼊することで 「仕様の共通化によるシステム外の認知コストの削減」という 価値を得ることができた - 関係各部署（カスタマーサポート部、営業部）と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった STEP ３．マイクロサービス導入 - マイクロサービス化に伴って、整合性担保の仕組み（⾮同期連携）を実装

16 ３. マイクロサービス導⼊の事例紹介

17 ⼀休.com レストランからマイクロサービスの呼び出し事例 予約メイン処理 Amazon EKS 予約時に、 ⼀休ポイントを100ポイント獲得 対象ユーザに ⼀休ポイントを付与 予約キャンセル時に、 ⼀休ポイントの獲得を取消 ⼀休ポイント付与の 取消 ポイントサービス Cloud Run

18 ⼀休.com レストランからマイクロサービスの呼び出し事例 予約メイン処理 Amazon EKS ポイントサービス Cloud Run 同期的に呼び出すと - ユーザへのレスポンスに時間がかかってしまう - ポイントサービスで障害が起きると予約処理が停⽌してしまう

19 マイクロサービスとの⾮同期連携のアーキテクチャ キューイング サービス Cloud Tasks ワーカー Cloud Run マイクロサービス Cloud Run 予約メイン処理 Amazon EKS ※将来的に  Google Cloudに移⾏予定 マイクロサービスの呼び出し処理を 予約メイン処理から切り出して 成功するまでリトライする仕組みに 予約キャンセル時に ポイント獲得の取消タスクを エンキュー ポイントマイクロサービスに リクエストする ⼀休ポイント付与の取消

20 マイクロサービスとの⾮同期連携のアーキテクチャ キューイング サービス Cloud Tasks ワーカー Cloud Run マイクロサービス Cloud Run 予約メイン処理 Amazon EKS ⾮同期連携にしたことの課題（要件） - 発⽣した順番にイベントを処理したい - 単⼀予約に対しN回の操作が 起 こりうる - マイクロサービス側に履歴を持ちたい データベースで予約‧ワーカーイベント を管理 予約 イベント ワーカー イベント Write Write Read

21 マイクロサービスとの⾮同期連携のアーキテクチャ キューイング サービス Cloud Tasks ワーカー Cloud Run マイクロサービス Cloud Run 予約メイン処理 Amazon EKS （id: 1, history_no: 1, event_type: BOOKED, point: false) （id: 1, history_no: 2, event_type: MODIFIED, point: true) （id: 1, history_no: 3, event_type: CANCELED, point: true) （id: 2, history_no: 1, event_type: BOOKED, point: true) 対象のid（予約）に対して 予約イベントと ワーカーイベントを⽐較して 未処理のものを順番に実⾏する 予約 イベント ワーカー イベント （id: 2, history_no: 1) history_no:2 history_no:3 かなり堅く作ったので 順序性を完全に制御すべきか 個別のケースで検討が必要

22 ⾮同期処理を他のマイクロサービス導⼊時に再利⽤する 予約メイン処理 Amazon EKS ポイント キュー Cloud Tasks ポイント ワーカー Cloud Run ポイントサービス Cloud Run 会員 キュー Cloud Tasks 会員 ワーカー Cloud Run  会員サービス Cloud Run 予約メイン処理に ⼤きく修正を加えずに マイクロサービス 連携を 追加できた

23 まとめ‧既存プロダクトにマイクロサービスを導⼊して - ⼀休では既存プロダクトにマイクロサービスを導⼊することで、 システムのリファクタリングに留まらず業務全体の最適化につながった - 実装に⼊る前に、泥臭く調査‧各関係者と調整するプロセスを踏むことで     プラスオンの成果を得ることができました - 実装⾯では、⾮同期処理にしたことでイベントの順番のハンドリングを どのように担保するべきか⾮常に難しかった - 個別のケースで求められる要件が違ってくると思うので 都度⾒なおしていきたい

24 ありがとうございました！