開発者を魅了するマイクロソフトの開発プラットフォームを探れ 第10回

Java on Azure Day 2022でヴイエムウェア、日本IBM、レッドハットが登壇

Java on Azureを支えるテクノロジー　Spring、Open Liberty、KEDAの基礎を学ぶ

Java EEをクラウドネイティブの世界でも活かすLibertyとは？

　次に「Azure上でもJava EEアプリケーションを使う　OSSの実行環境　Open Liberty」というタイトルで登壇したのは、「WebSphere Application Server」などのテクニカルセールスを20年以上担当している日本IBMの田中孝清氏になる。

　クラウドネイティブの世界ではKubernetesやコンテナ、マイクロサービスなど魅力的な技術が次々と現れている。これからの時代に必要なアジリティのあるITシステムを構築するためには役立つ技術ではあるが、クラウドに行くには慣れ親しんだJava EEを捨てなければならないと考えている人は多いかも知れない。これに対して、田中氏は「今回紹介する技術を使えば、Java EEはクラウドネイティブの世界でも非常に有力な選択肢になりうる。メインのプレイヤーになり続ける」と提案する。

　では、なぜJava EEがクラウドネイティブに向かないと考えられているのか？　この大きな原因はアプリケーションサーバーにあるという。これは「サイズが大きく、起動時間が遅い」「仕様が古くてマイクロサービスに対応しにくい」「DevOpsやPlatform as Codeといったソフトウェア開発がやりにくい」「コンテナ対応が難しい」などが原因で、実際に従来のWebSphere Application Serverもこれらの課題を抱えていた。しかし、Open Libertyであればこれらの課題は解消する。

　IBMは2012年に従来のWebSphere Application Serverを完全に作り直しており、既存のTraditionalランタイムに対して、Libertyランタイムとして提供することにした。そして、このWebSphere Libertyを2017年にOSS化された。これがOpen Libertyになる。Open Libertyで採用されているEPL（Eclipse Public License）は、拡張されたソースコードの公開義務がないため、ビジネスでも使いやすいという。以降、新機能はOpen Libertyで開発され、IBMはこれをベースに製品版である「WebSphere Liberty」を提供している。

WebSphereからOpen Libertyへ

　田中氏は課題のうち前者の2つをどのように解決しているか説明した。まずは「サイズが大きく、起動時間が遅い」という課題。そもそもなぜJava EEアプリケーションサーバーは大きく、起動時間がかかるのか？　実はJava EE/Jakarta EEは非常に多くの仕様の集合体になっており、これらすべてに対応した実行環境は重くなりがちだ。

　これに対してOpen Libertyは1つ1つのAPIへの対応を「Feature」という独立したモジュール単位で実装しており、使用する構成ファイルのみを有効化させて利用できる。使用する機能だけを本番環境にコピーしたり、コンテナに入れることも可能だという。そのため、メモリ使用量も少なく、起動時間も短縮されている。実際にFeatureのないカーネル部分のZIPファイルは11.6MBで、5つのFeatureを搭載した展開後のサイズも56MBしかないという。

モジュール化されたOpen Liberty

MicroProfileをJava EEから利用できるLibertyの魅力

　続いて「仕様が古くてマイクロサービスに対応しにくい」という課題について。Javaではマイクロサービスを利用するための標準仕様群として「MicroProfile」が定義されており、マイクロサービスで必要な機能を実装固有ではなく、業界標準の機能として提供している。

　一般的にはJava EEとMicroProfileは排他的な選択肢だと考えられているが、両者をサポートしているOpen Libertyであれば、組み合わせて使うことが可能だ。「MicroProfileはRESTで通信しあうマイクロサービス型のアプリケーションだけではなく、Java EEの中から使っても有用な機能が非常にたくさん含まれている」と田中氏は指摘する。

MicroProfileはJava EEと排他な選択肢だと思われている

　たとえば、Javaアプリケーションから構成情報を抜き出す場合、リソースバンドルやプロパティファイル、システムプロパティ、環境変数などから取得する方法があり、それぞれ別のコードを書かなければならなかった。しかし、MicroProfileのConfig APIを使うと、Config Sourceを切り替えながらいろいろな構成情報を統一した書き方で取得できる。

　この便利なConfig APIは現在策定中のJakarta EE 10には含まれる予定だが、APIのパッケージがjavaxからjakartaに変更されるため、Jakarta EE 9以降への移行は容易ではない。しかし、LibertyであればJava EE 7/8とMicroProfileをいますぐ組み合わせて使えるというメリットがある。具体的には構成ファイルで両方のAPIの機能を提供するFeatureを有効にするだけでOKだ。

　ちなみにLibertyは、基本的に一度提供されたFeatureは削除されないため、たとえばServlet APIは3.1、4.0、5.0のすべてに対応している。構成ファイルで設定すれば、アッパーコンパチビリティではなく、昔のAPIがそのまま動作するという特徴を持つ。「一度作ったアプリケーションを長く使いたいという場合には、非常に使いやすいアプリケーションサーバーになっています」と田中氏はアピールする。

　この「ゼロマイグレーションポリシー」は、今後のJava EEからJakarta EEへの移行にも大きな効果を発揮する。たとえば、Tomcatの場合、Servlet 5.0対応の最新版に上げると、すべてのアプリケーションのパッケージをjavaxからjakartaに変換しなければならないが、いずれのServletのバージョンにも対応するLibertyであれば、適切なタイミングでアプリケーションを移行すればよい。

ゼロマイグレーションポリシー

　最後、田中氏はAzure上でOpen Libertyを動かすための詳細情報が載っているマイクロソフトのドキュメントやGit、JDK、Mavenがあればほとんど実行できるLibertyの使い方ガイドを紹介。「高速軽量モダンな開発運用スタイルにも対応しているので、Azureをはじめとしたクラウド環境の世界でも、Java EEを活用できる」とアピールし、セッションを終えた。

■関連サイト

• 日本IBM