PR

SQLパフォーマンスの「見える化」をプロセス全体に適用する

2010年10月25日(月)
藤井 等

テスト段階でのパフォーマンス問題への対応

SQLパフォーマンスを最も重点的にチェックするのは、テスト段階でしょう。テスト段階では、ボトルネックを検出するという作業が重要になりますが、アプリケーションの形態によって、そのアプローチは異なります。クライアント/サーバーのようなシンプルなアーキテクチャを採用している場合には、SQLに原因があるかどうかは比較的容易に理解できます。しかし、アプリケーションサーバーなどを用いた多層分散アーキテクチャの場合、分散したさまざまなサービスのどこにボトルネックがあるのかを理解しなければなりません。

エンバカデロのツールの場合、J OptimizerというJavaアプリケーション向けのパフォーマンスプロファイリングツールがあります。このツールには、Javaアプリケーションのプロファイリング、メモリリーク検出、スレッドデバッグなどの機能が用意されています。このツールに含まれているRequest Analyzerを用いると、JEEの各サービスのどこにボトルネックがあるかを理解でき、最終的にデータベースアクセスに問題があると分かると、そのSQLを知ることもできます。

このように、ひとつのツールだけでなく、いくつかのツールを組み合わせることで、アプリケーション全体から、最終的に問題となるSQLの細部までドリルダウンしていくことができるのです。

図2:Request AnalyzerによるJEEアプリケーションのパフォーマンス分析(クリックで拡大)

運用段階でのSQLパフォーマンス分析とチューニング

運用段階でのトラブルは可能な限り回避したいものですが、実際にシステムが稼働し始めると、予期しないパフォーマンス劣化が発生するものです。

このようなケースでは、どのようにDB Optimizerを活用すればよいのでしょうか。

ひとつ重要なのは、運用環境で発生したパフォーマンス問題は、必ずしもラボでは再現しないということです。運用チームから報告を受け、テスト環境で問題箇所を確認しようとしても、同じようなパフォーマンス劣化を確認できなければ、推測による解決しか望めません。

そこでお薦めする構成が、運用環境でのDB Optimizerの活用です。DB Optimizerは、特別なエージェントも不要で、サーバーに負荷をかけることなくパフォーマンス情報を収集することができるので、運用環境でのプロファイリングについても問題はありません。常時プロファイリングではなく、問題が発生した時点でプロファイリングを行うようにすれば、さらにサーバーへの影響は最小化できます。

そして、DB Optimizerでは、収集したプロファイリング情報をファイルに保存して別の環境で利用できます。つまり、収集したプロファイリング情報を他のDB Optimizerで「再生」することができるのです。この機能によって、運用環境で発生したパフォーマンス問題を、まさに問題が発生しているその環境で収集した情報を用いて、ラボで解析できるのです。

プロファイリング情報の共有機能は、運用チームと開発チームをつなぐ重要な役割を担います。これは、開発チーム内でも、テスターと実際の分析エンジニアの分業を可能にし、パフォーマンス問題解決をより効率化します。

エンバカデロ・テクノロジーズ 日本法人代表
千葉大学文学部行動科学科卒業。石油関連会社でGISなどの開発を経験したのち、1995年、ボーランドに入社。マーケティングとしてJava開発ツールJBuilderやVisiBrokerなどミドルウエア製品の立ち上げを行う。2008年7月、ボーランドの開発ツール部門を合併したエンバカデロ・テクノロジーズに移籍。2009年1月より日本法人代表を務める。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています