Tomcat 9からIBMサポート付きJavaアプリケーションランタイム「WebSphere Liberty」へ移行してみた

はじめに

Apache Tomcatは、多くのJava Webアプリケーションで利用されているオープンソースのJavaアプリケーションサーバーです。

一方、企業システムでは、次のような理由からベンダーサポート付きのJavaランタイムが求められることがあります。

• 問い合わせ窓口を明確にしたい
• 障害発生時にベンダーの技術支援を受けたい
• 脆弱性に対する修正提供を製品サポートのもとで受けたい
• 製品のサポート・ライフサイクルに沿って運用したい

また、Apache Tomcatプロジェクトは、Tomcat 9.0.xのサポートを2027年3月31日に終了する予定です。

Tomcatの新しいバージョンへの更新も選択肢ですが、この機会に、商用サポート付きのJavaランタイムへの移行を検討するケースもあるでしょう。

そこで本記事では、Tomcat 9で動作しているWebアプリケーションを、IBMの製品サポートを利用できるWebSphere Libertyへ移行します。

今回検証したのは、次の2つのパターンです。

1. 標準的なServlet/JSPアプリケーションを、WARを変更せずに移行する
2. Tomcat固有機能を含むアプリケーションを、移行ツールを活用して移行する

先に結論を書くと、次の結果になりました。

移行パターン	結果
標準APIを中心としたアプリケーション	同じWARをLibertyへ配置するだけで動作した
Tomcat固有機能を含むアプリケーション	固有部分の変更は必要だったが、移行ツールで簡単にLibertyへ移行することができた

TomcatからLibertyへの移行は、すべてを作り直す作業ではありません。
標準APIを使用している部分はそのまま活用し、Tomcat固有の部分だけを確認・変更することで、段階的に移行できます。

WebSphere Libertyとは

WebSphere Libertyは、IBMが提供する軽量なJavaアプリケーションランタイムです。Servlet、JSP、JPA、JAX-RSなど、アプリケーションが必要とする機能だけを「フィーチャー」として選択し、有効化できます。

また、Libertyは、ゼロ・マイグレーション・ポリシーという方針を採用しています。
servlet-4.0やservlet-5.0のように機能をバージョン番号付きのフィーチャーで指定するため、ランタイムを更新したあとも既存のフィーチャーを使い続けられ、新しいフィーチャーへ切り替えるタイミングを利用者が判断できます。

さらに、Libertyはオンプレミスだけでなく、コンテナやクラウドでも利用できます。既存のWARを活用した移行から始め、必要に応じてコンテナ化やクラウドネイティブ化へ段階的に発展させられる点も、Libertyへ移行するメリットです。

Tomcat 9からLibertyへの2つの移行パターン

Tomcat 9からWebSphere Libertyへの移行方法は、アプリケーションがTomcat固有の機能にどの程度依存しているかによって変わります。

本記事では、移行方法を次の2つに分けて検証します。

パターン1: WARを変更せずそのまま移行できる場合

Tomcat固有部分のないアプリケーションでは、WARを変更せず、Libertyへ配置するだけで動作する可能性があります。

具体的には、以下のようなアプリケーションを指します。

• ServletやJSPなどの標準APIを使用している
• 必要なライブラリーがWARに含まれている
• org.apache.catalina.*などのTomcat固有APIを使用していない
• TomcatのValveやRealmを使用していない
• Tomcat側のJNDI設定や共通ライブラリーに依存していない
• 外部TomcatへWARを配置する形式である

この場合の主な移行作業は、次の3点です。

1. Libertyで必要なフィーチャーを有効化する
2. Tomcatで使用していたWARをLibertyへ配置する
3. アプリケーションの動作を確認する

Tomcat 9
  └── application.war
          │
          │ 同じWARを配置
          ▼
WebSphere Liberty
  ├── 必要なフィーチャー
  └── application.war

パターン2: Tomcat固有部分がある場合

Tomcat固有のAPIやサーバー構成を使用しているアプリケーションでは、その部分をLiberty向けに置き換えることで移行を進めます。

例えば、次のような機能を使用している場合は、移行ツールで影響範囲を確認しながら、必要なコードや構成を変更します。

• org.apache.catalina.*などのTomcat固有API
• ValveやRealm
• context.xmlに定義したDataSourceやJNDIリソース
• CATALINA_HOME/libなどの共通ライブラリー
• AJP Connector
• Tomcatのセッション・レプリケーション
• データベース、LDAP、メッセージキューなどの外部リソース

この場合は、WARだけでなく、Tomcatの構成や外部リソースも移行対象になります。

Tomcat 9
  ├── application.war
  ├── context.xml
  ├── Realm / Valve
  ├── 共通ライブラリー
  └── 外部リソース
          │
          │ 分析・変換・修正
          ▼
WebSphere Liberty
  ├── application.war
  ├── server.xml
  ├── 認証設定
  ├── 共有ライブラリー
  └── 外部リソース接続

この場合でも、すべてのコードや構成を手作業で調査する必要はありません。

後述する移行ツールを使用することで、Libertyへの移行にあたって確認・修正が必要な箇所を洗い出し、AIの支援を受けながら修正を進めることができます。

実際に試してみる

ここまで、Tomcat 9からLibertyへの移行方法を、アプリケーションがTomcat固有機能に依存しているかどうかという観点で整理しました。

ここからは、それぞれのパターンについて、実際にサンプルアプリケーションを使用して移行を試します。

まず、標準的なServlet/JSPアプリケーションをTomcat 9で動作させ、同じWARを変更せずにLibertyへ配置します。
続いて、Tomcat固有APIやDataSource、Valveを含むアプリケーションを用意し、AMAとIBM Bobを活用してLiberty向けに移行します。

パターン1: WARを変更せずそのまま移行できる場合

最初に、標準的なServlet/JSPアプリケーションを移行します。

検証したアプリケーション

今回のサンプルアプリケーションでは、次の機能を使用しました。

• Servlet 4.0
• JSP 2.3
• HTTPセッション
• 日本語表示
• web.xml
• javax.*名前空間

Tomcat固有APIやValve、Realm、Tomcat側のDataSourceなどは使用していません。

サンプルアプリケーションをMavenでビルドし、WARファイルを作成しました。

Tomcat 9で動作を確認する

作成したWARをTomcatのwebappsディレクトリーへ配置し、アプリケーションを起動しました。

確認結果は次のとおりです。

確認項目	Tomcatでの結果
JSPが正常に表示される	OK
Servletを呼び出せる	OK
日本語が文字化けしない	OK
HTTPセッションが維持される	OK
ログにアプリケーションエラーがない	OK

実行中のサーバー情報には、次の値が表示されました。

Apache Tomcat/9.0.120

HTTPセッションについても、同じCookieを使用して複数回アクセスすることで、アクセス回数が増加することを確認しました。

1回目のアクセス: 1
2回目のアクセス: 2
3回目のアクセス: 3

同一のWARをLibertyへ移行したことを確認するため、移行前のWARのSHA-256を取得しました。

shasum -a 256 target/tomcat-liberty-sample.war

取得した値は次のとおりです。

2b0e40fd3432707437251e259e07998839fce215d1215f696822e0d4afc4bbdc

Libertyに移行する

Libertyでは、アプリケーションに必要なServlet 4.0とJSP 2.3のフィーチャーを有効化しました。

使用したserver.xml（サーバーの構成ファイル）の主要部分は次のとおりです。

<server description="Tomcat 9 migration sample">

    <featureManager>
        <feature>servlet-4.0</feature>
        <feature>jsp-2.3</feature>
    </featureManager>

    <httpEndpoint
        id="defaultHttpEndpoint"
        host="*"
        httpPort="9080"
        httpsPort="9443" />

    <webApplication
        id="tomcatLibertySample"
        location="tomcat-liberty-sample.war"
        contextRoot="/tomcat-liberty-sample" />

</server>

構成している内容は次の3点です。

• Servlet 4.0を有効化する
• JSP 2.3を有効化する
• Tomcatで使用したWARをアプリケーションとして登録する

Tomcatで動作確認したWARを変更せず、Libertyのappsディレクトリーへ配置しました。
このパターンで新たに行ったのは、Liberty側のフィーチャー有効化とアプリケーション配置の設定だけです。

Libertyで動作を確認する

Libertyを起動し、動作を確認しました。

Tomcatと同じ確認を実施したところ、JSP、Servlet、日本語表示、HTTPセッションのすべてが正常に動作しました。

実行中のサーバー情報には、次の値が表示されました。

IBM WebSphere Liberty/25.0.0.6

検証結果

結果を比較すると、次のようになりました。

確認項目	Tomcat 9	Liberty
JSP	OK	OK
Servlet	OK	OK
日本語表示	OK	OK
HTTPセッション	OK	OK
WARのSHA-256	一致	一致

TomcatとLibertyへ配置したWARのSHA-256は、どちらも次の値でした。

2b0e40fd3432707437251e259e07998839fce215d1215f696822e0d4afc4bbdc

この結果から、今回使用した標準Servlet/JSPアプリケーションについては、WARを変更せずに、実行ランタイムをTomcat 9からLibertyへ変更できました。

パターン2: Tomcat固有部分がある場合

次に、Tomcat固有の機能を使用したアプリケーションを移行します。

今回は、次の3つをサンプルアプリケーションへ意図的に追加しました。

• /catalina-info: Tomcat固有APIを使用する
• /db: context.xmlで定義したDataSourceを使用する
• Valve: レスポンスへX-Audited-Byヘッダーを追加する

Tomcatでは正常に動作する

Tomcat上では、3つの機能が正常に動作しました。

Libertyへの移行時に変更が必要な箇所を確認する

まず、Tomcatで動作しているアプリケーションを、コードや構成を変更せずにLibertyへ配置しました。

標準APIを使用しているServlet/JSPの部分はそのまま動作しましたが、Tomcat固有API、context.xmlのDataSource、Valveを使用している部分は、Liberty向けの実装または構成への置き換えが必要でした。

結果を整理すると、次のようになります。

機能	そのまま移行	Liberty向けの対応
標準的なServlet/JSP	可能	変更なし
Tomcat固有API	要変更	標準APIなどへ置き換える
context.xmlのDataSource	要変更	LibertyのDataSource構成へ移行する
Valveによるヘッダー追加	要変更	Servlet Filterなどへ置き換える

この結果から、アプリケーション全体を作り直す必要があるのではなく、Tomcat固有の部分を特定して置き換えればよいことが分かります。

小規模なアプリケーションであれば、ソースコードやTomcatの構成を手作業で確認することもできます。一方、実際の業務環境では、複数のアプリケーション、共有ライブラリー、JNDIリソース、データベース、LDAP、メッセージキュー、認証設定、Webサーバー連携、クラスタリング構成など、多くの依存関係が存在する可能性があります。

このような環境でも、最初からすべてを手作業で調査する必要はありません。IBM Application Modernization Acceleratorというツールを利用すると、アプリケーションとTomcatの構成をまとめて分析し、標準APIのまま利用できる部分と、Liberty向けに変更する部分を整理できます。

AMAで変更箇所と移行計画を確認する

IBM Application Modernization Accelerator (AMA) は、既存のアプリケーション環境を分析し、モダナイゼーションの計画や優先順位付けを支援するツールです。

（AMAの画面の例）

対象環境でデータを収集し、その結果をAMAへ取り込むことで、次のような情報を確認できます。

• アプリケーションの一覧
• アプリケーションの構造
• 共有ライブラリー
• データベースなどの外部依存関係
• 移行時に確認が必要な箇所
• 移行の複雑度
• 移行にかかる推定工数の比較

Tomcat環境をスキャンする

まずはAMAでワークスペースを作成し、Discovery Tool をダウンロードします。
Discovery Toolは移行元環境からアプリケーションやサーバー構成、依存関係などの情報を収集するためのツールです。

移行元としてTomcatを選択し、画面に表示される手順に従って対象環境をスキャンします。

Discovery Toolでは、アプリケーションだけでなくサーバー構成も収集できます。
WARだけでは把握できない共有ライブラリーやJNDIリソースを調査する場合は、サーバー構成も含めて収集することが重要です。

移行先としてLibertyを選択する

Discovery Toolによる分析結果をAMAへアップロードし、移行先としてLibertyを選択します。

変更が必要な箇所を確認する

分析が完了すると、Libertyへの移行時に確認または変更が必要な項目が一覧で表示されます。

さらに、手動でコードを修正する必要がある箇所と、ツールによる支援が可能な箇所を確認できます。

Libertyへ配置して発生したエラーを一つずつ調べる方法では、実行した処理に関係する問題しか確認できない可能性があります。
AMAを使用すると、アプリケーションとTomcatの構成をまとめて分析し、移行前に対応箇所を把握できます。

これにより、次の判断がしやすくなります。

• そのまま移行できるアプリケーションはどれか
• 変更が必要なアプリケーションはどれか
• どの部分を優先して対応するか
• 移行にどの程度の作業が必要か
• ツールで支援できる箇所はどこか

すべてのアプリケーションに同じ規模の修正が必要なわけではなく、AMAでの分析によって、そのまま移行できるものとTomcat固有部分だけを変更するものを仕分けられます。

Migration Planを取得する

アプリケーションの各ページからは、 Migration Plan をダウンロードできます。
Migration Planは分析結果をもとに、Libertyへの移行で対応すべき問題や構成情報をまとめた計画ファイルです。

このファイルを使用することで、実際のコード修正を効率的に実施できます。

AMAのメリットは、問題を検出できることだけではありません。
移行前に変更対象を一覧化し、Migration Planとして整理できるため、調査から実際の修正へつなげやすくなります。

IBM Bobでコードと構成の変更を進める

AMAで「どこを変更するか」を把握したあとは、手作業で各項目を修正することも可能ですが、今回は IBM Bob を使用してAIを活用しながら修正を進めていきます。

IBM Bobは、コードベース上で開発者と協働し、ソフトウェア開発を支援するAIパートナーです。

コード補完だけでなく、アプリケーションの分析、設計、実装、レビュー、モダナイゼーションなど、開発ライフサイクル全体を支援します。

30日間の無料トライアルでは、IBM Bobの利用に必要な「Bobコイン」を40コイン利用できます。

• 無料トライアル：https://bob.ibm.com/trial
• Bobコインの追加購入：https://bob.ibm.com/pricing

AMAが移行対象と変更箇所を可視化し、IBM Bobがその計画に沿ったコードや構成の修正を支援する、という組み合わせによって調査から修正までを一連の流れとして進められます。

Liberty Replatformingを実行する

IBM BobのアドオンであるPremium Package for Java Modernization では、Libertyへの移行を効率的かつ標準化された手順で実施できるワークフローを実行することができます。
Java Modernizationワークフローを実行し、Liberty Replatformingを選択します。

AMAからダウンロードした移行計画のファイルを、IBM Bobへアップロードします。

IBM Bobはアップロードされたファイルを参照し、AMAの分析で確認された修正対象を処理します。

分析結果をもとに移行計画とTodoリストが作成されるため、対応すべき作業を確認しながら移行を進められます。

ソースコードや構成ファイルの変更内容を確認しながら、修正を進めます。

手作業ですべて調査して書き換えるのではなく、Bobが示した移行計画とTodoリスト、コード修正を確認しながら作業を進められる点が大きなメリットです。

今回の流れを整理すると、次のようになります。

1. AMAでTomcat固有の依存関係を検出する
2. 変更が必要な箇所を一覧化する
3. Migration Planを作成する
4. IBM BobへMigration Planを取り込む
5. Todoリストに沿って修正する
6. 変更内容を確認する
7. Libertyで動作を検証する

修正後のアプリケーションをLibertyで確認する

修正したアプリケーションをLibertyへ配置したところ、正常に動作しました。

Tomcat固有APIを使用していた処理についても、標準APIなどを使用する実装へ変更され、Liberty上で動作することを確認できました。

検証結果

移行前後の結果を整理すると、次のようになります。

確認項目	Tomcat	Libertyへ最初に配置した時点	AMA・IBM Bobで対応後
標準Servlet/JSP	OK	OK	OK
Tomcat固有APIを使う機能	OK	要変更	OK
DataSource接続	OK	要変更	OK
追加のリクエスト・レスポンス処理	OK	要変更	OK

標準的なServlet/JSPはそのままLibertyで動作し、Tomcat固有の部分もAMAで変更箇所を可視化してIBM Bobで修正することで動作しました。
つまり、Tomcat固有機能を含むアプリケーションでも、全体を作り直すのではなく、必要な部分を特定して効率的に移行できます。

まとめ

今回の検証から、標準APIを中心に構成されたTomcatアプリケーションであれば、想像していたよりもずっと簡単にLibertyへ移行できることが分かりました。

パターン1では、Tomcat 9で動作していたWARを変更せずにLibertyへ配置し、既存環境と同じように動作しました。
アプリケーションを変更せずにランタイムだけを移行できています。

パターン2では、Tomcat固有の箇所をLiberty向けに置き換える必要がありました。
AMAで変更箇所と移行計画を可視化し、IBM Bobで修正を進めた結果、Tomcat固有機能を含むアプリケーションも簡単にLibertyへ移行できました。

今回の検証から、TomcatからLibertyへの移行は、必ずしもアプリケーション全体の作り直しを必要としないことが分かりました。
標準APIを使用している部分はそのまま活用し、Tomcat固有の部分だけを特定して変更することで、既存資産を活かした移行が可能です。

また、Libertyは必要なフィーチャーだけを有効化できる軽量なランタイムで、オンプレミスだけでなくコンテナやクラウド環境でも利用できます。
まずは既存のWARをLibertyへ移行し、将来的にはコンテナ化やクラウド展開へ発展させるなど、段階的なモダナイゼーションの第一歩として検討してみてはいかがでしょうか。