クライムどこでもセミナー：『どこから調査する？』の悩みを解消！失敗しない仮想化DB監視術
•Download as PPTX, PDF•
0 likes•250 views
データベース管理者はアプリケーションのパフォーマンスの問題が発生したら、これがデータベースの問題かどうかも含めて、パフォーマンスの問題をすばやく見つける必要があります。 仮想化の流行に伴い、データベースも物理ハードではなく、仮想環境の一部として構築することが増えてきたことによって、SQLの不備やリソースの不足などデータベースの観点からのみではなく、仮想化の観点からもパフォーマンスの問題を分析する必要が出てきており、原因を突き止めるのが困難になる場合があります。 そこで紹介するのが、Database Performance Analyzerです。Oracle, SQL Server, MySQL, Db2, Sybaseといった様々なデータベースに対応しており、さらにこれらがVMware上で構築されている場合、仮想化の観点からもパフォーマンスを分析し、問題を総合的に判断することができます。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to クライムどこでもセミナー：『どこから調査する？』の悩みを解消！失敗しない仮想化DB監視術
Similar to クライムどこでもセミナー：『どこから調査する？』の悩みを解消！失敗しない仮想化DB監視術 (20)
More from 株式会社クライム
More from 株式会社クライム (20)
Recently uploaded
Recently uploaded (9)
クライムどこでもセミナー：『どこから調査する？』の悩みを解消！失敗しない仮想化DB監視術
- 2. 株式会社クライム • 主な事業内容 ソフトウェアの販売とサポート 海外ソフトウェアの日本語対応 • 弊社製品サイト https://www.climb.co.jp/ • お問合せ 東京：03-3660-9336 大阪：06-6147-8201 https://www.climb.co.jp/soft/contact/contact.php © 2020 Climb Inc. 2
- 3. 目次 1. 仮想化されたデータベースの悩み 2. Database Performance Analyzerによる監視術 3. デモンストレーション 4. プレゼントクイズ 5. 今後のセミナーの紹介 © 2020 Climb Inc. 3
- 4. 仮想化のメリット • 仮想化とは • 1台の物理的なサーバー上で複数の仮想的なサーバーを運用 • 物理サーバー上のリソース（CPUやメモリ）を複数に分割 • メリット • 管理のコストや負荷が削減できる • リソースを有効活用できる • 手軽に新しいサーバーを導入できる © 2020 Climb Inc. 4
- 5. 仮想化されたデータベース 仮想化の有無 仮想化した 仮想化していない 仮想化した割合 100% 50-99% 50%未満 87% 13% 24%24% 52% © 2020 Climb Inc. 5
- 6. 仮想化されたデータベース 0 10 20 30 40 50 60 70 80 90 100 SQL Server Oracle MySQL PostgreSQL MongoDB MariaDB DB2 SAP ASE その他 データベースの種類 データベースの種類 © 2020 Climb Inc. 6
- 8. 仮想化による悩み ・CPU Ready ・VM CPU Usage ・Host CPU Usage ・Co-Stop ・VM Memory Swap Rate ・VM Active Memory Usage ・Host Memory Usage ・VM Memory Overhead ・VM Memory Balloon ・VM Disk Commands ・VM Disk Usage ・VM Read/Write Rates ・Host Disk Device Read/Write Rates ・Host Max Disk Latency ・Host Disk Latency データベース側の監視に加え、仮想環境の監視も必要 仮想環境（VMware）のメトリックの例 © 2020 Climb Inc. 8
- 9. Database Performance Analyzer (DPA) ・パフォーマンス分析を機械学習異常検出と組み合わせて パフォーマンスの問題の根本原因を特定 ・VMwareからデータを取り込み仮想化レイヤーの データベースのパフォーマンスへの影響を簡単に判断 © 2020 Climb Inc. 9
- 10. DPAの監視アプローチ • 個々のSQLクエリの応答時間(レスポンスタイム)を測定 • 応答時間が遅くなっている部分を可視化 = ボトルネックを容易に特定 © 2020 Climb Inc. 10
- 11. DPAのアーキテクチャ © 2020 Climb Inc. 11 リポジトリDB （監視データを保持） 監視対象DB Webブラウザ DPAインストールサーバー （Windows/Linux） データ収集 負荷の少ない エージェントレスな監視
- 12. 対応データベース © 2020 Climb Inc. 12 リポジトリDB （監視データを保持） 監視対象DB DPAインストールサーバー （Windows/Linux） データ収集 複数のDBインスタンスを 一元的に管理/監視
- 13. 数クリックで遅延原因を特定・分析・最適化 • ドリルダウンしていくだけで、具体的な遅延原因と特定 © 2020 Climb Inc. 13
- 14. 数クリックで遅延原因を特定・分析・最適化 • ドリルダウンしていくだけで、具体的な遅延原因と特定 • リソースとの相関関係も明確に分析可能。 • 解決策を用いた最適化も。 © 2020 Climb Inc. 14
- 15. VMware仮想化の監視との統合 • データベースと仮想環境の パフォーマンスを関連付け • データベースのメトリックに 合わせて表示 • 発生したVMイベントの確認 © 2020 Climb Inc. 15
- 17. まとめ • 仮想化されたデータベースはパフォーマンスの調査が困難 • データベースと仮想環境の両方の監視が必要 • データベースと仮想化のパフォーマンスデータを 関連付けて監視が可能 • パフォーマンス低下の根本原因の調査が容易に © 2020 Climb Inc. 17
Editor's Notes
- 仮想化について簡単に説明すると、物理的な1台のサーバー上で、複数の仮想的なサーバーを運用することを「サーバーの仮想化」といいます。 サーバーの仮想化では、専用の仮想化ソフトウェアによって物理サーバー上のプロセッサ・メモリといったリソースを複数に分割し、仮想サーバーに割り当てて使います。 1台の物理サーバー上に複数のサーバーを集約できるため、管理のコストや負荷が削減できるメリットがあります。 そのため、様々な企業で仮想化が導入されており、自社のサーバーを仮想サーバーとして動かしています。 データベースももちろんその対象となっています。
- 実際にとある企業でアンケートを行ったところ、回答者の実に87%がデータベースを仮想化していると回答しました。 また、24%が自社のデータベースのすべてを仮想化している回答しました。 このうち、Vmwareの使用者が90%を占めているようです。
- また仮想化したデータベースの種類についてもアンケートを取ったところ、SQL Serverが一番多く、Oracle、MySQLと続いています。 オープンソースのDBも多い結果となりました。 このように様々な企業でデータベースが仮想化されていますが、仮想化は便利な反面、デメリットといいますか、不便な面もあります。 例えば、仮想化されたデータベースのパフォーマンス分析を行いたい場合、どのようにしたらよいのでしょうか？
- そのため、データベースの問題なのか、仮想化の問題なのか、切り分けが必要になり、根本原因を突き止めるのが困難になってきます。
- そのため、データベース側の監視に加え、仮想環境の監視も必要になってきます。 しかし、ただでさえ大変なデータベースの管理に加え、ここに記載したような多数の仮想環境のメトリックまで監視を行うのは非常に大変です。 仮想環境の監視用のツールを使用することもできますが、データベースと仮想環境を別々に監視していると、それぞれのデータを関連付けることができず、結局何が問題なのかを調査するために複雑な作業や時間が必要になってきます。 そこで紹介したいのが、
- 特長、個々のSQLクエリの応答時間(レスポンスタイム)を測定 通常の処理の流れ、ユーザーがクエリの実行⇒データベースで処理⇒クエリの結果を出力 複雑なクエリを実行、各SQLの処理にかかる時間を測定し可視化することで、どのクエリの実行に時間がかかっているか、ボトルネックとなっているかを容易に特定できる チャートによって可視化され、クエリ全体の遅延だけでなく、さらに踏み込んだボトルネックを容易に特定できる
- 複数のDBを監視したい DPAをインストールするサーバーと監視データを保持するリポジトリDBを用意 これらをDPAに登録するだけで監視が行える 監視対象DBにはエージェント不要 ユーザーが監視を行いたいときはWebブラウザからDPAサーバーにアクセスすれば見れる
- 監視対象として対応しているDBはこれら これらを一つのDPAサーバーでまとめて監視可能 アプリケーションによって異なるDBを使用するなど、複数のDBを運用する必要があっても、監視は一つのコンソールからまとめて行える
- 実際に取得したデータからユーザーがどのようにしてパフォーマンス低下の根本原因を特定していくか 非常に簡単 表示されたパフォーマンスデータの気になるところをどんどんクリックしていくだけで、簡単に特定 気になるDBを選択⇒データベースの詳細情報の長い部分が遅延している箇所⇒クエリのどの部分でどの処理で遅延しているかがわかる⇒処理のイベント等を確認することで何が原因かを特定できる →この場合はCPU待機イベントがボトルネック
- また、単純に遅延原因を特定するだけでなく、リソースの情報も収集しているので、クエリとリソースとの相関関係も一目でわかる 左下の図、赤枠で囲った箇所、クエリの応答時間が伸びているが、リソースの状況をみると、メモリの負荷が高かったことがわかる クエリが遅延していた原因を表示するだけでなく、それに対する解決策の提案も行ってくれるので、それをもとに遅延の改善を行うこともできる リソース相関関係の分析。この場合だとメモリ消費がわかる、 応答時間が遅延していた事象の説明だけではなく、ソリューションも掲示 →パフォーマンスの最適化も楽々
- そして、DPAはデータベースの監視だけでなく、Vmwareの監視も行うことができます。 データベースとVmwareのパフォーマンスデータを関連付けして表示するため、特定のクエリにドリルダウンして、応答時間が長い個所を見つけた際にも、その時にVMware側で問題が発生していなかったかを一目で見ることができます。 また、VMWareで発生したイベントも表示されるため、アプリケーションのパフォーマンスが低下したときに、vMotionなどのタスクがVMに対して発生していなかったかどうかを確認できます。
- 左側が各DBの応答時間の推移 複数DBを登録している場合、マウスオーバーすることでDB名がわかります。 スクロールして登録しているDBをみせる アラートが出てることの説明とか Status Summaryからもある程度はどんな問題が発生しているかわかる インスタンスをクリック 各SQLの応答時間が可視化されている 棒グラフが縦に長いところは応答時間が長い ＝パフォーマンスが悪かったといえる マウスオーバーするとどのようなクエリが処理されたか、応答時間はどれくらいだったのかを見れる 過去の応答時間に比べ、極端に長くなっていた場合にはクリティカルとして表示される Resourcesタブをクリックすると、リソースとの相関関係が見れる この時DBが仮想化されている場合、OS上のリソースだけでなくVMwareの観点から見たリソースも見ることができる Waitsタブ SQL Serverの待機イベントごと リンクをクリックすることでどのようなイベントなのかを確認 各タブを見せて、様々な観点から応答時間の変化を知ることができる 特定のユーザーのみ遅いのか、特定のサーバーからの実行が遅いのかなど Critialとなっているバーをクリック 時間単位のパフォーマンス状況を確認 応答時間が長いバーをさらにクリック 待機イベントを確認からの解決策 Tunigタブ この日に実行されたクエリのうちこれだけアドバイスできるクエリが見つかりました RessourceタブでDBサーバー上のリソースの使用状況を見れる さらに仮想化されたデータベースの場合、DBインスタンス、VM、物理ホストのメトリックを並べてみることができるので、SQLの応答時間が長い時にVmware上で以上がなかったを検知 矢印にマウスオーバーでVMイベントを確認 このようにパフォーマンスグラフの気になった個所をクリックしてどんどんドリルダウンしていくだけで、根本原因を簡単に特定 あまりDBに詳しくないユーザーでもどこが悪いのかを見つけることはできるので、パフォーマンス遅延のエビデンスとしても利用できる