ページの本文へ

Hitachi

OSS(オープンソース・ソフトウェア)

Red Hat社

JBossはRed Hat社が提供するオープンソースのミドルウェア製品群です。 本コラムでは、JBoss製品情報や関連する技術動向、ビジネスの現状などをご紹介します。

第1回 コンテナ型クラウドアプリケーションに最適、軽量化されたJava EE アプリケーションプラットホームJBoss EAP 7

昨今、クラウド向けに最適化されたアプリケーションやその開発手法、関連技術のコンテナにも注目が集まっており、Red HatもDocker/Kubernetesをベースとしたコンテナ活用基盤OpenShift Container Platformを提供しています。一方、企業システムにおいてはJava EE仕様を実装するJavaアプリケーションプラットフォームに対する根強い要求がいまだにあることも事実です。 JBoss Enterprise Application Platform 7 (以下EAP7) は、Java EE7仕様に準拠したアプリケーションプラットフォームで、Webプロファイルをサポートしています。JBoss EAP7はJava EE7機能をクラウド上で効率的に利用するためにフットプリント(メモリ消費量)を小さくし、高速に動作します。

検証 JBossは”小さくて、早い”

まず最初にJava EEアプリケーションプラットフォームの最小限の定義について確認したいと思います。Java EEアプリケーションプラットフォームとは、特定のJava EE仕様に準拠し、実装されたものを示します。現在のJava EE仕様は広範囲で、290ページに及ぶドキュメントで定義されています。この仕様に準拠したプラットフォームを実装するのはそう簡単ではありません。現在、Oracle社が検証によって認定したJava EE 7の仕様を完全に準拠したプラットフォーム製品は、8個あります。Red Hat JBoss EAP 7はその一つです。しかし、Apache Tomcat、JBoss Web Serverは準拠プラットフォーム製品に含まれておらず、Java EEの仕様に準拠されている製品とは言えません。

次にJava EE仕様には、実装する必要のあるもののみ記載されており、厳密にその仕様の実装方法は記載されていません。そのため、同じJava EE仕様に準拠したJava EEアプリケーションプラットフォームであっても大きな相違があります。Java EEアプリケーションプラットフォームの製品提供ベンダーは、実装方法、共通なコードを他ベンダーと同じにする必要はありません。たとえば、JBoss EAPは、Oracle社とIBM社のJava EEアプリケーションプラットフォームのコードとはまったく異なります。 このコードの違いが、プラットフォームを比較するときに顕在化するパフォーマンスやメモリの使用など多くの違いをもたらすことになります。

最終的なJava EEアプリケーションプラットフォームのメモリ占有量は、展開されるアプリケーションのインスタンスの数、および使用される共有コアによって変わってきます。Java EEアプリケーションプラットフォームが起動すると、使用可能な機能と実行方法を指定した設定に基づいてプラットフォームが実行されます。

JBoss EAPの構成要素には拡張(extensions)とサブシステムがあり、サブシステムはサーブレット、EJBコンテナ、JTAなどのサービスを提供する機能セットです。拡張(extensions)はコア機能を拡張するモジュールで、デプロイメントに必要なときにロードされ、必要なくなったときにアンロードされます。JBoss EAPには、40程度の事前に定義されたサブシステムが付属しており、ユーザーは必要に応じてカスタムサブシステムを作成できます。サブシステムのグループ化はプロファイルによって定義され、サーバ・ランタイムにロードして使用できます。

JBoss EAPは、アウトオブボックス(工場出荷時の設定)の設定で利用できます。JBoss EAPをスタンドアロンサーバとして起動するための標準のスクリプトは、Java仮想マシン用の実稼動可能なメモリをギガバイト単位で割り当てるように設定されていますが、実際は、はるかに少ないメモリで動作します。サーバが起動してから5秒以内にガベージコレクションを強制すると、使用されるメモリは約40〜60メガバイトになります。Apache JMeterを使用してサーバに負荷をかけると、メモリ使用量は200〜400MBに増加しますが、それでも、かなり小さいフットプリントで済みます。これはRhaspberry Piのようなデバイス上で動作するのに十分小さいサイズとなります。

JBossEAPをどのような環境で実行するかにかかわらず、アプリケーションのロードのためにJava仮想マシンのメモリをどのように設定するかはさまざまです。ただし、EAPに必要なメモリ量は、最小限に抑えられるようになっています。実際、JBoss EAPが使用する最小限のメモリ量は、JBoss Web Server(Tomcat)を実行する場合とほぼ同じで、”fat Jar”としてデプロイされた基本的なSpringBootアプリケーションとも同じとなります。

表1:デフォルトの設定を使用してランタイムを持つ単純なRESTアプリケーションを実行するリソース使用例。 テストはApacheBenchを使用して50人のユーザーが100Kをリクエストするようにシナリオされ、キープアライブが有効となっている。

ランタイム (フレームワーク) 起動時間 (サーバのみ) 起動時間 (アプリケーションの配備を含む) メモリ消費量 (ロード分は含まず) メモリ消費量 (ロード分を含む) 計測スループット
JBoss EAP (Java EE Web) 2 - 3 秒 4 - 4.5 秒 40 - 60 MB 200 - 400 MB 15K req/秒
JBoss EAP (Spring) 2 - 3 秒 9 - 12 秒 40 - 60 MB 500 - 700 MB 6.8K req/秒
JBoss WS/Tomcat (Spring) 0 - 1 秒 8 - 10 秒 40 - 60 MB 0.5 - 1.5 GB 8K req/秒
Fat JAR (Spring Boot) N/A 4 - 6 秒 30 - 50 MB 0.5 - 1.5 GB 9K req/秒

まとめ

クラウド対応アプリケーションのランタイムとしてJava EEアプリケーションプラットフォームの導入が有効です。クラウドでJava EEを使用することで、Java EEアプリケーションプラットフォームがリソースを大量に消費するという、既成概念に基づいた判断は間違いとなります。こうした認識は、おそらく他のファットなJava EEプラットフォームを使用した結果、その意見が独り歩きしてしまった可能性があると思います。

JBoss EAPが軽量で効率的であるように設計されていることにまだ気づいていない方は多いでしょう。Red HatはJava EEをより効率的にするための取り組みをオープンソースコミュニティと共に継続しています。本コラムの次回では、その主な取り組みである、マイクロプロファイルとWildFly Swarmプロジェクトについてご紹介する予定です。


コラム執筆者
レッドハット株式会社 プロダクトソリューション本部


今回のコラムは、Red Hat Inc., シニアプリンシパル・製品マーケティング・マネージャー Rich Naszcyniecの以下ブログ投稿を元に、レッドハット株式会社 プロダクトソリューション本部にて日本向けに編集・校正しています。