miya10kei’s diary

2017年1月23日（月）のJJUG、JSUG共催のナイトセミナー「入門Spring Boot&Spring Cloud」に参加してきました。
その時のメモになります。

さくっと理解するSpring Bootのしくみ by 小川岳史さん

必要なライブラリのリストアップ
- 依存性関係の記述が楽になる。
- バージョンの互換性を解決する。
起動に必要なBeanの定義をする
- よく使う Bean を自動で定義してくれる。（Auto Configure）
- 自作 Bean を使いたい場合はそこだけ記述する。
プログラミング
- Tomcat 内包で生産性が上がる。
- コードの変更をビルド時に検知し、オートリロードがかかる。
パッケージング・デプロイ
- 実行可能 jar でパッケージングできる。（Fully Executable Jar）
モニタリング
- エンドポイントの自動配備（ブラウザでエンドポイントの情報が見られる。）

Core：　起動が楽になる
- Tomcatが内包されている。 → Jetty, Undertow にも置き換え可能。
- Spring Boot が作成する Fully Executable Jar = Nested Jar ≠ uber.jar(fat.jar)
Starter：　ライブラリ同士のバージョン互換を解決
- 実態は pom のみで、自分でStarterを作成できる。

Auto-Configure：　自動でBeanを準備してくれる

以下のアノテーションで、Bean生成制御が行われる。（自作Beanにも付与可能）

アノテーション	説明
@ConditionalOnBean	Context に ○○Bean があれば Bean を生成する。
@ConditionalOnMissingBean	Context に ○○Bean がなければ Bean を生成する。
@ConditionalOnClass	classpath に ○○クラスがあれば Bean を生成する。
@ConditionalOnMissingClass	classpath に ○○クラスがなければ Bean を生成する。

CLI：　雛形をCLIベースで作れる
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 がデフォルトでセットしてくれる。

Cloud Native の特徴
- 小さな単位のアプリに分かれている（マイクロサービスアーキテクチャ）
- メリット
  - 疎結合で変化・機能追加に強い Dを追加しても
  - サービスの多重化による処理性能向上・対障害性向上

発生しうる問題
- 急激なリクエスト増加
- 機能追加による負荷の偏り
解決策
- サービスの多重化
  - Service Discovery:　Eurekaサーバ（≠DNS）の導入
  - Client-side Load Balancing：　要求元がアクセスサーバを決定
実現する3ステップ
1. @EnableEurekaService でEurekaサービスを作成
2. @EnableEurekaClient でEurekaサービス登録
3. @LoadBalanced で負荷分散

発生しうる問題点
- 1ヶ所の障害でサービス全体が応答しなくなる可能性（1サービスの障害が全体に波及する。）
解決策
- 障害時の規定の動作を定義
- 障害を検知した場合、事前に定義した既定の応答を返す。
実現する2ステップ
1. @EnableCircuitBreaker でCircuit Breaker の有効化
2. @HystrixCommand で障害時の既定動作を定義

発生しうる問題
- サービスの数だけ設定ファイルが存在。
- 設定変更が大変で不整合の恐れあり
解決策
- 設定ファイルの集中管理
- Gitで設定ファイルの保管し、Configサービスで設定ファイルを取次ぐ
実現する2ステップ
1. @EnablConfigService でConfigsサービスを作成
2. @EnablConfigClient でConfigクライアント作成

設定を集約管理して信頼性は大丈夫か？SPOFになるのでは？
- 必要に応じて冗長化は必要。
  実際には、LBのあとに複数のConfigインスタンスをおく場合が多い
Eurekaの冗長化（AZ毎にEurekaサーバを用意する。）
- Eureka 同士がお互いを登録し合い、常に情報共有している
- 障害時にEureka同士が持っている情報が異なる場合がある。
  Eurekaの考え方が Availability > Consistency (ただしバランスが大事)
Config First or Discovery First
- Config First !!!
  1. Config First Bootstrap
    　Configを起動　-> ConfigからEurekaの情報を取得　-> Eurekaへ登録
  2. Discovery First Bootstrap
    　Eurekaを起動 -> ConfigをEurekaへ登録 -> EurekaからConfigの情報を取得 -> Configへ問合わせ
EurekaとDNSの違い
- DNSより、Sevice Registryと負荷分散が簡単にできる