JSUG勉強会 2020 その2 Spring Boot 1.x から 2.x への移行 に行ってきた #jsug

Spring メモ

JSUG勉強会 2020 その2 Spring Boot 1.x から 2.x への移行 に行ってきました。簡単に所感をまとめます。

jsug.doorkeeper.jp

所感

普段あまり他社さんのバージョンアップの話を聴く機会は多くないかと思うので、なかなか興味深い内容でおもしろかったです。バージョンアップの流れとかハマりどころとかまとまった情報は重宝しそう。

細いけど、非推奨な機能を使ってるときに警告を出力する設定にしたり、小まめに PR してレビューコストを削減 (分散？) するのがわりとポイントかなと思ったり。

Micrometer の話は、去年の Spring Fest でも聴いたけど、とても便利そうだし使ってみたいです。なかなか使える機会がないけど...。(そもそも Boot アプリじゃない)

あとで読む。

以下、メモから抜粋。

決済サービスの Spring Boot のバージョンを2系に上げた話

www.slideshare.net

  • 2.x のリリースは 2018/03 なので 1.x を使ってる場合じゃない
  • 2.0.x は EOL 間近なので早めにアップデート
  • 2.0.x は Gradle 4+
  • バージョンアップ作業は半年くらい
  • まずは Gradle のバージョンをあげる
  • --warning-mode all が便利
    • Gradle 5 で非互換になる機能を出力してくれる
  • implementation
    • マルチジュール構成でハマった
    • モジュールが双方向に依存してるとつらい
  • プロジェクト直下の build.gradle でバージョン一元管理
  • hibernate-validator => javax.validation
  • spring-boot-starter-json
  • コネクションプールが Tomcat から HikariCP に
    • プロパティが url から jdbc-url に
  • HtmlEmail で null のときに Exception 投げるように
  • AWS X-Ray の SQL トレースで HikariCP が使えない
  • Flyway が2バージョンあがる (3.x ⇒ 5.x)
  • @ConfigurationProperties の prefix は必ずケバブケースで書く
  • Gradle と Lombok のバージョン相性問題
    • ClassCastException が起きる、などなど

Spring Boot 1.5 → 2.1 バージョンアップを経験して分かったハマりどころ

  • Migration Guide & Release Note でざっくり把握
  • 小さいリポジトリから着手
  • 変更点が多いのでモブレビューでコスト削減
    • 一気にPRすると大変なので小出しにする
  • maven-compiler-plugin の warning と非推奨ログを出力するように
  • Spring Data JPA
    • Query By Example のみに
    • PK による検索は *ById を使う
  • 2.1 から Bean の override はデフォルト禁止
    • allow-bean-definition-overriding で変更可
  • Mockito の any* や any(class) では null 禁止
    • isNull() か any() を使う
    • そもそも引数が nullable かどうか見直すこと
  • spring-boot-properties-migrator
    • 旧verの書き方のときに warning を出力してくれる
  • @SpringBootTest による結合テスト大事
  • バージョンアップをやり切ってから機能追加する

Metrics with Micrometer in Spring Boot 2

docs.google.com

  • 1.x でも /metrics は使える
    • 階層的なメトリクスしか対応してない
    • 時間計測は未対応
    • ネーミングの標準化は未対応
  • Micrometer
    • SLF4J のようなもの
    • 抽象化している
    • バックエンドに送るところは実装による
    • タグなどを使うことで多次元に分析できる
  • Spring とは別のプロジェクトで開発されている
  • 問題検知 & 分析
  • ログとは別にメトリクスを管理することでストレージを節約
  • 普段はインメモリでメトリクスを保持
    • いいタイミングでバックエンドに publish する
  • ネーミングルールなどのバックエンドによる違いは Micrometer が吸収してくれる
  • カスタムメトリクスを作るときはネーミングルールに気を付けること
  • 複数のバックエンドに publish することも可
  • publish する間隔はデフォルト1分
  • Controller で HTTP リクエストのメトリクスを取ると便利 (ステータスコードとか)
  • not boot アプリでも利用可
    • もちろん Auto Configuration ではない
  • 多次元の分析ができるバックエンドがおすすめ
    • Prometheus, Datadog など
  • jvm の shutdown-hook で publish する実装になっている