「"プロアクティブ"なパフォーマンス・チューニングの心得」

日本オラクル
コンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
データベースソリューション第1部
マネージングプリンシパルコンサルタント
中島益次郎氏

　「我々が日ごろお客様と接していて感じるのは、SQLレベルでのチューニングにはいろいろと気を配っているものの、システム全体や業務要件とのバランスへの配慮が欠けていたり、チューニングを組織的に行っていくための体制が作られていなかったりするケースが多いことだ。データベースの性能問題が生じる背後には、これらの取り組みが十分に行われていないことがあると見ている」――日ごろOracle Databaseのコンサルタントとして企業の支援にあたっている中島氏と開發氏はこう語る。では具体的に、どのような性能問題が生じているのだろうか。

まずはシステムの性能目標値や制約条件を明確にせよ

　中島氏らが「一番困る」と声をそろえるのは、システムの性能目標値や、チューニングにかけられる期間／コストなどの制約条件が明確になっていないケースだ。

　「我々コンサルタントには、期間とコストを無尽蔵にかけられるのなら、どんな性能問題でも解決できるという自負がある。だが実際には、それが許されるプロジェクトなどありはしない。そこで、具体的な性能目標値と期間／コストの制約条件を踏まえて対応策を考えるのだが、これらが明確になっていないことが意外と多い」（中島氏）。

　チューニングのアプローチは1つとは限らない。選択肢は常に複数あり、その中のどれを使うかによって時間とコスト、性能が変わる。目標とする性能を、どの手段を使ってどれだけ安く／早く満たすかがチューニングの腕の見せ所なわけだが、目標値や制約条件が不明瞭だと、その選択肢を判断する材料を奪われてしまうことになる。「これだ！」と思った手段で最適化を進めたところ、あとから性能目標が明らかになり、その手段では目標を満たせないとなったら、それまでの作業は水泡に帰す。逆に、性能目標を大幅に超えるようなチューニングを行った場合も、過剰な期間／コストは無駄となる。

　なぜ、こうした問題が起きるのか？ 本来、性能要件はプロジェクト初期の要件定義フェーズで決めるものだが、「要件定義のフェーズに、データベース・アーキテクトなどのITスペシャリストが介在していないプロジェクトが意外と多い。そうしたプロジェクトでは、性能目標値が曖昧になりやすい」（中島氏）という。

　また、プロジェクト初期フェーズでのITスペシャリストの介在不足は、パフォーマンス問題の要因にもなる。アーキテクチャ設計の段階での検討が不十分となり、カットオーバー直前になって性能要件を満たせないことが判明するのだ。

　中島氏は、今日こうした問題が生じている原因は、「必要なスキル・セットと幅広い視野を持ったエンジニアが不足しているためだ」と見ている。業務に最適なデータベースを設計し、さらにそれをシステム上、望ましい設計に落とし込めるスペシャリストが不足しているのだ。その背景には、ITと、それを使う業務の双方が複雑化していることがある。従来は、ITも、ITを使う業務もさほど複雑ではなく、標準的な技術を学べば大方の問題に対処できた。しかし、現在はITと業務の双方が複雑化し、それぞれのスキルの幅を広げなければ十分に対応できなくなっている。

　このことを踏まえ、中島氏は、「今、求められているのは、ITと業務に"ある程度まで"通じたスペシャリストだ」と説明する。そうしたスペシャリストが中心となり、業務に精通した業務設計チームと、データベースなどのインフラに通じたインフラ設計チームのスペシャリストらをうまく協調作業させることで、最適な設計を行うのである。