はじめに
こんにちは、開発部の古川です。
普段は、ぐるなびの認証や個人情報、ポイントシステムといったぐるなび内の各サービスから利用される共通システムを担当しています。
今回は、私たちが担当しているシステムにおける JavaのEOSL (End of Support Life) 対応 について、検証から意思決定までの取り組みをまとめました。
現状について
扱っているシステムの特性上、なるべく無停止で安定したものが要求されます。
そのため、大きなシステム改修などは行わず、最低限の保守に留める運用となっていました。
しかし、オンプレミス環境のOSがEOSLを迎えるにあたり、オンプレミスのままリプレースをするか、クラウドにマイグレーションしていくかの検討を進めてきました。
まず、数年前の事例をお話しします。
当時、個人情報管理システムのAWS移行を機に、Java 6からJava 8へのアップデートを実施しています。
他のシステムは個人情報を扱うシステムよりも比較的新しく、新規開発時に当時、最もサポート期間が長く、かつ最新だったJava 8を採用しています。
これによって、グループで担当しているJavaのシステムが全てJava 8に揃ったのですが、いつまでも使えるわけではありません。
利用しているフレームワークやライブラリなどのサポートもどんどん新しいバージョンのものが推奨されていくため、いつかは新しいバージョンにしなくてはなりません。
今後数年かけてオンプレ環境のOS移行があり、そのタイミングでオンプレ環境のリプレース、もしくは、AWSへの移行を行っていくことになるのですが、今回、JavaのEOSLを踏まえたバージョン選定も合わせて行うこととしました。
各バージョンのサポート状況
まず、主なバージョンの2025年12月時点のサポート期間について「Oracle Java SE Supportのロードマップ | Oracle 日本」などを参考に整理しました。
| サポート種別 | リリース | Premier Support 期間 | Extended Support 期間 |
|---|---|---|---|
| Java 7 | 2011年7月 | 2019年7月 | 2022年7月 |
| Java 8 | 2014年3月 | 2022年3月 | 2030年12月 |
| Java 11 | 2018年9月 | 2023年9月 | 2032年1月 |
| Java 17 | 2021年9月 | 2026年9月 | 2029年9月 |
| Java 21 | 2023年9月 | 2028年9月 | 2031年9月 |
| Java 25 | 2025年9月 | 2030年9月 | 2033年9月 |
Java 8のままだと最長でも2030年12月でEOSLを迎えてしまいます。
執筆時 (2025年12月) から5年の猶予があります。
しかし、全てのシステムを現在のリソースで対応していくには一気にやることはできず、1サービスずつ検証から移行まで進めていく必要があるため、余裕があるというわけでもありません。
今年やってみたこと
Javaの各バージョン毎の検証
認証系サービスの一部で今年度中に解決しないといけない課題があったため、まずはこの環境についてインフラ担当に依頼し、新しいOS環境の選定と払い出しを行ってもらい、グループ内で色々と検証を行いました。
検証は以下のポリシーで行いました。
- ソースコードには手を入れない
- Tomcat、フレームワーク、ビルドツールなどはJavaの各バージョンでサポートされているなるべく新しいものを使用する
- 設定ファイルなどの変更は必要に応じて行う
検証結果
| バージョン | 検証結果 | 備考 |
|---|---|---|
| Java 8 | ◯ | 問題なく動いた |
| Java 11 | ◯ | 問題なく動いた |
| Java 17 | ◯ | 問題なく動いた |
| Java 21 | △ | 動くけどビルド時に警告が出る |
| Java 25 | ー | 検証時点 (2025年中旬) では未リリースだったため対象外 |
どうやらJava 17までならソースコードに手を入れなくても移行はできそうという結果が得られました。
しかし、現時点でJava 17のサポート期間はJava 8より短く、Java 11にしたとしても13ヶ月しか伸びないことが分かりました。
Java 17のサポート期間が延長されればまだいいのですが……
とはいえJava 8からJava 21やそれ以上のバージョンへのジャンプアップでは、バージョンの乖離が大きくソースコードの変更が必須となり、一旦Java 17を経由して次を考えるのもアリなのでは？ということで一旦落ち着き、引き続きJava 8かJava 17の2つに絞って検討を進めました。
コード管理をGitLabからGitHubに
ここで、Javaのバージョンをどうするか決まりかけたタイミングで、コード管理に利用しているGitLabの利用をやめてGitHubに移行するという話が出てきました。
デプロイツールもJenkinsからGitHub Actionsを使ったものに切り替わり、これまで利用していたビルドツールをAntからGradleに変更して再度検証することになりました。
再検証結果
| バージョン | 検証結果 | 備考 |
|---|---|---|
| Java 8 | ◯ | 問題なく動いた |
| Java 17 | × | フレームワークやGradleのバージョン相性、およびGradle化に伴う依存関係解決の厳格化により、既存ライブラリの一部がそのままでは利用できなかった |
検証の結論
色々と検証をしましたが、今回は「サーバー移行」と「コード管理の刷新」を優先し、アプリケーションのランタイムについては、あと5年猶予のあるJava 8を一旦継続して利用することとしました。
一度に全てのレイヤーを刷新するリスクを避け、まずはインフラ基盤を整えてから、次なるステップとしてJavaのバージョンアップに取り組む計画です。
さいごに
Javaに限った話ではなく、サポート期間の長いシステムを構築したとしてもいつかはEOSLを迎え、避けて通れないということを改めて認識しました。
また、EOSL対応を行ったとしても、選んだシステムにもEOSLがあるわけで、システムを健全に保つために保守していくことの重要性について考えさせられました。
以上、ここまで読んでいただきありがとうございました。
