APサーバー再起動やログファイル追跡が不要に? Java開発者の待ち時間をなくしてデバッグに必要な情報をすぐ取り出せる2つのツールの即効性:編集部で徹底調査
Java開発現場に即効性があるツールが登場した。「JRebel」はアプリケーションサーバーの再起動を待つ時間をなくしてくれる。「XRebel」はJavaアプリケーションのログファイルを解読しなくても、デバッグに必要な情報をすぐに取り出せる。この両ツールの使い勝手を見ていこう。
市場環境変化が速い近年、時々刻々と移り変わるビジネス要請にアジャイルに応えられる開発体制が求められている。長年ウオーターフォール開発のみを行ってきた現場に、いきなりアジャイル開発を導入することは難しい上に時間がかかり、教育コストが前もって把握しづらいという問題がある。
本稿で紹介する「JRebel」「XRebel」は、Java開発現場の工数削減、品質向上に即効性があるツールだ。日本に上陸して間もないため、初耳の読者もいるかもしれない。そこで本稿では、両ツールの特長、特に即効性を分かりやすく伝えていきたい。JRebel/XRebelの国内販売元であるインフォメーション・ディベロプメントのiD-Cloudソリューション部 ビジネスディベロプメントチーム シニアエンジニアの宮本朋範氏からJRebelとXRebelの特長を聞きながら、開発工程におけるツールの活用方法について調べていこう。
APサーバーの再起動を不要にするJRebel
まずJRebelからだ。このツールの役割は非常にシンプルである。アプリケーションサーバー(以下、APサーバー)の再起動時間を不要にするのだ。
エンタープライズシステムを構成するような複雑なJavaアプリケーションでは、APサーバーの起動のために5分から20分、といった時間が費やされることも珍しくない。多くの開発現場では「Webアプリケーションの画面の誤字を1文字だけ直したい」といったわずかな修正であっても、5分なり20分なりの時間が費やされている。
再起動が必要という事情は、エンジニアの作業時間を確実に増やしてしまう。それだけでなく、高度な集中力が必要なデバッグ作業の思考のリズムも乱れてしまい、作業効率も上がらない。
だが、「APサーバーの再起動時間を不要にする」といっても、その実現方法は簡単ではない。JRebelは、クラスファイルを直接操作する機構を有し、実行中にクラスファイルの中身を変更できるのだ。これはJavaの動作の深い部分をよく知っていなければ実現できない技術だ。
早速JRebelを使ってみよう。JRebelはIDE(統合開発環境)に組み込む形で利用する。ここでは例としてEclipseを使う。JRebelをインストールして、アクティベーションした(写真1)後は、設定が必要だ。
設定はターゲットとなるAPサーバーと(写真2上)、プロジェクトを選ぶ(写真2下)だけというシンプルなものだ。
一方、写真3は、JRebelを適用してAPサーバーを起動した画面だ。同時に「過去126日間で148回のデプロイを防ぎ、7.6時間を節約しました」と、JRebelがどれだけ役に立ったかを示す指標も出てくる。
IDE上で文字列を変更し[Ctrl]+[S]キーを押してソースコードを保存し、ブラウザーをリロードすれば、それだけでアプリケーション実行結果に文字列の変更が反映される。
ちなみに、[Ctrl]+[S]キーと押すと、IDEのログとして「JRebel Reloading classes……」とメッセージが出て、どのクラスファイルを修正しているかが分かる(写真4)。
もっとも、こうした説明だけだと「この種の機能は、前にもあったのでは?」と思う読者もいるだろう。「ホットデプロイ」と呼ばれる機能、例えばOracle WebLogicのFastSwap機能や、Spring FrameworkのSpring Loadedライブラリのような機能がそれだ。だが「これらはJRebelの競合にはなりません」と宮本氏は断言する。
なぜ競合にならないのかと言うと、1番目にカバーする機能の範囲がJRebelの方が広いことがある。JRebelではJavaプログラムのメソッド、コンストラクター、フィールド、クラスの追加/削除、インターフェースの変更など、幅広い内容のプログラム修正に対応する。他のホットデプロイ系の機能はここまで徹底していないそうだ。こうした対応範囲の広さは、開発工程でAPサーバーをどうしても再起動しなければならない局面を最小限に減らすことにつながる。
2番目に、JRebelは汎用性が高く、主要なIDEとAPサーバー、フレームワークのいずれにも対応することが挙げられる。IDEがEclipseでもIntelliJ IDEAでもNetBeansでもよい。APサーバーはIBM WebSphere、Oracle WebLogic、Jetty、Tomcat、JBossと幅広く対応する。富士通のInterstageなど国内ベンダーのAPサーバー製品でも、設定の工夫で対応可能だそうだ。Spring/Hibernateのようなフレームワークにも、各種バージョンのJava EEにも対応する。いわゆる「JVM言語」、Scala、Groovy、JRuby、Clojureも対応可能だ。
このように、JRebelは「APサーバー再起動をなくす」という目的に向けて、幅広いプログラム修正に対応し、幅広いIDE、APサーバー、フレームワークに対応している。名前を出せば誰でも知っている有力企業での使用実績もすでに持っているのだ。
JRebelの導入を検討する企業にとって良い点はまだある。ライセンス体系がシンプルなことだ。1開発者当たり年間4万8000円で、この価格にはバージョンアップやサポートなどが全て含まれている。販売元のインフォメーション・ディベロプメントでは、「APサーバー再起動の時間を単純計算してエンジニアの工賃に換算するだけで、1開発者当たり年間87万円を節約できます。1カ月使えば年間ライセンス料の元が取れます」(宮本氏)と話している。
貴重なエンジニアの工数を確実に節約できるJRebelは、幅広い対応範囲とシンプルな機能、操作法、ライセンス体系を合わせ持つツールだ。開発現場がAPサーバーの再起動時間に悩んでいる場合、このツールで解決できるならJava開発部隊の能力は確実に向上する。ぜひ検討したいツールといえる。
なお、ゆくゆくはAndroid開発での再起動を不要にするツールも製品化を予定している。楽しみにしている開発者も多そうだ。
デバッグに必要な情報をWeb上で教えてくれるXRebel
今回取材した2番目のツールがXRebelだ。これは昨年(2014年)登場したばかりのまだ新しいツールだが、Webアプリケーションの画面に「XRebel Bar」と呼ぶデバッグ情報の表示領域を表示することができ、デバッグ作業を支援してくれる。以下、その動作を見ていくことにする。
まず、XRebelの設定だが、これはXRebelのJARファイルをAPサーバーの起動オプションで指定するだけでおしまいだ(写真5)。
開発中のアプリケーション画面にXRebel Barが表示されているのが分かる(写真6)。
XRebel Barに表示されたアイコンは、上から順にDBのアクセス情報(SQL文、その処理時間)、セッション情報(保存されるデータ内容とサイズなど)、例外情報となる。
例えば、プログラムを動作させて、「2回のI/Oクエリが発生、処理時間は1.8ms、データのサイズは632バイト」といった情報がすぐ読み取れる。I/Oクエリの内容を見るには、XRebelのデータベースアイコンをクリックするとドリルダウン表示で、SQL文をすぐに見ることができる(写真7)。
この他、スレッショルド設定の機能も使いでがありそうだ。例えば設定画面でI/Oクエリの「Thresholds」として「10回」を設定すると、1リクエスト当たり10クエリ以上のアクセスが起こった場合にそれを検出して警告を表示してくれる(写真8)。
ここで面白いのは、データベースアクセスをラップするフレームワークを使っていて、SQL文が自動生成されたものであっても、デバッグ時には実際にフレームワークが発行したSQL文とその処理時間を確認できることだ。開発者が意図しなかったSQL文が生成されて全体のパフォーマンスを落としていた、といった場合にも早い段階で発見して対応できる。また、SQL文のパフォーマンスチューニングにも役立つだろう。
これらの機能の説明を聞いて、「ログを丹念に追えば同じ情報を得られるじゃないか?」と思う読者もいるかもしれない。だが、Webアプリケーションのアウトプットと同じWebページに、デバッグ関連情報が同時に表示される使い勝手の良さは、開発者の目線から見ると大いに魅力的なはずだ。
「特に、デバッグの経験が浅いエンジニアが混ざっているチームでは、このツールはチーム全体のパフォーマンスの底上げにつながります」と宮本氏は語る。「ログに埋没してしまうエラー、不具合に対して、問題を早期に特定できます。Webアプリケーションの開発中の画面を見ながら問題点を発見できるため、ログ追跡と開発作業がバラバラにならないのもメリットです」(宮本氏)。
以上、JRebel、XRebelの概要と、開発現場での使い勝手を見てきた。APサーバー再起動の待ち時間を大幅に削減してくれるJRebelと、開発中のアプリケーションのデバッグに必要な情報を素早く参照できるXRebelの組み合わせは、開発現場を目に見える形で良くしてくれることだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- Java 8時代の開発者のためのデバッグ/トラブル解決の基本・応用テクニック〜JJUG CCC 2014 Springまとめリポート(後編)
Java開発における3大トラブルと対策、IDEのデバッガー活用の必要性、Java 8より導入された新しいメモリ領域を使いこなすためのテクニック、独自のトランザクショナルメモリ機構を実装した有効性などをお伝えする。 - デバッグのヒント教えます(1):Javaプログラムにおけるデバッグのパターンは?
Javaエンジニアの皆さんが必ずぶつかるデバッグについて、実例を挙げながらその具体的な対処法について解説していきます - Java開発の問題解決を助ける(1):デバックでのブレークポイント活用
バグ、性能問題、メモリリークなど、Java開発における問題は多い。これらの解決を助けるツールの活用法を紹介する
関連リンク
提供:株式会社インフォメーション・ディベロプメント
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2015年8月23日