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