使わにゃ損! 3つのトラブル事例で知る「Java Flight Recorder」の威力--Oracle WebLogic Serverとの組み合わせは特に強力

WebLogic Channel編集部
2015-04-27 12:20:00
  • このエントリーをはてなブックマークに追加

オラクルがOracle WebLogic ServerやJava SE Advancedのユーザーに提供している「Java Flight Recorder」は、通常なら迷宮入りしてしまうようなトラブルの原因も究明できる強力なツールだ。3つのトラブル事例を基に、その威力を紹介する。

せっかくのライセンスを眠らせていない? システム障害の問題切り分け、原因究明をスピード化する強力ツール

 「Java Flight Recorder」は、オラクルのアプリケーション・サーバ製品「Oracle WebLogic Server Enterprise Edition」、および「Oracle WebLogic Server Suite」、そしてOracle Java SEの有償ライセンス「Java SE Advanced」のユーザーに提供されている高機能なシステム稼働情報記録ツールだ。OSからJVM、アプリケーション・サーバ、そしてOracle WebLogic Serverと組み合わせて利用した場合にはJava EEアプリケーションのレベルまで稼働情報を詳細に記録(レコーディング)し、万一の際には専用のログ可視化ツール「Java Mission Control」を使って迅速に障害解析を行うことができる。

新井庸介氏
日本オラクル Fusion Middleware事業統括本部 ビジネス推進本部 製品戦略部担当シニアマネジャーの新井庸介氏

 しかし、日本オラクルの新井庸介氏(Fusion Middleware事業統括本部 ビジネス推進本部 製品戦略部担当シニアマネジャー)によれば、Oracle WebLogic ServerやJava SE Advancedをライセンスを持っているのにもかかわらず、Java Flight Recorderを活用していない企業もあるという。

 「非常にもったいない話です。Java Flight Recorderは現在、Oracle Java SEに機能がバンドルされています。Java SE Advancedのライセンスさえあれば、JVMのパラメータ設定を行うだけでシステムの稼働情報を詳細に記録することができるのです。私が見聞きした範囲でも、これまでは原因究明を諦め、迷宮入りしていたようなトラブルの解決に役立ったケースが少なくありません」(新井氏)

 それでは、実際にどのようなトラブルの解決に役立つのか。一般に障害対応では、担当企業/組織が異なることの多いインフラ側とアプリケーション側のどちらに問題があるのかの切り分けが難しく、そこでつまずいてしまう場合が少なくない。ここでは、そうした点も踏まえ、実際のトラブル事例に基づく次の3つの活用ケースを例にとり、Java Flight Recorderの威力を紹介してみたい。

  • ケース(1) インフラ側の問題究明に役立ったケース
  • ケース(2) アプリケーション側の問題究明に役立ったケース
  • ケース(3) Oracle WebLogic Serverと組み合わせて使用し、Java EEアプリケーションのボトルネックを突き止めたケース

ケース(1) 特定機器の故障など、迷宮入りしがちなインフラ側トラブルの原因究明で威力を発揮

 初めに紹介するのは、不定期に性能劣化が生じるというトラブルにおいて、インフラ側に原因があることをJava Flight Recorderによって突き止めたケースだ。対象システムは2ノードのアプリケーション・サーバと4ノードのデータベース・サーバ(Oracle Real Application Clustersでクラスタ化)によって構成され、負荷テストの際に性能劣化が発現した。

 「『発生のタイミングにパターンが見られない』、『ときどき遅延などの問題が発生する』といったトラブルは原因を突き止めにくく、アプリケーション担当とインフラ担当が互いに相手を疑うようなことになりがちです。しかし、インフラ側の問題がどこにあるのかを突き止めようとすれば、JVMやアプリケーション・サーバの設定、パッチの適用状況など、チェックする項目が膨大になります。こうした問題で原因切り分けを行うのにJava Flight Recorderは打って付けであり、実際にこのケースでも活躍したのです」(新井氏)

 まず、Javaアプリケーションで行っている処理の内容をJava Mission Controlで可視化して確認したところ、通信処理(Socket Read)の回数と所要時間が、他の処理と比べて極端に多いことがわかった。

Javaプログラムの処理の内訳を確認Javaプログラムの処理の内訳を確認
※クリックすると拡大画像が見られます

 もっとも、データベースを利用するシステムの場合、アプリケーション・サーバはクライアントからのリクエストを受け取る度にSQLを発行するので、通信処理の回数が多いこと自体は不思議ではない。問題は、その内訳だ。

 次に、通信処理の内訳を、通信対象のホストごとに表示した。すると4台のデータベース・サーバのうち、「db02」サーバとの通信にのみ異常が見られた。他のデータベース・サーバよりも通信回数が少ないのにもかかわらず、通信時間が極端に長いのだ。

 「この時点でdb02が原因だと推測されるわけですが、さらに通信処理の詳細をスレッド・レベルで調べていくと、その疑いは確信に変わります。他のデータベース・サーバとの通信は1回当たり50ミリ秒程度で完了しているのに対して、db02との通信は遅延が発生しつつ数秒から数分もかかっていたのです。この情報を参考にしてネットワーク周辺を調査したところ、db02サーバに対するパケットの再送が多発していることがわかりました」(新井氏)

Javaプログラムの通信処理の内容を対象サーバごとに分析Javaプログラムの通信処理の内容を対象サーバごとに分析
※クリックすると拡大画像が見られます
データベース・サーバとの通信をスレッド・レベルで確認データベース・サーバとの通信をスレッド・レベルで確認
※クリックすると拡大画像が見られます

 そこで、db02をクラスタから外した状態と、ケーブルとスイッチ側ポートを変更してdb02を再接続した状態についてテストを行ってみた。すると、今度は遅延は発生せず、原因はスイッチ側のコンバータ・モジュールで接触不良が生じていたことであると突き止められたという。

 「トラブルシューティングでは、同じシステム構成の再現環境を用意して再現テストを行うことがよくありますが、特定機器の物理的な故障が原因のトラブルを再現するのは不可能に近く、結局は時間を浪費するだけで迷宮入りしてしまうことがあります。このケースでは、Java Flight Recorderを使うことで、手間と時間のかかる再現環境の構築などを省きつつ、短時間で『スイッチの故障』という原因を明らかにできたのです」(新井氏)