楽天トラベルとSpring(Spring Day 2016)

4,622 views

Published on

Author : Takahiro Fujii, Thomas Ludwig

Description :
Spring Day 2016で発表させて頂いた資料となります。
楽天トラベルでは、
大規模なオンライン旅行システムの開発・運用を行なっています。
本資料は
1 - 楽天トラベルはどのようにArchitectureが変化し、改善を行なってきたか
2 - 直面した課題を解決する為にどのようにSpringを利用し、目的を達成したのか
という構成となります。
TOPIC(抜粋)
APIドキュメントを継続して最新の状態を維持するには(Spring RestDocs)
シンプルにセッションを管理するために(Spring Session)
Microservice化していく中でログの追跡を可能にするには (Spring Cloud Sleuth)
同じプロパティの値を複数のアプリでそれぞれ管理したくない(Spring Cloud Config)
メンバーに使って欲しいライブラリを使ってもらうには・scaffoldを提供するには(Spring Initilizr)

Published in: Technology

楽天トラベルとSpring(Spring Day 2016)

  1. 1. 楽天トラベルとSpring Nov/18/2016 Takahiro Fujii / Thomas Ludwig Travel Service Development Department, Rakuten Inc
  2. 2. 自己紹介 – Takahiro Fujii 藤井 貴浩(@taka_ft) トラベルサービス開発・運用部 Hotel Booking チーム Assistant manager 仕事 ・ 海外ホテル関連システム ・ インバウンドサイトの開発 ・ コネクティビティ ・ 予約システムの開発 ・ 最近はフロントエンド 趣味 ・ Design ・ Web Design ・ Basketball
  3. 3. 自己紹介 – Tommy Ludwig Tommy Ludwig (@TommyLudwig) トラベルサービス開発・運用部 Booking Platformチーム 仕事 Walt Disney Parks & Resorts ・ 予約システムの開発 Rakuten (現在) ・ 楽天トラベルの予約システムの開発 Open source • Spring Boot • Spring Session 撮影者:藤井 貴浩 (Spring One 2015) • Zipkin
  4. 4. Past Slides • Spring REST Docsを利用して鮮度の高いDocumentを運用しよう • Cloud Native:PaaS編 / Spring Cloud at Netflix • Spring CloudとZipkinを利用した分散トレーシング • JSUG SpringOne Platform 2016 報告会 - New in Spring Data • SpringOnePlatform 2016報告会 Case study
  5. 5. Agenda • 楽天トラベルの説明 • 楽天トラベルのarchitectureの変化 • 直面した課題と解決へのアプローチ
  6. 6. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • Microservice化する中でログの追跡を可能にするには • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • 新しく来た人にSpringの色々を覚えてもらうには
  7. 7. 楽天トラベルの説明
  8. 8. 本セッションでは、楽天トラベルのシステム開発についてお話しさせて頂きます。 楽天では、各サービス(カンパニー)毎でシステム設計が異なります。 今回は、楽天トラベルというサービスにおいて、 Springをどのように利用している/したいというお話しになります。 本日お話しする楽天のシステムについて 楽天市場 楽天銀行楽天証券
  9. 9. 共通系のサービスは基本的に横断で管 理 決済 Platform 広告 Platform メール Platform 会員 Platform 楽天市場
  10. 10. 楽天トラベルとJava • 楽天トラベルでは、メイン言語の1つとしてJavaを利用。 • 古くはStruts, SAStruts, Seasar等のフレームワークを利用して いましたが、約5年前からSpringを利用し始めました。 • 現在では、自部署のJavaアプリケーションの多くがSpring, SpringBootを利用しています。 • 部署の開発環境・サービスに興味がある方は2年前の弊社 カンファレンスでの発表資料をご覧ください。 ※ある程度古い為、現在の状態とは異なる場合があります。
  11. 11. サービス • ユーザサービス – 楽天トラベルのサイトを構成するプロダクト • 施設向けサービス(管理画面) – 楽天トラベルで商品を販売される – クライアント(ホテル・レンタカー会社・バス会社など)向けのシステムのプロダクト • 社内向けサービス • 共通系サービス – 決済・会員・ポイント・広告・通知・メールなど – 横断系の部署でサービス(市場・トラベル・金融系)を跨いで管理されるものが多い
  12. 12. 楽天トラベルのarchitectureの変化 (ダイジェスト版)
  13. 13. 国内ホテル 海外ホテル 航空券 レンタカー バス 施設 管理画面 インバウンド 外言語 サイト DP (ホテル+航空券) etc…
  14. 14. Huge Monolithic App
  15. 15. 海外ホテル
  16. 16. Monolithic App Monolithic App Monolithic App
  17. 17. 施設 ページ (海外ホテル) 予約 (海外ホテル) 検索 (海外ホテル)
  18. 18. Front-End App Front-End App Front-End App Back-End App Back-End App Back-End App
  19. 19. 施設 ページ Front 予約 Front 検索 Front 施設 API 予約 API 検索 API
  20. 20. 国内ホテル 海外ホテル 航空券 レンタカー バス 施設 管理画面 インバウンド 外言語 サイト DP (ホテル+航空券) etc…
  21. 21. 似てるAPIができてる 国内 ホテル 海外 ホテル 予約 API 1 予約 API 2
  22. 22. 分割と再構築 予約 API1 予約(情報) 通知 決済(共通基盤) 在庫 予約 API2 管理画面 ・予約のドメインモデルを今一度理解する ・予約するという行為を分解して共通化
  23. 23. Front- End App Front- End App Front- End App Back- End App Back- End App Back- End App Back-End Generic App Back-End Generic App Back-End Generic App Back-End Generic App
  24. 24. 予約 Front1 予約 Front2 Front- End App 予約 API1 予約 API2 Back- End App 通知 API 決済 API 施設 情報 API Back-End Generic App
  25. 25. 予約 Front1 予約 Front2 Front- End App 予約 API1 予約 API2 Back- End App 通知 API 決済 API 施設 情報 API Back-End Generic App
  26. 26. 予約API 1? 2? (もちろん本当はそんな名前ではないです笑)
  27. 27. 予約するという(行為)は共通 国内 ホテル 海外 ホテル 航空券 レンタカー バス 予約する
  28. 28. 分割と再構築 予約 API1 予約(情報) 通知 決済(共通基盤) 在庫 予約 API2 管理画面
  29. 29. 分割と再構築 予約 予約(情報)(REST) 通知(REST) 決済(共通基盤) 在庫(REST) ・行為として共通かできるものはできるだけ共通化する(したい) ・機能を分割するだけではなく、同じにできるものは一つにしていく ・RESTfulに出来るならRESTfulに。APIを作るときは扱うリソースを意識する ・BFF的なものを薄くする 管理画面
  30. 30. ・APIの総数が増えてきた (新しいリソースの誕生・既存の機能の分割) ・APIの生まれ変わりが激しくなってきた (足りないAPIを作るから、最適なAPIを作るに) (APIをRESTfulに近づけていったり) +人も増えてきた
  31. 31. すると、多くの問題が (より)顕在化しました。
  32. 32. Issues • APIの使い方がすぐには分からない • セッション管理をもっと簡単にできないっけな、、 • アプリが増えてきて、プロパティファイルの変更が面倒… • ログの追跡が面倒 • もっと簡単にAPIを実装できないっけな、、 • + 新しく来た人にSpringの色々を覚えてもらうのにコストがかか るな…
  33. 33. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • Microservice化する中でログの追跡を可能にするには • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • + 新しく来た人にSpringの色々を覚えてもらうには
  34. 34. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • Microservice化する中でログの追跡を可能にするには • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • 新しく来た人にSpringの色々を覚えてもらうには
  35. 35. Issue APIの使い方習得するのに時間がかかる 「なんでこのAPIこんなに使うの大変なんだ…」 「挙動がよく分からない…」 「このパラメータの意味が、、」
  36. 36. API Documentation • Documentが嘘をついている – 実際にデプロイされているものと異なる – プロダクトの仕様変更を追えてない・更新漏れ 「このAPI, Documentに書いてある通りに呼ぶと エラーが返ってくるんだけど…??」 「ごめん、Documentには反映出来てないんだけど、最 近API更新して、この項目にはこの値をセットすること になったんだ」 Consumer Producer「まじか」 API利用者 API提供者
  37. 37. API Documentation • APIのExampleの不足 – 1パターンのRequest/Responseのサンプルしかない – ※少ないExampleでAPIの使い方がConsumerに迷いなく伝わるべきではある 「このAPI、複数部屋の予約するときってこのこの項 目のレスポンスの値ってどうなる? Documentになかったんだけど」 「お疲れ様です。前に自分が送ったときのサンプル があるので、見つけて送りますね。」 (そこきたかー) 「ありがとうございます。(たまに忘れられる)」 Consumer API利用者 Producer API提供者
  38. 38. API Documentation • 開発中のプロダクトのドキュメントが無い – DEV/STGなどにdeployされているAPIが本番と異なる仕様の場合の把 握が難しい 「DEV環境の**API動いてなくない?」 「あ、今PJTで改修していて、インタフェースを変 更しています。○○にこの項目を追加してもら えれば呼べますよー」 「ありがとうございます・・・」 Consumer API利用者 Producer API提供者
  39. 39. API Documentation • 適正・役割・管理の問題 – Documentの品質の不安定さ(ルールがなく、プロダクト担当のエンジニアに品質が依 存する、特にエンジニアでは得手・不得手は結構はっきり分かれる) – Documentを書く係の人なんていない(特に内部API) – Documentが大切なのはみんな(たぶん)分かってる、が整備することができない(特に 更新・維持) 「Document書くのはエンジニアの仕事じゃないんじゃないかな…」 「そうでなくとも、Document書くの苦手・・」 「あの人の書くコードは分かりやすいんだけど、Documentが何言っ てるか分からない…」 Developer1 Developer2「これリリースしたらあそこのDocument更新しないと・・・」(忘れる) 何回か忘れると維持するモチベーションがなくなる
  40. 40. API Documentation(あとで見てね) • Issues – APIの使い方のキャッチアップに時間が掛かる(生産性の低下) – Documentが嘘をついている(実際にデプロイされているものの仕様変更を追えてない・更新漏れ) – Documentの品質の不安定さ(ルールがなく、プロダクト担当のエンジニアに品質が依存する、特にエンジニ アでは得手・不得手は結構はっきり分かれる) – Documentを書く係の人なんていない(特に内部API) – Documentが大切なのはみんな(たぶん)分かってる、一方でなかなか整備することができない(特に更新・維 持) – APIでカバーされている機能の領域が不明瞭(機能がかぶるAPIが他につくられたり、使えると思ったAPIが 機能足りてなかったり、思っていたのとちょっと違うということがAPIを使い始めてから分かったり) – APIのExampleの不足(1パターンのRequest/ResponseのサンプルしかないAPIなど) – 開発環境・QA環境で動いているプロダクトのドキュメントがない(今動いているプロダクトのドキュメントが環 境毎にほしい) – APIのRoll(Vision)が不明瞭で、ある機能を作成するのに、新規のAPIを作成するべきか、既存の機能を改修 するべきか悩むことがある – 古いシステム、日本語サイト用の仕様が日本(語)に依存するところがあったりして、英語でちゃんとドキュメ ントを書いておかないと日本(語・文化)に詳しくない人には分かりにくい仕様がある – (昔の話ですが)似ているけど違う、他のチームのAPIだと連携に時間がかかったりすることが理由の一端と なり、機能がかぶるAPIが作成された – サービス設計者が必要なリソースを取得するのに利用するAPIをすぐに特定できない
  41. 41. API Documentation Tool http://swagger.io/ { }… Swagger RAML http://raml.org/ Spring REST Docs https://projects.spring.io/spring-restdocs/ etc...
  42. 42. API Documentation Tool https://projects.spring.io/spring-restdocs/ etc... 今日は、 Spring REST Docs について話します。
  43. 43. Spring REST Docs こんな感じのDocumentが作れます。
  44. 44. Spring REST Docs 自動生成 自動生成
  45. 45. API Documentation Tool src/test/javaの下に *Documentation.javaというクラス を作成します。 ※Document対象となるクラス名のルールは変更可能 spring mvc testのテストコードに、 documentするためのmethodを追 加するようなイメージ ※REST Assuredでもできます
  46. 46. Actual code(Sample) Build この3つの.adocファイルがビルド時に生成される(デフォルト) ※ここを変更するとdocumentが できるディレクトリを分けられます
  47. 47. adocって? [source,bash] ---- $ curl 'http://localhost:8080/greeting?name=takahiro' –I ---- [source,http] ---- GET /greeting?name=takahiro HTTP/1.1Host: localhost ---- [source,http] ---- HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Content-Length: 37 {"id":1,"content":"Hello, takahiro!”} ---- curl-request.adoc http-request.adoc http-response.adoc adocを直接開くとこんな感じです。
  48. 48. adocって? curl-request.adoc http-request.adoc http-response.adoc add-on,plugin firefox : https://addons.mozilla.org/ja/firefox/addon/asciidoctorjs-live-preview/ chrome : https://chrome.google.com/webstore/detail/asciidoctorjs-live- previe/iaalpfgpbocpdfblpnhhgllgbdbchmia sublime : https://github.com/asciidoctor/sublimetext-asciidoc atom : https://github.com/asciidoctor/atom-asciidoc-preview 対応しているブラウザ/ソフト で開くとこんな感じに表示されます。
  49. 49. Spring REST Docsって何してくれるの? http://projects.spring.io/spring-restdocs/ snippet : 切れ端・断片 > Document RESTful services by combining hand-written documentation with auto-generated snippets produced with Spring MVC Test.
  50. 50. SpringRESTDocsは snippets(断片) を自動生成してくれるもの
  51. 51. snippetsの親は自分で用意
  52. 52. 親adoc src/main/asciidocの下に *.adocというファイルを作成します。 api-guide.adocの中で、 SpringRESTDocsで生成したsnippets をincludeすることができます。
  53. 53. Spring MVC Test 1.SpringRESTDocsが部品(snippets)を作ってくれる(with SpringMVCTest) 2. snippetsをincludeする.adocファイルを作ると、ビルド時に 指定した形式に変換してくれる SpringREST Docs *-request.adoc *-response.adoc *Documentation.java api-guide.adoc Asciidoctor api-guide.html snippets *-request.adoc *-response.adoc
  54. 54. targetフォルダ targetの中にできるので、 例えばJenkinsとかのbuild からドキュメントが参照できる api-guide.html appname.jar アプリの中にドキュメントを組み込み、 アプリ配下にドキュメントページ を組み込める api-guide.html
  55. 55. Why Spring RESTDocs for us now テスト 成功 Create document start end false true ・Documentの正確性が保証されることが大切だった (テストコードからDocumentを作る・テストが通らないとDocumentは生成されない) ・継続的な更新が仕組みとして提供される ・Documentをアプリに内包出来るので、各環境にデプロ イされているアプリのDocumentが提供される ・Documentを作成するのに、テストコード側の修正し かいらない ・エンジニアはテストコードかける (テストコードを書く感覚で、APIを使うのに必要なサンプルケースはまず間違いなく揃うとかも) ・Hypermediaに対応してる
  56. 56. How we use Spring RESTDocs • 利用促進/簡単に使ってもらえるためにabstruct class を提供(jarで + SpringInitializr経由で配布(後述)) • DefaultでアプリにDocumentがincludeされるように する • EndPointを統一 • Method名でsnippetが作られるように • alwaysDo入れておいて、コード書く側は何も考えず(い や、考えるんですが)テスト書いたらsnippetsが出来る ような状態
  57. 57. How we use Spring RESTDocs @Before public void setUp() { this.mockMvc = MockMvcBuilders.webAppContextSetup(this.context) .apply(documentationConfiguration(this.restDocumentation)) .alwaysDo(document("{method-name}/{step}/")).build();} http://docs.spring.io/spring-restdocs/docs/current/reference/html5/
  58. 58. How we use Spring RESTDocs this.mockMvc.perform(delete("/entry?parameter=hoge")) .andExpect(status().isOK()); http://docs.spring.io/spring-restdocs/docs/current/reference/html5/ → Snippetsが作成される
  59. 59. API Documentation • 結果 – APIの使い方のキャッチアップに時間がかなり減った – Documentが嘘をつかなくなった – サンプルが充実(API console無いのが、少し悩ましい) – アプリに内包、URIを統一することで、誰もが簡単に各環 境で動いているアプリのdocumentを閲覧できる – 他のチームのエンジニアに喜ばれた(嘘をつかない安心 の価値が高かったと思う)
  60. 60. API Documentation • 所感 – 正しいDocumentが当たり前にある最初の一歩としてSpring REST Docsは良 か った。 – もっと色々なことをやりたくなったら変えるかも(Swagger+Springfox/RAMLで作 られているプロダクトもあります) – 実際に使えるデータを使ったDocumentを作れないかなー – version差分を自動生成できないか。あるいはDocumentationのversioning – 基本的にテストコードだけいじればDocument作れるので、進めやすかった – Document作成より、REST DocsでDocument作るタスクの方がモチベートでき そうな肌感覚 – API Documentを作りはじめるのに、REST Docsは少ない工数で始められた – トップダウンのときどうしようかな – 今回のDocumentationの範疇ではないが、1アプリのDocumentではないもの について(依存関係は可視化すれば十分?)
  61. 61. Appendix DOCUMENTING RESTFUL APIS(SpringOne2GX(2015) Writing Comprehensive and Guaranteed Up-to-date REST API Documentation (SpringOne Platform(2016) Spring REST Docs Spring REST Docs を利用して鮮度の高いDocumentを運用しよう
  62. 62. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • Microservice化する中でログの追跡を可能にするには • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • 新しく来た人にSpringの色々を覚えてもらうには
  63. 63. SESSION管理 Session management
  64. 64. Session管理 • セッション毎にデータを持ちたい(買い物かごやCSRF トークンなど) • applicationのインスタンスをスケールしたい • 標準のServlet APIを使い続けたい – HttpServletRequest – HttpSession
  65. 65. 3つの解決方法 • Sticky sessions • (アプリケーションサーバの)Session replication • Spring Session
  66. 66. Sticky sessions Users Application instances Session data バランサー
  67. 67. Sticky sessions Users Application instances Session data バランサー
  68. 68. 新 Sticky sessions Users Application instances Session data バランサー
  69. 69. Session replication 同期 同期 同期 Users Application instances Session data バランサー
  70. 70. Session replication 同期 同期 同期 Users Application instances Session data バランサー
  71. 71. Session replication 同期 Users Application instances Session data バランサー
  72. 72. Session clustering (Spring Session) Data store cluster Users Application instances Session data バランサー
  73. 73. Session clustering (Spring Session) Data store cluster Users Application instances Session data バランサー
  74. 74. Session clustering (Spring Session) Data store cluster Users Application instances Session data バランサー
  75. 75. 解決方法の比較 方法 メリット デメリット Sticky sessions バランサーの設定だけ で済む HAではない ASのSession replication HA 設定・実装はASに 依存する Spring Session • HA • AS問わず利用可能 • REST/WebSocket 必要なdependency が増える?
  76. 76. Spring Session • Servlet Filterで標準のHttpSessionをwrapする • Sessionのデータストア(SessionRepository) – Redis – Hazelcast – JDBC – Mongo – GemFire
  77. 77. Spring Session • Spring Boot 1.4からAuto-configがある – See Spring Boot documentation – 例えば • Spring SessionとHazelcastをクラスパスに入れて • spring.session.store-type=hazelcast • Spring Bootでない場合は – @EnableHazelcastHttpSession
  78. 78. Spring Session @ Rakuten Travel • すべてのapplicationはセッション管理が必要 というわけではない。 • セッション管理が必要とされるapplicationの 一部がSpring Sessionを利用 – データストアはHazelcast – プラスSpring SecurityでCSRFトークン生成・チェック • 残りはその他のソリューション
  79. 79. 参考 • Spring Session – Documentation – Spring Boot documentation • (少し古めの)MakiさんのSpring Session記事
  80. 80. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • Microservice化する中でログの追跡を可能にするには • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • 新しく来た人にSpringの色々を覚えてもらうには
  81. 81. ログ追跡 Log correlation with Spring Cloud Sleuth
  82. 82. 問い合わせが来た時のログ調査は手間がかかりすぎる Q Issues QAや 他チームの デベロッパ このリクエストのログが見たいんだけど… A 呼んでるサービスからもらうわ A B〜Fさん、これ調べてくれない? 少々お待ちください! 。。。 F
  83. 83. Issues 問い合わせが来た時のログ調査は手間がかかりすぎる 全ログを収集して 共通の場所から 検索できたらええやんか そうしても、一つのリクエストに関係 するログは特定できないぞ
  84. 84. そんな人にログ追跡が必要ですよ
  85. 85. ログ追跡とは • リクエストのstartからendまでの全サービスのログが見たい • MDCというログの機能を利用し、ユニークIDをログに追加 • そのIDをサービスからサービスへ渡す
  86. 86. トレーシング用語 • Span – ひとつのサービス(境界)内の処理 • Trace – リクエストのstartからendまでのSpanを含む
  87. 87. それは分かった! 自分のプロジェクトで どうやってするの?!
  88. 88. Spring Cloud Sleuthで実現 • Spring Bootが前提条件 • spring-cloud-sleuth-starter を追加するだけ • ログを収集して分析が できる
  89. 89. それだけ?!
  90. 90. Sleuth Integrations • HTTP (RestTemplate) • @Async • @Scheduled • Messaging – Spring Integration • Spring Cloud – Zuul – Hystrix – Feign • RxJava • See Documentation
  91. 91. 楽天トラベルでのログ追跡 • ログ追跡はまだ導入し始めた頃です。 • SleuthでIDを生成し、サービス間で伝搬させる • Logstashでログ収集してElasticsearchに入れる • Kibanaで簡単にTrace IDなどで検索できる
  92. 92. 楽天トラベルでのログ追跡 • Spring Cloud Sleuthを利用するためにまずは Spring BootじゃないプロダクトをBoot化する • slf4j・logback・ログフォーマットを統一した上で ログ調査がしやすい – 共通コンフィグはSpring Cloud Configにある
  93. 93. 楽天トラベルでのログ追跡 • (既に使っていなければ)Sleuthが対応してい るIntegrationsを使うように修正する • リクエストのフローの中に対応していない サービスがあれば、その先は追跡できなく なってしまう
  94. 94. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • Microservice化する中でログの追跡を可能にするには • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • 新しく来た人にSpringの色々を覚えてもらうには
  95. 95. Centralized Configuration
  96. 96. アプリの数が増えてプロパティ変更が辛い 「え、またURL, KEY, **変わるの・・??」 Issues
  97. 97. Spring Cloud Config • コンフィグはGitにある – バージョニング – source-controlled • Config serverはHTTP API を提供する • クライアントはclient library でそのAPIを呼び、 Spring Environmentにコンフィグを 追加する • プロパティを暗号化できる • 再起動なしでコンフィグの リフレッシュさせることが できる • デフォルトはクライアントか らコンフィグをプル • Gitのコミットたびにプッシュ するように変えられる
  98. 98. VM-03 Local PC VM-01 VM-02 Config Server Client Client Client Client JSON  Centralized  Source-controlled  On-the-fly updates ✔ ✔ ✔ • アプリ共通の値の重複 • 環境共通の値の重複 • デプロイ・再起動なしで プロパティーを変更したい • どこで実行してもコンフィグ が取得できたい 問題 A A B C Actuatorの /refresh endpoint Git repo JSON JSON JSON
  99. 99. 重複の対策 • SpringのProfileで環境別のプロパティ を分ける • 共通のプロパティをグループ化 – 某app、某環境のプロパティ – 某app、環境共通のプロパティ – app共通、某環境のプロパティ – appも環境も共通のプロパティ
  100. 100. 一部のappで共通のプロパティは どうすればいいの?
  101. 101. 一部共通のプロパティ Issue • 共通のコンフィグだが、 一部のappだけに該当する • 全appのEnvironmentに入 れたくない Solution • ”Shared config”を作る • appのように作成 • Clientでapp nameとshared config nameを spring.cloud.config.nameに コンマ区切りで設定する • appA,shareAB
  102. 102. Cloud Config @ Rakuten Travel • セキュリティ:外からアクセスする必要がない ので、アクセス制限で充分 – 本番のコンフィグサーバは本番のアプリケーショ ンからしかアクセス出来ない • パスワードやキーを暗号化してGitに保存して、 サーバ側で復号化してクライアントに返す
  103. 103. Cloud Config @ Rakuten Travel • 静的ファイルの機能も利用しています! – ログコンフィグ(logback-spring.xml) – Hazelcastのコンフィグ(hazelcast.xml) • SpringのResourceで静的ファイルへのURI • IDEのauto-completeが使えなくなるのは個人 的に悲しいところです。
  104. 104. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • Microservice化する中でログの追跡を可能にするには • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • 新しく来た人にSpringの色々を覚えてもらうには
  105. 105. Create your scaffold from Spring Initializr
  106. 106. Issues(Improvement) API API API 簡単に 共通化 API API API API API ・高品質なAPIを提供するには ・Spring周りの機能を使えるように ・社内で共通の仕組み・ルールを適用する ・色んなチームがAPIを作る中、 最低限共通化したいところが出てきた (ロギングはこのライブラリで等) ・毎回同じことやってる…??
  107. 107. http://start.spring.io/
  108. 108. https://start.spring.io/ https://github.com/spring-io/initializr Spring Initializr
  109. 109. https://start.spring.io/ https://github.com/spring-io/initializr Spring Initializr
  110. 110. https://start.spring.io/ https://github.com/spring-io/initializr Spring Initializr
  111. 111. https://start.spring.io/ https://github.com/spring-io/initializr Spring Initializr
  112. 112. https://start.spring.io/ https://github.com/spring-io/initializr Spring Initializr
  113. 113. Spring Initializr • アプリケーションに必要なクラスライブラリ群がセット されたプロジェクトをサクッと作ることができる • これを使えば、様々なタイプのアプリをSpringで簡単に、 素早く作ることができる。 • 簡単にカスタマイズ可能で、社内で利用しているライブ ラリをSpring Initializrから設定できるようにすること ができる。
  114. 114. - name: Custom content: - name: Jasypt id: jasypt description: Provides Jasypt encryption support for property sources version: 1.6 groupId: com.github.ulisesbocchio artifactId: jasypt-spring-boot-starter Add a custom section(application.yml) https://github.com/spring-io/initializr/blob/master/initializr-service/src/main/resources/application.yml 下記のファイル一度ご参照ください 自分で3rd partyのライブラリを追加できる(簡単に) 社内のプライベートなライブラリを足したりとかも このymlもclooud-configで管理すると更新が楽
  115. 115. Spring Initializrのカスタマイズとは Dependencyに追加できるようになる
  116. 116. Spring Initializrのカスタマイズとは IDEからでもカスタマイズしたInitializrを利用することが可能
  117. 117. Spring Initializr Rakuten Travel Initializr Internal Repository Public Repository lombok*.jarspring*.jar rakuten*.jar customize Rakuten Travel Initializr
  118. 118. Spring Initializr • 会社の環境にあったinitializrの作成が可能。 • 個人やOpenなプロジェクト に限った利用ではなく、各 社のSpringアプリケーションのinitializrとしても 利用す ることができる。 • Spring Initializrを使って、簡単に社内の環境に即したア プリを作ることができる。 • Spring Initializrを使って新規プロジェクトを作るフロー にするとある程度使われるライブラリやバージョンの統 制がとれる。
  119. 119. ・社内ライブラリを追加する ・不要 / 使わせたくないライブラリ(SNAPSHOT等を取り除く) ・Initilizrのconfigをcloud configで管理 ・defaultのgroupを変更 ・利用促進中 こんな感じです。 Spring Initializr @ Rakuten Travel
  120. 120. Easy Consumption of Microservices(SpringOne Platform(2016)) ・Spring Initializrのカスタマイズについて触れています Appendix
  121. 121. ・spring-boot-actuatorを導入し、 health checkerを自動実装、必要に応じてカスタマイズ ここのサービス毎にバラバラだったhealth checkを統一している Appendix (Spring-Boot Actuator) http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#production-ready <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> </dependencies>
  122. 122. ・spring-boot-actuatorを導入し、 health checkerを自動実装、必要に応じてカスタマイズ Appendix (Spring-Boot Actuator) Initializrでactuatorをチェックすれば プロジェクト作ったタイミングからもうhealth checkエンドポイントが実装されている
  123. 123. 直面した課題と解決へのアプローチ • APIドキュメントを継続して最新の状態を維持するには • シンプルにセッションを管理するために • Microservice化する中でログの追跡を可能にするには • 同じプロパティの値を複数のアプリでそれぞれ管理したくない • メンバーに使って欲しいライブラリを使ってもらうには • もっと簡単にAPIを実装する為に • 新しく来た人にSpringの色々を覚えてもらうには
  124. 124. Issues ・プロダクトも増えれば、人も増えている ・最近はインターンの方もたくさん来てくれる
  125. 125. Issues みんなが(最初から) Springに詳しいわけではない :Springちょっとできる
  126. 126. Issues 教えるのに時間を結構使う :Springちょっとできる
  127. 127. https://spring.io/guides
  128. 128. TRVDD tutorial New comer 向けチュートリアルをasciidoc使って作りました :)
  129. 129. TRVDD tutorial New comer 向けチュートリアルをasciidoc使って作りました :)
  130. 130. TRVDD tutorial Guideへの リンクがたくさん笑 + 補足
  131. 131. Result 緑色になる最初の一歩を加速! + 僕の素振りとして非常にいい機会に。。
  132. 132. まとめ ・ APIドキュメントを継続して最新の状態を維持するには(Spring RESTDocs) ・シンプルにセッションを管理するために(Spring Session) ・ Microservice化していく中でログの追跡を可能にするには (Spring Cloud Sleuth) ・同じプロパティの値を複数のアプリでそれぞれ管理したくない(Spring Cloud Config) ・メンバーに使って欲しいライブラリを使ってもらう・scaffoldを提供する(Spring Initializr) ・ health checkなどの自動実装(Spring Boot Actuator) ・新しく来た人にSpringのいろいろを覚えてもらう(Spring guides)
  133. 133. まとめ ・ 課題を明確すること/課題に優先度をつけることは大切 解決策として新しい技術が使えるの方が導入しやすいし、結果がわかりやすい (通常の業務と並行して勧めやすい) 課題に対する解決策として使えるツールがSpring周りに沢山ある。 ・ Spring/Microservice周りでもまだまだ出来ることは沢山ある。 やろうとして出来ていないものもかなりある。 (Service Discovery / Circuit Breaker / CQRS / CDC / Event-Driven などなど…) おまけ ・ ここ1,2年で、様々な会社がSpring Boot/Cloud/ CFなどのケーススタディを紹介するよ うになったイメージがあります。 ( SpringOne Platformでも色々な所のケーススタディ の紹介がありました)
  134. 134. ケーススタディの情報交換など、大歓迎です。 気軽にお声がけいただけると嬉しいです。
  135. 135. We are hiring! Java / Spring 好きな方大歓迎…!! http://corp.rakuten.co.jp/careers/engineering/ 直接お声がけいただいても!

×