Payara FoundationがPayara Server 5とPayara Micro 5をリリース

Payara^® Foundationは先頃、新機能のホストとアップグレードを含んだPayara Serverのバージョン5とPayara Microをリリースした。Payara Server 5は今回、MicroProfile 1.2とGlassFish 5に対応した。その他の新機能としては、

• Payara Server用の新しい管理コンソール
• クラスタリングの改善
• Apache DerbyからH2への移行
• Java EE 8サポート
• Mojarra 2.4サポート
• 新しいHazelcast機能

今回は、これら機能拡張の一部を取り上げる。

Payara Server管理コンソール

最も分かりやすい変更は、管理コンソールに新設されたダークテーマだ。 これは主として、Payara Serverブランドを反映した外見上の変更である。

クラスタリングの変更

Payara Serverの従来バージョンでは、データ共有、インスタンス設定、デプロイメントターゲッティングはクラスタ技術の一部であり、GlassFishの初期リリースから利用可能だった。Domain Data GridとDeployment Groupの導入に伴い、使いやすさ、柔軟性、クラウド開発との互換性向上の観点から、クラスタは非推奨になる予定である。Payaraの創業者でディレクタのSteve Milledge氏は、ブログ記事に次のように書いている。

すべてのPayara Serverインスタンスがドメイン全体でひとつのデータグリッドに接続して、WebセッションやJCache、SSO、ステートフルなEJBといったメモリ内データを共有するようになります。

Payara Server ５では、ドメイン内のすべてのPayara Serverインスタンスが単一のドメイン全体のデータグリッドを形成し、すべてのインスタンスが開発者に対して透過的な方法でデータを共有します。データグリッドはほとんどの場合において、構成設定をまったく、あるいはほとんど必要としません。

Payara Server 4をご存知ならば、これまでのShoalクラスタ、GMS、これまでのHazelcast設定が不要になり、新たにData Gridに置き換えられたものと解釈してください。Payara Server 5にData Gridが取り入れられたことで、Clustered CDI Eventやライトウェイトなドメインメッセージ、Data Grid CDIシングルトンといったエキサイティングな新技術の構築と拡張が可能になりました。

デフォルトデータベースの変更

Apache Derbyには数多くの問題があったことから、ビルトインデータベースがDerbyからH2データベースに置き換えられた。従来のアプリケーションとの互換性のため、バージョン5でも引き続きDerbyを利用することは可能だが、Payara Serverの次期リリースで最終的に廃止されるまでの非推奨機能とされている。

PayaraでJavaミドルウェアコンサルタントを務めるMichael Croft氏が、最新リリースについて説明してくれた。

InfoQ: Payara ServerがJava 9以降に対応するのはいつになる予定ですか？

Croft: JDK 9で導入された新しいJPMSへの対応作業はすでに実施していますが、多くの作業がまだ残っています。Oracleは現在、6ヶ月サイクルでOpenJDKのビルドのみを開発しています。LTSバージョンはOracleJDKのみを対象として、間もなくOracleサポートユーザ限定で提供されるようになります。

今回の変更に対応して、PayaraはAzul Systemsと提携し、Payara ServerおよびPayara Microで使用するサポート対象JDKを提供します。Azulの計画では、JavaのLTSバージョンをOracleと同じタイミングで作成する予定ですので、当社としてはAzul LTSの最初のリリースとして今年9月にリリースされるJDK 11をターゲットにしています。

このリリースは当社のリリース周期と若干のずれがありますが、当面は変更する予定がないので、互換性が提供されるのは5.184がリリースされる11月になるかも知れません。

InfoQ: 今月初めのMichael Ranaldo氏のブログ記事には、“現在のクラスタ技術はやや古くなっている”という記述がありました。それがどういう意味なのか、現在のクラスタ技術に何らかの問題があるのか、説明して頂けますか？

Croft: ブログ記事で“現在のクラスタ技術”と言っているのは、GlassFishのクラスタリングで使用されているProject Shoalのことです。これは、初期のPayara Server 4.1.144を発表した時点でさえ、すでに長い間変更されていなかった、非常に古いプロジェクトです。当時からこれには問題があって、早い段階で、リプレース用のオプションとしてHazelcastが採用された動機のひとつになっていました。

ShoalをHazelcastで置き換える意図が常にあったため、5.181でShoalを非推奨として、Hazelcastを最優先(first-class-citizen)に配置することができたのです。

このフレーズのもうひとつの意味として、エラスティックなスケーリングや、警告なく生成されたり消滅したりするサーバに依存する現代のクラウド環境を考える上で、(GlassFishで使用されている)クラスタの概念がやや古くなっている、とも解釈できます。ステートレスなアプリケーションでは、これは問題にはなりませんが、既存のアプリケーションからステートを取り除く場合には別の問題があります。この問題を解決するため、Domain Data GridとDeployment Groupという概念を導入しました。これらは共にHazelcastを活用することで、セッションデータを保存するための、Shaolのように静的に定義されたクラスタに依存した方法ではない、動的で柔軟性のある方法を実現しています。

InfoQ: Apache DerbyをH2で置き換えることになった問題とは、どのようなものなのでしょう？

Croft: 当社はApache Derbyを実運用で使用することは推奨していませんでした。これはH2についても同じです。Paraya ServerやParaya Microが通常サポートするようなタイプのワークロードには、OracleやPostgreSQL、あるいはMariaDB/MySQLのような、もっと堅牢なデータベースの方が適しています。

それほど複雑でない比較的単純なケースや、小さな変更をローカルテストするためだけに大規模なデータベースをセットアップしたくない場合には、組込みデータベースが使用されることもよくあります。Derbyでは、同時使用される場合のロックに問題が見つかりました。これが原因で、バッチテストではロックアップなどがよく発生しています。従来型のデータベースでテストを作成して実行する場合には問題がないのですが、スモークテストとして設計されたテストやユニットテストを実行する際に、Parayaのコードとはまったく別の理由でサーバがフェールすることが分かりました。

当社のテストで問題が発生している以上、最終的に他のユーザも同じ問題に遭遇する可能性がある、という結論に達したのです。

InfoQ: Payara ServerはGlassFish Server Open Sourceから派生して、Payara 5はGlass Fish 5に対応しているのですが、開発者がいずれかを選択するユースケースというものはあるのでしょうか？

Croft: 重要なポイントはおそらく、Payara Serverが完全なオープンソースであって、GitHub上で活発にサポートされていることでしょう。コミュニティが参加してくれるために、私たちは、できる限りのことをしています。コミュニティのユーザがプロダクトの品質にとって大きな意味を持つこともよく理解していますから、まず最初にプレリリースビルドを公開して、早期のフィードバックを得るようにしています。全力で耳を傾け、全力で行動しているのです！

Payara Server 5.181ではGlassFish 5に相当するAPIを提供するとともに、Java EE 8アプリケーションのデプロイを可能にしています。それ以外の部分では、Payara ServerはGlass Fishとは大きく離れていて、当社の考えるエンタープライズJavaの将来的なビジョンへと向かっています。そのひとつが先程述べたDomain Data Gridで、AWSやAzure、Google Cloud Platformでの作業を容易にします。もうひとつはEclipse MicroProfileへの参加で、MicroProfile Metrics の提供する最新の監視システム、フォールトトレランスAPI、実行時にコンフィギュレーションを注入する方法などによって、手持ちのツール類をさらに充実させています。

Payara Serverはさらに、OpenTracingと互換性のある(MicroProfile OpenTracingも近日中にサポートする予定)Request Tracingサービス、高度なSQL診断ツール、MavenやNetBeansプラグインなどのエコシステムツールといった、運用チーム用の独自機能も提供しています。

最後に、Payara ServerとGlassFish Serverは同じライセンス下で完全なオープンソースとなっています。これはつまり、最新リリースバージョンのダウンロードや運用環境での使用において、どちらのサーバもまったく制限がない、という意味になります。しかしながら、運用開始後の段階でのサポートが必要だと判断した場合には、Paraya Serverを選択する必要があります。サポートのあるサーバでプロジェクトを開始することで、将来的な苦痛が軽減されるとともに、マイグレーションやテストの必要性を回避することができます。

InfoQ: Payara ServerとPayara Microが競合製品に対してユニークな点は何だと思いますか？

Croft: 競合という意味では、最も近い比較対象はJava EEアプリケーションを実行可能な他のオープンソースサーバということになるでしょう。つまり、WildFlyやOpenLibertyなどです。

WildFlyやWildFly Swarmと異なる点としては、Paraya ServerとParaya MicroがAPI実装を共有していて、完全な互換性があることがあげられます。当社は両方のサーバを同時にクラスタ化することを推奨すると同時に、両方の製品をサポートしています。WildFlyとWildFly Swarmに関するRed Hatの位置付けは、サポートの面でも少し違います。WildFlyは新機能が試される場であって、安定性とサポートが提供されるのはJBoss EAPを通じてなのです。Payara ServerとPayara Microについては、どちらも革新的かつ安定的であることを目標としているので、ユーザには毎月のパッチリリースを通じて安定性を提供しています。

OpenLibertyとは対象的に、当社は無償公開リリースで機能を制限することはしていません。事実、当社がコミュニティ向けに公開する機能リリースは、有償ユーザに提供するものとまったく同じです。コードベースをすべてオープンにしているので、オープンコア用の別ブランドというものはありません！

InfoQ: 将来的な計画はどのようになっているのでしょう？

Croft: 今年初めのことになりますが、Steve — Payaraの創業者 — が、2018年のロードマップの概要について説明しています。今年はリリース毎にテーマを決めているのですが、その最初となる181リリースでは、Payara Server 5とMicroProfile 1.2による標準に焦点を当てています。

その次の182リリースではセキュリティに注目して、サポートするセキュリティプロバイダの数を拡張します。さらにこのリリースでは、181で実現するには開発サイクルに対して少し遅過ぎた、MicroProfile 1.3のサポートも提供する予定です。

その次の183では、リアクティブプログラミングと非同期プログラミングのサポートを拡充する予定です。内容について初期的なアイデア(メッセージリスナとしてLambdaをサポートする、など)はありますが、具体的にどのような機能を含むかはまだ決まっていません。

184リリースでも引き続き開発者の生産性を重視しますが、こちらではツーリングを取り上げます。Payara ServerとPayara Microで使用するツールの開発にはすでに着手していますが、このリリースでは、Payara ServerとPayara Microでの開発作業をできる限り簡単にすることを目標とします。

リソース

• “New to Payara Server? You're in the Right Place!” — Payara (2017年4月)
• “Using PostgreSQL with Payara Server” — Jonathan Coustick (2018年1月18日)
• “Domain Data Grid in Payara Server 5” — Steve Milledge (2018年1月23日)
• “Using MySQL with Payara Server” — Jonathan Coustick (2018年3月18日)
• “Deployment Groups in Payara Server 5” — Steve Milledge (2018年3月22日)