shoito/event_20150828_spring-in-summer.md

## event_20150828_spring-in-summer.md

      
    Raw
  

              event_20150828_spring-in-summer.md
            
          
    Session1(R1-1.オープニングセッション)

Coffee Break


「Java EEが最近生意気だ」
「Seasarがカンファレンスやるらしいけど、もうライバルじゃないのでどうでもイイ」
「寺田生意気だ」

Springの歩み


2003 Spring 0.9
2004 Spring 1.0
2015 Spring 4.2
Boot, Data, Cloud, Batch...
将来?
Spring : Cloud (CloudFoundry)

Session2(R1-2.マイクロサービスアーキテクチャの設計)

鈴木さん、アジャイルで痛い目にあったことがあるのか？と疑問に思う発言がちらほら
MSAについて


Martin Fawlerのブログで取り上げられたのがキッカケで広がった。
2つの側面
技術面：分散配置と統合
文化面：持続性と分権

MSAの技術面


分散配置と統合
サービスをサービスで構成する
メッセージによる統合
サービスをマネージする

MSAの文化面


持続性と分権
サービス全体を持続的に 動作させる
ドメイン固有の技術と運営
ドメイン毎の自主性を認め、標準化を否定する
「社内標準フレームワークなんていらないですよね？」 by 鈴木さん
ドメイン固有のライフサイクル

MSAの背景


ウェブサービスのレガシー化
サービス共有の一般化
サービスレベルがコードで管理できる
動作構成パターンの共有化

MSAとは


新しい理想論ではなく現実解
「アジャイルという言葉が先鋭化して、理想論化されたけど騙されないでください」 by 鈴木さん

MSAを理解する


技術論よりは技術管理論
粒度ではなく関係性に注目を
どの粒度でも良い(マイクロに惑わされない)
アプリとコンポーネント
システムとサブシステム(この辺の事例が多い)
システム全体と個別システム
重要なのはサービス相互の関係性のあり方

SOAとMSA


SOA: トップダウン
個別システムの集合を統治(すべき)
MSA: ボトムアップ
全体サービスを分割して統治(するしかない)

システム統治としてのMSA


アーキテクチャは統治の手法
封建制 -> 君主制 -> 民主制への変化と似てる
乱立 = 封建制: 孤立した統治
SOA = 君主制: 偉大な王がいれば可能な統治
MSA = 民主制: 有識な市民が必要な統治

MSAの適用


MSAは銀の弾丸ではない

MSAと開発プロセス


アーキテクチャの逆襲
柔軟性をアーキテクチャが保証する
ドメインに適したプロセスを選択する

MSAのデザイン


前提: 企業システムにおける適用
ドメインの発見
プラットフォームの利用

ドメインの発見


ドメイン = 変化の境界線
変化の境界線を見つける
変化の要因を品質特性から理解する
変化の濃淡に線を引く
ドメインは境界を維持したがる

「ドメインというものがあるのではなく、ドメインというものを決めて考える(結果論)」 by 鈴木さん
プラットフォームの利用


プラットフォーム = 共有の動的資産

ドメインとプラットフォーム


バランスをいかに取るか
独立させすぎると無駄が増える
共有しすぎると対応できない

MSAの実例


企業システムで言えばECサイト

ECサイトのドメイン設計


特性
流入 -> 商品検索 -> 購買
個人情報やカード番号
基幹システム(請求/在庫)との連携

サービス配置例

(小さい図)
ESサイトの構成


商品管理
コンテンツ管理
商品検索エンジン
...

実例から実践へ


当然、「正解はない」
「手段は目的にしない」
「いい形に進めると、アジャイルもMSAも自然とそうなる」

Springについて


Spring Bootだけじゃない
Framework: アプリ内の関係性管理
Integration: アプリ間の関係性管理
Springはなにかを規定しないからこそ、アーキテクトにとって魅力的

まとめ


MSAについて
MSAを理解する
MSAのデザイン
MSAの実例
Springについて
「私はJava EEを好きになれなくて、最後までそこは寺田さんと折り合いがつかなかった」 by 鈴木さん
最後に
「MSAにする」のではなく「MSAになる」のが健全

Session3(R2-3.大規模・長期保守を見据えたエンタープライズシステム開発へのSpring Frameworkの適用)

TERASOLUNAとは


標準プロセス
開発環境
サポート

「Struts1はEOL迎えてるけど、これからも使い続けていく(古いTERASOLUNA)」 by NTT Data
新TERASOLUNA


Spring Security, MVC, Data JPA
Struts1とはサヨナラ
Java 5(???)

なぜSpringなのか？


開発リソースの確保のしやすさ
変化への対応
セキュリティ面の強化
社内に蓄積したノウハウ量

TERASOLUNAの構成要素


Software Framework
Common lib
Guideline
Tutorial
Samples
Blank project
e2e, Performance test suite

「Githubで公開してて誰でも使える」 by NTT Data
Springを利用した時の課題


Springのバージョン組み合わせ選定
Spring IO Platformに従うことで解決
Spring等の膨大な設定
乱雑なプロジェクト構成
レイヤ分割したマルチプロジェクト構成
環境依存を集約し、アプリケーションと分離
各種設定・ライブラリ依存関係をデフォで設定
不完全な例外ハンドリング・ロギング
(ありえないレベルの酷いコードが例として...)
必要な設定はブランクプロジェクトで設定済み
信頼性の低いコードの模倣
ガイドラインを提供
コピペしても安全なコード

GitBucket -> Jenkins -> APServer, Selenium
(以前、竹添さんが在籍していたからGitBucketなのかな)
Springへの貢献


脆弱性の報告(2件)
バグの報告

まとめ

TERASOLUNA FWの紹介でした
Session4(R1-5.キーノート The Macro of Microservices)

CDの話が主だった。
(スクリーンに映らないというトラブルで10分押し)
Continuous delivery


Microservices
CI
Cloud Computing
Agility

アジャイルとリーン


速いDeliveryが大事
DevOps
the Devops Handbook
各フェーズ、チーム間の待ち行列を無くす

misc


Value chain mapping (http://www.computerweekly.com/opinion/Value-chain-mapping-learning-to-use-IT-as-a-strategic-weapon)
事例: amazon.com
CloudFoundry is Cool!
Monolith
the art of scalability (http://theartofscalability.com/)
Netflix (http://www.slideshare.net/adrianco)
Conway’s Law (http://haacked.com/archive/2013/05/13/applying-conways-law.aspx/)
DDD
開発プロセス
Jenkins, CircleCI, Travis CI
10+ Deploys Per Day (http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr)
Spring Boot
Spring Cloud

Session5(R1-6.Spring DIと大規模プロジェクト、春は来るのか本当に？)

Companyの会社だけど、HUEプロジェクトでの事例について
構成の変遷


初期
MariaDB
Spring Bootは時期的な問題があってパス
現状
RDBMS -> Cassandra, Elasticsearch, ...
Batch -> Spark Streaming, Spark Batch, ...
Cache -> ...
Front -> SPA, karma + jasmine, ...

プロジェクトへの要求


要求
クラウドベースで動く
応答速度は100ms
条件
同時並行的に開発

時間の経過とともに...


APサーバ起動時間が遅くなっていく
プロジェクト間の依存関係が...
DIって言うけど何が読み込まれてるの？

表面的に噴出した問題


依存関係が謎、解決できない
起動時間が遅い
plugi-in的に扱うものは？

結論


Modularityの担保
実装とインタフェースの分離
フレームワークの設定は@Importで管理
2重ロード防止
速度も考慮
ComponentScanをしないという選択肢

まとめ


人の増加は大規模プロジェクトの宿命
Modularityを考えるのは大事

Session6(R1-7.The Bootiful Application)


SPRING INITIALIZR (http://start.spring.io)
Spring Bootのライブコーディング
Endpoints (http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html)

Session7(R1-8. 【前半】 Spring Framework/Boot/Data徹底活用～Sprnig Data Redis編～

Spring Data Redis


SpringでRedisを操作するためのライブラリ
JedisのローレベルAPIではなくTemplateを提供している
RedisCacheManagerによりspring-contextのCache機構と連携可
Redisに存在しない場合のみメソッドの中身が呼ばれる(@Cachable)

Redis構成の選択肢


Redis Cluster
Redis Sentinel
Load Balancer

試してみる


Spring + Redis Cluster
Spring Data Redisは未対応
Spring + Redis Sentinel
Sentinel, Master, Slaveと接続切り替えの対応が必要？
Spring + VIP(これがシンプルそう)

Session7(R1-8. 【後半】 Spring適用におけるバッドノウハウとベタープラクティス)

リクルートでの開発事情


ニジボックス


カードエンジンと呼ばれるPHPオレオレフレームワーク


リクルートライフスタイル


Seasar2ベースのR2と呼ばれるJavaオレオレフレームワーク


R2にロックインされたインフラ


バッドノウハウ


社内標準フレームワークを作りこむこと
社内標準フレームワークの縛りを増やすこと
ベースフレームワーク(Spring)のスタンダードから逸脱した構成にすること
オレオレフレームワークを作ること

ベタープラクティス


柔軟に選択可能な状態
ベースフレームワーク(Spring)のスタンダードに沿った構成で使う
独自の作りこみがどうしても必要な場合はプラグイン的な実装にする
Spring Frameworkの理解を進める

Session8(R1-9.The Bootiful Microservice)


Spring BootでMicroservicesなサービスを開発するライブコーディング


start.spring.io の Cloud部分をメインに


Netflixは600以上のサービスから構成されている


一元管理されたコンフィギュレーションが重要


共通化された1バイナリのデプロイができる


spring-cloud-config-server が全Microservicesのコンフィギュレーションを管理する(これのライブコーディング)


bootstrap.properties


Cloud Bus AMQPにより全Microservicesにコンフィギュレーションの変更を一斉に周知できる


Eureka Server


ParameterTypeReference


API Gateway - Edgeサーバの追加(AWSのじゃない)


Integration Component


Zero instanceの際のFallback


@EnableFeignClient


@EnableZuulProxy


@EnableCircuitBreaker


Hystrix Dashboard


@EnableHytrixDashboard


/hystrix.stream


分散システムのパターンをサポートする