データベース稼働環境は複雑化し性能調査も難易度が増している
国内の知名度はまだそれほど高くないが、SolarWindsはグローバルのネットワーク監視領域でNo.1シェアを持つベンダーだ。ネットワーク監視以外にもサーバー、アプリケーション性能、仮想環境、ストレージなどあらゆる領域の稼働状況の可視化が可能だ。SolarWindsではスケーラブルな共通プラットフォームを提供し、多角的な分析ができる。多様な監視の中で、データベース性能分析調査を担うのがDPAだ。
SolarWindsでは、製品提供だけでなく積極的に技術情報を公開している。またユーザーコミュニティの「THWACK」の活動が盛んなことでも有名だ。そのTHWACKでのアンケートによれば、データベースの稼働環境の80％が仮想化されており、管理するデータベースインスタンスの数が25以上あると答えた管理者も44.8％ある。中には「1人で200以上のインスタンスを管理しているとの回答もありました」と大森氏。これらの数字からは、データベース管理者の管理負荷がかなり高まっている様子がうかがえる。
クラウドの利用、特にクラウドベンダーが提供するマネージドサービスの利用が増えている。仮想化やマネージドサービスといった複数プラットフォームがあり、データベースの稼働環境の複雑性は増している。この複雑なデータベース環境のせいで、データベースの性能分析もさらに複雑化している。
管理者はデータベース処理が遅ければ、ボトルネックを調べ、根本原因を見つけ、適切な対策を施す。たとえばクラウド上で利用しているデータベースサーバーが、メモリが足りないために処理が遅くなっていると分かれば、メモリ追加の判断をする。クラウドではインスタンスサイズがあらかじめ決まっているので、追加したいメモリ容量が2ギガバイト程度でも、1つ上のスペックにすることでメモリやCPUは倍になり、時間当たりコストも倍となることもある。
追加したメモリのおかげで、一旦は性能が回復する。しかし2か月後に再びメモリが足りなくなるかもしれない。これは最初の段階で根本原因を追及できていなかったため、メモリ追加だけでは問題が解決していないのだ。結果、その後もメモリ追加を続ければ、運用コストがさらに上昇しかねない。
またデータベース管理者に対し、よくある問い合わせが「なんだか遅い気がする」と言うものだ。あるいは、今は大丈夫だけれど「急に遅くなった」もよくある。これらに対処しようとしても、問題が再現するかは分からない。多くの場合、時間に余裕がなく再び問題が発生するまで長い時間待つこともできない。
通常、データベース管理者は問題を解決のために、CPUやメモリなどが足りないことを想定し、基本的なリソースの調査から始めるだろう。VMwareの仮想化環境で動いていれば、仮想サーバー側の処理がぶつかり遅いこともあるため、そのような外部要因も調査する。さらに固有リソースも調査する。たとえばバッファIOやトランザクションに対するディスクIOの状況を調べ、他にも遅いクエリを見つけて実行プランやトレース情報の確認もするだろう。
Microsoft SQL Serverを利用していれば、性能調査のためにSQL Server Management Studioを使い、さまざまな画面を表示し原因の分析を進めるはずだ。さらにSQL Server Diagnostic Queriesなどで、エキスパートがより深い調査をするかもしれない。オンプレミスのSQL Serverだけなら、これらだけで調査は完結するだろう。
クラウドのマネージドサービスを利用していれば、それぞれのクラウドベンダーが用意するWebコンソールに接続して調査する。つまり性能調査のために「環境ごとに別々のツールを使いこなさなければなりません」と大森氏。複数のデータベースを扱う管理者は、このような複雑化する管理ツールの使いこなしにも苦労する。
稼働環境を選ばず専門家のノウハウに基づくアドバイスも得られる
SolarWindsのDPAは、誰でも簡単に使いこなせるデータベースの性能調査ツールだ。エージェントなしで監視ができ、監視対象データベースのCPU負荷も1％未満とかなり小さい。
DPAによる性能調査では、処理の待ち時間を中心に可視化を行う。これは、実際のエキスパートの性能調査手法に倣ったものだ。その上で「機械学習を使った異常検知ができるのも特長です」と大森氏。DPAでは、待機イベントの内部処理に至るところまで分析して、問題の根本的な原因を明らかにする。調査した結果のサマリーは1枚のレポートにまとめられ、分析した結果だけでなく施すべきチューニングのアドバイスも記載される。調査結果を得るまでに、画面遷移は4つしかない。
普段は問題なくある時点で突然異常が出て遅い場合には、処理が遅いクエリを闇雲に探すのではなく、DPAでは実際に遅くなった時点のクエリを見て調査する。クエリは秒単位で細分化してきめ細かい調査が可能だ。また遅いクエリのトップ10や待機イベントのトップ10も表示でき、1つ1つの内部処理でどこに時間がかかっていたかなども詳細レポートで分かる。さらに遅かったクエリについては、データベースのキャッシュのヒット率やディスクIO性能などを、時間軸を合わせ調査できる。
仮想化されたデータベースが増えていることもあり、DPAではVMwareのvCenterとESXiにも対応している。これにより、バックアップなどのVMwareイベントとのバッティングがなかったかなども容易に確認できる。「外部要因については、他のSolarWindsの監視機能と組み合わせられ、ネットワークやサーバーの状況とも合わせた調査ができます」と大森氏は言う。
DPAは本番運用での性能調査ができるだけでなく、テストや開発などフェーズを選ばずに利用可能だ。たとえばアプリケーション開発で、データベースとのやり取りに問題が発生するケースがある。データベースから応答が返ってこず、タイムアウトが発生する。その場合は、タイムアウトの原因を調査し対処するだろう。
本来はシンプルなSQL処理のはずなのに、データベースリソースを監視すると予想より多くのSQLが走っているのが分かるかもしれない。クエリをフレームワークやツールに任せていると、チューニングの施しようがないケースもあるが、その場合もトレースを追いかけるなどで原因を探り、何らかの対処をしなければならない。
このような開発フェーズで発生するデータベース処理の困りごとの多くが、DPAの活用で解決できる。クエリ状況をリアルタイムに確認し、ブロッカークエリを見つけてその内容を容易に確認できる。リアルタイム監視だけでなく、統計情報からの性能分析調査ももちろん可能だ。
たとえば"Updating"や"Sending data"などの待機イベントが見つかった場合、それらが何を意味しているのかをまずGoogle検索など調べるだろう。検索して意味が分かれば、さらに対処方法も検索し探すはずだ。一方でデータベースのエキスパートなら、Sending dataが何で、問題が出た際にどう対処するかは既に分かっている。DPAではそのようなエキスパートの知見を、すぐにポップアップ表示するのだ。「10年以上に亘りDPAを開発しているメンバーであるデータベーススペシャリストが、自分たちのナレッジをまとめて提供しています」と大森氏は説明する。
データベース管理者がよく行う、実行プランを使ったチューニングについては、DPAではSQL ServerとOracleに対応している。クエリのどこに時間がかかり、それにどう対処すれば高速化が図れるかまで提示し、今流れているクエリの検索も可能だ。自分が開発したアプリケーションから、実際にどのようなクエリが流れているかの確認がすぐにできる。
DPAはオンプレミス、クラウドの主要なリレーショナルデータベースで利用できる。開発はオンプレミスで行い、テスト環境をクラウドに作り、本番はAmazon RDSに展開すると言ったように、稼働環境が異なっても1つのDPAから分析できるのは便利だ。オンプレミスのサーバーはもちろん、クラウド上のインスタンスでも動かせ、分散して動く複数のDPAを1つのポータルにまとめて管理することも可能だ。
データベースの監視は、まず死活監視から始まり、続いて性能監視、予兆監視と監視レベルが徐々に深くなるだろう。DPAは深いレベルの監視のためにメトリックスの相関分析が可能で、さらに自動での異常検知や性能改善のための推奨事項提示までできる。DPAでかなり深いレベルまで監視ができ、監視のさらに深いレイヤにあるオブザーバビリティの一部についても実現している。DPAは今まさにデータベースで起こっていることの見える化ができ、既にオブザーバビリティを実現するツールになりつつあるのだ。
多くの開発者が、データベース性能の調査分析は分からないことも多く、できれば関わりたくないと考えるかもしれない。こうした開発者に対して大森氏は「専門家でなくても使いこなせるツールがあるので、ぜひ開発者も、運用者も、さらにはデータベースのスペシャリストも、DPAを試してみてほしいです。DPAなら、誰でも使いこなせます」と呼びかけ、セッションを終了した。
