gihyo.jpサイトのロゴ

Javaでなぜ問題が起きるのか 〜システムをきちんと運用するための基礎知識

第7回アプリケーションを業務視点で監視する

2017-05-31

前回は、Java VMを運用するにあたり何を監視しなければならないかを紹介しました。今回はJVMの上で動くアプリケーションは、何を監視しなければならないのかを紹介します。

アプリケーションを監視する際の2つの観点

利用者がアプリケーションを使用して問題なく業務を行えているかは、次の2つの観点で確認します。

  • 業務観点
  • システム観点

前者は、アプリケーションが実現している実業務の目線で確認することです。業務とは、ECサイトで行われる引当業務や、購買システムで行われる支払い業務を示します。

後者は、業務とは関係なくシステム上の都合で実現している処理を確認することです。たとえば、アプリケーションは、業務を実現するにあたり、通信やファイルの読み書きをします。通信先に一時的な問題が起きたり、ファイルのロックが一時的に取得できない場合にはリトライします。これらの処理は業務とは関係なく、システム上の都合でしかありません。

このように2つの観点で分析する理由は、発生した問題が業務の問題なのか、業務が動いているシステムの問題なのか、または両方が絡み合って発生している問題なのかを切り分けるためです。

業務観点で監視すべき5つのポイント

業務の観点で監視をするため、以下の5つを記録します。

  • 業務ロジックへ渡したパラメータ
  • 業務ロジックの成否
  • 業務ロジックの処理時間
  • ある時点で業務ロジックの成功件数
  • ある時点で業務ロジックの失敗件数

業務ロジックへ渡したパラメータと業務ロジックの成否、および業務ロジックの処理時間は、業務ロジックを1回実行するごとに記録します。また、業務ロジックが全体でどのくらい実行されているのかを記録するために、成功・失敗それぞれの数を記録します。

情報を記録することで可能になる5つのこと

これらの情報を記録することで、以下のことができるようになります。

  • バグの再現
  • 業務の再実行
  • スローダウンの検知
  • リソースの将来予測
  • システム改善案の検討

バグの再現

「業務ロジックが成功するはずのパラメータを与えたのに、業務ロジックが失敗してしまう」ということがあります。業務ロジックへ渡したパラメータと業務ロジックの成否を組み合わせることで、パラメータと成否の組み合わせが検証できるようになります。これらの情報は、バグの再現ケースとして使えます。

業務の再実行

業務観点からは問題がなくても、システム観点で問題が起きると、業務ロジックは失敗します。業務ロジックへ渡したパラメータを記録することで、システムの問題が解決した後に業務ロジックを手動で再実行できるようになります。

スローダウンの検知

アプリケーションを使っていると、なぜ処理が遅くなっているかの事実確認が難航することもあります。業務ロジックの処理時間を記録することで、業務ロジックのスローダウンを検知できます。また、システム観点の情報と組み合わせることで、システムのどこが原因で業務ロジックが遅くなったかを調査できます。

リソースの将来予測

「業務ロジックの処理量が増えたために、アプリケーションの動きが遅くなる」ということがあります。ある時点での業務ロジックの処理件数とシステム観点の情報を組み合わせることで、業務処理量に対してシステムが必要とするリソース量がわかります。そして、業務処理量の推移から処理量の限界を予想して、限界に達する前にリソースを追加することで、問題を回避できます。

システム改善案の検討

システムにエラーはつきものですが、可能な限りエラーを減らしたいのではないでしょうか。ある時点での業務ロジックの処理件数を記録することで、システムの改善案を検討できます。たとえば、失敗している理由の多くが利用者の入力値エラーが原因である場合には、エラーとなるパターンを洗い出すことで、入力時点でエラーとなる入力をさせないように改善できます。

また、システム観点での情報と組み合わせることで、システムの改善にもつなげられます。たとえば、業務ロジックの処理件数が多くなったことで、リソースが不足したためタイムアウトが発生し、業務ロジックが失敗してしまう問題を改善できたりします。

業務ロジックを監視するためのポイント

業務ロジックを1回実行するごとに記録する、業務ロジックへ渡したパラメータ、業務ロジックの成否、業務ロジックの処理時間は、ログに出力します。しかし、常にログに出力すると膨大な量になってしまうので、まずは致命的な失敗のみを出力するようにして問題を検知できるようにします。

問題となる業務ロジックに目星が付いたら、対象となる業務ロジックのログレベルを上げましょう。その際、記録したい内容ごとにログファイルを分けておくことで、分析がしやすくなります。

ある時点の業務ロジックの成功件数と失敗件数は、成功件数と失敗件数のMBeanを実装します。必要に応じてJMX経由で情報を取得することで、その時点での成功件数と失敗件数を得られます。定期的にこれらの件数を取得することで、値の推移を確認できます。ただし、バッチのように、特定の処理内で業務ロジックが何回実行されたかを取得する場合には、ログに記録することをおすすめします。

以下に業務観点で監視するサンプルコードを記載します。このサンプルコードは、業務観点での監視をわかりやすくすることを重視しています。実際にアプリケーションへ適用するには、ログの設計を行ったうえで、排他制御、ログレベルのチェックといったコードが必要です。

業務観点で監視するサンプル
public void bussinessLogicA (Parameter param) {

  mbean.executeCountUp(); // 開始回数を増やす
  logger.debug("{} ビジネスロジック開始: {}", System.nanoTime(), param);

  try {

    // ビジネスロジックを実行

    mbean.successCountUp(); // 成功回数を増やす
    logger.debug("{} ビジネスロジック成功", System.nanoTime());

  } catch (Exception e) {
    mbean.failCountUp(); // 失敗回数を増やす
    logger.info("{} ビジネスロジック失敗 {}", System.nanoTime(), e);
  }
}

MBeanは処理の実行回数、成功回数、失敗回数を管理し、実行時や処理の成功時・失敗時にそれぞれ数を1増やします。

普段は、失敗した時間と例外をログへ出力します。ログレベルをデバッグへ上げることで、開始時・成功時の時間と実行時の引数を出力します。

次回は、アプリケーションをシステム観点で確認する際のポイントについて解説します。

おすすめ記事

記事・ニュース一覧