Slide 1
Slide 1 text
Microservices
@microservice meetup vol.6
Jan.18.2018
Takahiro Fujii
Travel Product Dept.
Rakuten, Inc.
Slide 2
Slide 2 text
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の名渕さん(元同僚)
Slide 3
Slide 3 text
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
Slide 4
Slide 4 text
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
Slide 5
Slide 5 text
5
Rakuten Travel
本⽇は、楽天トラベルのシステム・開発についてお話しさせて頂きます。楽天では、各サービス(カンパ
ニー毎)でシステム設計が異なります。本⽇は、楽天トラベルとMicroserviceの関連についてお話しさせ
て頂きます。
Slide 6
Slide 6 text
6
Services(簡略化しています)
楽天トラベル
(Consumer)
Extranet
(管理画⾯)
In-house
(社内システム)
WEB
Native APP
API
(100+)
Distribution
(API連携)
others
Services UI Backend
Slide 7
Slide 7 text
7
Scale
Over 150+ Apps
Slide 8
Slide 8 text
8
Scale
Over 150+ Apps
150+ Engineers
⽐較的⼤きな組織です
Slide 9
Slide 9 text
9
Agenda(3つのフェーズに分けて話していきます)
Phase2
Phase1
Phase3
Engineer
Back-End Engineer
Assistant Manager
Front-End Engineer
Assistant Manager
ちょっとMicroservice?
っぽくなってきた時期
Roll
そして今
2010 - 2013
2014 - 2017
2017 -
⼤体の時期
⾊々な新規アプリを
ガシガシ作っていた時期
Slide 10
Slide 10 text
10
今⽇話すこと
楽天トラベルとmicroservice
の関係についてお話しながら、
僕の視点から、
BackEnd側から⾒えたmicroservice
FrontEnd側から⾒えたmicroservice
についてお話させて頂きます
Slide 11
Slide 11 text
11
Phase1 ⾊々な新規アプリを
ガシガシ作っていた時期
Slide 12
Slide 12 text
12
Rakuten Travel
まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。
2010年 : 海外ホテル関連のシステムを開発・運⽤(たくさんの新しいアプリもできる)
Monolithicなアプリケーションにどんどん機能を追加していって、
アプリケーションが持つ機能が増えていく。
Huge
Monolithic
App
Phase1
Slide 13
Slide 13 text
13
Rakuten Travel
海外ホテル
Phase1
まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。
2010年 : 海外ホテル関連のシステムを開発・運⽤(たくさんの新しいアプリもできる)
Monolithicなアプリケーションにどんどん機能を追加していって、
アプリケーションが持つ機能が増えていく。
Slide 14
Slide 14 text
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
沢⼭の⾊々なサービスができたり、機能追加されていった。
Slide 15
Slide 15 text
15
Rakuten Travel
2012年 : 肥⼤化してきたappを、機能別に切り出す✂
Monolithic
App
Monolithic
App
Monolithic
App
Phase1
Slide 16
Slide 16 text
16
Rakuten Travel
2012年 : 肥⼤化してきたappを、機能別に切り出す✂
ホテルページ
(海外ホテル)
検索
(海外ホテル)
予約
(海外ホテル)
Phase1
Slide 17
Slide 17 text
17
Rakuten Travel
2012年〜 さらにそこからAPI化してFrontとBackendを分離しはじめる。
この時点ではどのAPIもかなり⼤きく、各クライアントに最適化されたAPIという感じ
FrontEnd
App
FrontEnd
App
FronEnd
App
BackEnd
App
BackEnd
App
BackEnd
App
Phase1
Slide 18
Slide 18 text
18
Rakuten Travel
まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。
2012年〜 API化してFrontとBackendを分離しだす
ホテル 検索 予約
ホテルAPI 検索API 予約API
Phase1
Slide 19
Slide 19 text
19
Phase2 そして、少しずつ
Microserviceっぽくなってきた時期
Slide 20
Slide 20 text
20
分割と再構築
2013,4年~
・複数のAPIから共通のドメインやリソースをAPIに切り出し始める
API1
(予約系)
API2
(予約系)
Hoge API
在庫API
通知API
予約API
決済(他部署)
Phase2
Phase1
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
22
RESTについて
・APIのI/F決定にかける時間が⻑くなった
・全てをRestfulによせようとすると、APIの呼び出
し回数が必要以上に増えた
・どこまでRestに寄り添うか問題
考えさせられた点
良かった点
・巨⼤なAPIたちからRest APIが抽出され、整
理された
・どうにかしてRestfulに出来ないのか？(とい
うことについて考えることは⾟いこともあった
が)シンプルなAPI設計をまずは考えるという⾵
⼟を根付かせてくれた
・ある程度の規模の組織において、APIの粒度
に統⼀性がもたらされた
・沢⼭の先⼈の知恵
Phase2
Web API設計のこれまでとこれから よかった
Slide 23
Slide 23 text
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
Slide 24
Slide 24 text
24
これって、microserviceっぽい？ Phase2
予約Front 1
予約Front 2
Front3
予約API 1
予約API 2
Front3
通知API
決済API
ホテルAPI
BackEnd
Generic API
… …
…
※この時期で総数100+位
Slide 25
Slide 25 text
25
これって、microserviceっぽい？ Phase2
予約Front 1
予約Front 2
Front3
予約API 1
予約API 2
Front3
通知API
決済API
ホテルAPI
BackEnd
Generic API
… …
…
※この時期で総数100+位
それっぽくなってきた？
Slide 26
Slide 26 text
26
これって、microserviceっぽい？ Phase2
予約Front 1
予約Front 2
Front3
予約API 1
予約API 2
Front3
通知API
決済API
ホテルAPI
BackEnd
Generic API
… …
…
※この時期で総数100+位
Slide 27
Slide 27 text
27
課題1 : 本当に分けないといけない？
国内
ホテル
海外
ホテル
航空券 バス
レンタ
カー
予約する
予約するという⾏為は共通なはずなのに
Phase2
予約API 1 予約API 2
⽴ち⽌まって考えると、
本当に2つのAPIが必要なのかという疑問が…
なんで分ける必要あったんだっけ…
Slide 28
Slide 28 text
28
Phase2
課題2 : 理想と現実
FrontEnd
App
汎⽤化された
使いやすいAPI
Slide 29
Slide 29 text
29
Phase2
課題2 : 理想と現実
画⾯専⽤のロ
ジックが
沢⼭うまった
API
FrontEnd
App
Slide 30
Slide 30 text
30
Phase2
・この頃はclient毎の処理を⽤意するのが⾟かった
・なんとかしてもっと汎⽤的な処理を定義して、BackEnd側としては汎⽤的なAPI
のみを提供する形にできないものか
・画⾯毎に最適化されたapiを本当に作る必要があるのか
画⾯専⽤のロ
ジックが
沢⼭うまった
API
FrontEnd
App
課題2 : 理想と現実
Slide 31
Slide 31 text
31
気づいたら・・・
Phase2
Slide 32
Slide 32 text
32
メンテ⼤変
Orchestration API※ボトルネックになっている感
Phase2
※ここではUIからの⼀時受けをしているAPIのことを意図しています
Slide 33
Slide 33 text
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があいまい
Slide 34
Slide 34 text
34
あふれる改善点
このころやっていたAPI間の改善は 楽天トラベルとSpring をご覧下さい
Phase2
Slide 35
Slide 35 text
35
その他の問題(抜粋)
Phase2
Slide 36
Slide 36 text
36
歪んでいたGlobal対応
国内
海外
※(⽇本以外)
・⼀部のAPIだけ多⾔語されていたり、されていな
かったり。(clientからすると使いづらい)
・⾔語だけではなく、キャンセルポリシー、税⾦、
などなどなどが、⽇本よりの設計になっていて、海
外クライアントから⾮常に使いづらいものに
・海外クライアントがシステム連携するには使いづ
らいAPIインターフェース
(統⼀されていなかった)
多⾔語化へのアプローチ
世界基準ではない(主に強く⽇本の影響をうけた)
データフォーマット、ドメインを無理やり使う
Slide 37
Slide 37 text
37
各UIアプリケーション/外部向けAPIの機能のずれ
Web
Native
App
・WebとAppで仕様がかなりごちゃごちゃに。
・どちらも分かる⼈がいなくなり、独⾃進化を遂げ
始める
・Webが使うAPIと外部公開/連携⽤APIで違う仕様
があったりするが、ふと距離をおいて考えると、
「あれ、なんで違う必要あるんだっけ」っていう漢
字の違い
・なぜかWebに出来ないことが外部公開⽤のAPIか
らだと出来たり、Webからじゃないと出来ないこと
があったりしてバグを⽣んだりする
・アプリの修正範囲の洗い出しが⾯倒
提供している機能が(無駄に)違う
WebとNative Appで実装の責任範囲が異なる
外部公
開/連携
⽤API
User(Consumer)
Slide 38
Slide 38 text
38
質が低かった / だんだんと品質が下がっていった
microservice
Slide 39
Slide 39 text
39
Microservice
Slide 40
Slide 40 text
40
改善しよう
Slide 41
Slide 41 text
今取り組んでいるMicroservices
@microservice meetup vol.6
Jan.18.2018
Takahiro Fujii
Travel Product Dept.
Rakuten, Inc.
Phase3
Slide 42
Slide 42 text
42
Services(簡略化しています)
楽天トラベル
(Consumer)
Extranet
In-house
WEB
Native APP
API
(100+)
Distribution
(API連携)
others
Services UI Backend
Phase3
Slide 43
Slide 43 text
43
APP + Front
+ backend
2017/6 now
僕はUI Platform Groupに。
(FrontEndよりの⼈に)
Phase3
Slide 44
Slide 44 text
44
Architecture(簡略化されています)
UI
Distribution API
API Gateway BFF/Orch Domain APIs
楽天トラベル
(WEB)
楽天トラベル
(Native)
検索API
Gateway
api
api
api
api
api
Orch
Repository
Slide 45
Slide 45 text
45
Architecture(簡略化されています)
UI
Distribution API
API Gateway BFF/Orch Domain APIs
楽天トラベル
(WEB)
楽天トラベル
(Native)
検索API
Gateway
api
api
api
api
api
Orch
Repository
そんなに前と変わってなくない？
Slide 46
Slide 46 text
46
変わってないように⾒えて、⾊々変わってきました
Slide 47
Slide 47 text
47
1. Language / Framework
Slide 48
Slide 48 text
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)
Slide 49
Slide 49 text
49
2. Organization(FrontEnd中⼼)
Slide 50
Slide 50 text
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を替えたこともあり、
そこから結構な数のエンジニアに参画して頂いています。
(異動してくるパターンも有)
⼈、増えております。
Slide 51
Slide 51 text
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+)
Slide 52
Slide 52 text
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!
Slide 53
Slide 53 text
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についても意
識するように
Slide 54
Slide 54 text
54
UI Component
3. UI component と microservice
Slide 55
Slide 55 text
55
UI Component
・StoryboardでUI Componentを管理
・いわゆるドメインを含まないComponentだけで
はなく、ドメイン情報を含むようなComponentに
関しても、共通化、汎⽤化するものに関してはUI
Componentとして管理
・UI componentを意識が向くようになると、UIと
いう観点でのmicroserviceについて考えるように
・Designerと密にコミュニケーションをとりなが
ら、汎⽤化したいところと汎⽤化しないポイントを
探っている(試⾏錯誤している状態)
・DomainlessのUI ComponentはPivotal UIに近いか
も(Pivotal UIはstorybookではないですが)
Slide 56
Slide 56 text
56
UI Component
・ドメインを含んだUI Componentは、Microserviceと強い結びつきがある
・画⾯に対応するOrchestrationからComponentに対応するOrchestration APIに(まとめるこ
とはある)
Page A
とある画⾯
Orchestration API
Slide 57
Slide 57 text
57
UI Component
・Component内に閉じ込められるUI⽤のビジネスロジックは閉じ込める
・Componentを跨ぎあって、作⽤しあうビジネスロジックはそんなに多くはなかった(ある
にはある)
Form
Hotel information
Item information
とある画⾯
Orchestration API
Orchestration API
Slide 58
Slide 58 text
58
UI Component
・Component内に閉じ込められるUI⽤のビジネスロジックは閉じ込める
・Componentを跨ぎあって、作⽤しあうビジネスロジックはそんなに多くはなかった(ある
にはある)
Form
Hotel information
Item information
とある画⾯
Orchestration API
Orchestration API
Form
Hotel information
とある画⾯2
Component間の汎⽤性はある
Slide 59
Slide 59 text
59
課題 – でも、UIに最適化されたAPIはやっぱり必要
Form
Hotel information
Item information
とある画⾯
Componentを
またがるロジックがある場合
もあったり
API
API
Orchestrat
ion API
Slide 60
Slide 60 text
60
Responsibility
Slide 61
Slide 61 text
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の実装の責任範
囲を今⼀度明確にする為に再定義しました。
Slide 62
Slide 62 text
62
まとめ
ドメインが独⽴した汎⽤性の⾼いAPIを作りたい
UIに最適化されたAPIレスポンスがほしい
はどっちも本当。だけど、ここの齟齬や(必要以上の)差分を無くしていくことで、
より強いmicroserviceができる(品質の⾼いorchestration層を作る?)
→そして、UIはUIにより集中出来、BackEndはよりドメインが独⽴した汎⽤性の⾼いAPIの作成に注⼒
でき、引いてはサービスの質、開発の速度が向上する。
FrontEnd Engineer BackEnd Engineer
Slide 63
Slide 63 text
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
の中⼼
Slide 64
Slide 64 text
64
Architecture
UI
Distribution API
API Gateway BFF/Orch Domain APIs
楽天トラベル
(WEB)
楽天トラベル
(Native)
検索API
Gateway
api
api
api
api
api
Orch
Repository
FrontEndから
みた
Microservice
って？
Slide 65
Slide 65 text
65
Architecture
UI
Distribution API
API Gateway BFF/Orch Domain APIs
楽天トラベル
(WEB)
楽天トラベル
(Native)
検索API
Gateway
api
api
api
api
api
Orch
Repository
いいから使いや
すいResponse
くれ
Slide 66
Slide 66 text
66
じゃなくて
Slide 67
Slide 67 text
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
※親⼦関係は有
Slide 68
Slide 68 text
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
Slide 69
Slide 69 text
69
API間の改善については、今⽇はあまり話せなかったけど。。
⾼橋勲さん
渡邊太⼀さん
BackEndから2⼈の精鋭にお越しいただいております
Spring Data RESTを利⽤したAPIの設計と、作り直しまでの道のり
Slide 70
Slide 70 text
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も!)
話聞いてみたいとかだけでも気軽にお声がけください
[email protected]
Slide 71
Slide 71 text
No content