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

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

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

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

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

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

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

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

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

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

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

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