Spring in Summer 2015 行きました。

マイクロサービスアーキテクチャの設計

SLIDE

MSAの2つの側面

技術面
文化面

分散配置と統合

機能をどうやって持続させるか＝サービス
サービス同士を協調させること
メッセージングで統合→標準プロトコルを使って繋ぐ（HTTP, REST...）

持続と分権

ソフトウェア開発がゴールではない。
サービスを運営することが興味の対象になってきている。

ドメインごとの自主性を認めて 標準化を否定する

みんな標準化フレームワーク嫌いだよね

サービス全体を再構築するのはできないけど、部分的に再構築が可能。

捨てることを前提にしたアーキテクチャ。

何故出てきたか

Webサービスのレガシー化

Amazonクソでかい

サービス共有の一般化→クラウド

コーディングでサービスを管理できるようになった。

MSAは理想論じゃなくて、現実解。

みんな同じようなアーキテクチャ採用してたからこういう名前を付けたよ。

MSAを理解する

技術論よりも技術管理論

MSAは優れた技術に支えられている

MSAというものがあって、それを使えば何か解決するわけじゃない。

粒度じゃなくて関係性の問題。

システムとサブシステムの例とか多いけど、粒度は別にこだわらなくていい

SOAとMSA

SOA:トップダウン
- 理想の世界
- 全体最適
MSA:ボトムアップ
- 現実解
- 部分最適の集合
- 実際にはこうするしかないよね、的なある種の諦め

アーキテクチャは統治の手法

乱立＝封建制
- あるシステムとシステムのやりとりがバッチだったり
- それぞれバラバラに統治されてる
SOA＝君主制
- 標準化による統治
- 偉大な王がいれば可能
- 企業全体を見渡して全体最適を考えられるならできる
- 変化の激しいWebサービスとかだとうまいこといかない
MSA＝民主制
- 各システムにそれなりにできる人がいる

大体人の問題！！！

MSAは銀の弾丸ではない

辺境の独立国家
暴君がいる
有識な市民の存在

SOAとMSAは補完的な考え方である

アーキテクチャの逆襲

ここ数年で柔軟性なアーキテクチャができるようになった
これまではプロセスでカバーしていた（＝アジャイル）

キャパシティプランニングできるアーキテクチャができるようになった

アジャイルもそうだけど、結局自分ができるところをやればいいんだな、って思うわ。

MSAのデザイン

MSAは複雑なものをどうにかするためにやるもの

前提：企業システムにおける適用

レガシーを保全・変化の許容を両立

ドメイン＝変化の境界線

ドメインというものがあるわけじゃなくて、結果的に境界線があってそれに名前付けたのがドメイン。

変化の境界線を見つけるのが重要。

例：車の部品
地面に接して減ってくものだから車本体とは別の材質になってるし、色んなメーカーがある。

変化の境界線は大体不明瞭だけど線を引くしかない

ドメインを1回引くと変えたくない

プラットフォーム

バランスをいかに取るか

現時点ではプラットフォームを先に決めた方が楽

単一プラットフォームにしちゃうのも大変

プライベートPaaSはこれから取り組んでいかないといけない部分

MSAの実例

ECサイトがわかりやすいと思う

ECサイトはけっこう社会的責任がある

企業システムがすでにあってECサイトを開くパターンでレガシーとの連携が発生する

ECサイトの機能のレイヤーでそれぞれあったプロセスがあるからMSAになってるとやりやすい

境界が明確だからプラットフォームをクラウドで部分適用するのは可能

サービスと運営主体の近さもけっこうポイント

まとめ

MSAにする、というよりもMSAになったなら使ってもいい

ドメインとプラットフォームのバランスが難しい

独立させすぎるとムダが増える

良識的な市民が多いかどうかはけっこう重要。

Spring Bootだけじゃない！

大規模エンタープライズにおける、最新のフロントエンド・アーキテクチャへの挑戦

UXに興味漏ってる人達増えてきてる

ドメインモデリングは大規模でやって抽象化しちゃうと分けわかんなくなるからやらない。

ミドルウェアを替えられない問題

アプリに影響が出てきてヤバイ。
まあそりゃあそうだな。

ログ出力機能作り込んでる

トランザクションスクリプトなので全部トレースログ出してる。
アプリに関する障害はこれでほぼいける。

なぜSpring MVCを採用したのか

アプリ開発方式変えられない →
組織の役割分担変えられない →
ミドルウェアは変えられない → Spring MVCにするだけ

この前に聞いたセッションでMSAの話聞いたせいかよけいにんおおお、ってなった。
だからMSAにするんじゃないのかな、って。

ランチセッション Wagbyの紹介

ジャスミンソフトさん提供の沖縄弁当が最高に美味しかった。

Wagbyという開発ツール。
自動生成するツール。

モデルベース

Wagbyは話し聞いてるとすごいよくできてて、できてるんだけど作るのめっちゃ大変だっただろうな、って思った。
そしてその投資が回収できるほど売れるのかはよくわかんねえな、と思った。

the Micro of Microservices

キーノート。
機材トラブルで画面が表示されなかったｗ

コードとプロダクションの溝を埋めたい。
これらは非常に重要。

Open Sourceと叫ばされましたｗ

早く、頻繁にプロダクションに移行するには？

クラウド

昔は待ち行列がドンドン増えていく
リーン開発をソフトウェアでもやろう

DevとOpsの二つのチームが一つのチームにして早くしよう。

DevelopmentチームとOperationチームの対立

全体のシステム＝オペレーションだけでもなく、ソフトウェアだけでもなく、全部。

お客さんはプラットフォームを作りたい→クレイジーだ

ソフトウェアの人は物理的なチップ、それを動かす電気・発電を気にする必要はない。
コモディティ化してるから。
これを考えるのはムダ。

インフラを管理する必要はない。

GCPやらなんでも使えば、低レベルなところは気にしなくていい。

ドメイン、機能を明らかにしていくのを繰り返す。
これが重要。

Googleとかじゃなきゃ十分かもしれん。
Art of Scalability

インターネットのトラフィックの80%がNetflixじゃないか説

できる限り自動化して縦軸を排除する。
コードベースが小さくなる。

MSAになるとドメインというものが重要になってくる。

軽量なユニットテストを何回もやる。
1ヶ月かけて素晴らしいするよりも、早くたくさん回す事の方が大事。

Observe Orient Decide Act
Innocation BigData Culture Cloud

軍事的な用語。
ソフトウェアでも使える。

細かいサービスを作っていると次の問題が出てくる

サービスレジストレーション＆ディスカバリー

Spring DIと大規模プロジェクト、春は来るのか本当に？

HUE HUEだよ！

500人規模、言語の壁・技術レベルの壁がある

最初はできるだけSpringで構成した

構成の変遷

MariaDB → Cassandra、Elasticsearch

@Chachable → バグがあった

本題 DIの話

要求が高いｗ

応答速度は100msであってほしい。

@Autowired使ってますか！

SpringならAutowiredの恩恵は受けたい

だがしかし…

AP起動時間が遅くなっていく
- 瞬間的にスケールしたい
プロジェクト間の依存関係
DIって？

じつはめっちゃくちゃになってるんじゃないか？

そもそおもDIなんでやるの？

Modularity の担保
- 実装とインターフェース分離
- フレームワークの設定は@Importで管理
速度も考慮
- ComponentScanしない

Modularityを担保

全部を一個にしちゃわない
- warで一個にすると楽だけど…

ComponentScan-Autowiredに胸躍る

10人くらいでやってたときは問題なく使えた。

問題発生

依存関係が謎、解決できない
- 推移的依存解決で色んなもんが必要になるから…
- ありがたいけどありがたくない
起動時間遅い
- basePackageで対象パッケージを指定して解決
- コンストラクタでDB読み込みをするアホがいた
プラグイン的に使いたい
- プラグインが要求するものが分からない

人が増える＝jarが増える

ComponentScanしない

速度を重視してScanしないようにする
@Componentは自前で管理
例外的にプラグインはスキャンする

@Configurationを有効活用

@Importもちゃんと使う

@Qualifierは複雑だから使いたくない

@GuardedConfigurationを作った。
これで二重登録防止。

もっと厳密なルールがある。
Configにも適用。

結果

モジュラリティ向上
テストが楽になった
- 依存が透過的になってわかりやすい

まとめ

人が増えると…

知識が薄まる
成果物が増える

小さく作ることが大事！！！

おまけ

傾聴

開発者野口に敏感になろう！！

作りにくい
時間かかる
なんでだ？
なんか怒ってる、諦めてる（そんな雰囲気）

QA

Q. ComponentScanやめてどれくらい速くなった？
A. 2，3分くらいは速くなった

Bootiful Applicatio

ロックンロール！！

Spring Boot始めるには

CLI
start.spring.io
etc...

Springの開発チームはみんなのために日夜がんばってるから禿げ上がってるらしいｗ

Joshのライブコーディングスムーズすぎてすごかった。

Spring Framework/Boot/Data徹底活用～Spring Data Redis編～

Spring Data Redisの話。

Spring Data Redisとは

RedisCacheManagerを利用することでChache機構と連携可能

@Cacheable

Redis構成の選択肢

Redis Cluster
- Redis 3.0から
- ちゃんと可用性を考慮すると6大のノードが必要
Redis Sentinel
Load Balancer

Spring + Redis Cluster

Spring まだ対応してない

Spring + Redis Sentinel (masterへのアクセス）

Sentinelにアクセスできないと無限に起動しない
最低1台は起動時に繋がる必要がある

Spring + Redis Sentinel (slaveへのアクセス)

Slaveへのコネクションが別途必要

Spring + VIP

シンプル。
1台を見ればOK
MultipulJedisConnection

まとめ

実運用に耐えられるようにするためにはある程度カスタマイズする必要がある

Spring適用のアンチパターンとベストプラクティス(仮)

何に使ってる？

社内標準
自社プロダクト
日曜プログラミング

Springの採用はかなり広がっている実感がある

ConfluenceではSpring使ってる
JetBrainsも

バッドノウハウ

社内標準開発時

Spring Framework 3.0を採用した → GOOD!!!
- ナレッジベースがでかい方がいい
- 現状を見るとよかった
Wicketを採用した → BAD!!!
- フレームワーク縛ってしまった
- IEのモーダルウィンドウとかに対応しようとして辛かった

一般的なSpringプロジェクトの構成

せめてViewは柔軟にかえれるようにしとくべきだった。

組織にフレームワークを採用するメリット/デメリットを共有しといた方がよかった

Strutsみたいな構成にしてしまった

適切な責務分割

オレオレフレームワーク

オレオレフレームワークあるある

ドキュメント不足
フレームワークに縛られるインフラ
- Javaのバージョン上げられないとか
継続サポートない
新しい技術に対応できない
フレームワークのクセが仕事になる
- それバグじゃね

オレオレフレームワークはやめよう！
ダメ絶対！

バッドノウハウまとめ

周辺アーキテクチャ縛らない
基本のレイヤデザインにしたがおう

ベタープラクティス

ベストとは言い切れないのでベター。

リポジトリレイヤーを抽象化して、データソースを切り替えられるようにする

着脱可能な実装を意識して作る

レガシーな部分も多いけど、Spring始めたところはエキサイトしてる！！

The Bootiful Microservice

Spring Cloudでコードがほとんどなくなる
Spring Bootの知識が必要

単一アプリケーションを作るよりもずっと複雑だけど、それを上回るメリットがある。

去年JJUG CCC Fall 2014でウケたハンズオンとけっこうかぶってた。
でももう一回見てもやっぱりすごかった。