1月23日、
JJUG ナイト・セミナー 「入門Spring Boot&Spring Cloud」
を聞いてきた！
SpringMVCを中心とした、フレームワークのフレームワークであるSpring Bootについては
確かに入門したが・・・
Springのクラウドを使う為のユーティリティ（ロードバランサとか）のSpring Cloudについては
う～ん、入門できなかったかも・・
ということで、とにかく、聞いた内容をメモメモ
■さくっと理解するＳｐｒｉｎｇＢｏｏｔのしくみ
・自己紹介
・今日話すこと
SpringとSpring Bootの関係
使われる機会増えた：Bootでてきてから
Spring Bootがカイゼンする開発プロセス
Spring Bootの構成要素
・そもそもSpringってなに？
Springフレームワーク
・SpringとSpring Bootの関係
ざっくり言えば
Spring - spring config（面倒な設定排除） + Tomcat = Spring Boot
・一般的な開発のプロセス
１．必要なライブラリのリストアップ
２．起動に必要なＢｅａｎの定義をする
３．プログラミング
４．パッケージング・デプロイ
５・モニタリング
１．必要なライブラリをリストアップ
最小限で記述できる仕組み：
pom,gradleに記載する記述少なくなる
ライブラリのバージョン互換性をキープしたまま依存性注入
２．起動に必要なＢｅａｎの定義をする
同じようなＢｅａｎ定義→Ｂｏｏｔ側が持っている
Ｂｅａｎ定義が自動的になされる：オリジナルの動作変更もできる
３．プログラミング
Ｔｏｍｃａｔ内包。生産性が上がる
デモ：は上手くいかなかったので省略
４．パッケージング・デプロイ
実行可能Ｊａｒでパッケージングできる
５．モニタリング
ヘルスチェック、ＲＥＳＴ ＡＰＩエンドポイント自動生成
・Ｓｐｒｉｎｇ Ｂｏｏｔの仕組み
Ｓｐｒｉｎｇ Ｂｏｏｔの構成要素 ７つのコンポーネント
core:DIコンテナの起動楽に
Starter：ライブラリ同士のバージョン互換
AUto-configure：自動でBeanを定義
CLI：ＣＬＩで作れる
Actuator：エンドポイントを提供（モニタリング）
Test：JUintユーティリティ
Tools：自動再起動など
・Core
起動が簡単に
Ｔｏｍｃａｔがないほうされている
Jetty,Undertowに置き換えできる
Tomcat7から組み込み版対応→Spring Bootが組み込んだ
Fully Excutable jar
１つにパッケージング
ubar jar(fat jar)→どんなものかわからなくなる
→Spring BootはNested jar(Jarの中にJarを入れる）
特殊なクラスローダーがある
Maven Gradle、Excutableをtrueにする
・Starters
実体：pomしかない
自分でＳｔａｒｔｅｒを作れる
・Auto-configure
進化した設定の簡易化
いままでＸＭＬで定義→Java config→進化した設定の簡易化Ｂｏｏｔ
@conditipnalOnClass/Bean
必要なＢｅａｎだけを定義
クラスパスにクラスがあるかないかでＢｅａｎの定義を切り分け
→実行時に自動的に判断
・Ａｃｔｕａｔｏｒ アプリのモニタリング
クラウドネイティブなアプリを付けるとき
Spring Cloudフレンドリ
マイクロサービスの状態チェック
・Ｔｏｏｌｓ
Dev Tools：
オートマチックリスタート
設定で有効になる：２つのクラスローダー（再起動用、非再起動用）
２つのクラスローダーの使い分け
JRebel Spring Loaded：リロードになっている
Live Reload
自動でリロードしてくれるブラウザのプラグインに対応
→Ｆ５を押す手間なくなった
開発時のデフォルトプロパティ
・Maven/Gradle plugin
Maven→Ｇｒａｄｌｅ
地味にビルドを助けてくれるプラグイン
・まとめ
Spring Bootのはじめかた
ＩＤＥ：いんてりＪ、ＳＴＳ，Ｅｃｌｉｐｓｅ
イニシャライザー
ＣＬＩ
↓
Ｍａｖｅｎ・Ｇｒａｄｌｅ
↓
メインメソッド実行でＴｏｍｃａｔ
・むすびに
ちょっとしたカイゼンの積み重ねで開発が楽になる
アイデアがＧｏｏｄ
クラウドサービスの登場：Ｊａｖａがお手軽に
Ｑ＆Ａ
・内部構造でのポイント
Ａｕｔｏ－ｃｏｎｆｉｇｕｒｅのソースコード
Ｂｅａｎ Ｄｅｆｉｎｉｔｉｏｎｓ
・ＳｐｒｉｎｇＭＶＣとＡＯＰは？
ＡＯＰ：ＳｐｒｉｎｇフレームワークのＣｏｒｅプロジェクト
ＭＶＣ：Ｃｏｒｅのソースコード
・ＵＩはTimeleafをつかうけど、ＪＳＰをつかったら？
ＪＳＰがＨＴＭＬとロジックをまぜこぜにする点で・・・
不都合はないが、選ぶ理由がない
マニュアルに避けろと書いてある
組み込みで動かないことがある
■ぱぱっと理解するSpring Cloudの基本
・自己紹介
・Spring Cloudとは
クラウドネイティブアプリのツールの集合体
・クラウドネイティブなメリット
変化に強い、
性能のスケールアウト
障害に強い
・Ｓｐｒｉｎｇ Ｃｌｏｕｄで抑えておきたい基本技術
そもそもできること
クラウドネイティブなアプリ
マイクロサービスアーキテクチャ→疎結合
サービスの多重化：処理性能・耐障害性
・要素を簡素化した題材で基礎技術
結合した文字列を返す
りんごとペンを結合する Uh
もし、爆発的な人気が出たら・・・
・サービスディスカバリとクライアントサイドロードバランシング
発生しうる問題：集中
→多重化
Eurekaサービス：DNSみたいなもん
アプリ名、ＩＰアドレス、ポート番号
【実際のコーディング】
３ステップ
１）Eurekaサービスの立ち上げ ：イニシャライザー
依存関係にEurekaサーバー追加
２）サービス登録：Eurekaディスカバリ
３）ロードバランスで負荷分散：リボンを追加 Ｒｅｓｔ Ｔｅｍｐｌａｔｅを介して
・サーキットブレーカーで障害検知
１箇所の障害でサービス全体が応答しなくなる可能性
→障害時の規定の動作を定義、継続性を担保
→サーキットブレーカーパターン
【実際のコーディング】
２ステップ
１）EnableCircuitBreaker：Hystrix追加
２）HystrixCommandで障害の規定動作の指定
・Config Serverで設定情報の集中管理
サービスの数だけ設定ファイル：設定変更が大変、不整合の恐れ
→設定ファイルの集中管理
configサービスとgit
設定ファイルの更新
Ｇｉｔ更新
refresh要求：管理者→アクチュエーターで
設定の再取得
【実際のコーディング】
２ステップ
１）EnableConfigServiceでConfigサービス立ち上げ
→イニシャライザーで設定ファイル
Ｇｉｔ側アプリ名.propertiesでプッシュ
２）EnableConfigClientでクライアント作成
アクチュエーター経由で環境変数の確認
http://アプリ名/env
Ｓｐｒｉｎｇ Ｃｌｏｕｄを使ってみて感じた疑問
・信頼性は大丈夫（ＳＰＯＦの問題）
→必要に応じて冗長化の必要がある
実際にはＬＢの後に複数のＣｏｎｆｉｇインスタンスをおく場合が多い
・Eureka冗長化の考え方
可用性＞整合性
Eureka動詞の間にお互い登録
→障害時、Eureka同士が持っている情報がずれている場合がある
・Config First or Discovery First
Config firstでしょう（ただし、両方とも動く）
config first：Configサーバーを起動→Eurekaへ登録
Discovery First：Eurekaを起動→Configを登録
→必要に応じて検討
・EurekaとＤＮＳの違い
サービスレジストリと負荷分散
Eurekaだと、アノテーションを付けるだけ
ミドルウエアか、アプリか→検討
・おわりに
本セッションは基礎に絞って紹介
Ｑ＆Ａ
・パフォーマンスは？
アプリレイヤでやるので、パフォーマンスは・・
それなのにアプリでやるのは、柔軟にできる点
・Ｓｐｒｉｎｇ Ｃｌｏｕｄのデザインパターンみたいなまとめはないの？
ＣｌｏｕｄＦｏｕｎｄｒｙが流行ってるよね。
ＳｐｒｉｎｇＣｌｏｕｄ公式ドキュメンテーションにいろいろある
・アクセスキューの動的制御は？
動的スケールアウト：ないかなあ・・・？
・悪意のあるユーザーがいたら？
デフォルトで認証機能が有効でない
認証してね
・ロードバランシングのカスタマイズは？
メトリクスの取得は？
クラスで定義、注入する
パフォーマンス：Ｓｐｒｉｎｇ Ａｃｔｕａｔｏｒはリアルタイムで情報見える
・開発コスト
マイクロサービスをどう考えるか
・整合性担保
おなじリポジトリを見るので、いつかは整合性：Config
Eureka：一人でも動くようになっている
■ＣＭ
・ＪＳＵＧでＳｐｒｉｎｇ勉強会
・年１回 Ｓｐｒｉｎｇ Ｄａｙ→１０月中旬
JJUG ナイト・セミナー 「入門Spring Boot&Spring Cloud」
を聞いてきた！
SpringMVCを中心とした、フレームワークのフレームワークであるSpring Bootについては
確かに入門したが・・・
Springのクラウドを使う為のユーティリティ（ロードバランサとか）のSpring Cloudについては
う～ん、入門できなかったかも・・
ということで、とにかく、聞いた内容をメモメモ
■さくっと理解するＳｐｒｉｎｇＢｏｏｔのしくみ
・自己紹介
・今日話すこと
SpringとSpring Bootの関係
使われる機会増えた：Bootでてきてから
Spring Bootがカイゼンする開発プロセス
Spring Bootの構成要素
・そもそもSpringってなに？
Springフレームワーク
・SpringとSpring Bootの関係
ざっくり言えば
Spring - spring config（面倒な設定排除） + Tomcat = Spring Boot
・一般的な開発のプロセス
１．必要なライブラリのリストアップ
２．起動に必要なＢｅａｎの定義をする
３．プログラミング
４．パッケージング・デプロイ
５・モニタリング
１．必要なライブラリをリストアップ
最小限で記述できる仕組み：
pom,gradleに記載する記述少なくなる
ライブラリのバージョン互換性をキープしたまま依存性注入
２．起動に必要なＢｅａｎの定義をする
同じようなＢｅａｎ定義→Ｂｏｏｔ側が持っている
Ｂｅａｎ定義が自動的になされる：オリジナルの動作変更もできる
３．プログラミング
Ｔｏｍｃａｔ内包。生産性が上がる
デモ：は上手くいかなかったので省略
４．パッケージング・デプロイ
実行可能Ｊａｒでパッケージングできる
５．モニタリング
ヘルスチェック、ＲＥＳＴ ＡＰＩエンドポイント自動生成
・Ｓｐｒｉｎｇ Ｂｏｏｔの仕組み
Ｓｐｒｉｎｇ Ｂｏｏｔの構成要素 ７つのコンポーネント
core:DIコンテナの起動楽に
Starter：ライブラリ同士のバージョン互換
AUto-configure：自動でBeanを定義
CLI：ＣＬＩで作れる
Actuator：エンドポイントを提供（モニタリング）
Test：JUintユーティリティ
Tools：自動再起動など
・Core
起動が簡単に
Ｔｏｍｃａｔがないほうされている
Jetty,Undertowに置き換えできる
Tomcat7から組み込み版対応→Spring Bootが組み込んだ
Fully Excutable jar
１つにパッケージング
ubar jar(fat jar)→どんなものかわからなくなる
→Spring BootはNested jar(Jarの中にJarを入れる）
特殊なクラスローダーがある
Maven Gradle、Excutableをtrueにする
・Starters
実体：pomしかない
自分でＳｔａｒｔｅｒを作れる
・Auto-configure
進化した設定の簡易化
いままでＸＭＬで定義→Java config→進化した設定の簡易化Ｂｏｏｔ
@conditipnalOnClass/Bean
必要なＢｅａｎだけを定義
クラスパスにクラスがあるかないかでＢｅａｎの定義を切り分け
→実行時に自動的に判断
・Ａｃｔｕａｔｏｒ アプリのモニタリング
クラウドネイティブなアプリを付けるとき
Spring Cloudフレンドリ
マイクロサービスの状態チェック
・Ｔｏｏｌｓ
Dev Tools：
オートマチックリスタート
設定で有効になる：２つのクラスローダー（再起動用、非再起動用）
２つのクラスローダーの使い分け
JRebel Spring Loaded：リロードになっている
Live Reload
自動でリロードしてくれるブラウザのプラグインに対応
→Ｆ５を押す手間なくなった
開発時のデフォルトプロパティ
・Maven/Gradle plugin
Maven→Ｇｒａｄｌｅ
地味にビルドを助けてくれるプラグイン
・まとめ
Spring Bootのはじめかた
ＩＤＥ：いんてりＪ、ＳＴＳ，Ｅｃｌｉｐｓｅ
イニシャライザー
ＣＬＩ
↓
Ｍａｖｅｎ・Ｇｒａｄｌｅ
↓
メインメソッド実行でＴｏｍｃａｔ
・むすびに
ちょっとしたカイゼンの積み重ねで開発が楽になる
アイデアがＧｏｏｄ
クラウドサービスの登場：Ｊａｖａがお手軽に
Ｑ＆Ａ
・内部構造でのポイント
Ａｕｔｏ－ｃｏｎｆｉｇｕｒｅのソースコード
Ｂｅａｎ Ｄｅｆｉｎｉｔｉｏｎｓ
・ＳｐｒｉｎｇＭＶＣとＡＯＰは？
ＡＯＰ：ＳｐｒｉｎｇフレームワークのＣｏｒｅプロジェクト
ＭＶＣ：Ｃｏｒｅのソースコード
・ＵＩはTimeleafをつかうけど、ＪＳＰをつかったら？
ＪＳＰがＨＴＭＬとロジックをまぜこぜにする点で・・・
不都合はないが、選ぶ理由がない
マニュアルに避けろと書いてある
組み込みで動かないことがある
■ぱぱっと理解するSpring Cloudの基本
・自己紹介
・Spring Cloudとは
クラウドネイティブアプリのツールの集合体
・クラウドネイティブなメリット
変化に強い、
性能のスケールアウト
障害に強い
・Ｓｐｒｉｎｇ Ｃｌｏｕｄで抑えておきたい基本技術
そもそもできること
クラウドネイティブなアプリ
マイクロサービスアーキテクチャ→疎結合
サービスの多重化：処理性能・耐障害性
・要素を簡素化した題材で基礎技術
結合した文字列を返す
りんごとペンを結合する Uh
もし、爆発的な人気が出たら・・・
・サービスディスカバリとクライアントサイドロードバランシング
発生しうる問題：集中
→多重化
Eurekaサービス：DNSみたいなもん
アプリ名、ＩＰアドレス、ポート番号
【実際のコーディング】
３ステップ
１）Eurekaサービスの立ち上げ ：イニシャライザー
依存関係にEurekaサーバー追加
２）サービス登録：Eurekaディスカバリ
３）ロードバランスで負荷分散：リボンを追加 Ｒｅｓｔ Ｔｅｍｐｌａｔｅを介して
・サーキットブレーカーで障害検知
１箇所の障害でサービス全体が応答しなくなる可能性
→障害時の規定の動作を定義、継続性を担保
→サーキットブレーカーパターン
【実際のコーディング】
２ステップ
１）EnableCircuitBreaker：Hystrix追加
２）HystrixCommandで障害の規定動作の指定
・Config Serverで設定情報の集中管理
サービスの数だけ設定ファイル：設定変更が大変、不整合の恐れ
→設定ファイルの集中管理
configサービスとgit
設定ファイルの更新
Ｇｉｔ更新
refresh要求：管理者→アクチュエーターで
設定の再取得
【実際のコーディング】
２ステップ
１）EnableConfigServiceでConfigサービス立ち上げ
→イニシャライザーで設定ファイル
Ｇｉｔ側アプリ名.propertiesでプッシュ
２）EnableConfigClientでクライアント作成
アクチュエーター経由で環境変数の確認
http://アプリ名/env
Ｓｐｒｉｎｇ Ｃｌｏｕｄを使ってみて感じた疑問
・信頼性は大丈夫（ＳＰＯＦの問題）
→必要に応じて冗長化の必要がある
実際にはＬＢの後に複数のＣｏｎｆｉｇインスタンスをおく場合が多い
・Eureka冗長化の考え方
可用性＞整合性
Eureka動詞の間にお互い登録
→障害時、Eureka同士が持っている情報がずれている場合がある
・Config First or Discovery First
Config firstでしょう（ただし、両方とも動く）
config first：Configサーバーを起動→Eurekaへ登録
Discovery First：Eurekaを起動→Configを登録
→必要に応じて検討
・EurekaとＤＮＳの違い
サービスレジストリと負荷分散
Eurekaだと、アノテーションを付けるだけ
ミドルウエアか、アプリか→検討
・おわりに
本セッションは基礎に絞って紹介
Ｑ＆Ａ
・パフォーマンスは？
アプリレイヤでやるので、パフォーマンスは・・
それなのにアプリでやるのは、柔軟にできる点
・Ｓｐｒｉｎｇ Ｃｌｏｕｄのデザインパターンみたいなまとめはないの？
ＣｌｏｕｄＦｏｕｎｄｒｙが流行ってるよね。
ＳｐｒｉｎｇＣｌｏｕｄ公式ドキュメンテーションにいろいろある
・アクセスキューの動的制御は？
動的スケールアウト：ないかなあ・・・？
・悪意のあるユーザーがいたら？
デフォルトで認証機能が有効でない
認証してね
・ロードバランシングのカスタマイズは？
メトリクスの取得は？
クラスで定義、注入する
パフォーマンス：Ｓｐｒｉｎｇ Ａｃｔｕａｔｏｒはリアルタイムで情報見える
・開発コスト
マイクロサービスをどう考えるか
・整合性担保
おなじリポジトリを見るので、いつかは整合性：Config
Eureka：一人でも動くようになっている
■ＣＭ
・ＪＳＵＧでＳｐｒｉｎｇ勉強会
・年１回 Ｓｐｒｉｎｇ Ｄａｙ→１０月中旬
アクセス
トータル
ランキング
