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

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

Transcript

1. 一休.comのアーキテクチャ変遷から考えるサービス分割の勘所
2. 2 自己紹介 徳武 聡 システム本部 CTO室 プラットフォーム開発チーム所属
3. 3 今日話すこと 2015年から実施している一休 .comのサイトのリニューアルの紆余曲折を振り返りつつ、サービス分割について 学んだことを概観します。
4. 4 一休.com の変遷 … ～ 2015年 DB ASP.NET (VB.NET) 一休.com 典型的なモノリス。 あらゆる処理がひとつのアプリケーションに。
5. 5 一休.com の変遷 … 2015年 ～ 2018年 DB ASP.NET (VB.NET) 一休.com ASP.NET(C#) 認証基盤 ASP.NET (C#) 検索API ASP.NET(C#) カード決済API プロダクト開発要求を牽引力にしてWindows系の資産を生かしつつサービス分割。
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
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
8. 8 まとめると • フェーズ1 (2015年 ～ 2018年) … まず、モノリスの一部をサービス分割し、 • フェーズ2 (2018年 ～) … モノリス自体のリニューアルも開始し、 • フェーズ3 (2023年 ～) … リニューアルをしつつ、フェーズ 1/2で生まれたカオスを合理化
9. 9 考察① カキヤスサ分割の罠 • カキヤスサ分割 … モノリスがレガシーで変更しにくいので、新機能は、スクラッチで開発しやすい技術スタッ クで実装！ • しかし、モノリスの全面的なリニューアルを最終目標とするなら、この技術的関心事ドリブンな分割は、その目標 に対するはじめの一歩にはなっていない可能性がある 。 LB 旧実装 新実装 LB 旧実装 新実装 一部の画面/機能を新実装してLBで振り分け 一部の処理を新実装してマイクロサービス化 https
10. 10 事例① カキヤスサ分割であいまいになるシステム境界 • カキヤスサ分割 + 分割後のオーナーシップ不在によってシステムの役割があいまいに。 ◦ 一休会員を管理するシステムだったのに、なぜかサイトの CMS機能やSEO管理機能が... LB ASP.NET Core 会員管理システム LB Classic ASP 会員管理システム Classic ASP 新機能はASP.NET Coreで作ろう!! LB ASP.NET Core 会員管理システム ???? Classic ASP 管理機能ならあそこが書きやすいゾ。 会員管理と無関係な機能がモリ モリ実装されていく … だれも.NET Coreのバージョンを管理しない …
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をつくったんだっけ？
12. 12 事例② モノリスリニューアルに追い抜かれる • 最終的には、検索APIは廃止。Golangの実装に吸収されることに。 ASP.NET (VB.NET) 一休.com Nuxt.js Golang GraphQL ASP.NET (C#) 検索API 廃止 統合
13. 13 まとめ① カキヤスサ分割は書きやすくなる(だけ) • 書きやすくなるので短期的な生産性は上がる。 ◦ 短期的に開発スピードを上げるなら有効なアプローチ。場合によってはベストなアプローチかも。 • しかし、それだけ。モノリスの全面的なリニューアルのはじめの一歩にはならない可能性がたかい。 ◦ 書きやすいからこそドメイン境界を無視した開発がされがち。新たなカオスが … • カキヤスサ分割をモノリスの脱却や負債の返却に対する有効なアプローチにするなら、以下のどちらかの問い にYESで答えられる必要ある。 ❖ ゼロから同じサービスを作った場合でもその境界で分割するか？ ❖ その分割をテコにしてモノリスを置き換えることはできるか？ ➢ オーナーシップや設計方針は明確か？
14. 14 考察② プロダクトの課題を解決する分割は安定する • レガシー脱却/開発生産性向上、だけでなく、 プロダクトの課題を解決するためのアプローチ としてサービス 分割をすると、 ◦ 安定する分割境界が見つかりやすい。 ◦ スポンサーが付きやすい。 ▪ 大義名分があるので。
15. 15 事例① 認証統合からのインハウスIDaaS誕生 一休.com ログイン ログイン 一休レストラン etc ログイン 会員認証処理が各サービスで実装されている まずい。とくにセキュリティ。統合だ。 ASP.NET (C#) 認証基盤 2段階認証を導入したい。リニューアル ! Vue + Golang 認証基盤 会員が自分の個人情報を管理できる機能を集約中 • 技術スタックは変化しているが、分割境界自体は揺らがない。 • 開発が進めば進むほど、担うべき役割が明確に。
16. 16 まとめ② 分割の引き金を探る • プロダクトの課題/ビジネスの課題を解決するための開発に乗っかるカタチで分割 /リニューアルができないか、 眼を光らせておく。 ◦ 技術的関心事ドリブンな分割の罠が避けられる可能性が高い。 ◦ 予算がつきやすい。工数が確保しやすい。 ◦ ビジネスドメインの境界で分割できる可能性が高い。結果として境界が安定しやすい。
17. 17 考察③ 同じ役割のAPIの乱立、APIの粒度のばらつき • 全社横断でみたとき、同じ役割のマイクロサービスが複数出来上がっていた。 • 明らかに包含関係のあるドメインを扱う、別々のマイクロサービスが出来上がっていた。 • 全体最適できるのが望ましいが、そのための体制を作っておく必要がある。
18. 18 事例① 3つあるカード決済マイクロサービス
19. 19 事例① 3つあるカード決済マイクロサービス 一休.com ASP.NET (VB.NET) service-card card-payment card-payment2 一休レストラン Classic ASP 一休SPA Python 決済代行サービス • できること/やりたいことが少しだけ違う、同じ役割のサービスが 3つ。 • ボトムアップ開発、局所最適の弊害
20. 20 事例② 小さすぎるサービスの粒度 • サービスが担うビジネスドメインに包含関係がある。 ◦ ビジネス的な課題の解決のための開発を引き金にマイクロサービス化を進めると、結果的におきえる。 • 最終的には会員ランク APIが独立している必然性がなくなってしまった。 Golang 会員ランクAPI Vue + Golang 認証基盤 ⊇ 一休会員関連の業務処理を担当 ログインや会員向けの個人情報管理 UI/各種APIを提供 インハウスIDaaS 一休会員ランク関連の業務処理を担当 キャンペーンの制御のため開発 会員ランク関連業務は会員関連の業務に包含されると考えるのが自然
21. 21 事例② 小さすぎるサービスの粒度 • 分割だけでなく統合も意識する。 Golang 会員ランクAPI Vue + Golang 認証基盤 もともとASP.NETで実装していたが、Golangにリプレース中。 実装系が揃ったので統合が容易に。 統合へ
22. 22 まとめ③ 自律と統制のバランス • プロダクト単位で局所最適の弊害を避けるには、そのための体制を作り統制を取る必要がありそう。 • 一方で、独立したサービスを作るメリットは、そのような統制が開発の足枷になってしまうことを避けられる点 にあるのも事実。 • 自律と統制のバランスを取る必要がある。 • 一休は、全社で使うプラットフォームをマイクロサービスとして作る & 責任を持つ開発チームを置く、という体 制に。 ◦ 各プロダクト内では、細かくサービス分割をしない、という方向になりつつある。
23. 23 全体のまとめ • サービス分割は事前に計画しても、その通りに進めるのは難しい。 ◦ 開発現場は常にさまざまな方向から動機付けされている。 ◦ 開発方針を決めるパラメータは無数にある。 • 分割のきっかけ/動機を逃さない。 ◦ プロダクト/ビジネスの課題解決に乗っかってリニューアル /分割ができるのが一番。 ▪ ビジネスドメインの境界で分割できる可能性が高い。 ◦ カキヤスサ分割の罠に要注意！ • 局所最適の弊害を避けるには、そうならないための体制 /チーム/方針を作り統制する必要がある。
24. 24 一休プラットフォーム構想について • 新規サービスを立ち上げるときに必要になる、一休の全社横断の機能群をマイクロサービス化する。これに よって、、、 ◦ 新規サービスの立ち上げのときのエンジニアリング工数を削減し、より高速に事業を立ち上げられる ようにする。 ◦ これらのマイクロサービス群をレガシー脱却の武器として活用できるようになる。 ▪ モノリスの新技術スタックの塗り替えを進めつつ、共通処理は一休プラットフォームで置き換え る。 ◦ 全サービスの業務処理の共通化 /一元管理化を実現し運用コストを下げる。
25. 25 一休プラットフォーム構想について • 新規サービスを立ち上げるときに必要になる、一休の全社横断の機能群をマイクロサービス化する。これに よって、、、 ◦ 新規サービスの立ち上げのときのエンジニアリング工数を削減し、より高速に事業を立ち上げられる ようにする。 ◦ これらのマイクロサービス群をレガシー脱却の武器として活用できるようになる。 ▪ モノリスの新技術スタックの塗り替えを進めつつ、共通処理は一休プラットフォームで置き換え る。 ◦ 全サービスの業務処理の共通化 /一元管理化を実現し運用コストを下げる。 レガシー脱却も！ ビジネスの開発要求を牽引力に！ 一休プラットフォーム Golang 一休ポイント Golang 決済 Golang 認証/会員