Spring in Summer 2015 行きました。
マイクロサービスアーキテクチャの設計
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でウケたハンズオンとけっこうかぶってた。
でももう一回見てもやっぱりすごかった。