今回は、あるシステムのDBサーバーの負荷が想定より高くなる事象について、オープンシステム向け性能管理ソフトウエア ES/1 NEO CSシリーズを活用した分析事例をご紹介いたします。
インフラ部門のお客様からCPU負荷上昇により、システムへ接続できないという業務影響が発生したとのご連絡をいただき、分析を実施いたしました。
分析内容は負荷上昇時の原因分析です。以下の分析により、DBサーバーの負荷が上昇した原因がアプリ機能の追加であること、およびその時期と負荷を上昇させているURLを明らかにすることができました。
分析の流れ
１.CPU負荷と業務量（コンシステントGET回数）の確認
２.HTTPアクセス数を確認し、CPU負荷・業務量の増加に影響していることを確認
３.HTTPアクセスをグループ化し、特にCPU負荷・業務量増加に関連しているグループを特定
４.対象グループとCPU負荷の相関が高まった時期を特定
５.CPU負荷の上昇に影響を与えたシステム変更を特定
上記結果により、CPU負荷が上昇した事象の原因が特定でき、第三者的な視点でご報告させていただいたことにより部門間で共有の課題として認識していただくことにつながりました。
以下では、経緯から分析結果を得るまでの詳細をご紹介していきます。
経緯
対象はメインフレームからオープン系へ移行中のシステムです。移行が完了した機能は、既に本番環境で稼働していました。
その本番環境において、次期サーバーの見積もりが必要となりましたが、DBサーバーのCPU使用率が想定より高く、ピーク時にはシステムへの接続ができないといった業務影響が発生しました。そこで、負荷が上昇した原因を突き止め、問題を改善するため、今回の分析を実施いたしました。
システム構成
WEB/APサーバー、DBサーバーの2層で構成されています。
● WEB/AP : IBM HTTP Server / WebSphere
● DB : Oracle
ピーク時期は月末月初で、この時期に業務影響が発生するとのことでした。利用者は営業部門の方のため、ピーク時期を運用によってずらすということは難しいシステムです。
調査内容
1.負荷状況の確認
まず、ピーク時の負荷状況の確認を行いました。業務影響発生の事象確認を行うため、当該日のプロセッサ使用率を確認しました。
図1のグラフは、プロセッサ使用率とOracleのデータから、コンシステントGET回数を重ねた複合グラフです。この図を見ると、9時台にプロセッサ使用率が100％まで到達していることがわかります。合わせて参照系の処理であるコンシステントGET回数がプロセッサ使用率と同じように上昇しているため、コンシステントGET回数が増加したことがプロセッサ使用率の上昇に影響していると判断しました。
下記のような２つの要素を重ねた複合グラフを用いることで、要素間の関係性を確認できます。
図1：プロセッサ使用率とコンシステントGET回数
2. 負荷増加時期の確認
次に、コンシステントGET回数（＝業務量）がいつから増加し始めたのか、急激に増えたのかもしくは漸増傾向にあったのかを確認します。
そこで、各月のコンシステントGET回数の最大値を確認していきます（図2）。
図2：各月最大コンシステントGET回数
図2のグラフを確認しますと、2019年の1月から最大値に増加傾向が見られます。特に、2019年の3月は最大値が大きく上昇しており、以前と比べて業務量が大きく増加したことがわかります。（2月：およそ200万回→３月：およそ280万回）
3.負荷増加の原因特定
2018年の12月～2019年の1月の間でシステムに変更が加えられた可能性が考えられたため、お客様に確認いたしましたところ、2018年12月17日に機能の追加があったことが分かりました。そこで、その機能追加が負荷上昇に関連しているかどうかを確認しました。
まずはDBの負荷であるコンシステントGET回数の増加に影響を与えているデータ種別を調査します。以下３つの中からDBサーバーのCPU使用率と相関の高いものを特定していきます。（図3）
1. アクセス件数（HTTPログ）
2.Servlet起動回数（WebSphere）
3.JDBC実行回数（WebSphere）
図3：DBサーバーCPU使用率×アクセス件数
図3のグラフから、DBサーバーのCPU負荷とHTTPログのアクセス件数における相関が高いことがわかります。そこで、HTTPログデータを利用し、URLをグルーピングしてどのグループが最もDBへ負荷を与えているかを確認します。
そのために、DBサーバーのCPU負荷とHTTPログのアクセス件数の相関係数を確認します。期間を分けてURLグループ別に値を確認したところ、2019年1月以降相関の高かったURLグループはAとBの2つとなりました。（図4）
※一般に相関係数が0.7以上となると、相関が高いとみなします。
図4：DBサーバーのCPU使用率×URLグループ別のアクセス件数の相関表
では、これらのURLグループでの相関が高くなった時期はいつなのかを探っていきます。
1ヶ月毎の相関係数を折れ線グラフで確認すると、2019年1月から相関が高くなっています。(図5)
図5：DBサーバーのCPU使用率×URLグループ別のアクセス件数の相関係数グラフ
次に、機能追加を実施した2018年12月17日を分岐点として相関係数の確認を行います。
12月のデータを対象に対象日前後で相関係数を比較すると、12月17日を境に相関が高くなっています。（図6）
図6： 2018年12月の相関係数（URLグループA・B）
上記の結果から、12月17日に追加された機能がURLグループA,Bに属しており、DBへの負荷を高めたことが確認できました。
本事象の解決に向けて
DBへの負荷が高まった（＝CPU使用率が上昇した）理由は、2018年12月17日の機能追加によることが明らかになりました。ここから考えられる解決策は以下のようになります。
1.プログラムの改修
2.読み込みデータ量の削減
今回のケースですと、パラメータ変更によるチューニングではDBの負荷を小さくすることは難しいため、アプリへの変更や、DBの構成変更による対応策をご提案させていただくこととなりました。
まとめ
今回は、DBへの負荷上昇の原因を特定するため、対象システムにおいて収集している複数のデータを合わせて分析を実施しました。このような分析によって、インフラ側からのアプローチでは解決できないことや、情報システム部門全体における問題意識の共有にお役立ていただけますと幸いです。
執筆者
Y.I.
営業技術本部 技術サービス統括部 技術サービス１部
お客様担当SEとして、製品の構築から活用方法までの一連のサポートを担当
お客様環境にて性能問題が発生した際には、製品のアウトプットを利用し、問題解決に向けた調査／提案業務を実施
■経歴
2017年 入社
2017年9月～ 2018年2月まで西日本でのお客さまサポートを担当
主にシステムリソース情報からの性能管理サポートに従事し、近年は、上記に加えAPM製品を利用したユーザー体感レスポンスやアプリケーション視点での性能管理サポートにも従事。現在に至る
