Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices@microservice Meetup vol.6

Microservices@microservice Meetup vol.6

Microservice meetup vol6

Takahiro Fujii

January 18, 2018
Tweet

More Decks by Takahiro Fujii

Other Decks in Programming

Transcript

  1. Microservices
    @microservice meetup vol.6
    Jan.18.2018
    Takahiro Fujii
    Travel Product Dept.
    Rakuten, Inc.

    View full-size slide

  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の名渕さん(元同僚)

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  5. 5
    Rakuten Travel
    本⽇は、楽天トラベルのシステム・開発についてお話しさせて頂きます。楽天では、各サービス(カンパ
    ニー毎)でシステム設計が異なります。本⽇は、楽天トラベルとMicroserviceの関連についてお話しさせ
    て頂きます。

    View full-size slide

  6. 6
    Services(簡略化しています)
    楽天トラベル
    (Consumer)
    Extranet
    (管理画⾯)
    In-house
    (社内システム)
    WEB
    Native APP
    API
    (100+)
    Distribution
    (API連携)
    others
    Services UI Backend

    View full-size slide

  7. 7
    Scale
    Over 150+ Apps

    View full-size slide

  8. 8
    Scale
    Over 150+ Apps
    150+ Engineers
    ⽐較的⼤きな組織です

    View full-size slide

  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 -
    ⼤体の時期
    ⾊々な新規アプリを
    ガシガシ作っていた時期

    View full-size slide

  10. 10
    今⽇話すこと
    楽天トラベルとmicroservice
    の関係についてお話しながら、
    僕の視点から、
    BackEnd側から⾒えたmicroservice
    FrontEnd側から⾒えたmicroservice
    についてお話させて頂きます

    View full-size slide

  11. 11
    Phase1 ⾊々な新規アプリを
    ガシガシ作っていた時期

    View full-size slide

  12. 12
    Rakuten Travel
    まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。
    2010年 : 海外ホテル関連のシステムを開発・運⽤(たくさんの新しいアプリもできる)
    Monolithicなアプリケーションにどんどん機能を追加していって、
    アプリケーションが持つ機能が増えていく。
    Huge
    Monolithic
    App
    Phase1

    View full-size slide

  13. 13
    Rakuten Travel
    海外ホテル
    Phase1
    まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。
    2010年 : 海外ホテル関連のシステムを開発・運⽤(たくさんの新しいアプリもできる)
    Monolithicなアプリケーションにどんどん機能を追加していって、
    アプリケーションが持つ機能が増えていく。

    View full-size slide

  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
    沢⼭の⾊々なサービスができたり、機能追加されていった。

    View full-size slide

  15. 15
    Rakuten Travel
    2012年 : 肥⼤化してきたappを、機能別に切り出す✂
    Monolithic
    App
    Monolithic
    App
    Monolithic
    App
    Phase1

    View full-size slide

  16. 16
    Rakuten Travel
    2012年 : 肥⼤化してきたappを、機能別に切り出す✂
    ホテルページ
    (海外ホテル)
    検索
    (海外ホテル)
    予約
    (海外ホテル)
    Phase1

    View full-size slide

  17. 17
    Rakuten Travel
    2012年〜 さらにそこからAPI化してFrontとBackendを分離しはじめる。
    この時点ではどのAPIもかなり⼤きく、各クライアントに最適化されたAPIという感じ
    FrontEnd
    App
    FrontEnd
    App
    FronEnd
    App
    BackEnd
    App
    BackEnd
    App
    BackEnd
    App
    Phase1

    View full-size slide

  18. 18
    Rakuten Travel
    まずは、僕が⼊ったころ位からのarchitectureの変化をダイジェストで。
    2012年〜 API化してFrontとBackendを分離しだす
    ホテル 検索 予約
    ホテルAPI 検索API 予約API
    Phase1

    View full-size slide

  19. 19
    Phase2 そして、少しずつ
    Microserviceっぽくなってきた時期

    View full-size slide

  20. 20
    分割と再構築
    2013,4年~
    ・複数のAPIから共通のドメインやリソースをAPIに切り出し始める
    API1
    (予約系)
    API2
    (予約系)
    Hoge API
    在庫API
    通知API
    予約API
    決済(他部署)
    Phase2
    Phase1

    View full-size slide

  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

    View full-size slide

  22. 22
    RESTについて
    ・APIのI/F決定にかける時間が⻑くなった
    ・全てをRestfulによせようとすると、APIの呼び出
    し回数が必要以上に増えた
    ・どこまでRestに寄り添うか問題
    考えさせられた点
    良かった点
    ・巨⼤なAPIたちからRest APIが抽出され、整
    理された
    ・どうにかしてRestfulに出来ないのか?(とい
    うことについて考えることは⾟いこともあった
    が)シンプルなAPI設計をまずは考えるという⾵
    ⼟を根付かせてくれた
    ・ある程度の規模の組織において、APIの粒度
    に統⼀性がもたらされた
    ・沢⼭の先⼈の知恵
    Phase2
    Web API設計のこれまでとこれから よかった

    View full-size slide

  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

    View full-size slide

  24. 24
    これって、microserviceっぽい? Phase2
    予約Front 1
    予約Front 2
    Front3
    予約API 1
    予約API 2
    Front3
    通知API
    決済API
    ホテルAPI
    BackEnd
    Generic API
    … …

    ※この時期で総数100+位

    View full-size slide

  25. 25
    これって、microserviceっぽい? Phase2
    予約Front 1
    予約Front 2
    Front3
    予約API 1
    予約API 2
    Front3
    通知API
    決済API
    ホテルAPI
    BackEnd
    Generic API
    … …

    ※この時期で総数100+位
    それっぽくなってきた?

    View full-size slide

  26. 26
    これって、microserviceっぽい? Phase2
    予約Front 1
    予約Front 2
    Front3
    予約API 1
    予約API 2
    Front3
    通知API
    決済API
    ホテルAPI
    BackEnd
    Generic API
    … …

    ※この時期で総数100+位

    View full-size slide

  27. 27
    課題1 : 本当に分けないといけない?
    国内
    ホテル
    海外
    ホテル
    航空券 バス
    レンタ
    カー
    予約する
    予約するという⾏為は共通なはずなのに
    Phase2
    予約API 1 予約API 2
    ⽴ち⽌まって考えると、
    本当に2つのAPIが必要なのかという疑問が…
    なんで分ける必要あったんだっけ…

    View full-size slide

  28. 28
    Phase2
    課題2 : 理想と現実
    FrontEnd
    App
    汎⽤化された
    使いやすいAPI

    View full-size slide

  29. 29
    Phase2
    課題2 : 理想と現実
    画⾯専⽤のロ
    ジックが
    沢⼭うまった
    API
    FrontEnd
    App

    View full-size slide

  30. 30
    Phase2
    ・この頃はclient毎の処理を⽤意するのが⾟かった
    ・なんとかしてもっと汎⽤的な処理を定義して、BackEnd側としては汎⽤的なAPI
    のみを提供する形にできないものか
    ・画⾯毎に最適化されたapiを本当に作る必要があるのか
    画⾯専⽤のロ
    ジックが
    沢⼭うまった
    API
    FrontEnd
    App
    課題2 : 理想と現実

    View full-size slide

  31. 31
    気づいたら・・・
    Phase2

    View full-size slide

  32. 32
    メンテ⼤変
    Orchestration API※ボトルネックになっている感
    Phase2
    ※ここではUIからの⼀時受けをしているAPIのことを意図しています

    View full-size slide

  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があいまい

    View full-size slide

  34. 34
    あふれる改善点
    このころやっていたAPI間の改善は 楽天トラベルとSpring をご覧下さい
    Phase2

    View full-size slide

  35. 35
    その他の問題(抜粋)
    Phase2

    View full-size slide

  36. 36
    歪んでいたGlobal対応
    国内
    海外
    ※(⽇本以外)
    ・⼀部のAPIだけ多⾔語されていたり、されていな
    かったり。(clientからすると使いづらい)
    ・⾔語だけではなく、キャンセルポリシー、税⾦、
    などなどなどが、⽇本よりの設計になっていて、海
    外クライアントから⾮常に使いづらいものに
    ・海外クライアントがシステム連携するには使いづ
    らいAPIインターフェース
    (統⼀されていなかった)
    多⾔語化へのアプローチ
    世界基準ではない(主に強く⽇本の影響をうけた)
    データフォーマット、ドメインを無理やり使う

    View full-size slide

  37. 37
    各UIアプリケーション/外部向けAPIの機能のずれ
    Web
    Native
    App
    ・WebとAppで仕様がかなりごちゃごちゃに。
    ・どちらも分かる⼈がいなくなり、独⾃進化を遂げ
    始める
    ・Webが使うAPIと外部公開/連携⽤APIで違う仕様
    があったりするが、ふと距離をおいて考えると、
    「あれ、なんで違う必要あるんだっけ」っていう漢
    字の違い
    ・なぜかWebに出来ないことが外部公開⽤のAPIか
    らだと出来たり、Webからじゃないと出来ないこと
    があったりしてバグを⽣んだりする
    ・アプリの修正範囲の洗い出しが⾯倒
    提供している機能が(無駄に)違う
    WebとNative Appで実装の責任範囲が異なる
    外部公
    開/連携
    ⽤API
    User(Consumer)

    View full-size slide

  38. 38
    質が低かった / だんだんと品質が下がっていった
    microservice

    View full-size slide

  39. 39
    Microservice

    View full-size slide

  40. 40
    改善しよう

    View full-size slide

  41. 今取り組んでいるMicroservices
    @microservice meetup vol.6
    Jan.18.2018
    Takahiro Fujii
    Travel Product Dept.
    Rakuten, Inc.
    Phase3

    View full-size slide

  42. 42
    Services(簡略化しています)
    楽天トラベル
    (Consumer)
    Extranet
    In-house
    WEB
    Native APP
    API
    (100+)
    Distribution
    (API連携)
    others
    Services UI Backend
    Phase3

    View full-size slide

  43. 43
    APP + Front
    + backend
    2017/6 now
    僕はUI Platform Groupに。
    (FrontEndよりの⼈に)
    Phase3

    View full-size slide

  44. 44
    Architecture(簡略化されています)
    UI
    Distribution API
    API Gateway BFF/Orch Domain APIs
    楽天トラベル
    (WEB)
    楽天トラベル
    (Native)
    検索API
    Gateway
    api
    api
    api
    api
    api
    Orch
    Repository

    View full-size slide

  45. 45
    Architecture(簡略化されています)
    UI
    Distribution API
    API Gateway BFF/Orch Domain APIs
    楽天トラベル
    (WEB)
    楽天トラベル
    (Native)
    検索API
    Gateway
    api
    api
    api
    api
    api
    Orch
    Repository
    そんなに前と変わってなくない?

    View full-size slide

  46. 46
    変わってないように⾒えて、⾊々変わってきました

    View full-size slide

  47. 47
    1. Language / Framework

    View full-size slide

  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)

    View full-size slide

  49. 49
    2. Organization(FrontEnd中⼼)

    View full-size slide

  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を替えたこともあり、
    そこから結構な数のエンジニアに参画して頂いています。
    (異動してくるパターンも有)
    ⼈、増えております。

    View full-size slide

  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+)

    View full-size slide

  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!

    View full-size slide

  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についても意
    識するように

    View full-size slide

  54. 54
    UI Component
    3. UI component と microservice

    View full-size slide

  55. 55
    UI Component
    ・StoryboardでUI Componentを管理
    ・いわゆるドメインを含まないComponentだけで
    はなく、ドメイン情報を含むようなComponentに
    関しても、共通化、汎⽤化するものに関してはUI
    Componentとして管理
    ・UI componentを意識が向くようになると、UIと
    いう観点でのmicroserviceについて考えるように
    ・Designerと密にコミュニケーションをとりなが
    ら、汎⽤化したいところと汎⽤化しないポイントを
    探っている(試⾏錯誤している状態)
    ・DomainlessのUI ComponentはPivotal UIに近いか
    も(Pivotal UIはstorybookではないですが)

    View full-size slide

  56. 56
    UI Component
    ・ドメインを含んだUI Componentは、Microserviceと強い結びつきがある
    ・画⾯に対応するOrchestrationからComponentに対応するOrchestration APIに(まとめるこ
    とはある)
    Page A
    とある画⾯
    Orchestration API

    View full-size slide

  57. 57
    UI Component
    ・Component内に閉じ込められるUI⽤のビジネスロジックは閉じ込める
    ・Componentを跨ぎあって、作⽤しあうビジネスロジックはそんなに多くはなかった(ある
    にはある)
    Form
    Hotel information
    Item information
    とある画⾯
    Orchestration API
    Orchestration API

    View full-size slide

  58. 58
    UI Component
    ・Component内に閉じ込められるUI⽤のビジネスロジックは閉じ込める
    ・Componentを跨ぎあって、作⽤しあうビジネスロジックはそんなに多くはなかった(ある
    にはある)
    Form
    Hotel information
    Item information
    とある画⾯
    Orchestration API
    Orchestration API
    Form
    Hotel information
    とある画⾯2
    Component間の汎⽤性はある

    View full-size slide

  59. 59
    課題 – でも、UIに最適化されたAPIはやっぱり必要
    Form
    Hotel information
    Item information
    とある画⾯
    Componentを
    またがるロジックがある場合
    もあったり
    API
    API
    Orchestrat
    ion API

    View full-size slide

  60. 60
    Responsibility

    View full-size slide

  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の実装の責任範
    囲を今⼀度明確にする為に再定義しました。

    View full-size slide

  62. 62
    まとめ
    ドメインが独⽴した汎⽤性の⾼いAPIを作りたい
    UIに最適化されたAPIレスポンスがほしい
    はどっちも本当。だけど、ここの齟齬や(必要以上の)差分を無くしていくことで、
    より強いmicroserviceができる(品質の⾼いorchestration層を作る?)
    →そして、UIはUIにより集中出来、BackEndはよりドメインが独⽴した汎⽤性の⾼いAPIの作成に注⼒
    でき、引いてはサービスの質、開発の速度が向上する。
    FrontEnd Engineer BackEnd Engineer

    View full-size slide

  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
    の中⼼

    View full-size slide

  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
    って?

    View full-size slide

  65. 65
    Architecture
    UI
    Distribution API
    API Gateway BFF/Orch Domain APIs
    楽天トラベル
    (WEB)
    楽天トラベル
    (Native)
    検索API
    Gateway
    api
    api
    api
    api
    api
    Orch
    Repository
    いいから使いや
    すいResponse
    くれ

    View full-size slide

  66. 66
    じゃなくて

    View full-size slide

  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
    ※親⼦関係は有

    View full-size slide

  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

    View full-size slide

  69. 69
    API間の改善については、今⽇はあまり話せなかったけど。。
    ⾼橋勲さん
    渡邊太⼀さん
    BackEndから2⼈の精鋭にお越しいただいております
    Spring Data RESTを利⽤したAPIの設計と、作り直しまでの道のり

    View full-size slide

  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も!)
    話聞いてみたいとかだけでも気軽にお声がけください
    [email protected]

    View full-size slide