GlassFish から Payara 移行のススメ

2016年5月30日 at 5:43 午後 1件のコメント

先日 decode:2016 が開催され、山本裕介さんと一緒にセッションを行いました。ご参加いただいた皆様、誠にありがとうございました。

今回の de:code 2016 では、私が今できること、私ならではの内容が何かないかを考え構成を検討しました。本ブログではその経緯をご紹介します。そして次のエントリでは技術的な内容に触れる予定です。

結論から申し上げると、今回ご紹介した内容は、 Payara という Java EE アプリケーション・サーバを利用した、マルチリージョン間のレプリケーション方法(冗長構成)についてです。かんたんにいうならば、Azure の東日本リージョンと西日本リージョンに、それぞれクラスタ環境を構築し、その東日本と西日本のリージョンをさらに冗長化させるという超ミッション・クリティカル向けのお客様用の構成をご案内しました。


Payara Cluster on Azure のハンズオン・ラボ・コンテンツへのリンクはこちら

Payara クラスタの機能を紹介の前に、Payara について紹介したいと思います。
エンタープライズ Java 系の開発を行っている方は、GlassFish というアプリケーション・サーバの名前は聞いたことがあるのではないかと思います。先日のアプリケーション・サーバ利用者アンケートにおいても Tomcat の次に利用されていたのが GlassFish でした。そこで、おそらく名前は聞いたことがあるのではないかと思います。私は Sun Microsystems 時代は、この GlassFish のエバンジェリストをしていました。このブログでも GlassFish に関連したコンテンツを多数記載しています。GlassFish にご興味のある方は、タブを切り替えて GlassFish に関するコンテンツをぜひごらんください。

さて、ここで簡単に GlassFish についてご紹介します。GlassFish は Java EE 5 がリリースされるタイミングで、Tomcat に変わって Java EE の参照実装になったアプリケーション・サーバです。各バージョンの違いは下記になります。

GlassFish v1 : Java EE 5 開発者向け(参照実装)
GlassFish v2.x : Java EE 5 本番環境向け(参照実装:商用サポート可)
GlassFish v3.x : Java EE 6 開発→本番環境向け(参照実装:商用サポート可)
GlassFish v4.x : Java EE 7 開発者向け(参照実装:商用サポート不可)

Tomcat と GlassFish の大きな違いは、Tomcat は Servlet/JSP を動作させるための Web コンテナ、EL 式の実装など、Java EE に含まれる一部の機能しか保持していませんが、GlassFish は Java EE に含まれる機能をすべて動作させることができます。

Tomcat, Jetty : Web コンテナ(Servlet, JSP) + EL + WebSocket など一部
GlassFish, WildFly, WebSphere Liberty, Payara, WebLogic, WebSphere など : Java EE 準拠

Web アプリケーション開発に必要な機能がオールインワンで提供され、依存関係も自分で解決しなくてもよいため Java EE 開発にはとても便利です。

また、GlassFish の登場が、その後のアプリケーション・サーバ市場に与えた影響は大きいものと思っています。実際に、はじめて軽量化を打ち出し、高速起動(モジュール化は既にあった)を実現したのはこの製品でした。Sun Microsystems 時代、この製品の新バージョンにワクワクし、自信を持ってこの製品を訴求をしていました。そして、GlassFish v3 の登場で、重厚長大だったアプリケーション・サーバのイメージが変わり、随分と扱いやすい物になったと思われた方もいらしゃるのではないかと思います。そして、その後 JBoss(WildFly) や、WebSphere がこれに追随し軽量版を出してきたのはいうまでもありません。

Sun Microsystem と Oracle との統合後、2013年11月04日 Oracle は Java EE and GlassFish Server Roadmap Updateを発表しました。この内容によると、今後も継続して、GlassFish は Java EE の参照実装として提供するものの、GlassFish v4 以降の商用サポートを打ち切る内容も発表しました。変わりに WebLogic Server を戦略的な製品として位置付け、商用サポート系は全てそちらにフォーカスするという内容でした。その当時、書いたブログの内容がコチラになります。
Java EE and GlassFish Server Roadmap Updateについて

この発表は、日本以上に利用されていた、北米・ヨーロッパでは大きなインパクトがあったようです。そして、2013年末 ロンドンに拠点をおく、C2B2 というミドルゥエア関連のコンサルティング企業が GlassFish(OpenSource GPLv2, CDDL) を fork して商用サポートを提供することを発表しました。

2016 年より Payara Services Ltd という企業を立ち上げ、現在はこの会社名でサービスを提供しています。つまり、Payara は GlassFish を商用サポートできるようにし、一部機能をエンハンスした製品です。たとえば GlassFish v4 には含まれていないクラスタ機能が Payara には含まれており、本番環境へも安心して適用可能になりました。また、Hazelcast という Open Source の In-Memory Data Grid 製品を同梱し、セッション・レプリケーション、JCache, JPA の2次キャッシュとして利用できます。Hazelcast は、ここ最近 Java 業界で注目されている製品で、下記の用途として利用できます。

Hazelcast
* Caching
* NoSQL
* In-Memory Data Grid
* Web Session Replication

さらに、Payara の商用製品 Payara Enterprise のライセンスを購入すると、Hazelcast Enterprise の機能が利用できるようになり(OEM)、Payara Scales という機能が利用できるようになります。これは、よりミッション・クリティカル環境への用途に向いています。

http://www.payara.fish/payara_scales

Payara のソースコードは GitHub でメンテナンスが施されており、Java EE 8 の参照実装プロジェクト(GlassFish v5)へのサポートも迅速に行うようです。また、今まで GlassFish を利用していた方は、全く同じ方法で Payara を利用することができます。

https://github.com/payara
https://github.com/payara/Payara/tree/Payara-5

GlassFish を開発環境でご使用中で、本番環境へもご適用したいと思われている方は Payara を試されてみては如何でしょうか?

次のエントリでは、Payara Scale を利用した、Azure 上でのマルチ・リージョン間の冗長構成について説明します。

ブログにするには量が多かったので、下記にまとめました。
Payara Cluster on Azure のハンズオン・ラボ・コンテンツへのリンク

余談:
私は Sun Microsystems から Oracle 時代に「Tomcat やめましょう、Struts やめましょう、Eclipse やめましょう」といったメッセージを出してきました。ここで、なぜそのようなメッセージを出してきたのかの理由を少し説明します。個人個人でお話しをする方には話しをしたことはありますが、これを公でちゃんと言ったことは恐らくないので。

本来、自分の押す技術を紹介するために、他者の技術を否定したりするのは良くないと思っています。実際、それに対してご指摘(お叱り)をいただいたことも何度かありますし、逆に Java の観点で Java 自身が言われる立場の思いもしたこともあります。言われる方の悲しさも知っています。それではなぜ、あえてそうした事を言い続けたかというと、「寺田さん、別にそれでできるから…」、「寺田さんの言ってるのは、技術者としてはとても良く分かるけど、上からこれを使いなさいと言われる」といった言葉をたくさん聞いたためでした。この言葉を受け取った時「何も行動していただけない、このままだと何も変わらない」と感じたものでした。前者は私の伝え方が足りないんだと思います、しかし後者は、あきらかに違うとおもいました。日本独自の標準化思考によって、利用する物をエンジニアが取捨選択するのではなく、それが最適な方法なのかも考えずに、ただ上から指摘された物を利用する。これは、エンジニアにとってアン・ハッピーだと思います。その止まった(と思える)思考を再度動きだしていただくために、そして「今正しいと思っていることが将来にわたって正しいと思ってはいけない」ということをどうしてもお届けしたくて、あのようなメッセージをだしていました。

メッセージをだし始めたのが、今から 7,8年くらいまえだと思いますが、そこから色々と変わったと思います。たとえば Struts は日本でもずいぶんと取り扱われなくなり、Eclipse も「Java サポートにおいては一時期停滞していたように思えます」が、Eclipse Che などの先進的なブラウザ・ベースの IDE がでてきたりしています。また、日本でも IntelliJ IDEA といった人気の IDE が使われるようになっています。さらに、最近ではマイクロ・サービスを実現するための実行可能 jar 形式の Web アプリ・フレームワーク(Spring Boot, Payara Micro, WildFly Swarm)も登場し、利用者数も著しく増加しています。私はこれはとても良い傾向だと思っていますし、今後この手法がより多く採用されるようになる可能性が強くあります。一方でアーキテクトの立場の方は、今とても難しいのかもしれません。プログラミング言語においても、フレームワークにしても、アプリケーション・サーバにおいても、たとえそれが開発方法論であったとしても、銀の弾丸と呼べる物はありません。これをやっておけば、十分という物はないんだと思います。場合に応じて、テクノロジー・方法論を取捨選択する必要があり、それを考えられる方が、より良いシステムを作っていけるのではないかと思います。

Entry filed under: Java.

Java サーバ利用状況アンケート結果の公開 Azure MarketPlace サービス一覧

1件のコメント


Java Champion & Evangelist

Translate

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2016年5月
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

カテゴリー

clustermap

ブログ統計情報

  • 1,288,942 hits

Feeds

アーカイブ