DB をボトルネックにしないアプリケーション開発
|
業務システムにおいて、DB がパフォーマンス低下の原因となるケースは少なくないようです。今回は、DB をシステムのボトルネックにしないためにはどうすれば良いのか、その着眼点と具体的な対策を説明します。特に、アプリケーション開発者が突然やってきて、「DB が遅いからチューニングしてほしい」と頼まれて困っているというDB エンジニアは必読です。ポイントは、今後を見据えたデータ量の見積もりと、早めのSQL 文レビューです。
基礎力を伸ばす絶好の機会
年が明けて早2ヶ月が過ぎようとしていますが、2005年という1年間を振り返ってみると、技術的には大きなパラダイムシフトがない、言ってみれば「凪（なぎ）の一年」だったように感じます(注1)。今年も、今のところ目立ったパラダイムシフトの兆しは感じられませんので、凪はもうしばらく続くのではないでしょうか。
2005年が凪の1年だったことに起因するかどうかは計りかねますが、この1年で雑誌／書籍やWebサイトなどの各種メディアでは、上流工程や開発方法論、プロジェクトマネジメントといった要素技術ではない「広い視点」からのテーマや、非常にベーシックな技術テーマを取り上げることが多かったようです。凪の時期は新技術を学ぶことに追い立てられずに済みますし、何よりメディアにはベーシックな学習題材があふれています。この時期に基本スキルに磨きをかけない手はありません。
さて、今回解説する「DBをボトルネックにしないアプリケーション開発」というテーマも、この凪の1 年にならった非常にベーシックなテーマと言えます。とはいえ、世にリリースされる多くのシステムでは、DBがパフォーマンス上のボトルネックになるケースが少なくないようです。つまり、DBのパフォーマンスとは、技術論的には非常にベーシックであるにもかかわらず、多くの場合において「うまくやれていない」のです。
DBはなぜ重要なのか
DBは、業務システムの中核を担う存在です。DB マガジンにしても、DB 専門誌としてすでに6年以上も刊行を続けているそうですから、DBに関しては語るべき話題が豊富にあり、その需要もあるわけです。DBが「ずっと重要であり続けている」のは間違いありません。ドッグイヤー（はたまたラットイヤー）などと称されるこの業界では、これはすごいことです。RDBMSというものが（今のところは） この業界におけるワンアンドオンリーな存在だということがよく分かります。
しかし、DBがシステムのボトルネックになるケースが多いのも事実です。今回はその原因と対策を解説していきますが、まずはDBがなぜ重要なのか、また、DBはどのような特性を持っているのかをここで確認しておきましょう。
DBは業務システムの中核
そもそも業務システムでは、業務に必要な情報（データ）を抽出したり、業務の記録を記録したりすることが要件の大部分を占めています。つまり、DBのI/O処理が業務システムのほとんどを担っているといっても過言ではないのです（図1）。皆さんが現在携わっている、あるいは過去に携わった開発プロジェクトを思い返してみてください。データの参照および記録にまったく関係のない処理はおそらくほとんどないと思います。
図1 DBは業務システムの中核
DBは情報を集約している
また、DBは業務に必要な情報を集約的に保持していることに価値があります。逆に、DBにデータを分散して保持させることは困難だとも言えます。
もちろん、現在リリースされているRDBMS製品は、パーティションやレプリケーションといったデータを物理的に分散させる機能を提供しています。しかし、DBの利用者から見ると、論理的には一元管理されているものとしてデータにアクセスしたいものです。例えば、「顧客マスタ」データが物理的にはマシンAとマシンBに分散配置されているとしても、「顧客マスタ」を扱うプログラムはマシンAとマシンB両方のデータを透過的に扱いたいはずです（図2）。
一方、処理プロセスは比較的分散が容易なものです(注2)。つまり、ある処理プロセスがマシン Aで動いてもマシンBで動いても、利用者にとっては別段問題ないわけです（図3）。
図2 DBは分散させるのが困難
図3 処理プロセスは分散が容易
DBがボトルネックになるケース
いかがでしょうか。DBは理論的に分散できない存在であるにもかかわらず、業務システムの中核を担わなければならない、という二重の両立困難な要件を課せられた存在であることがお分かりいただけたと思います。そりゃあ、ボトルネックにもなりやすいというものです。
では、具体的にどのようなケースにおいて、DBがボトルネックになってしまうのでしょうか。以降では、DBがボトルネックになるケースを大きく3つに分類し、それぞれについて、その発生原因や背景について解説していきます。
なお、それぞれのケースに対する対策および解決の方法は、さらにその次の節にて解説します。
次節を読むと不安な気持ちだけが煽られてしまうかもしれませんが、どうぞ我慢して先へ読み進めてください。ちゃんと解決方法が記されていますので……。
（注1）インパクトの大きい新技術が登場しないという意味では凪だったかもしれませんが、筆者は大時化プロジェクトにハマってしまいましたので、決して穏やかな1 年ではありませんでした……。
（注2）もちろんプロセスの分散においても、「セッションの管理」などの問題を解決しなけ「フェイルオーバー」ればなりませんが、今回のテーマから外れた議論になりますので、ここでは割愛します。