「入門Spring Boot&Spring Cloud」に行ってきた
2017年1月23日(月)のJJUG、JSUG共催のナイトセミナー「入門Spring Boot&Spring Cloud」に参加してきました。
その時のメモになります。
さくっと理解するSpring Bootのしくみ by 小川岳史さん
http://www.slideshare.net/OgawaTakeshi/spring-boot-71285225
1.Spring と Spring Boot の関係
- Spring Boot = Spring - 面倒な設定 + 組み込みTomcat
2.Spring Boot が改善する開発プロセス
- 必要なライブラリのリストアップ
- 依存性関係の記述が楽になる。
- バージョンの互換性を解決する。
- 起動に必要なBeanの定義をする
- よく使う Bean を自動で定義してくれる。(Auto Configure)
- 自作 Bean を使いたい場合はそこだけ記述する。
- プログラミング
- Tomcat 内包で生産性が上がる。
- コードの変更をビルド時に検知し、オートリロードがかかる。
- パッケージング・デプロイ
- 実行可能 jar でパッケージングできる。(Fully Executable Jar)
- モニタリング
- エンドポイントの自動配備(ブラウザでエンドポイントの情報が見られる。)
3.Spring Bootの構成要素
Core: 起動が楽になる
Starter: ライブラリ同士のバージョン互換を解決
- 実態は pom のみで、自分でStarterを作成できる。
Auto-Configure: 自動でBeanを準備してくれる
Actuator: アプリのモニタリング
- Cloud Nativeなアプリの作成時に Cluoud がアプリのことを知るために必要なあるあるエンドポイント(ヘルスチェックやメトリックスなど)を自動的に用意してくれる。
- Spring Cloud フレンドリ
Test: Junitのユーティリティ
Tools: 開発効率を上げる便利ツール
- Springの自動再起動
- 2つのクラスローダー
- 再起動用: よく変更するクラス(自作のクラス)
- 非再起動用: 外部 Jar で読み込んでいるクラスファイルなど
- Tomcatの再起動ではなく、DIコンテナ(= Spring)のリロード
よく変更するクラスファイルだけを再読込し、再起動する。
(Tomcat のリスタートよりかは速い。)
| Spring | ← ここだけを再起動
| Tomcat |
| JVM | - LiveReload(自動でリロードしてくれるブラウザのプラグインに対応)
- 開発時のデフォルトプロパティ
application.properties に設定を手動で記載しなくても Spring Boot Devtools がデフォルトでセットしてくれる。
4.質問
Spring Boot の仕組みを理解する上で見ておくといいソースコード
- AutoConfigure
- BeanDefinitions
- Core
ぱぱっと理解するSpring Cloudの基本(熊谷一生さん&Xiaozhou Jiaさん)
http://www.slideshare.net/kazukikumagai1/spring-cloud
Spring Cloud とは
- Cloud Nativeなアプリを作るための便利なツールの集合体
- Cloud Nativeのメリット
- 変化に強い
- 性能のスケールアウト
- 障害に強い
1.Spring Cloud おさえておきたい基本技術
- Cloud Native の特徴
2.Service Discovery, Client-side Load Balancing
- 発生しうる問題
- 急激なリクエスト増加
- 機能追加による負荷の偏り
- 解決策
- サービスの多重化
- Service Discovery: Eurekaサーバ(≠DNS)の導入
- Client-side Load Balancing: 要求元がアクセスサーバを決定
- サービスの多重化
- 実現する3ステップ
- @EnableEurekaService でEurekaサービスを作成
- @EnableEurekaClient でEurekaサービス登録
- @LoadBalanced で負荷分散
3.Circuit Breakerで障害検知・対応
- 発生しうる問題点
- 1ヶ所の障害でサービス全体が応答しなくなる可能性(1サービスの障害が全体に波及する。)
- 解決策
- 障害時の規定の動作を定義
- 障害を検知した場合、事前に定義した既定の応答を返す。
- 実現する2ステップ
- @EnableCircuitBreaker でCircuit Breaker の有効化
- @HystrixCommand で障害時の既定動作を定義
4.ConigServerで設定情報を集中管理管理
- 発生しうる問題
- サービスの数だけ設定ファイルが存在。
- 設定変更が大変で不整合の恐れあり
- 解決策
- 設定ファイルの集中管理
- Gitで設定ファイルの保管し、Configサービスで設定ファイルを取次ぐ
- 実現する2ステップ
- @EnablConfigService でConfigsサービスを作成
- @EnablConfigClient でConfigクライアント作成
5.疑問点
- 設定を集約管理して信頼性は大丈夫か?SPOFになるのでは?
- Eurekaの冗長化(AZ毎にEurekaサーバを用意する。)
- Eureka 同士がお互いを登録し合い、常に情報共有している
- 障害時にEureka同士が持っている情報が異なる場合がある。
Eurekaの考え方が Availability > Consistency (ただしバランスが大事)
Config First or Discovery First
- Config First !!!
- Config First Bootstrap
Configを起動 -> ConfigからEurekaの情報を取得 -> Eurekaへ登録 - Discovery First Bootstrap
Eurekaを起動 -> ConfigをEurekaへ登録 -> EurekaからConfigの情報を取得 -> Configへ問合わせ
- Config First Bootstrap
- Config First !!!
EurekaとDNSの違い
- DNSより、Sevice Registryと負荷分散が簡単にできる