Oracle Databaseのスマートな開発／運用の鉄則
第2回 「"プロアクティブ"なパフォーマンス・チューニングの心得」
ITエンジニアにとって、データベースのパフォーマンス・チューニングは日常的な作業の1つだろう。だが、実際の現場を見てみると、チューニングへの取り組み方に問題のあるケースが少なくない。今回は、日本オラクルのデータベース・コンサルタントらの視点から、ユーザー企業の現場に見られる問題点や、今日データベース・チューニングに臨むうえでの留意点などを紹介する（編集部）。
日本オラクル
コンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
データベースソリューション第1部
マネージングプリンシパルコンサルタント
中島益次郎
日本オラクル
コンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
データベースソリューション第1部
シニアコンサルタント
開發健太郎
「我々が日ごろお客様と接していて感じるのは、SQLレベルでのチューニングにはいろいろと気を配っているものの、システム全体や業務要件とのバランスへの配慮が欠けていたり、チューニングを組織的に行っていくための体制が作られていなかったりするケースが多いことだ。データベースの性能問題が生じる背後には、これらの取り組みが十分に行われていないことがあると見ている」――日ごろOracle Databaseのコンサルタントとして企業の支援にあたっている中島氏と開發氏はこう語る。では具体的に、どのような性能問題が生じているのだろうか。
■まずはシステムの性能目標値や制約条件を明確にせよ
中島氏らが「一番困る」と声をそろえるのは、システムの性能目標値や、チューニングにかけられる期間／コストなどの制約条件が明確になっていないケースだ。
「我々コンサルタントには、期間とコストを無尽蔵にかけられるのなら、どんな性能問題でも解決できるという自負がある。だが実際には、それが許されるプロジェクトなどありはしない。そこで、具体的な性能目標値と期間／コストの制約条件を踏まえて対応策を考えるのだが、これらが明確になっていないことが意外と多い」（中島氏）。
チューニングのアプローチは1つとは限らない。選択肢は常に複数あり、その中のどれを使うかによって時間とコスト、性能が変わる。目標とする性能を、どの手段を使ってどれだけ安く／早く満たすかがチューニングの腕の見せ所なわけだが、目標値や制約条件が不明瞭だと、その選択肢を判断する材料を奪われてしまうことになる。「これだ！」と思った手段で最適化を進めたところ、あとから性能目標が明らかになり、その手段では目標を満たせないとなったら、それまでの作業は水泡に帰す。逆に、性能目標を大幅に超えるようなチューニングを行った場合も、過剰な期間／コストは無駄となる。
なぜ、こうした問題が起きるのか？ 本来、性能要件はプロジェクト初期の要件定義フェーズで決めるものだが、「要件定義のフェーズに、データベース・アーキテクトなどのITスペシャリストが介在していないプロジェクトが意外と多い。そうしたプロジェクトでは、性能目標値が曖昧になりやすい」（中島氏）という。
また、プロジェクト初期フェーズでのITスペシャリストの介在不足は、パフォーマンス問題の要因にもなる。アーキテクチャ設計の段階での検討が不十分となり、カットオーバー直前になって性能要件を満たせないことが判明するのだ。
中島氏は、今日こうした問題が生じている原因は、「必要なスキル・セットと幅広い視野を持ったエンジニアが不足しているためだ」と見ている。業務に最適なデータベースを設計し、さらにそれをシステム上、望ましい設計に落とし込めるスペシャリストが不足しているのだ。その背景には、ITと、それを使う業務の双方が複雑化していることがある。従来は、ITも、ITを使う業務もさほど複雑ではなく、標準的な技術を学べば大方の問題に対処できた。しかし、現在はITと業務の双方が複雑化し、それぞれのスキルの幅を広げなければ十分に対応できなくなっている。
このことを踏まえ、中島氏は、「今、求められているのは、ITと業務に"ある程度まで"通じたスペシャリストだ」と説明する。そうしたスペシャリストが中心となり、業務に精通した業務設計チームと、データベースなどのインフラに通じたインフラ設計チームのスペシャリストらをうまく協調作業させることで、最適な設計を行うのである。
■近視眼的なSQLチューニングやハードウェア頼みの設計は禁物
開發氏は、中島氏が指摘する「幅広い視野を持った人材の不足」の影響を、SQLレベルのチューニングでも感じている。
「単一のSQL文レベルのチューニングばかりに気を取られ、そのチューニングがシステム全体にどう影響するのかを考慮できていないケースが見られる」（開發氏）。
例えば、あるテーブルにインデックスを張ったとしよう。このとき、そのテーブルにアクセスしているのが、1つのSQL文だけであれば問題はないが、実際には他のさまざまなSQL文からアクセスされているものだ。よって、それらの個所にどういった影響が及ぶのかを考えなければならないのである。
なお、以前なら、そうした調査には多くの時間を要したが、現在ではOracle Databaseに備わる各種の機能を使うことで効率的に作業が行える。例えば、Oracle Database 11gで追加された「SQL Plan Management（SPM）」を使うと、SQL文の実行計画を記録し、それを評価したうえで本番環境に適用することができる。実行計画の変更による影響を事前に把握し、効果のある変更だけを適用することが可能なのだ。
オラクルエンジニア通信：「【技術資料】SQL Plan Management 機能解説：Oracle Database 11g」
また、Oracle Database 11gで追加された「インビジブル・インデックス」も、SQL文の変更に伴う影響範囲を限定し、チューニング効率を高めてくれる便利な機能だ。これを使うと、指定したインデックスを特定のセッションでしか見えないようにできるので、それによってインデックス追加の影響範囲をコントロールできるのである。
オラクルエンジニア通信：「不可視索引（インビジブル・インデックス）」
また、近年は業務設計担当者でも、自分が書くSQL文の性能に注意を払うようになってきているが、「その反面、SQL以外の部分の設計が雑になってきた」と開發氏は嘆く。ハードウェアの性能が向上してリソースが潤沢になったためか、インフラまで十分に意識した設計が行われていないのだ。その結果、設計のバランスが悪くなるケースが散見される。
当然のことながら、システム全体の性能はハードウェアとソフトウェアの性能のバランスをとって調整しなければならない。例えば、現在はメモリが安価なので大量のメモリを搭載し、その上にデータを展開して処理を行うケースが多いが、本番環境で膨大なデータが発生してメモリからデータがあふれてしまうと、そこで大量のI/Oが発生する。このI/O処理には、メモリ上での処理と比べて数十倍の時間がかかるため、パフォーマンスは大幅に劣化する。「大量のメモリを搭載しているから」とデータベース・パーティショニングなどへの配慮を怠ると、途端にこのようなトラブルに見舞われるのだ。こうした問題の背景にあることは何か？
「先のSQLチューニングの問題にしても、ハードウェア性能に依存した設計にしても、その根本には業務／アーキテクチャに応じたチューニングを継続的かつ効果的に行っていくための体制を作るという意識が欠如していることがある。そのため、場当たり的にSQL文を修正したり、無闇にハードウェアに頼ったりといったことが起きるのだろう」（開發氏）。
■最新の手法／機能を取り込んで運用プロセスを改善すべし
従来からの慣習にこだわった運用の仕方が、パフォーマンス・チューニングの妨げとなることもある。
「最近は減ったが、以前はシステムにかかる負荷を気にして、データベースの稼働情報を取らないお客様が多かった。稼働情報が何も残っていないと、何が原因で遅くなったのかがわからず、"打つ手なし"となってしまう」（開發氏）。
稼働情報の記録は、データベース・チューニングの大前提だ。もちろん、やみくもに情報を取得すると、そのことが性能に悪影響を与えるので、どういった情報をどのタイミングで取るのかを事前に精査しておかなければならない。そして、取得する情報を決めたら、Oracle Database 10gで追加された「Automatic Workload Repository」などの機能を使って情報を収集し、それを「Oracle Enterprise Manager」で確認／分析すればよい。
オラクルエンジニア通信：「Oracle Enterprise Manager for Database 技術資料」
オラクルエンジニア通信：「オラクルコンサルタントが語る 統計情報管理の真髄 Part1」｜「Part2」｜「Part3」｜「Part4」
またもう1つ、中島氏と開發氏が強調するのが、多くのユーザーがOracle Databaseの新機能を十分に使いこなしていないということだ。特にOracle Database 11gでは多くの新機能が追加され、パフォーマンス・チューニングが効率的かつ容易に行えるようになっている。それらの新機能を自社の運用プロセスに組み込むことで、これまでよりも効率的な運用を行い、パフォーマンス・チューニングの作業を円滑にし、ひいてはITの投資対効果を高められるのである。今後データベースのバージョンアップを行う際には、ぜひ新機能の活用を前提にした運用プロセスの見直しを検討してみていただきたい。
「「他社のシステムではどの新機能が使われている？」～Oracle Database 11g Release2 人気のお勧め新機能」
■データベース・チューニングはリアクティブから"プロアクティブ"へ
今回は、パフォーマンス・チューニングへの取り組みに関して、多くの企業に見られる問題点を指摘してきたが、そもそも中島氏は、この「チューニング」という言葉の使われ方自体に違和感を持っている。
「IT業界では、チューニングという言葉がリアクティブ（受動的）な意味で使われることが多い。つまり、何か問題が起き、それに対処することをチューニングと呼んでいるのだ。しかし一般に、チューニングという言葉は、例えばミュージシャンが本番演奏の前に行う調律のように、音のズレなどの問題を未然に防ぐ準備、すなわち「プロアクティブ（予見的）」な行為に対して使われる。オラクルでは今後、データベースの世界におけるチューニングを、そうしたプロアクティブな行為として提唱していく構えだ。
ちなみに、中島氏によれば、Oracle Database 11gの新機能の多くも、プロアクティブなチューニングの支援に重きが置かれているという。
■"プロアクティブなチューニング"に向けた3つのポイント
では、今後プロアクティブなチューニングを実践していくうえで、どのような点に留意すればよいのか。ここまでに説明した事柄も踏まえ、中島氏と開發氏が強調するのが、次の3つのポイントだ。
●目標値を明確にする：チューニングの最終ゴールを性能目標値として、期間／コストの制約条件とともに明確化する。それにより、何をどこまでやるのかが明らかになる
●業務とシステム・アーキテクチャの双方を十分に把握する：業務要件と、それを踏まえたシステム・アーキテクチャの双方を十分に把握し、それらに応じたチューニング・ポイントやチューニング手法の洗い出しを行う
●チューニングのプロセスを確立する：チューニングを効率的に行うためのプロセスや体制、実施可能なチューニング手法などをあらかじめ決めておく
これらに関して適切な手を打つことで、今回紹介したようなトラブルを未然に防ぐ"プロアクティブなデータベース・チューニング"を実践できるのだ。
なお、今回はデータベース・チューニングの基本的な心得とも言える事柄を紹介したが、SQLに関する具体的なチューニングの手法については、中島氏が執筆した下記の書籍を参考にしていただきたい。
■ 基礎から学ぶOracle SQLチューニング
■ 加藤 祥平、中島 益次郎
■ ISBN978-4-7981-2066-9
■ 定価 2,520円（税込）
■ 株式会社翔泳社 発行
オラクルエンジニア通信：「データベースの監視およびパフォーマンス・チューニング 技術資料」
（第3回に続く）
Printer View