Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

歴史あるプロダクトにマイクロサービスを導入するプロセス

kikuchia
September 18, 2024

 歴史あるプロダクトにマイクロサービスを導入するプロセス

一休×AEON 事業会社のサービスを支える基盤開発トーク の登壇資料です
https://ikyu.connpass.com/event/327095/

kikuchia

September 18, 2024
Tweet

Other Decks in Technology

Transcript

  1. 4 プロダクトの歴史から⾒る⼀休の課題 2000 2006 2011 会員 ポイント 決済 会員 ポイント

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

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

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

                  決済サービス 次は既存プロダクトに マイクロサービスを導⼊へ 今⽇は⼀休.com レストランに ポイントサービス、会員サービスを 導⼊したときの話をしたいと思います!
  5. 12 既存プロダクトにマイクロサービスを導⼊するプロセス STEP 1.デッドコード削除‧現⾏仕様の調査 - デッドコードを削除(2か⽉で10機能/4,700⾏削除) - コードベースが⾒通しやすくなった - 実際に⼿を動かしたことで、実装のキャッチアップがスムーズになった

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

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

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

    - カスタマーサポート部に確認したところ、プロダクト間の仕様差分を把握したうえで 問い合わせ対応をしているため業務がややこしくなっている状態だった ⼀休では、既存プロダクトにマイクロサービスを導⼊することで 「仕様の共通化によるシステム外の業務負荷(認知コスト)の解消」 という価値を得ることができた - 関係各部署(カスタマーサポート部、営業部)と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった STEP 2.マイクロサービス化部分の不必要な仕様ずれの調整 - 関係各部署(カスタマーサポート部、営業部)と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった 当初想定していなかった成果 ⼀休では、既存プロダクトにマイクロサービスを導⼊することで 「仕様の共通化によるシステム外の認知コストの削減」という 価値を得ることができた - 関係各部署(カスタマーサポート部、営業部)と調整して、共通的な仕様に変更した ⇒システム外で発⽣していた認知コストの削減につながった STEP 3.マイクロサービス導入 - マイクロサービス化に伴って、整合性担保の仕組み(⾮同期連携)を実装
  9. 18 ⼀休.com レストランからマイクロサービスの呼び出し事例 予約メイン処理 Amazon EKS ポイントサービス Cloud Run 同期的に呼び出すと

    - ユーザへのレスポンスに時間がかかってしまう - ポイントサービスで障害が起きると予約処理が停⽌してしまう
  10. 19 マイクロサービスとの⾮同期連携のアーキテクチャ キューイング サービス Cloud Tasks ワーカー Cloud Run マイクロサービス

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

    Cloud Run 予約メイン処理 Amazon EKS ⾮同期連携にしたことの課題(要件) - 発⽣した順番にイベントを処理したい - 単⼀予約に対しN回の操作が 起 こりうる - マイクロサービス側に履歴を持ちたい データベースで予約‧ワーカーイベント を管理 予約 イベント ワーカー イベント Write Write Read
  12. 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 かなり堅く作ったので 順序性を完全に制御すべきか 個別のケースで検討が必要
  13. 22 ⾮同期処理を他のマイクロサービス導⼊時に再利⽤する 予約メイン処理 Amazon EKS ポイント キュー Cloud Tasks ポイント

    ワーカー Cloud Run ポイントサービス Cloud Run 会員 キュー Cloud Tasks 会員 ワーカー Cloud Run  会員サービス Cloud Run 予約メイン処理に ⼤きく修正を加えずに マイクロサービス 連携を 追加できた