Spring Boot 2.7 から 3.1 への アップグレードに苦労したことと学んだこと

皆さんは Spring Boot のアップグレードにどれぐらいかかりましたか？
私は繁忙期を挟むなどして約半年間もの時間を費やしました。

Spring Boot 2.7 の OSS サポート終了を前に社内でもシステムの Spring Boot 2.7 から Spring Boot 3.1 へのアップグレードの話が持ち上がりました。
私はその主担当として、そして、初めての大きなアップグレードで苦労したこと、そして学んだこと、どうしてここまで時間がかかったのかをまとめました。
また、アップグレードによる影響を小さくする為に行った段階的なリリースについてもその概要を紹介します。

【要点】
アップグレードでの理想とギャップ
アップグレードでのつまづきポイント
上記のつまづきポイントに対して工夫したこと
アップグレードの影響を小さくする為の段階的なリリースの概要

【目標】
アップグレードのプロセスにおけるヒントの共有

【扱わないこと】
コードレベルでの詳細な説明

Transcript

1. Spring Boot 2.7 から 3.1 への アップグレードに苦労したことと学んだこと JJUG CCC 2024 Spring 2024.06.16 BABY JOB 株式会社 米岡 毅 @kometsubu_bj
2. 自己紹介 所属 BABY JOB 株式会社 開発部 手ぶら登園開発課 🍙チーム (2023年9月入社) 最近 2歳の娘の食育も兼ね色々な野菜を 家庭菜園しています 私から皆様へ イベント登壇初めてなので 暖かく見守ってください 米岡　毅 よねおか たけし こめつぶ🍙 | 2歳児のパパエンジニア@BABY JOB @kometsubu_bj
3. Ajenda 1. 前提
 2. 苦労したこと
 3. 学んだことを生かして
 4. まとめ
4. 前提 まずは 今日取り上げる内容と 私が苦労するきっかけとなった プロダクトの状態について ご説明します。
5. 今日取り上げる内容 • アップグレードでの理想とギャップ • アップグレードでのつまづきポイント • 上記のつまづきポイントに対して工夫したこと • アップグレードの影響を小さくする為の段階的なリリースの概要
6. 今日取り上げないこと • コードレベルでの詳細な説明
7. プロダクト プロダクトは以下の環境で動作しています。 • Java 21(Amazon Corretto) • Spring Boot 2.7
8. プロジェクトと私の状況 背景としては以下のような状態でした。 • アップグレードを見据えて動き始めたのは 2023/10 • 私は入社２カ月目 • プロダクトについて右が分かり始めた程度 • Spring Boot のアップグレードはやったことない • Spring Boot 3.1用のブランチを作成し、そこに全てを詰め込む方針 で進めた
9. 苦労したこと ここからが本題です。 まずは、私が苦労したことを 紹介します。
10. 予め情報収集したものと違う Case 1
11. 予め情報収集したものと違う 1 実際に適用する前に、リリースノートからどの辺りが変更になったのか を大まかに調べました。 キーワードやライブラリ、Spring Boot が依存するパッケージを検索し、 「そんなに影響範囲がない」と判断。
12. 予め情報収集したものと違う 2 なにが起きた？ ローカルでバージョンを上げると想定していないエラーが続出。 コード上のエラーを解消しても動作させて初めて出てくるエラーや画面 が表示できないなどのエラーが発生。 それらの対応を地道に潰すこととなり、想定以上にリリースまでの時 間がかかった
13. 予め情報収集したものと違う 3 なぜか？
14. 予め情報収集したものと違う 3 なぜか？ そう、ここです。
15. 予め情報収集したものと違う 3 なぜか？ そう、ここです。 入社２カ月目だったのでそんなにプロダクトのに詳しくなく 情報収集した内容だけで大まかなスケジュールを立ててしまったので す。 その結果、大幅なスケジュール変更が必要になりました。
16. パスの厳密化による確認・メンテに追われる Case 2
17. パスの厳密化による確認・メンテに追われる 1 どんな変更？ Spring Framework 6.0 からリクエストURIの厳密化が行われ、 トレイリングスラッシュ（URLの末尾のスラッシュ）の有無が 識別されるようになった。 そのため、/hoge/ と /hoge は別のURIとして扱われるようになった。 つまり、アプリ上でこれらの定義が混在しないように整理しないといけな い
18. パスの厳密化による確認・メンテに追われる 2 どう対応しようとした？ トレイリングスラッシュ無に統一。 トレイリングスラッシュ有でリクエストされた場合は、トレイリングスラッ シュ無のエンドポイントに処理を流すFilterクラスを作成。
19. パスの厳密化による確認・メンテに追われる 3 なにが起きた？ エンドポイントが 400 以上。 それらの定義が統一され、正しく呼び出されるのか。 アップグレード後に定義間違いでエンドポイントに到達できなくならない かの確認が必要でした。 画面から全てのエンドポイントを叩き、確認を行いました。
20. 認証パスの追加、慣れるまで忘れがち Case 3
21. 認証パスの追加、慣れるまで忘れがち 1 どんな変更？ Spring Security 6.0 から SecurityConfig で許可や認証の要否の定義 が、ブラックリスト型からホワイトリスト型に変更。 そのため、今まで定義していなかったパスを漏れなく定義する必要が あった。
22. 認証パスの追加、慣れるまで忘れがち 2 どう対応しようとした？ ローカルをSpring Boot 3.1にアップグレードし、認証不要なパスを洗い 出し、一つずつ定義を追加。 画面上から動作を確認。 エンドポイントの追加や変更があれば、都度取り込み、再度確認するを 繰り返す。
23. 認証パスの追加、慣れるまで忘れがち 3 なにが起きた？ 都度、本線の差分を取り込みメンテし続けなければならなかった。 自身でも慣れるまでは「認証パスに追加されてる？」とならず、はまるこ ともあった。 これが、地味だが面倒だった。
24. 学んだことを生かして 続いて、苦労したことから 学んだことを生かして 今後どうすればいいか 考えたことを紹介します。
25. 学んだことを生かして 1 調べるのも大切だけど、アップグレードしてみる。 リリースノートが全てではない。 Spring Boot 以外の部分も影響する可能性は大いにある！
26. 学んだことを生かして 2 パスの厳密化 → Configurer.setUseTrailingSlashMatch(false); 認証パスのホワイトリスト化 → denyAll() 何かしら次のバージョンを模す設定があり、それらを設定することで、 アップグレード前であっても同様の状態を再現することができる。
27. 学んだことを生かして 3 1. アップグレード後を模す設定を入れる 2. 対応する 3. １～２を繰り返す 4. アップグレードする 5. １の設定を削除する このようにして一見、全てを同時に対応しないといけないように考えられ るアップグレードを分割することができる
28. まとめ 最後にまとめましょう。
29. まとめ • 情報収集も良いけど、手を動かして現状を確認！ ◦ リリースノートも人が作っているので、漏れもある ◦ プロダクトも様々だし、合わないことだってある
30. まとめ • 一見大きなタスクに見えても、分割する方法はある！ ◦ そのヒントは実はマイグレーションマニュアルなどにある ◦ 柔軟な発想でタスクを分割
31. まとめ • けど ◦ プロダクト全体を見ることができた ◦ イベント登壇できる機会が得られたのはプラス
32. ご清聴ありがとうございました 良ければ、Xフォローお願いします。 こめつぶ🍙 | 2歳児のパパエンジニア@BABY JOB @kometsubu_bj