Microservices@microservice Meetup vol.6

Microservice meetup vol6

1. Microservices @microservice meetup vol.6 Jan.18.2018 Takahiro Fujii Travel Product Dept. Rakuten, Inc.
2. 2 About me Takahiro Fujii@taka_ft Travel Product Development Section UI Platform Group Booking Team / Smart Device Team Assistant Manager 楽天トラベルのサービスを開発しています。 去年の勉強会にはブロク書く枠で参加させて頂きました。 http://takahiro-fujii.hatenablog.com/entry/2017/04/01/182855 http://takahiro-fujii.hatenablog.com/entry/2017/04/03/225809 FiNCの名渕さん(元同僚)
3. 3 About me Takahiro Fujii@taka_ft Travel Product Development Section UI Platform Group Booking Team / Smart Device Team Assistant Manager BackEnd + Front(Java) Front/BackEnd APP + Front + backend 2014 2017/6 now Develop start-up system with small department (International development dep) Focus on web API development. (e.g booking api, restful apis, and so on.) Booking Platform Development Java / Spring Consider entire architecture Manage smart device team Development new web app by SPA React / Swift / Java (Kotlin!) 2016/7 Developed 1st SPA in our department as a front-end engineer. presentation
4. 4 About me Takahiro Fujii@taka_ft Travel Product Development Section UI Platform Group Booking Team / Smart Device Team Assistant Manager Phase2 Phase1 Phase3 2014 2017/6 now Develop start-up system with small department (International development dep) Focus on web API development. (e.g booking api, restful apis, and so on.) Booking Platform Development Java / Spring Consider entire architecture Manage smart device team Development new web app by SPA React / Swift / Java (Kotlin!) 2016/7 Developed 1st SPA in our department as a front-end engineer. presentation
5. 5 Rakuten Travel 本⽇は、楽天トラベルのシステム・開発についてお話しさせて頂きます。楽天では、各サービス(カンパ ニー毎)でシステム設計が異なります。本⽇は、楽天トラベルとMicroserviceの関連についてお話しさせ て頂きます。
6. 6 Services(簡略化しています) 楽天トラベル (Consumer) Extranet (管理画⾯) In-house (社内システム) WEB Native APP API (100+) Distribution (API連携) others Services UI Backend
7. 7 Scale Over 150+ Apps
8. 8 Scale Over 150+ Apps 150+ Engineers ⽐較的⼤きな組織です
9. 9 Agenda(3つのフェーズに分けて話していきます) Phase2 Phase1 Phase3 Engineer Back-End Engineer Assistant Manager Front-End Engineer Assistant Manager ちょっとMicroservice? っぽくなってきた時期 Roll そして今 2010 - 2013 2014 - 2017 2017 - ⼤体の時期 ⾊々な新規アプリを ガシガシ作っていた時期
10. 10 今⽇話すこと 楽天トラベルとmicroservice の関係についてお話しながら、 僕の視点から、 BackEnd側から⾒えたmicroservice FrontEnd側から⾒えたmicroservice についてお話させて頂きます
11. 11 Phase1 ⾊々な新規アプリを ガシガシ作っていた時期
12. 12 Rakuten Travel まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。 2010年 : 海外ホテル関連のシステムを開発・運⽤(たくさんの新しいアプリもできる) Monolithicなアプリケーションにどんどん機能を追加していって、 アプリケーションが持つ機能が増えていく。 Huge Monolithic App Phase1
13. 13 Rakuten Travel 海外ホテル Phase1 まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。 2010年 : 海外ホテル関連のシステムを開発・運⽤(たくさんの新しいアプリもできる) Monolithicなアプリケーションにどんどん機能を追加していって、 アプリケーションが持つ機能が増えていく。
14. 14 Rakuten Travel Domestic Hotel Overseas Hotel Airticket Rent a car Bus DP (Hotel + Air) Extranet Multilingual Inbound In-house API Alliance Accounting Inbound Etc… Phase1 沢⼭の⾊々なサービスができたり、機能追加されていった。
15. 15 Rakuten Travel 2012年 : 肥⼤化してきたappを、機能別に切り出す✂ Monolithic App Monolithic App Monolithic App Phase1
16. 16 Rakuten Travel 2012年 : 肥⼤化してきたappを、機能別に切り出す✂ ホテルページ (海外ホテル) 検索 (海外ホテル) 予約 (海外ホテル) Phase1
17. 17 Rakuten Travel 2012年〜 さらにそこからAPI化してFrontとBackendを分離しはじめる。 この時点ではどのAPIもかなり⼤きく、各クライアントに最適化されたAPIという感じ FrontEnd App FrontEnd App FronEnd App BackEnd App BackEnd App BackEnd App Phase1
18. 18 Rakuten Travel まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。 2012年〜 API化してFrontとBackendを分離しだす ホテル 検索 予約 ホテルAPI 検索API 予約API Phase1
19. 19 Phase2 そして、少しずつ Microserviceっぽくなってきた時期
20. 20 分割と再構築 2013,4年~ ・複数のAPIから共通のドメインやリソースをAPIに切り出し始める API1 (予約系) API2 (予約系) Hoge API 在庫API 通知API 予約API 決済(他部署) Phase2 Phase1
21. 21 分割と再構築 2014年~ ・この時期に⼀度Restfulに寄せようとした流れがあった。 ・ResourceやDomainについて考えると、「あ、これはRestでいける」というものもそこそこあり、 Restful(もしくは準ずる)APIが多く作られた。Ref ) 楽天トラベルとSpring API1 (予約系) API2 (予約系) Hoge Rest(ful) API Rest(ful) API Rest(ful) API? Rest(ful) API? Phase2 Phase1
22. 22 RESTについて ・APIのI/F決定にかける時間が⻑くなった ・全てをRestfulによせようとすると、APIの呼び出 し回数が必要以上に増えた ・どこまでRestに寄り添うか問題 考えさせられた点 良かった点 ・巨⼤なAPIたちからRest APIが抽出され、整 理された ・どうにかしてRestfulに出来ないのか？(とい うことについて考えることは⾟いこともあった が)シンプルなAPI設計をまずは考えるという⾵ ⼟を根付かせてくれた ・ある程度の規模の組織において、APIの粒度 に統⼀性がもたらされた ・沢⼭の先⼈の知恵 Phase2 Web API設計のこれまでとこれから よかった
23. 23 分割と再構築 2014年~ ・この時期に⼀度Restfulに寄せようとした流れがあった。 ・ResourceやDomainについて考えると、「あ、これはRestでいける」というものもそこそこあり、 Restful(もしくは準ずる)APIが多く作られた。Ref ) 楽天トラベルとSpring API1 (予約系) API2 (予約系) Hoge Rest(ful) API Rest(ful) API Rest(ful) API? Rest(ful) API? Phase2 Phase1
24. 24 これって、microserviceっぽい？ Phase2 予約Front 1 予約Front 2 Front3 予約API 1 予約API 2 Front3 通知API 決済API ホテルAPI BackEnd Generic API … … … ※この時期で総数100+位
25. 25 これって、microserviceっぽい？ Phase2 予約Front 1 予約Front 2 Front3 予約API 1 予約API 2 Front3 通知API 決済API ホテルAPI BackEnd Generic API … … … ※この時期で総数100+位 それっぽくなってきた？
26. 26 これって、microserviceっぽい？ Phase2 予約Front 1 予約Front 2 Front3 予約API 1 予約API 2 Front3 通知API 決済API ホテルAPI BackEnd Generic API … … … ※この時期で総数100+位
27. 27 課題1 : 本当に分けないといけない？ 国内 ホテル 海外 ホテル 航空券 バス レンタ カー 予約する 予約するという⾏為は共通なはずなのに Phase2 予約API 1 予約API 2 ⽴ち⽌まって考えると、 本当に2つのAPIが必要なのかという疑問が… なんで分ける必要あったんだっけ…
28. 28 Phase2 課題2 : 理想と現実 FrontEnd App 汎⽤化された 使いやすいAPI
29. 29 Phase2 課題2 : 理想と現実 画⾯専⽤のロ ジックが 沢⼭うまった API FrontEnd App
30. 30 Phase2 ・この頃はclient毎の処理を⽤意するのが⾟かった ・なんとかしてもっと汎⽤的な処理を定義して、BackEnd側としては汎⽤的なAPI のみを提供する形にできないものか ・画⾯毎に最適化されたapiを本当に作る必要があるのか 画⾯専⽤のロ ジックが 沢⼭うまった API FrontEnd App 課題2 : 理想と現実
31. 31 気づいたら・・・ Phase2
32. 32 メンテ⼤変 Orchestration API※ボトルネックになっている感 Phase2 ※ここではUIからの⼀時受けをしているAPIのことを意図しています
33. 33 本当に分けないといけない？ Phase2 予約Front 1 予約Front 2 Front3 予約API 1 予約API 2 Front3 通知API 決済API ホテルAPI BackEnd Generic API … ・Front1ではポイントのこの機能が使えるのに、 Front2ではこの機能が使えないとかが発⽣(本当は そうしたくないのに) ・ある機能を修正する際に、予約API1にだけ修正 が⾏われて気づかぬ間に若⼲の仕様差分が⽣まれる ・機能の挙動がFront1,Front2で微妙に違う ・Front1にだけ影響がある修正なはずなのに、なぜ か根っこの⽅にあるAPIも直さないといけない ・ユーザは同じサイト(楽天、楽天トラベル)を回遊 しているはずが、UIがガラッと変わったり、微妙な 差分に悩まされたりする ・ビジネスロジックの責任範囲がfront/back-end間 で曖昧なので、案件ごとに影響範囲を正確に特定す るのに時間がかかる(本当はもっと複雑な図) ・ドメインロジックが散らばっていて、複数のアプ リケーションが同じドメインに対してアクションし ている (微妙に異なる) ⼀緒でいいはずの UI Component (微妙に異なる) 重複した Business Logic 特定のクライアント⽤の ビジネスロジックに 侵⾷しているGeneric API FrontEnd / Backendの実装の Responsibilityがあいまい
34. 34 あふれる改善点 このころやっていたAPI間の改善は 楽天トラベルとSpring をご覧下さい Phase2
35. 35 その他の問題(抜粋) Phase2
36. 36 歪んでいたGlobal対応 国内 海外 ※(⽇本以外) ・⼀部のAPIだけ多⾔語されていたり、されていな かったり。(clientからすると使いづらい) ・⾔語だけではなく、キャンセルポリシー、税⾦、 などなどなどが、⽇本よりの設計になっていて、海 外クライアントから⾮常に使いづらいものに ・海外クライアントがシステム連携するには使いづ らいAPIインターフェース (統⼀されていなかった) 多⾔語化へのアプローチ 世界基準ではない(主に強く⽇本の影響をうけた) データフォーマット、ドメインを無理やり使う
37. 37 各UIアプリケーション/外部向けAPIの機能のずれ Web Native App ・WebとAppで仕様がかなりごちゃごちゃに。 ・どちらも分かる⼈がいなくなり、独⾃進化を遂げ 始める ・Webが使うAPIと外部公開/連携⽤APIで違う仕様 があったりするが、ふと距離をおいて考えると、 「あれ、なんで違う必要あるんだっけ」っていう漢 字の違い ・なぜかWebに出来ないことが外部公開⽤のAPIか らだと出来たり、Webからじゃないと出来ないこと があったりしてバグを⽣んだりする ・アプリの修正範囲の洗い出しが⾯倒 提供している機能が(無駄に)違う WebとNative Appで実装の責任範囲が異なる 外部公 開/連携 ⽤API User(Consumer)
38. 38 質が低かった / だんだんと品質が下がっていった microservice
39. 39 Microservice
40. 40 改善しよう
41. 今取り組んでいるMicroservices @microservice meetup vol.6 Jan.18.2018 Takahiro Fujii Travel Product Dept. Rakuten, Inc. Phase3
42. 42 Services(簡略化しています) 楽天トラベル (Consumer) Extranet In-house WEB Native APP API (100+) Distribution (API連携) others Services UI Backend Phase3
43. 43 APP + Front + backend 2017/6 now 僕はUI Platform Groupに。 (FrontEndよりの⼈に) Phase3
44. 44 Architecture(簡略化されています) UI Distribution API API Gateway BFF/Orch Domain APIs 楽天トラベル (WEB) 楽天トラベル (Native) 検索API Gateway api api api api api Orch Repository
45. 45 Architecture(簡略化されています) UI Distribution API API Gateway BFF/Orch Domain APIs 楽天トラベル (WEB) 楽天トラベル (Native) 検索API Gateway api api api api api Orch Repository そんなに前と変わってなくない？
46. 46 変わってないように⾒えて、⾊々変わってきました
47. 47 1. Language / Framework
48. 48 Language(Before) Front - Java (Thymeleaf, Spring等) - Swift, Java BackEnd - Java(Spring Boot) API Gateway - Rakuten App Engine(Java) Front - Javascript(Node, React, Redux等), Node - Java (Thymeleaf, Spring等) - Swift, Java + Kotlin? BackEnd - Java(Spring Boot) API Gateway - Kong Language(After)
49. 49 2. Organization(FrontEnd中⼼)
50. 50 Scale(FrontEnd) BackEnd + Front(Java) Front + backend 2014 2017/6 now 2016/7 Developed 1st SPA in our department as a front-end engineer. 2 FrontEnd Engineer 4 Native App Engineer 20+ FrontEnd Engineer 8 Native App Engineer Language / Frameworkを替えたこともあり、 そこから結構な数のエンジニアに参画して頂いています。 (異動してくるパターンも有) ⼈、増えております。
51. 51 Organization(簡略化しています) UI Platform Group DevOpts PDM STE SDET Notification DBA Customer Data Booking & Membership Search Platform WEB iOS Android API Gateway Product Management QA FrontEnd(20+) Infra / CI / CD Domain(70+)
52. 52 Organization(簡略化しています) UI Platform Group DevOpts PDM STE SDET Notification DBA Customer Data Booking & Membership Search Platform WEB iOS Android API Gateway Product Management QA FrontEnd(20+) Infra / CI / CD Domain(70+) Javascript / Node Java(BackEnd) New!
53. 53 UI Platform Group UI Platform Group WEB iOS Android API Gateway FrontEnd(20+) Javascript / Node New! ・様々な理由により、⾔語・フレームワーク変更 ・全体的にSPA(SSR)に舵を切った ・html, cssの実装も⾃グループ内で⾏うように(正 確にはzeplinのdesign mockをからUI componentを 実装するようになった) ・UI componentを意識が向くようになると、UIと いう観点でのmicroserviceについて考えるように ・元々そこを専⾨にしていた⼈が2⼈だったので、 急速拡⼤中！(2 -> 20+) / Facebookから来てくれた ⼈も ・API Gatewayも⾃グループにチームを作り、他部 署と主体的にAPI Gatewayの責務について調整する ように ・(個⼈的には) Native Appも⾒るようになったこと で、webとnative app間のarchitectureについても意 識するように
54. 54 UI Component 3. UI component と microservice
55. 55 UI Component ・StoryboardでUI Componentを管理 ・いわゆるドメインを含まないComponentだけで はなく、ドメイン情報を含むようなComponentに 関しても、共通化、汎⽤化するものに関してはUI Componentとして管理 ・UI componentを意識が向くようになると、UIと いう観点でのmicroserviceについて考えるように ・Designerと密にコミュニケーションをとりなが ら、汎⽤化したいところと汎⽤化しないポイントを 探っている(試⾏錯誤している状態) ・DomainlessのUI ComponentはPivotal UIに近いか も(Pivotal UIはstorybookではないですが)
56. 56 UI Component ・ドメインを含んだUI Componentは、Microserviceと強い結びつきがある ・画⾯に対応するOrchestrationからComponentに対応するOrchestration APIに(まとめるこ とはある) Page A とある画⾯ Orchestration API
57. 57 UI Component ・Component内に閉じ込められるUI⽤のビジネスロジックは閉じ込める ・Componentを跨ぎあって、作⽤しあうビジネスロジックはそんなに多くはなかった(ある にはある) Form Hotel information Item information とある画⾯ Orchestration API Orchestration API
58. 58 UI Component ・Component内に閉じ込められるUI⽤のビジネスロジックは閉じ込める ・Componentを跨ぎあって、作⽤しあうビジネスロジックはそんなに多くはなかった(ある にはある) Form Hotel information Item information とある画⾯ Orchestration API Orchestration API Form Hotel information とある画⾯2 Component間の汎⽤性はある
59. 59 課題 – でも、UIに最適化されたAPIはやっぱり必要 Form Hotel information Item information とある画⾯ Componentを またがるロジックがある場合 もあったり API API Orchestrat ion API
60. 60 Responsibility
61. 61 Responsibility of front-end application Realize UI / UX according to • How looks like. • How user can interact in our system. • How system feedback to user after user interacted. • Place of the UI parts • Calculation logic for styling. Such as width, height of the UI. • SEO Requirements • And so on.. I18n / I10n User Interaction feature • Gather user interaction data for tracking. Part of Validation / Identify User ※ ⼀部を抜粋しているもので、本当はもっと沢⼭ あります。FrontEndと、BackEndの実装の責任範 囲を今⼀度明確にする為に再定義しました。
62. 62 まとめ ドメインが独⽴した汎⽤性の⾼いAPIを作りたい UIに最適化されたAPIレスポンスがほしい はどっちも本当。だけど、ここの齟齬や(必要以上の)差分を無くしていくことで、 より強いmicroserviceができる(品質の⾼いorchestration層を作る?) →そして、UIはUIにより集中出来、BackEndはよりドメインが独⽴した汎⽤性の⾼いAPIの作成に注⼒ でき、引いてはサービスの質、開発の速度が向上する。 FrontEnd Engineer BackEnd Engineer
63. 63 Architecture UI Distribution API API Gateway BFF/Orch Domain APIs 楽天トラベル (WEB) 楽天トラベル (Native) 検索API Gateway api api api api api Orch Repository BackEnd Engineerから ⾒えていた Microservice の中⼼
64. 64 Architecture UI Distribution API API Gateway BFF/Orch Domain APIs 楽天トラベル (WEB) 楽天トラベル (Native) 検索API Gateway api api api api api Orch Repository FrontEndから みた Microservice って？
65. 65 Architecture UI Distribution API API Gateway BFF/Orch Domain APIs 楽天トラベル (WEB) 楽天トラベル (Native) 検索API Gateway api api api api api Orch Repository いいから使いや すいResponse くれ
66. 66 じゃなくて
67. 67 Architecture(こんな感じ!) UI Components※ API Gateway BFF/Orch Domain APIs Front End App Front End App Gateway api api api api api Orch Repository Front End App Front End App ※親⼦関係は有
68. 68 Architecture(こんな感じ!) UI Components※ API Gateway BFF/Orch Domain APIs Front End App Front End App Gateway api api api api api Orch Repository Front End App Front End App ※親⼦関係は有 FrontEnd BackEnd
69. 69 API間の改善については、今⽇はあまり話せなかったけど。。 ⾼橋勲さん 渡邊太⼀さん BackEndから2⼈の精鋭にお越しいただいております Spring Data RESTを利⽤したAPIの設計と、作り直しまでの道のり
70. 70 We are hiring. BackEnd + Front(Java) Front + backend 2014 2017/6 now 2016/7 Developed 1st SPA in our department as a front-end engineer. 2 FrontEnd Engineer 4 Native App Engineer 20+ FrontEnd Engineer 8 Native App Engineer FrontEnd Engineer募集中です!! (Native Appも!) 話聞いてみたいとかだけでも気軽にお声がけください takahiro.fujii@rakuten.com