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

楽天トラベルとSpring

Nov/18/2016Takahiro Fujii / Thomas LudwigTravel Service Development Department, Rakuten Inc

自己紹介 – Takahiro Fujii

藤井貴浩(@taka_ft)トラベルサービス開発・運用部

Hotel Booking チームAssistant manager

仕事・海外ホテル関連システム・インバウンドサイトの開発・コネクティビティ・予約システムの開発・最近はフロントエンド

趣味・ Design・ Web Design・ Basketball

https://twitter.com/taka_ft

自己紹介 – Tommy Ludwig

Tommy Ludwig (@TommyLudwig)トラベルサービス開発・運用部

Booking Platformチーム

仕事Walt Disney Parks & Resorts

・予約システムの開発Rakuten (現在)

・楽天トラベルの予約システムの開発

Open source• Spring Boot• Spring Session

撮影者：藤井貴浩 (Spring One 2015)

• Zipkin

https://twitter.com/TommyLudwig

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

http://www.slideshare.net/241takahiro/spring-onewebdocument

http://www.slideshare.net/tommyludwig/springone-2015-lattice-spring-cloud-netflix

http://www.slideshare.net/rakutentech/spring-cloudzipkin

http://www.slideshare.net/tommyludwig/jsug-springone-platform-2016-new-in-spring-data

http://www.slideshare.net/241takahiro/case-study-feed-back-springoneplatform

Agenda

• 楽天トラベルの説明

• 楽天トラベルのarchitectureの変化

• 直面した課題と解決へのアプローチ

直面した課題と解決へのアプローチ

• APIドキュメントを継続して最新の状態を維持するには

• シンプルにセッションを管理するために

• 同じプロパティの値を複数のアプリでそれぞれ管理したくない

• Microservice化する中でログの追跡を可能にするには

• メンバーに使って欲しいライブラリを使ってもらうには

• もっと簡単にAPIを実装する為に

• 新しく来た人にSpringの色々を覚えてもらうには

楽天トラベルの説明

本セッションでは、楽天トラベルのシステム開発についてお話しさせて頂きます。楽天では、各サービス(カンパニー)毎でシステム設計が異なります。今回は、楽天トラベルというサービスにおいて、Springをどのように利用している/したいというお話しになります。

本日お話しする楽天のシステムについて

楽天市場楽天銀行楽天証券

共通系のサービスは基本的に横断で管理

決済Platform

広告Platform

メールPlatform

会員Platform

楽天市場

楽天トラベルとJava• 楽天トラベルでは、メイン言語の1つとしてJavaを利用。

• 古くはStruts, SAStruts, Seasar等のフレームワークを利用していましたが、約5年前からSpringを利用し始めました。

• 現在では、自部署のJavaアプリケーションの多くがSpring, SpringBootを利用しています。

• 部署の開発環境・サービスに興味がある方は2年前の弊社カンファレンスでの発表資料をご覧ください。※ある程度古い為、現在の状態とは異なる場合があります。

http://www.slideshare.net/rakutentech/rakuten-techconf2014-b6-rakuten-travel-architecture-and-development-process?ref=http://tech.rakuten.co.jp/rtc2014/speakers.html

サービス• ユーザサービス

– 楽天トラベルのサイトを構成するプロダクト

• 施設向けサービス(管理画面)– 楽天トラベルで商品を販売される

– クライアント(ホテル・レンタカー会社・バス会社など)向けのシステムのプロダクト

• 社内向けサービス

• 共通系サービス– 決済・会員・ポイント・広告・通知・メールなど

– 横断系の部署でサービス(市場・トラベル・金融系)を跨いで管理されるものが多い

楽天トラベルのarchitectureの変化

(ダイジェスト版)

国内ホテル海外ホテル航空券レンタカーバス

施設管理画面

インバウンド外言語サイト

DP(ホテル+航空券)

etc…

HugeMonolithic

App

海外ホテル

MonolithicApp

MonolithicApp

MonolithicApp

施設ページ

(海外ホテル)

予約(海外ホテル)

検索(海外ホテル)

Front-EndApp

Front-EndApp

Front-EndApp

Back-EndApp

Back-EndApp

Back-EndApp

施設ページFront

予約Front

検索Front

施設API

予約API

検索API

国内ホテル海外ホテル航空券レンタカーバス

施設管理画面

インバウンド外言語サイト

DP(ホテル+航空券)

etc…

似てるAPIができてる

国内ホテル

海外ホテル

予約API 1

予約API 2

分割と再構築

予約API1

予約(情報)

通知

決済(共通基盤)

在庫

予約API2

管理画面

・予約のドメインモデルを今一度理解する・予約するという行為を分解して共通化

Front-EndApp

Front-EndApp

Front-EndApp

Back-EndApp

Back-EndApp

Back-EndApp

Back-EndGeneric

App

Back-EndGeneric

App

Back-EndGeneric

App

Back-EndGeneric

App

予約Front1

予約Front2

Front-EndApp

予約API1

予約API2

Back-EndApp

通知API

決済API

施設情報API

Back-EndGeneric

App

予約API 1? 2?(もちろん本当はそんな名前ではないです笑)

予約するという(行為)は共通

国内ホテル

海外ホテル

航空券レンタカーバス

予約する

分割と再構築

予約API1

予約(情報)

通知


在庫

予約API2

管理画面

分割と再構築

予約予約(情報)(REST)

通知(REST)


在庫(REST)

・行為として共通かできるものはできるだけ共通化する(したい)・機能を分割するだけではなく、同じにできるものは一つにしていく

・RESTfulに出来るならRESTfulに。APIを作るときは扱うリソースを意識する・BFF的なものを薄くする

管理画面

・APIの総数が増えてきた(新しいリソースの誕生・既存の機能の分割)

・APIの生まれ変わりが激しくなってきた(足りないAPIを作るから、最適なAPIを作るに）(APIをRESTfulに近づけていったり) +人も増えてきた

すると、多くの問題が(より)顕在化しました。

Issues

• APIの使い方がすぐには分からない

• セッション管理をもっと簡単にできないっけな、、

• アプリが増えてきて、プロパティファイルの変更が面倒…

• ログの追跡が面倒

• もっと簡単にAPIを実装できないっけな、、

• + 新しく来た人にSpringの色々を覚えてもらうのにコストがかかるな…








• + 新しく来た人にSpringの色々を覚えてもらうには

Issue

APIの使い方習得するのに時間がかかる

「なんでこのAPIこんなに使うの大変なんだ…」「挙動がよく分からない…」「このパラメータの意味が、、」

API Documentation

• Documentが嘘をついている– 実際にデプロイされているものと異なる

– プロダクトの仕様変更を追えてない・更新漏れ

「このAPI, Documentに書いてある通りに呼ぶとエラーが返ってくるんだけど…??」

「ごめん、Documentには反映出来てないんだけど、最近API更新して、この項目にはこの値をセットすること

になったんだ」

Consumer Producer「まじか」

API利用者 API提供者

API Documentation

• APIのExampleの不足– 1パターンのRequest/Responseのサンプルしかない

– ※少ないExampleでAPIの使い方がConsumerに迷いなく伝わるべきではある

「このAPI、複数部屋の予約するときってこのこの項目のレスポンスの値ってどうなる？

Documentになかったんだけど」

「お疲れ様です。前に自分が送ったときのサンプルがあるので、見つけて送りますね。」

(そこきたかー)

「ありがとうございます。(たまに忘れられる)」Consumer

API利用者

Producer

API提供者

API Documentation

• 開発中のプロダクトのドキュメントが無い– DEV/STGなどにdeployされているAPIが本番と異なる仕様の場合の把握が難しい

「DEV環境の**API動いてなくない？」

「あ、今PJTで改修していて、インタフェースを変

更しています。○○にこの項目を追加してもらえれば呼べますよー」

「ありがとうございます・・・」Consumer

API利用者

Producer

API提供者

API Documentation

• 適正・役割・管理の問題– Documentの品質の不安定さ(ルールがなく、プロダクト担当のエンジニアに品質が依存する、特にエンジニアでは得手・不得手は結構はっきり分かれる)

– Documentを書く係の人なんていない(特に内部API)

– Documentが大切なのはみんな(たぶん)分かってる、が整備することができない(特に更新・維持)

「Document書くのはエンジニアの仕事じゃないんじゃないかな…」「そうでなくとも、Document書くの苦手・・」

「あの人の書くコードは分かりやすいんだけど、Documentが何言ってるか分からない…」

Developer1 Developer2「これリリースしたらあそこのDocument更新しないと・・・」(忘れる)何回か忘れると維持するモチベーションがなくなる

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をすぐに特定できない

API Documentation Tool

http://swagger.io/

{ }…Swagger

RAML

http://raml.org/

SpringREST Docs

https://projects.spring.io/spring-restdocs/

etc...

http://swagger.io/

http://raml.org/




etc...

今日は、

Spring REST Docsについて話します。


Spring REST Docs

こんな感じのDocumentが作れます。

Spring REST Docs

自動生成

自動生成


src/test/javaの下に

*Documentation.javaというクラスを作成します。※Document対象となるクラス名のルールは変更可能

spring mvc testのテストコードに、documentするためのmethodを追加するようなイメージ※REST Assuredでもできます

Actual code(Sample)

Build

この3つの.adocファイルがビルド時に生成される(デフォルト)

※ここを変更するとdocumentが

できるディレクトリを分けられます

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 OKContent-Type: application/json;charset=UTF-8Content-Length: 37{"id":1,"content":"Hello, takahiro!”}----

curl-request.adoc

http-request.adoc

http-response.adoc

adocを直接開くとこんな感じです。

adocって？

curl-request.adoc

http-request.adoc

http-response.adocadd-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

対応しているブラウザ/ソフトで開くとこんな感じに表示されます。

https://addons.mozilla.org/ja/firefox/addon/asciidoctorjs-live-preview/

https://chrome.google.com/webstore/detail/asciidoctorjs-live-previe/iaalpfgpbocpdfblpnhhgllgbdbchmia

https://github.com/asciidoctor/sublimetext-asciidoc

https://github.com/asciidoctor/atom-asciidoc-preview

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.

http://projects.spring.io/spring-restdocs/

SpringRESTDocsは

snippets(断片)

を自動生成してくれるもの

snippetsの親は自分で用意

親adoc

src/main/asciidocの下に

*.adocというファイルを作成します。

api-guide.adocの中で、SpringRESTDocsで生成したsnippetsをincludeすることができます。

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

targetフォルダ

targetの中にできるので、例えばJenkinsとかのbuildからドキュメントが参照できる

api-guide.html

appname.jar

アプリの中にドキュメントを組み込み、アプリ配下にドキュメントページ

を組み込める

api-guide.html

Why Spring RESTDocs for us now

テスト成功

Create document

start

end

false

true

・Documentの正確性が保証されることが大切だった(テストコードからDocumentを作る・テストが通らないとDocumentは生成されない)

・継続的な更新が仕組みとして提供される

・Documentをアプリに内包出来るので、各環境にデプロイされているアプリのDocumentが提供される

・Documentを作成するのに、テストコード側の修正しかいらない

・エンジニアはテストコードかける(テストコードを書く感覚で、APIを使うのに必要なサンプルケースはまず間違いなく揃うとかも)

・Hypermediaに対応してる

How we use Spring RESTDocs

• 利用促進/簡単に使ってもらえるためにabstruct classを提供(jarで + SpringInitializr経由で配布(後述))

• DefaultでアプリにDocumentがincludeされるようにする

• EndPointを統一

• Method名でsnippetが作られるように

• alwaysDo入れておいて、コード書く側は何も考えず(いや、考えるんですが)テスト書いたらsnippetsが出来るような状態


@Beforepublic 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/



this.mockMvc.perform(delete("/entry?parameter=hoge")).andExpect(status().isOK());


→ Snippetsが作成される


API Documentation

• 結果

– APIの使い方のキャッチアップに時間がかなり減った

– Documentが嘘をつかなくなった

– サンプルが充実(API console無いのが、少し悩ましい)

– アプリに内包、URIを統一することで、誰もが簡単に各環境で動いているアプリのdocumentを閲覧できる

– 他のチームのエンジニアに喜ばれた(嘘をつかない安心の価値が高かったと思う)

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ではないものについて(依存関係は可視化すれば十分?)

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を運用しよう

http://www.slideshare.net/SpringCentral/documenting-restful-apis

https://2016.event.springoneplatform.io/schedule/sessions/writing_comprehensive_and_guaranteed_up_to_date_rest_api_documentation.html

https://2016.event.springoneplatform.io/schedule/sessions/writing_comprehensive_and_guaranteed_up_to_date_rest_api_documentation.html


http://www.slideshare.net/241takahiro/spring-onewebdocument

SESSION管理

Session management

Session管理

• セッション毎にデータを持ちたい（買い物かごやCSRFトークンなど）

• applicationのインスタンスをスケールしたい

• 標準のServlet APIを使い続けたい

– HttpServletRequest

– HttpSession

3つの解決方法

• Sticky sessions

• （アプリケーションサーバの）Session replication

• Spring Session

Sticky sessions

UsersApplication

instances

Session

dataバランサー

新

Sticky sessions

UsersApplication

instances

Session

dataバランサー

Session replication

同期

同期

同期

UsersApplication

instances

Session

dataバランサー

Session replication

同期

UsersApplication

instances

Session

dataバランサー

Session clustering （Spring Session）

Data store cluster

UsersApplication

instances

Session

dataバランサー

解決方法の比較

方法メリットデメリットSticky sessions バランサーの設定だけ

で済むHAではない

ASのSession replication

HA 設定・実装はASに依存する

Spring Session • HA• AS問わず利用可能• REST/WebSocket

必要なdependencyが増える？

Spring Session

• Servlet Filterで標準のHttpSessionをwrapする

• Sessionのデータストア（SessionRepository)

– Redis

– Hazelcast

– JDBC

– Mongo

– GemFire

Spring Session

• Spring Boot 1.4からAuto-configがある

– See Spring Boot documentation

–例えば

• Spring SessionとHazelcastをクラスパスに入れて

• spring.session.store-type=hazelcast

• Spring Bootでない場合は

– @EnableHazelcastHttpSession

http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-session.html

Spring Session @ Rakuten Travel

• すべてのapplicationはセッション管理が必要というわけではない。

• セッション管理が必要とされるapplicationの一部がSpring Sessionを利用– データストアはHazelcast

– プラスSpring SecurityでCSRFトークン生成・チェック

• 残りはその他のソリューション

参考

• Spring Session

– Documentation

– Spring Boot documentation

• （少し古めの）MakiさんのSpring Session記事

http://projects.spring.io/spring-session/

http://docs.spring.io/spring-session/docs/current/reference/html5/

http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-session.html

http://jsug-spring-boot-handson.readthedocs.io/en/latest/SpringSession.html

ログ追跡Log correlation with Spring Cloud Sleuth

問い合わせが来た時のログ調査は手間がかかりすぎる

Q

Issues

QAや他チームのデベロッパ

このリクエストのログが見たいんだけど…

A

呼んでるサービスからもらうわ

A

B〜Fさん、これ調べてくれない？

少々お待ちください！

。。。

F

Issues

問い合わせが来た時のログ調査は手間がかかりすぎる

全ログを収集して共通の場所から検索できたらええやんか

そうしても、一つのリクエストに関係するログは特定できないぞ

そんな人にログ追跡が必要ですよ

ログ追跡とは

• リクエストのstartからendまでの全サービスのログが見たい

• MDCというログの機能を利用し、ユニークIDをログに追加

• そのIDをサービスからサービスへ渡す

http://logback.qos.ch/manual/mdc_ja.html

トレーシング用語

• Span –ひとつのサービス（境界）内の処理

• Trace – リクエストのstartからendまでのSpanを含む

それは分かった！自分のプロジェクトでどうやってするの？！

Spring Cloud Sleuthで実現

• Spring Bootが前提条件• spring-cloud-sleuth-starter

を追加するだけ

• ログを収集して分析ができる

それだけ？！

Sleuth Integrations

• HTTP

(RestTemplate)

• @Async

• @Scheduled

• Messaging

– Spring Integration

• Spring Cloud

– Zuul

– Hystrix

– Feign

• RxJava

• See Documentation

http://cloud.spring.io/spring-cloud-sleuth/spring-cloud-sleuth.html#_integrations

楽天トラベルでのログ追跡

• ログ追跡はまだ導入し始めた頃です。

• SleuthでIDを生成し、サービス間で伝搬させる

• Logstashでログ収集してElasticsearchに入れる

• Kibanaで簡単にTrace IDなどで検索できる


• Spring Cloud Sleuthを利用するためにまずはSpring BootじゃないプロダクトをBoot化する

• slf4j・logback・ログフォーマットを統一した上でログ調査がしやすい

–共通コンフィグはSpring Cloud Configにある


• （既に使っていなければ）Sleuthが対応しているIntegrationsを使うように修正する

• リクエストのフローの中に対応していないサービスがあれば、その先は追跡できなくなってしまう

Centralized Configuration

アプリの数が増えてプロパティ変更が辛い

「え、またURL, KEY, **変わるの・・??」

Issues

Spring Cloud Config

• コンフィグはGitにある– バージョニング– source-controlled

• Config serverはHTTP APIを提供する

• クライアントはclient libraryでそのAPIを呼び、 SpringEnvironmentにコンフィグを追加する

• プロパティを暗号化できる

• 再起動なしでコンフィグのリフレッシュさせることができる

• デフォルトはクライアントからコンフィグをプル

• Gitのコミットたびにプッシュするように変えられる

VM-03

Local PCVM-01

VM-02

Config Server

Client

Client

Client

Client

JSON

Centralized

Source-controlled

On-the-fly updates

✔

✔

✔

• アプリ共通の値の重複

• 環境共通の値の重複

• デプロイ・再起動なしでプロパティーを変更したい

• どこで実行してもコンフィグが取得できたい

問題

AA

B

C

Actuatorの/refresh endpoint

Git repo

JSONJSON

JSON

重複の対策

• SpringのProfileで環境別のプロパティを分ける

• 共通のプロパティをグループ化

– 某app、某環境のプロパティ

– 某app、環境共通のプロパティ

– app共通、某環境のプロパティ

– appも環境も共通のプロパティ

一部のappで共通のプロパティはどうすればいいの？

一部共通のプロパティ

Issue

• 共通のコンフィグだが、一部のappだけに該当する

• 全appのEnvironmentに入れたくない

Solution

• ”Shared config”を作る

• appのように作成

• Clientでapp nameとshared config nameをspring.cloud.config.nameにコンマ区切りで設定する

• appA,shareAB

Cloud Config @ Rakuten Travel

• セキュリティ：外からアクセスする必要がないので、アクセス制限で充分

–本番のコンフィグサーバは本番のアプリケーションからしかアクセス出来ない

• パスワードやキーを暗号化してGitに保存して、サーバ側で復号化してクライアントに返す

Cloud Config @ Rakuten Travel

• 静的ファイルの機能も利用しています！

–ログコンフィグ（logback-spring.xml）

– Hazelcastのコンフィグ（hazelcast.xml）

• SpringのResourceで静的ファイルへのURI

• IDEのauto-completeが使えなくなるのは個人的に悲しいところです。

Create your scaffold from Spring Initializr

Issues(Improvement)

API

APIAPI

簡単に

共通化

API

API API

API

API・高品質なAPIを提供するには・Spring周りの機能を使えるように

・社内で共通の仕組み・ルールを適用する・色んなチームがAPIを作る中、最低限共通化したいところが出てきた(ロギングはこのライブラリで等)・毎回同じことやってる…??

http://start.spring.io/

http://start.spring.io/

https://start.spring.io/ https://github.com/spring-io/initializr

Spring Initializr

https://start.spring.io/

https://github.com/spring-io/initializr

Spring Initializr• アプリケーションに必要なクラスライブラリ群がセット

されたプロジェクトをサクッと作ることができる

• これを使えば、様々なタイプのアプリをSpringで簡単に、素早く作ることができる。

• 簡単にカスタマイズ可能で、社内で利用しているライブラリをSpring Initializrから設定できるようにすることができる。

- 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で管理すると更新が楽

https://github.com/spring-io/initializr/blob/master/initializr-service/src/main/resources/application.yml

Spring Initializrのカスタマイズとは

Dependencyに追加できるようになる

Spring Initializrのカスタマイズとは

IDEからでもカスタマイズしたInitializrを利用することが可能

Spring Initializr

RakutenTravel Initializr

InternalRepository

PublicRepository

lombok*.jarspring*.jar

rakuten*.jar

customize

Rakuten Travel Initializr

Spring Initializr

• 会社の環境にあったinitializrの作成が可能。

• 個人やOpenなプロジェクトに限った利用ではなく、各社のSpringアプリケーションのinitializrとしても利用することができる。

• Spring Initializrを使って、簡単に社内の環境に即したアプリを作ることができる。

• Spring Initializrを使って新規プロジェクトを作るフローにするとある程度使われるライブラリやバージョンの統制がとれる。

・社内ライブラリを追加する・不要 / 使わせたくないライブラリ(SNAPSHOT等を取り除く)

・Initilizrのconfigをcloud configで管理・defaultのgroupを変更・利用促進中

こんな感じです。

Spring Initializr @ Rakuten Travel

Easy Consumption of Microservices(SpringOne Platform(2016))・Spring Initializrのカスタマイズについて触れています

Appendix

https://2016.event.springoneplatform.io/schedule/sessions/easy_consumption_of_microservices.html

・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>

http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#production-ready

・spring-boot-actuatorを導入し、health checkerを自動実装、必要に応じてカスタマイズ

Appendix (Spring-Boot Actuator)

Initializrでactuatorをチェックすればプロジェクト作ったタイミングからもうhealth checkエンドポイントが実装されている

Issues・プロダクトも増えれば、人も増えている・最近はインターンの方もたくさん来てくれる

Issues

みんなが(最初から) Springに詳しいわけではない

：Springちょっとできる

Issues

教えるのに時間を結構使う

：Springちょっとできる

https://spring.io/guides

https://spring.io/guides

TRVDD tutorial

New comer 向けチュートリアルをasciidoc使って作りました :)

TRVDD tutorialGuideへのリンクがたくさん笑 + 補足

Result

緑色になる最初の一歩を加速！

+ 僕の素振りとして非常にいい機会に。。

まとめ

・ APIドキュメントを継続して最新の状態を維持するには(Spring RESTDocs)

・シンプルにセッションを管理するために(Spring Session)

・ Microservice化していく中でログの追跡を可能にするには (Spring Cloud Sleuth)

・同じプロパティの値を複数のアプリでそれぞれ管理したくない(Spring Cloud Config)

・メンバーに使って欲しいライブラリを使ってもらう・scaffoldを提供する(Spring

Initializr)

・ health checkなどの自動実装(Spring Boot Actuator)

・新しく来た人にSpringのいろいろを覚えてもらう(Spring guides)

まとめ

・課題を明確すること/課題に優先度をつけることは大切

解決策として新しい技術が使えるの方が導入しやすいし、結果がわかりやすい

(通常の業務と並行して勧めやすい)

課題に対する解決策として使えるツールがSpring周りに沢山ある。

・ Spring/Microservice周りでもまだまだ出来ることは沢山ある。

やろうとして出来ていないものもかなりある。

(Service Discovery / Circuit Breaker / CQRS / CDC / Event-Driven などなど…)

おまけ

・ここ1,2年で、様々な会社がSpring Boot/Cloud/ CFなどのケーススタディを紹介するようになったイメージがあります。 ( SpringOne Platformでも色々な所のケーススタディの紹介がありました)

ケーススタディの情報交換など、大歓迎です。

気軽にお声がけいただけると嬉しいです。

We are hiring!

Java / Spring 好きな方大歓迎…!!

http://corp.rakuten.co.jp/careers/engineering/

直接お声がけいただいても！

http://corp.rakuten.co.jp/careers/engineering/

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

Technology

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