インフラ更改時の大きな負担「テストのコスト」をどう下げる? 「自動化」と「スピーディな障害解析」が、かなり効く

Oracle Java & Developers編集部
2014-06-24 10:00:00
  • このエントリーをはてなブックマークに追加

Java Flight Recorderで本番環境の稼働情報をすべて記録し、障害時には迅速に原因究明。トラブルを迷宮入りさせない

 RUIEとOracle Application Replay Packにより、本番環境のリアルな稼働状況をテスト環境で再現し、手間をかけずに正確なテストを行うことが可能となる。これにより、テストにかかるコストは大きく引き下げられるが、アプリケーション基盤のテストに関しては、もう1つ解決すべき課題がある。それは、不具合や性能問題が見つかった際の迅速な原因究明だ。このスピードが遅いままでは、「テストで問題個所を見つけ、その原因を究明し、不具合を修正して再度テストを実施する」という回帰テストのサイクルをスピーディに回していくことはできないのである。

 今日の現場では、障害が発生した際に属人的なスキルに強く依存した対応が行われるケースが多い。しかし、さまざまなシステムが複雑に連携して動作している環境において、属人的な対応だけに頼るのは限界がある。問題個所の特定にも時間がかかり、場合によっては原因不明のまま対応できずに"迷宮入り"してしまうといったケースも出てくるだろう。

 この問題に対し、オラクルは属人性を極力排したツールによる解決策を提供している。それが、システム稼働情報記録ツール「Java Flight Recorder」だ。これはJava SEの有償ライセンスであるJava SE Advancedのユーザーと、Oracle WebLogic Server Enterprise EditionおよびOracle WebLogic Suiteのユーザーに対して提供されるものだ。同ツールを使うことで、迅速かつ確実な問題の切り分けと原因分析が行える。

 「Java Flight Recorderを使えば、本番環境の稼働情報を常に記録し、その情報をエラーや不具合が発生した際の原因究明に使うことができます。CPU利用率は5%未満と動作負荷が低い点が特徴であり、国内でも多くの企業の基幹システムで使われている実績のあるツールです」(新井氏)

 記録した稼働情報は、専用の分析ツール「Java Mission Control」上でグラフなどを使ってグラフィカルに表示し、詳細情報にドリルダウンしながら問題究明を素早く行うことができる。例えば、RUIEとOracle Application Replay Packによるテストの結果、本番環境では問題がないのに、テスト環境では十分な性能が出ていないことがわかったとしよう。そうした場合に、テスト環境に組み込んだJava Flight Recorderで取得した稼働情報をJava Mission Controlで確認しながら原因を究明するといった具合に使用する。

 「CPUやメモリの利用率は低く、ログを見てもエラーは発生していないのにもかかわらず、十分な性能が出ないといった状況に直面することがあるでしょう。多くの方は、そこでお手上げだと諦めてしまうかもしれませんが、Java Flight RecorderとJava Mission Controlを使えば、その先の原因究明が簡単に、しかもスピーディに行えるのです」

 次に示すのは、Java Flight Recorderで取得した稼働情報をJava Mission Controlで表示させた画面だ。画面右側の横棒グラフはスレッドの稼働状況を示すものであり、グラフ中の灰色の部分は「Thread Parked」、つまりスレッドが待機中であることを示す。ご覧のとおり、多くのスレッドが頻繁にThread Parkedの状態を繰り返している。

 このような個所を見つけた場合、各スレッドの情報をドリルダウン表示してスタックトレースを表示させ、Thread Parkedを発生させているのがプログラム中のどの部分なのか、該当するソースコードのレベルまで追いかけることができる。これだけの情報が得られれば、原因究明もスピーディに進むだろう。

 なお、Java Flight Recorderは標準でOSレベルからJVMレベル、Javaアプリケーション・レベルまでの稼働情報記録に対応しているが、Oracle WebLogic Serverと組み合わせて使用した場合には、さらにサーブレットやEJBコンポーネント、JDBC接続などの情報も記録することが可能だ。

【Java Flight Recorderで記録できる稼働情報】

OSレベル

コンテキスト・スイッチ、CPUビジー、物理メモリ使用状況、環境変数情報、自JVM以外のプロセス情報

JVMレベル

オブジェクト・アロケーション、ガーベジ・コレクション、空きメモリ、CPUビジー、システム・プロパティ、クラス・ロード、JITコンパイル、クラス別ヒープ利用状況

Javaアプリケーション・レベル

ファイル/ソケットのI/O、ロック獲得/待機、イベント待機、例外

Oracle WebLogic Server

コネクタ、サーブレット、EJB、JDBC、Webサービス、JTA

 「Java Mission Control上で『WebLogic Server』タブを展開すると、Oracle WebLogic Server上で稼働するサーブレットなどの稼働情報を詳細に確認することができます。どのサーブレットの処理が原因で性能が出ないのか、どのJDBC接続でどういったSQLを実行しているのかといったことまでわかるため、Java EEシステムで発生した不具合の原因究明もスムーズに進められます」

RUEI、Oracle Application Replay Pack、Java Flight Recorderでインフラ更改時のコスト削減を果たした国内大手製造業も

 実際にここまでに紹介したツール群を活用し、ある国内大手製造業はアプリケーション基盤の回帰テストの効率化に取り組んでいるという。この企業では、ハードウェアの入れ替えやミドルウェアのバージョンアップといったITインフラの更改にかかるコスト負担の重さが課題になっていた。

 「お客様を悩ませていたコストの問題は、大きく2つありました。1つは、インフラ更改の作業に、人手や時間など多くの『作業コスト』がかかること。もう1つは、毎年のようにインフラのどこかで更改作業が発生し、それに伴って負担が生じるという『更改作業の頻度』の問題です」(新井氏)

 同社は、まず作業コストの問題を解決すべく、オラクルのテスト・ソリューションを導入。テスト作業を自動化したうえで、不具合が見つかった際には迅速に対処できる仕組みを整える。この中で同社は、先に紹介したRUEIやOracle Application Replay、Java Flight Recorderを使ってアプリケーション・サーバのバージョンアップに伴うテストの効率化に取り組んでいる。また、本番環境のデータベース・トランザクションをキャプチャしてテスト環境でリプレイすることのできるテスト・ツール「Oracle Real Application Testing」なども活用。インフラ更改時のミドルウェア層の回帰テストにかかるコストの削減に向けた作業を進めている。

 また、もう1つの懸案であった「更改作業の頻度」に関しては、オラクルの製品サポート体系である「ライフサイクル・サポート」を活用。製品リリースから5年間の標準サポートである「Premier Support」、Premier Support終了から3年間の延長サポート「Extended Support」、Extended Support終了後の無期限サポート「Sustaining Support」といったサポート・サービスを利用して各ミドルウェアの更改時期を徐々に統一。更改作業の集約と頻度の削減に取り組んでいるという。

 以上、今回はOracle WebLogic Serverとともに活用することで、インフラ更改に伴うアプリケーション基盤のテスト自動化、不具合の原因究明のスピード化に威力を発揮するツール群を紹介した。Oracle WebLogic Serverをアプリケーション基盤として利用することで、企業のアプリケーション・ライフサイクル管理を大幅に効率化できることがおわかりいただけただろう。Oracle WebLogic Serverユーザーは、その投資対効果をさらに高めるためにも、ぜひこれらのツールを活用いただきたい。

  • コメント(1件)
#1 8181   2014-07-07 22:11:14
けっこう参考になった
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]