今回は、オープンシステム向け性能管理ツール「ES/1 NEO CS」と次世代型エンタープライズシステム向け性能管理ツール「ES/1 Shelty」を活用し、性能分析した事例を紹介します。
お客様の開発部門ご担当者様より、「アプリケーションの機能追加が本番システムに与える影響について」分析してほしいとの
ご依頼を頂きました。
分析の観点は実施した負荷テストのリソース使用状況は想定通りか、機能追加が本番機に与える影響の2点です。
これらの観点を、下記①～④の手順で、検証機と本番機のデータを使用し、分析を実施しました。
【検証機】
① 検証機で追加機能の負荷テスト
② 負荷テスト時の分析、改善点の洗い出し
③ 改善後、再度負荷テストと分析
【本番機】
④ ②と③の負荷テスト結果と本番システムの稼働実績より、機能追加後の負荷をシミュレーション
ここからは、検証機及び、本番機それぞれにおける分析結果の詳細をお伝えします。
・負荷テストのシナリオ
検証機では、業務ピーク時のアクセス負荷を100とし、50%、100%、200%の3パターンで負荷を掛けたシナリオを実行
・分析の観点
‐応答時間：目標値（3秒以内）に収まっているか
‐リソース：想定範囲内の負荷であるか
‐ミドルウェアの稼働に問題がないか
・分析結果
‐応答時間→3秒以内で問題なし
‐リソース→CPU、メモリ、I/Oともに想定内の負荷のため問題なし
‐ミドルウェア→Oracleヒット率が想定外の稼働であること、負荷の高いSQLが実行されていることを発見
・お客様にてチューニングの実施
ミドルウェアの結果に対して下記のチューニングを実施
‐テストシナリオと実行の順番を変更
‐SQLの変更を実施
・再検証のための負荷テスト時の分析結果
‐テストシナリオを変更して再実行後、想定通りのOracleヒット率になっていることを確認
‐SQLの変更後、SQL総実行時間が改善され、且つテスト結果にも影響を及ぼしていないことを確認
ここでは、負荷テストの分析とチューニング後の結果の詳細をお伝えします。
①応答時間
応答時間が目標値の3秒以内に収まっていることを確認しました。(図1)
図1から負荷テストで流れた全トランザクションにおいて、応答時間は3秒以内であることが確認できます。
また、最大応答時間(1,912ms)はURL① 18:59:50~18:59:52に流れたトランザクションであることも確認できます。
②リソースの使用状況
負荷テスト時のリソース(CPU/メモリ/IO)は問題ないことを確認しました。(図2~4)
図2からCPU使用率は60%～80%であるため、問題ないことが確認できます。
図3からメモリは約10GBの空きがあり、ページアウトも多発していないため問題ないことが確認できます。
図4から10ms前後のレスポンス時間であるため、問題ないことが確認できます。
③ミドルウェアの稼働状況
ミドルウェアではJavaとOracleの稼働の詳細を確認しました。
Oracleの稼働において、シナリオ毎にキャッシュをクリアしているにも拘らず、バッファキャッシュヒット率に違いが出ていることが判明しました。こちらは想定外の稼働であった為、テストシナリオと順番を変更し、再実行したところ、すべてのシナリオで同等のバッファキャッシュヒット率となり、問題ないことを確認しました。（図5)
④負荷の高いSQLを洗い出し
また、負荷テスト時に実行されたSQLの一覧を負荷率順にソートし確認したところ、負荷が高いSQLにおいて想定外の稼働をするものが存在していることに気づき、該当するSQLの最適化を実施いただきました(図6)
その後、最適化されたSQLの稼働を比較したところ、総実行時間が約75%削減されていることを確認しました。(図7)
本番機では、「ES/1 NEO CS」により取得したピーク時の稼働実績を、検証機では、「ES/1 Shelty」により取得した負荷テスト時の稼働実績、これらのデータを掛け合わせ、機能追加時の負荷予測を実施しました。
・分析の観点
‐リソース使用率：本番機のリソースに機能追加分のリソース負荷が増加しても問題がないか
‐JVMメモリ：本番機のヒープに機能追加分のヒープ量が増加しても問題がないか
・分析結果
‐CPU使用率→機能追加後もCPU使用率は問題なし
‐JVMメモリ→ヒープメモリが枯渇する可能性を指摘
①ピーク時のリソース使用率の比較
本番機のピーク時におけるCPU使用率に機能追加時のCPU負荷率を追加し、シミュレーションしたところ、CPU使用率に問題がないことを確認しました。(図8~9)
図8からCPU使用率においては、テスト①の範囲で最大10％前後の負荷がかかることが想定できます。
図9から業務ピーク月におけるAP1,AP2の最大CPU使用率は40％以下を推移していることが確認できます。
このことから、機能追加によって本番機のCPUに10％前後の負荷がかかっても問題がないことが確認できます。
②ヒープ使用量の想定
JVMヒープでは、GC発生のタイミングから、どの程度メモリを消費するかを確認したところ、機能追加を実施した場合、ヒープメモリが枯渇する可能性があることをお伝えしました。(図10~11)
現在の本番機では、ヒープサイズを拡張している為、機能追加しても問題ないことを確認しています。
図11はピーク日における本番機のヒープ使用量に機能追加分の600MBを追加したグラフです。
このグラフから、一時的にヒープ使用量が最大値に達している時間帯が確認できます。一時的なヒープの増加に対応するために、本番機のヒープサイズを増やす、もしくは、機能追加で利用するヒープ使用量を削減する必要があることをお伝えしました。
お客様からは今後の機能追加時の負荷テストだけでなく、リリース後の本番機の監視においてもES/1 Sheltyを活用していきたいとの声を頂きました。
今回の事例が、開発部隊の方々が担当されるであろう機能追加時の負荷テストの可視化や、本番環境での運用の最適化のお役に立ちましたら幸いです。