第10回『Java EEアプリケーションをコンテナの世界でも活用する：Open Libertyのすすめ』

記事をシェアする:

こんにちは。IBM Automation Softwareでテクニカルセールスをしている田中孝清といいます。20年以上にわたって、WebSphere Application Server(WAS)を利用したり検討したりしていただいているお客様の技術支援を担当しています。

今回は、コンテナ環境でJava EEアプリケーションを作成・実行するのに最適なアプリケーションサーバー、Open Libertyについてご紹介します。

コンテナの世界でもJava EEを活用するには

コンテナの世界では，マイクロサービスによるサービスメッシュスやサーバーレス，リアクティブシステムやCQRSによる高速処理など，多くの新しい技術が登場しています。これらは，これから業務システムを構築していこうと思っている技術者にとって，魅力的な選択肢となっていくでしょう。

しかし、いま現在、日本の多くのお客様ではエンタープライズJava仕様（Java EEやJakarta EE）にしたがって実装されたWebアプリケーションベースの業務システムを中心に利用されているでしょう。蓄積されてきたアプリケーションや、いままで使っていた技術を捨てないと、コンテナの世界に移行できないのでしょうか？

そんなことはありません。

たしかに、Java EEの実行環境を提供していたアプリケーションサーバーの多くは、コンテナ環境での実行には適さない、多くの制限を持ってしまっています。そのため、コンテナ環境ではいままでのやり方とはちがう手段でアプリケーションを実装するべきだという意見もあります。しかし、ここで紹介するOpen Libertyは、多くのお客様が使われているJava EEをつかって、コンテナ上で業務システムを構築するための最適な環境を提供します。ServletやJSP、JPAやJMSなど、いままで親しんできた技術をつかって、コンテナ上でのアプリケーションを作成することができるのです。

この文章では、一般にコンテナ環境で実行するアプリケーションに要求される要件のうち、いままでのJava EEアプリケーションサーバーでは難しかったものについて、Open Libertyではどう解決されるのかを紹介していきたいと思います。

Open Liberty

IBMが長年にわたって提供しているエンタープライズJavaの実行環境、WebSphere Application Server。1998年に最初のバージョンが出てから、標準仕様の進化にあわせて機能追加を繰り返してきた既存のランタイムは、モノリシックな実装が限界に達していました。そのままではCloud Nativeの世界に対応することが難しいということで、IBMではプログラムの根本的なリファクタリングを実施し、アプリケーションサーバーのカーネル部分から根本的に設計し直しました。そうして開発された新しいサーバーランタイムを2012年に公開されたWAS V8.5から提供しています。

これがWebSphere Libertyランタイムです。

Libertyは提供する全ての機能をモジュールとして実装しているため、新しい機能の追加が容易であり、短期間で高機能なアプリケーションサーバーに成長しました。現在は、WASの主要なランタイムとして広くご利用いただいています。

このWebSphere Libertyランタイムは、2017年からOSS（オープンソース・ソフトウェア）であるOpen Libertyとして開発されています。GitHub上でソースが公開され、問題修正のためのIssueや将来の新機能実装計画なども全て公開されています。EPL（Eclipse Public License）というライセンスで公開されており、どなたでも無償で利用することができます。製品版のWebSphere Libertyは、OSS版のOpen Libertyをほとんどそのまま取り入れており、稼働するアプリケーションや構成ファイルなどは、同じものを相互に利用することが可能です。

Open Libertyは、Cloud時代にあわせて新規に作成されたランタイムであるため、従来のアプリケーションサーバーをコンテナ環境で使用するさいの問題の多くを解決しています。Libertyを活用すれば、従来から利用していたJava EEのアプリケーションや開発スキルを活用して、コンテナ上でも利用することができるようになります。

Open Libertyはサイズが小さい

一般に、コンテナイメージのサイズはできるだけ小さくすることが望ましいとされています。ディスクなどのリソース消費量、起動にかかる時間、更新にかかるネットワーク通信時間など抑えることができるからです。多くのプログラムでリソースを共有するコンテナ環境では、これらは少なければ少ないほど、ダイレクトにコストに反映されます。また起動時間の短さは、オートスケールなどによる負荷耐性の性能にも影響するといわれています。

従来のJava EEアプリケーションサーバーというのは、巨大なプログラムでした。何年もバージョンアップを続けてきた導入後のディスクサイズは数Gバイトになることも珍しくありません。また実装されている全ての機能が常に有効化されているため、プロセスの起動には長い時間がかかり、多くのメモリやCPU資源を消費していました。

Open Libertyは、提供される機能の全てがFeatureという単位でモジュール化されており、本当に必要なものだけにしぼって有効にすることができます。これは、Java EEなどの大きな単位ではなく、JPAやCDIなど個別のAPIの単位で制御することができます。またモニタリング機能やセキュリティ機能などもそれぞれで有効化することができるようになっています。これらは単にプロセス起動時にメモリに読み込まれないようにするだけではなく、不要なFeatureをコンテナイメージに入れず、必要なFeatureのみを入れることもできるようになっています。そのため、Libertyのコンテナイメージは非常にコンパクトです。

コンテナイメージは、Docker Hubで公開されているものをみると、カーネル機能だけに限定したものは300Mバイトを切るサイズになっています。これはTomcatのイメージと比較しても、1割も差がありません。Libertyには、ここからアプリケーションで使用しているFeatureを追加していくのですが、それでも、300Mを大きく超えることはありません。

% podman images
REPOSITORY                       TAG                        IMAGE ID      CREATED       SIZE
docker.io/library/tomcat         jre8-temurin               3c0a24568bc0  5 hours ago   278 MB
docker.io/library/open-liberty   kernel-slim-java8-openj9   eb8922e7a12f  4 days ago    292 MB

コンテナのベストプラクティスには、イメージごとに1つのアプリケーションをパッケージングする、というものがあります。複数の機能をもつイメージを作成すると、運用や更新、負荷分散の構成に大きな制限をうけてしまうからです。しかし、従来のアプリケーションサーバーはあまりに数を多く立てることは現実的でなかったため、通常は一つのアプリケーションサーバーには多くのアプリケーションがデプロイされていました。

もちろんOpen Libertyでも一つのアプリケーションサーバーのインスタンスに複数のアプリケーションをデプロイすることはできます。ですが、Open libertyはスリムなランタイムであるので、アプリケーションごとに一つのコンテナを作ることが、リソースの観点から問題になりにくくなっています。

OpenLibetyは導入や構成が簡単

従来のアプリケーションサーバーは、GUIの画面や、対話式のコマンドを介して構成をおこなうのが一般的でした。このような構成手段は、人間が直接作業をおこなうには適していますが、コンテナのように機械的にビルドをおこなって環境を構築するのには適していません。

Open Libertyは、ZIPファイルで提供されている導入イメージを展開するだけで導入が完了しますし、構成ファイルを指定された場所にコピーするだけで構成ができます。アプリケーションの導入もファイルをディレクトリに置くだけです。これはコンテナのイメージを作成手順を記述するDockerfileなどの親和性が極めて高く、自分でコンテナイメージを作成したり、あるいは公式で提供されているイメージをカスタマイズしたりが簡単にできます。

Open Libertyの構成ファイルは、全ての設定項目にデフォルト値が決まっており、デフォルトから変更するものだけを記述するようになっています。そのため、多くの環境で構成ファイルは非常に簡潔であり、またどのような値が環境に合わせて設定されているのかを簡単に把握することができます。

また、Open Libertyの構成ファイルは可搬性が高く、一度作成したものを様々な場所にコピーして使うことが容易にできるように設計されています。環境変数や追加ファイルなどで構成内容をカスタマイズすることも簡単にできます。コンテナ環境では、実行時に外部から環境変数で情報を与えることが一般的におこなわれていますが、それらの情報をつかって構成をカスタマイズできるのです。

<!-- 環境変数HTTP_PORT/HTTPS_PORTが設定されていればそれを使う。
	 なければデフォルト値として9080/9443を使う。 -->
<variable name="http.port" defaultValue="9080"/>
<variable name="https.port" defaultValue="9443"/>
<httpEndpoint httpPort="${http.port}" httpsPort="${https.port}"
	host="*" id="defaultHttpEndpoint"/>

server.xml サンプル

マイクロサービスの実装も

Java言語を使ってマイクロサービスを実装するための標準仕様として、MicroProfileが多くのベンダーの協力のもと策定されています。MicroProfileは多くの仕様の集合です。そのなかには、REST通信で連携し合うアプリケーションに必要な仕様、複数のサーバーから構成されるアプリケーションで使うと便利な仕様が含まれています。コンテナやKubernetes上で実行しているアプリケーションに有用な仕様もあります。

ただ、それ以外の機能、DBと連携する機能やWebアプリケーションを実装する機能などはMicroProfile仕様には含まれていません。そのためMicroProfileにだけ対応したアプリケーションサーバーやフレームワークだと、業務アプリケーションを実装するのに必要な機能が十分でなかったりします。

Open Libertyは、Java EE/Jakarta EEとMicroProfileの両方に対応しています。そのため、両者を組み合わせたアプリケーションを作成し、利用することができます。Java EE仕様をつかって実装したWebアプリケーションの中から、MicroProfileの一部の機能だけを選んで使う、という事ができるのです。

たとえば、様々なソースからアプリケーションの構成情報を取得するMicroProfileの仕様として、Config APIがあります。Libertyでは、Servletの中からConfigを使って情報を取得したりすることができます。

@WebServlet("/configTest")
@ApplicationScoped
public class ConfitTestServlet extends HttpServlet {
    
	@Inject
	@ConfigProperty(name = "PWD")
	private String pwd;
	
	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException
	{
		response.setContentType("text/plain; charset=utf-8");
		response.getWriter().append("Currend directory: ").append(pwd);
	}

これはHttpServletを継承し@WebServletでアノテーションされた、典型的なJava EEのServletのコードです。このなかで、同じくJava EE仕様の一部であるCDIのアノテーションである@Injectとともに、MicroProfileのConfig APIのアノテーションである@ConfigPropertyが使われています。Open Libertyでは、このように普通にJava EEとMicroProfileの機能を混在させて使用することができます。

この@ConfigPropertyは、構成ソースから値を取得して変数にインジェクション（外部から代入）するためのアノテーションです。Libertyの提供するデフォルトの構成ソースには環境変数がふくまれているので、このようなコードで環境変数PWDを取得して、Servletで表示することができます。

一般に構成情報は、環境変数のほか、JVMのシステムプロパティや構成ファイル、JNDIなどの外部のサービスなど、様々な方法で与えられます。それらを取得するJavaのコードは、構成が提供される方法によってそれぞれ異なります。ですが、Config APIを使えば共通の方法で取得することができ、構成ソースの設定を変更するだけで異なる手段で構成情報をアプリケーションに提供することができるようになります。

このようにOpen Libertyをつかえば、Java EEの技術を使ってアプリケーションを作成しながら、サービスメッシュやマイクロサービスに対応した機能を実装することができるようになります。

コンテナ化が難しいJavaEEの仕様

ただ、Java EEのどんな機能でも、コンテナ上で使用できるわけではありません。コンテナ上では使用が困難なAPIも一部にあります。具体的には、RMI/IIOPを使用したEJBのリモート呼び出しです。

これらは、サービスを提供するサーバーのIPアドレスが固定されていることが内部実装の前提となってしまっており、起動のたびにIPアドレスが動的に割り当ているコンテナ環境で正常に使用することは非常に困難です。IPアドレスを固定するなど、標準的でない構成が必要となってしまいます。

これらの機能を使用している場合は、RESTやSOAP通信などでラップするなどの対処が必要になってくるでしょう。

既存のJavaEEをOpen Liberty上に移行するには

IBMでは、既存のJava EEアプリケーションや、それを実行しているサーバー環境を分析して、Liberty化しコンテナ環境へ移行するために必要な工数や修正箇所を分析するツールとしてTransformation Advisorを提供しています。このツールを利用すれば、現在使用しているアプリケーションが簡単にコンテナ環境に移行できるのか、あるいはある程度書き換えないと移行できないのかということを簡単に分析することができます。また、具体的に修正が必要なクラス・メソッドについても指摘してくれますし、コンテナ化に必要なプロジェクトのひな形や構成ファイルなども作成してくれます。

またアプリケーションを簡便に分析してくれるツールとして、Migration Toolkit for Application Binariesも提供されていて、無償で利用することができます。

コンテナ環境でJava EEのアプリケーションを実行するためには、これらのツールも活用してください。また、実際にOpenShift上でLibertyを使用する際の詳細な日本語ガイドをこちらで公開しています。あわせてご利用ください。