Application Advisorを用いた継続的なアップグレード
Keynoteセッションの最後に登壇したBroadcom社Tanzu部門のDeveloper AdvocateであるCora Iberkleid氏は、VMware TanzuがSpringアプリケーションのライフサイクル全体を支援する最適なプラットフォームであることを、具体的な機能説明を通じて紹介しました。その内の一つが、Application Advisorです。
Application Advisor については、DaShaun Carter氏のセッション「Survival Guide to Continuously Align and Upgrade Your Spring Dependencies」でより詳しく紹介されています。Carter氏の言葉によれば、Application AdvisorはSpringベースのアプリケーションにおける依存関係とフレームワークのアップグレードを「一度の大規模移行」ではなく、「継続的かつ自動化された小刻みに移行」することを実現するツールです。SBOMの解析⇒アップグレード計画の自動生成⇒（OpenRewriteという移行ツールの）レシピ適用⇒PullRequest自動作成⇒検証という一連の流れをCI（Continuous Integration）に組み込み、安全にアップグレードを進められるとともに、開発者の負担を減らすことができるようになるとのことです。
従来の移行方法であるDependabotやSnykによるフレームワークの自動的なアップグレードについて、有用性は認められつつも、一度に大きなアップグレードをすることに伴う「破壊的な変更」の影響や、多数の「推移的依存に起因するビルドエラー」を招きやすい点が課題であるとされていました。Carter氏はこの様なアップグレードを開発者任せにするのではなく、プラットフォームと自動化に寄せることが重要であることを強調し、この課題を解決する方法の一つがApplication Advisorを用いたアップグレードパイプラインの整備であると述べました。
Application AdvisorはOpenRewriteという移行ツール（レシピと呼ばれるYAML形式の書き換えルールを用い自動的にソースコードの書き換えを実施するツール、レシピは既に公開されているもの利用することも独自に定義することもできる）を利用しています。同じく OpenRewriteを利用した「SpringBoot Migrator」というツールの経験を元に作られており、以下の様な仕組みとなっています。
- リポジトリをスキャンしてSBOMを作成し、利用しているJavaのバージョンやビルドツール、依存関係を検出したうえで、アプリケーションの現在地を可視化する。
- 「Java11からJava17へ、SpringBoort 2.6 から 2.7へ、最後に SpringBoot 3.0へ」といった段階的なアップグレードのプランを立てる。
- プランごとにOpenRewriteのレシピを自動適用し、コード変更や依存関係の更新を包括的に実施する。
- 実施した変更内容をもとにPullRequestを発行し、テストが通るまで自動的に検証する。（PullRequestは自動的にマージすることも、開発者がレビューしてからマージするようにすることもできる）
このように「継続的かつ自動化された小刻みの移行」を実現することで、破壊的な変更を局所化しつつ問題点の早期検知とロールバックが容易になります。特にSpringチームが提供するフレームワークについては、CVEが公開された時点で最新のパッチを提供しているため、このような自動化を活用することで迅速にパッチを適用することができ、開発者への負担を軽減しつつ、情報漏洩などでニュースになってしまうリスクを回避することもできます。
加えて、Application Advisorはアップグレードの実現だけではなく「アドバイス」という強力な機能を提供しています。アプリケーションの内容を分析してSpringにおけるベストプラクティスや非推奨なままとなっている実装の書き換えを提案することに留まらず、「利用しているミドルウェアとの組み合わせ」において性能・セキュリティ・信頼性が最適となるような実装をSpringチームの知見をもとに提案してくれるそうです。
また、レシピやJava要件の定義をすることでSpringに含まれない外部のOSSや独自の共通ライブラリに対応することもでき、それらを自動化のパイプラインに組み込むことでアップグレードプロセスがSpringだけではなくシステム全体をカバーできるようになる点についても補足されました。
マイクロサービス、モノリス、モジュラモノリス
Keynoteセッションでは言及がなかったものの、この数年継続的に扱われているトピックの一つがSpring Modulithによるモジュラモノリスアーキテクチャの実装です。Cora Iberkleid氏とGlenn Renfro氏のセッション「Of Microservices and Monoliths, and Everything in Between」では、マイクロサービス、モノリス、モジュラモノリスそれぞれの特徴と選び方を解説し、モノリスなシステムからモジュラモノリス、そしてマイクロサービスへと変化させる方法が紹介されました。
モノリスは一体型のアプリケーション構造であり1つのパッケージとしてまとめられます。一方でマイクロサービスは機能ごとに独立した小さなサービスに分割したアーキテクチャです。モジュラモノリスではモノリス内に独立したモジュール構造を持つことでモノリスとマイクロサービスの中間的立ち位置になります。モノリスとマイクロサービスは相反するメリット、デメリットを持つため、モジュラモノリスも重要な選択肢であると解説されました。
実際には1つのアーキテクチャで統一することは難しく、3つの方式が混在することも十分にあり得ると言及しています。モジュラモノリスとマイクロサービスの比較については、別の比較表も共有されています。
講演ではRest Bucksと呼ばれるコーヒーを注文できるアプリを例に、Spring Modulithを使ってモノリスからモジュラモノリスへ変更する方法が紹介されました。デモに使用したリポジトリはこちらに公開されています。
Spring Modulithではルートパッケージ直下のサブパッケージを独立したモジュールとして扱うため、パッケージ構成をmodel、view、controllerなどのアプリケーションレイヤ単位で密結合に設計している場合は、ドメイン駆動設計の考えに沿ってorder、paymentといったドメイン単位のパッケージ構成にリファクタリングする必要があります。このリファクタリングの際にもSpring Modulithはテストコードにおけるモジュール依存関係のチェック機能や、リファクタリングを段階的に進めるために既存のMVCモデルのコードをモジュールとして参照可能にできる機能が利用できます。
リファクタリング以外でも、Spring Modulithはモジュール関係のドキュメント生成機能やイベントが中断された際のリトライ処理、分散トレースによる一連のモジュール呼び出しの流れを可視化できるなど、設計から運用までを想定した機能が提供されています。
次に、ステップを踏みながらモジュラモノリスの機能の一つを切り出し、マイクロサービス化するデモが披露されました。
マイクロサービスへの移行前にモジュラモノリス化することで、アプリケーション内がドメインに基づいてモジュール化され、マイクロサービスとして抽出した際に問題が生じた場合にも原因の切り分けが簡単になるというメリットがあり、移行ステップを効率的に進めることができると説明されました。
Spring ModulithはSpring Boot 4.0に対応したバージョン2.0のリリースが予定されており、さらなる発展を計画しているそうです。
まとめ
以上、SpringOne 2025の主要トピックをまとめてレポートしてきました。改めて、現在の技術トレンドの中心が生成AIであることがよく分かると同時に、Springが今も進化を続けていることが伝わってくるイベントだったと感じます。急速に変化する生成AI関連技術をSpringがどのように取り込んでいくのか、今後も目が離せません。
