一休.comのアーキテクチャ変遷から考えるサービス分割の勘所

techplayの登壇資料です。
https://techplay.jp/event/908123
#ikyu_TP

Transcript

1. 一休.comのアーキテクチャ変遷から考えるサービス分割の勘所
   

   View Slide

2. 2
   自己紹介
   徳武 聡
   システム本部 CTO室 プラットフォーム開発チーム所属
   

   View Slide

3. 3
   今日話すこと
   2015年から実施している一休 .comのサイトのリニューアルの紆余曲折を振り返りつつ、サービス分割について
   学んだことを概観します。
   

   View Slide

4. 4
   一休.com の変遷 … ～ 2015年
   DB
   ASP.NET (VB.NET)
   一休.com
   典型的なモノリス。
   あらゆる処理がひとつのアプリケーションに。
   

   View Slide

5. 5
   一休.com の変遷 … 2015年 ～ 2018年
   DB
   ASP.NET
   (VB.NET)
   一休.com
   ASP.NET(C#)
   認証基盤
   ASP.NET (C#)
   検索API
   ASP.NET(C#)
   カード決済API
   プロダクト開発要求を牽引力にしてWindows系の資産を生かしつつサービス分割。
   

   View Slide

6. 6
   Nuxt.js
   一休.com の変遷 … 2019年 ～ 2023年
   DB
   ASP.NET
   (VB.NET)
   一休.com
   ASP.NET
   (C#)
   Golang
   GraphQL
   Golang
   会員ランクAPI
   Vue +
   Golang
   認証基盤
   プロダクト開発要求を牽引力にしてリプレース/サービス分割をさらに推進。カオス。Golangが主力の言語に。
   ASP.NET (C#)
   検索API
   ASP.NET(C#)
   カード決済API
   

   View Slide

7. 7
   Nuxt.js
   一休.com の変遷 … 2023年～
   DB
   ASP.NET
   (VB.NET)
   一休.com
   Golang
   GraphQL
   Golang
   会員ランクAPI
   ASP.NET (C#)
   検索API
   廃止
   統合
   フロントはNuxtjs、サーバサイドはGolangで引き続きリニューアル中。
   統合
   ASP.NET
   (C#)
   Vue +
   Golang
   認証基盤
   ASP.NET(C#)
   カード決済API
   

   View Slide

8. 8
   まとめると
   ● フェーズ1 (2015年 ～ 2018年) … まず、モノリスの一部をサービス分割し、
   ● フェーズ2 (2018年 ～) … モノリス自体のリニューアルも開始し、
   ● フェーズ3 (2023年 ～) … リニューアルをしつつ、フェーズ 1/2で生まれたカオスを合理化
   

   View Slide

9. 9
   考察① カキヤスサ分割の罠
   ● カキヤスサ分割 … モノリスがレガシーで変更しにくいので、新機能は、スクラッチで開発しやすい技術スタッ
   クで実装！
   ● しかし、モノリスの全面的なリニューアルを最終目標とするなら、この技術的関心事ドリブンな分割は、その目標
   に対するはじめの一歩にはなっていない可能性がある
   。
   LB
   旧実装 新実装
   LB
   旧実装 新実装
   一部の画面/機能を新実装してLBで振り分け
   一部の処理を新実装してマイクロサービス化
   https
   

   View Slide

10. 10
    事例① カキヤスサ分割であいまいになるシステム境界
    ● カキヤスサ分割 + 分割後のオーナーシップ不在によってシステムの役割があいまいに。
    ○ 一休会員を管理するシステムだったのに、なぜかサイトの CMS機能やSEO管理機能が...
    LB
    ASP.NET
    Core
    会員管理システム
    LB
    Classic ASP
    会員管理システム
    Classic ASP
    新機能はASP.NET Coreで作ろう!!
    LB
    ASP.NET
    Core
    会員管理システム ????
    Classic ASP
    管理機能ならあそこが書きやすいゾ。 会員管理と無関係な機能がモリ
    モリ実装されていく …
    だれも.NET Coreのバージョンを管理しない …
    

    View Slide

11. 11
    事例② モノリスリニューアルに追い抜かれる
    ● 検索処理をAPI化したが、モノリス側のリニューアルが進んだ結果、検索だけ別の APIになっている合理性がなく
    なってしまった。
    ○ 分割した側で採用した技術スタックが相対的に古くなってしまった。
    ASP.NET
    (VB.NET)
    一休.com
    LB
    LB
    ASP.NET
    (C#)
    検索API
    ASP.NET
    (VB.NET)
    一休.com
    Solrを導入して検索を速くするゾ。
    Solrクエリの構築は書きやすい
    C#で!
    VB.NETのモノリスからGolang+Nuxtjsへリニューアルする
    !
    Golang
    GraphQL
    Nuxt.js
    ASP.NET
    (VB.NET)
    LB
    ASP.NET
    (C#)
    検索API
    一休.com
    なんで検索APIをつくったんだっけ？
    

    View Slide

12. 12
    事例② モノリスリニューアルに追い抜かれる
    ● 最終的には、検索APIは廃止。Golangの実装に吸収されることに。
    ASP.NET
    (VB.NET)
    一休.com
    Nuxt.js
    Golang
    GraphQL
    ASP.NET (C#)
    検索API
    廃止
    統合
    

    View Slide

13. 13
    まとめ① カキヤスサ分割は書きやすくなる(だけ)
    ● 書きやすくなるので短期的な生産性は上がる。
    ○ 短期的に開発スピードを上げるなら有効なアプローチ。場合によってはベストなアプローチかも。
    ● しかし、それだけ。モノリスの全面的なリニューアルのはじめの一歩にはならない可能性がたかい。
    ○ 書きやすいからこそドメイン境界を無視した開発がされがち。新たなカオスが …
    ● カキヤスサ分割をモノリスの脱却や負債の返却に対する有効なアプローチにするなら、以下のどちらかの問い
    にYESで答えられる必要ある。
    ❖ ゼロから同じサービスを作った場合でもその境界で分割するか？
    ❖ その分割をテコにしてモノリスを置き換えることはできるか？
    ➢ オーナーシップや設計方針は明確か？
    

    View Slide

14. 14
    考察② プロダクトの課題を解決する分割は安定する
    ● レガシー脱却/開発生産性向上、だけでなく、 プロダクトの課題を解決するためのアプローチ
    としてサービス
    分割をすると、
    ○ 安定する分割境界が見つかりやすい。
    ○ スポンサーが付きやすい。
    ■ 大義名分があるので。
    

    View Slide

15. 15
    事例① 認証統合からのインハウスIDaaS誕生
    一休.com
    ログイン
    ログイン
    一休レストラン etc
    ログイン
    会員認証処理が各サービスで実装されている
    まずい。とくにセキュリティ。統合だ。
    ASP.NET
    (C#)
    認証基盤
    2段階認証を導入したい。リニューアル
    !
    Vue + Golang
    認証基盤
    会員が自分の個人情報を管理できる機能を集約中
    ● 技術スタックは変化しているが、分割境界自体は揺らがない。
    ● 開発が進めば進むほど、担うべき役割が明確に。
    

    View Slide

16. 16
    まとめ② 分割の引き金を探る
    ● プロダクトの課題/ビジネスの課題を解決するための開発に乗っかるカタチで分割 /リニューアルができないか、
    眼を光らせておく。
    ○ 技術的関心事ドリブンな分割の罠が避けられる可能性が高い。
    ○ 予算がつきやすい。工数が確保しやすい。
    ○ ビジネスドメインの境界で分割できる可能性が高い。結果として境界が安定しやすい。
    

    View Slide

17. 17
    考察③ 同じ役割のAPIの乱立、APIの粒度のばらつき
    ● 全社横断でみたとき、同じ役割のマイクロサービスが複数出来上がっていた。
    ● 明らかに包含関係のあるドメインを扱う、別々のマイクロサービスが出来上がっていた。
    ● 全体最適できるのが望ましいが、そのための体制を作っておく必要がある。
    

    View Slide

18. 18
    事例① 3つあるカード決済マイクロサービス
    

    View Slide

19. 19
    事例① 3つあるカード決済マイクロサービス
    一休.com
    ASP.NET
    (VB.NET)
    service-card card-payment card-payment2
    一休レストラン
    Classic ASP
    一休SPA
    Python
    決済代行サービス
    ● できること/やりたいことが少しだけ違う、同じ役割のサービスが 3つ。
    ● ボトムアップ開発、局所最適の弊害
    

    View Slide

20. 20
    事例② 小さすぎるサービスの粒度
    ● サービスが担うビジネスドメインに包含関係がある。
    ○ ビジネス的な課題の解決のための開発を引き金にマイクロサービス化を進めると、結果的におきえる。
    ● 最終的には会員ランク APIが独立している必然性がなくなってしまった。
    Golang
    会員ランクAPI
    Vue + Golang
    認証基盤
    ⊇
    一休会員関連の業務処理を担当
    ログインや会員向けの個人情報管理
    UI/各種APIを提供
    インハウスIDaaS
    一休会員ランク関連の業務処理を担当
    キャンペーンの制御のため開発
    会員ランク関連業務は会員関連の業務に包含されると考えるのが自然
    

    View Slide

21. 21
    事例② 小さすぎるサービスの粒度
    ● 分割だけでなく統合も意識する。
    Golang
    会員ランクAPI
    Vue + Golang
    認証基盤
    もともとASP.NETで実装していたが、Golangにリプレース中。
    実装系が揃ったので統合が容易に。
    統合へ
    

    View Slide

22. 22
    まとめ③ 自律と統制のバランス
    ● プロダクト単位で局所最適の弊害を避けるには、そのための体制を作り統制を取る必要がありそう。
    ● 一方で、独立したサービスを作るメリットは、そのような統制が開発の足枷になってしまうことを避けられる点
    にあるのも事実。
    ● 自律と統制のバランスを取る必要がある。
    ● 一休は、全社で使うプラットフォームをマイクロサービスとして作る & 責任を持つ開発チームを置く、という体
    制に。
    ○ 各プロダクト内では、細かくサービス分割をしない、という方向になりつつある。
    

    View Slide

23. 23
    全体のまとめ
    ● サービス分割は事前に計画しても、その通りに進めるのは難しい。
    ○ 開発現場は常にさまざまな方向から動機付けされている。
    ○ 開発方針を決めるパラメータは無数にある。
    ● 分割のきっかけ/動機を逃さない。
    ○ プロダクト/ビジネスの課題解決に乗っかってリニューアル /分割ができるのが一番。
    ■ ビジネスドメインの境界で分割できる可能性が高い。
    ○ カキヤスサ分割の罠に要注意！
    ● 局所最適の弊害を避けるには、そうならないための体制 /チーム/方針を作り統制する必要がある。
    

    View Slide

24. 24
    一休プラットフォーム構想について
    ● 新規サービスを立ち上げるときに必要になる、一休の全社横断の機能群をマイクロサービス化する。これに
    よって、、、
    ○ 新規サービスの立ち上げのときのエンジニアリング工数を削減し、より高速に事業を立ち上げられる
    ようにする。
    ○ これらのマイクロサービス群をレガシー脱却の武器として活用できるようになる。
    ■ モノリスの新技術スタックの塗り替えを進めつつ、共通処理は一休プラットフォームで置き換え
    る。
    ○ 全サービスの業務処理の共通化 /一元管理化を実現し運用コストを下げる。
    

    View Slide

25. 25
    一休プラットフォーム構想について
    ● 新規サービスを立ち上げるときに必要になる、一休の全社横断の機能群をマイクロサービス化する。これに
    よって、、、
    ○ 新規サービスの立ち上げのときのエンジニアリング工数を削減し、より高速に事業を立ち上げられる
    ようにする。
    ○ これらのマイクロサービス群をレガシー脱却の武器として活用できるようになる。
    ■ モノリスの新技術スタックの塗り替えを進めつつ、共通処理は一休プラットフォームで置き換え
    る。
    ○ 全サービスの業務処理の共通化 /一元管理化を実現し運用コストを下げる。
    レガシー脱却も！
    ビジネスの開発要求を牽引力に！
    一休プラットフォーム
    Golang
    一休ポイント
    Golang
    決済
    Golang
    認証/会員
    

    View Slide