クライムどこでもセミナー：『どこから調査する？』の悩みを解消！失敗しない仮想化DB監視術

Editor's Notes

• #5: 仮想化について簡単に説明すると、物理的な1台のサーバー上で、複数の仮想的なサーバーを運用することを「サーバーの仮想化」といいます。サーバーの仮想化では、専用の仮想化ソフトウェアによって物理サーバー上のプロセッサ・メモリといったリソースを複数に分割し、仮想サーバーに割り当てて使います。 1台の物理サーバー上に複数のサーバーを集約できるため、管理のコストや負荷が削減できるメリットがあります。 そのため、様々な企業で仮想化が導入されており、自社のサーバーを仮想サーバーとして動かしています。 データベースももちろんその対象となっています。
• #6: 実際にとある企業でアンケートを行ったところ、回答者の実に87%がデータベースを仮想化していると回答しました。 また、24%が自社のデータベースのすべてを仮想化している回答しました。 このうち、Vmwareの使用者が90%を占めているようです。
• #7: また仮想化したデータベースの種類についてもアンケートを取ったところ、SQL Serverが一番多く、Oracle、MySQLと続いています。 オープンソースのDBも多い結果となりました。 このように様々な企業でデータベースが仮想化されていますが、仮想化は便利な反面、デメリットといいますか、不便な面もあります。 例えば、仮想化されたデータベースのパフォーマンス分析を行いたい場合、どのようにしたらよいのでしょうか？
• #8: そのため、データベースの問題なのか、仮想化の問題なのか、切り分けが必要になり、根本原因を突き止めるのが困難になってきます。
• #9: そのため、データベース側の監視に加え、仮想環境の監視も必要になってきます。 しかし、ただでさえ大変なデータベースの管理に加え、ここに記載したような多数の仮想環境のメトリックまで監視を行うのは非常に大変です。 仮想環境の監視用のツールを使用することもできますが、データベースと仮想環境を別々に監視していると、それぞれのデータを関連付けることができず、結局何が問題なのかを調査するために複雑な作業や時間が必要になってきます。 そこで紹介したいのが、
• #11: 特長、個々のSQLクエリの応答時間(レスポンスタイム)を測定 通常の処理の流れ、ユーザーがクエリの実行⇒データベースで処理⇒クエリの結果を出力 複雑なクエリを実行、各SQLの処理にかかる時間を測定し可視化することで、どのクエリの実行に時間がかかっているか、ボトルネックとなっているかを容易に特定できる チャートによって可視化され、クエリ全体の遅延だけでなく、さらに踏み込んだボトルネックを容易に特定できる
• #12: 複数のDBを監視したい DPAをインストールするサーバーと監視データを保持するリポジトリDBを用意 これらをDPAに登録するだけで監視が行える 監視対象DBにはエージェント不要 ユーザーが監視を行いたいときはWebブラウザからDPAサーバーにアクセスすれば見れる
• #13: 監視対象として対応しているDBはこれら これらを一つのDPAサーバーでまとめて監視可能 アプリケーションによって異なるDBを使用するなど、複数のDBを運用する必要があっても、監視は一つのコンソールからまとめて行える
• #14: 実際に取得したデータからユーザーがどのようにしてパフォーマンス低下の根本原因を特定していくか 非常に簡単 表示されたパフォーマンスデータの気になるところをどんどんクリックしていくだけで、簡単に特定 気になるDBを選択⇒データベースの詳細情報の長い部分が遅延している箇所⇒クエリのどの部分でどの処理で遅延しているかがわかる⇒処理のイベント等を確認することで何が原因かを特定できる →この場合はCPU待機イベントがボトルネック
• #15: また、単純に遅延原因を特定するだけでなく、リソースの情報も収集しているので、クエリとリソースとの相関関係も一目でわかる 左下の図、赤枠で囲った箇所、クエリの応答時間が伸びているが、リソースの状況をみると、メモリの負荷が高かったことがわかる クエリが遅延していた原因を表示するだけでなく、それに対する解決策の提案も行ってくれるので、それをもとに遅延の改善を行うこともできる リソース相関関係の分析。この場合だとメモリ消費がわかる、 応答時間が遅延していた事象の説明だけではなく、ソリューションも掲示 →パフォーマンスの最適化も楽々
• #16: そして、DPAはデータベースの監視だけでなく、Vmwareの監視も行うことができます。 データベースとVmwareのパフォーマンスデータを関連付けして表示するため、特定のクエリにドリルダウンして、応答時間が長い個所を見つけた際にも、その時にVMware側で問題が発生していなかったかを一目で見ることができます。 また、VMWareで発生したイベントも表示されるため、アプリケーションのパフォーマンスが低下したときに、vMotionなどのタスクがVMに対して発生していなかったかどうかを確認できます。
• #17: 左側が各DBの応答時間の推移 複数DBを登録している場合、マウスオーバーすることでDB名がわかります。 スクロールして登録しているDBをみせる アラートが出てることの説明とか Status Summaryからもある程度はどんな問題が発生しているかわかる インスタンスをクリック 各SQLの応答時間が可視化されている 棒グラフが縦に長いところは応答時間が長い ＝パフォーマンスが悪かったといえる マウスオーバーするとどのようなクエリが処理されたか、応答時間はどれくらいだったのかを見れる 過去の応答時間に比べ、極端に長くなっていた場合にはクリティカルとして表示される Resourcesタブをクリックすると、リソースとの相関関係が見れる この時DBが仮想化されている場合、OS上のリソースだけでなくVMwareの観点から見たリソースも見ることができる Waitsタブ　SQL Serverの待機イベントごと リンクをクリックすることでどのようなイベントなのかを確認 各タブを見せて、様々な観点から応答時間の変化を知ることができる 特定のユーザーのみ遅いのか、特定のサーバーからの実行が遅いのかなど Critialとなっているバーをクリック 時間単位のパフォーマンス状況を確認 応答時間が長いバーをさらにクリック 待機イベントを確認からの解決策 Tunigタブ この日に実行されたクエリのうちこれだけアドバイスできるクエリが見つかりました RessourceタブでDBサーバー上のリソースの使用状況を見れる さらに仮想化されたデータベースの場合、DBインスタンス、VM、物理ホストのメトリックを並べてみることができるので、SQLの応答時間が長い時にVmware上で以上がなかったを検知 矢印にマウスオーバーでVMイベントを確認 このようにパフォーマンスグラフの気になった個所をクリックしてどんどんドリルダウンしていくだけで、根本原因を簡単に特定 あまりDBに詳しくないユーザーでもどこが悪いのかを見つけることはできるので、パフォーマンス遅延のエビデンスとしても利用できる