SQLの実行を「見える化」する

システム性能の重要な位置を占めるデータベースのパフォーマンス

ソフトウエアが大規模化、複雑化していく中で、システムのパフォーマンス問題にかかわるトラブルの話を多く耳にします。「安定稼働していたシステムが突然遅くなった」「テスト段階では問題がなかったのに、本稼働で思ったようなパフォーマンスが出ない」「新しい環境に移行したら途端に性能が出なくなった」など。

これらの症状には、さまざまな原因が考えられます。実際には、複合的にいろいろな要素が絡み合っていることが多く、一概に「ここが悪い」と指摘することはできません。

しかし、多くのシステムでデータベースにかかわるパフォーマンス問題が発生しているのは事実であり、しかも、その性能劣化が、指数関数的に拡大していることが多いことを見逃すことはできません。データベースにかかわるパフォーマンス問題は、ハードウエアパフォーマンス、ネットワークパフォーマンス、DBMSの処理パフォーマンス、データ転送の速度や量など、いろいろな要素が関係しますが、これらが複合的に絡み合って、実際のデータ処理、つまりユーザーの体感や操作性にかかわる重大なパフォーマンス劣化を引き起こしています。

特に扱うデータ量が膨大であったり、複雑な処理を必要とする操作であればあるほど、これらの影響は大きくなり、「誰が見ても遅い」と感じるほどに性能に影響を与えます。そして、その損失は計り知れません。

そもそも、見て分かるほどに遅くなるまで問題を認識できないというのも問題です。実際のデータ処理にどれだけの遅延があり、どのようなリスクがあるのかを把握してはじめて事前の対処が可能になるというものです。

データベースパフォーマンスは誰が対処すべきか？

ここで、データベースパフォーマンスとひとくくりにしていることがらを、もう少し分割してみましょう。

データベースのパフォーマンス問題は、主にデータベースそのものにかかわる部分と、その上で実行されるSQLにかかわる部分があります。両者は最終的に不可分ですが、前者がインフラを最適な状態に保つという運用管理に近い内容であるのに対し、後者は、どのようなSQLを発行するのかというプログラミングに近い領域になります。

そのため、データベースのパフォーマンス問題は、運用時の問題だけでなく、開発時、時には設計時の問題として考えなければなりません。本稿では、主にSQLの問題からデータベースパフォーマンスの問題をとらえ、開発段階を含めて、どのようにSQLのパフォーマンス問題に対処すべきかを考えていきます。

SQLのパフォーマンス問題をとらえるにはどうすればよいか？

さて、ではSQLのパフォーマンス問題に、多くの技術者はどうやって対処しているのでしょうか。一般的な方法は、統合テスト段階での負荷テストです。過負荷な状態でパフォーマンスのボトルネックを洗い出し、その箇所を修正するのです。

この方法では、システムに大きな負荷がかかったときに起こりうるSQLパフォーマンス問題を未然につぶしていくことができます。しかし、SQL単独で見た場合に、本当にそれが効率的なSQLなのかどうかといった網羅性は検証できません。また、問題箇所を特定したとしても、多くの場合、経験に基づいた試行錯誤によるチューニングを行っています。

先にも述べたように、パフォーマンス問題にはさまざまな複合要因がからんでいます。状況に応じて異なるこれらの要因から、経験やカンを頼りにして、的確にその原因を突き止めるのは容易ではありません。

そこで、新しく採用する方法が、SQLパフォーマンス問題の「見える化」です。ツールの力を借りて、SQLの実行状況の詳細を見ることによって、問題となっているSQLがどのように実行されているのか、また、その中で、どこに問題があるのかを理解できるのです。