SQL Server特A級エンジニアの集まり、CAT(Customer Advisory Team)。パフォーマンスを最大限に引き出すハードウェアの組み方を、Dr.Kが伝授します(編集部)
データベースの「チューニング」は、なぜ難しいのでしょうか?
チューニングには2つのフェイズがあります。それは「クエリーチューニング」と「プラットフォームチューニング」。第1フェイズのクエリーチューニングは、テーブル構造やインデックスの選択、結合処理の最適化など、皆さんが最初に思い浮かぶチューニングです。このフェイズでは、トランザクションミックスでのパフォーマンスを予測しにくいなど、不確定要素が多いことが本稼働後のチューニングを難しくする原因の1つです。
例えば、SQL Serverを全面的に導入し、私もシステム構築に携わった大手のBtoC情報提供Webサイト企業も、サービス開始時点ではここまでページビューがあがるとは想定していませんでした。当初は性能要件をクリアしていたとしても、ページビューの爆発的な増加や新サービスの追加などの不確定要素が多くなると、性能面ではお手上げです。
そんなときに、第1回でもお伝えしたマイクロソフトのCAT(Customer Advisory Team)がやってきました。彼らはハードウェアの内部の情報を基に行う、第2フェイズ「プラットフォームチューニング」のスキルを提供してくれました。これにより、OS、DBエンジンの内部から、システムが持つ潜在的な問題を把握できました。大手のB2C情報提供Webサイト企業の事例ではこれが大変効きました。このとき彼らが作った「火消しのための」ツールは、その後SQL Server 2005 から提供された動的管理ビュー(DMVとDMF)として提供されました。
チューニングの作業は、基本的に試行錯誤、経験則に頼らざるを得ません。今回はCATから受けたスキルを基に、皆さまにその経験を伝えていきたいと思います。
SQL Serverの進化は第1回でお伝えしましたが、ハードウェアの進化もすさまじいものがあります。
従来のSQL Server 2000の32ビットアドレス方式のシステムでは、メモリは高価で貴重なリソースであり、ほとんどの場合がメモリによるボトルネックでした。2000年当時は4ソケットのCPU構成も大変高価でした。しかしいまや、メモリも大量に搭載でき、CPUもマルチコアが当たり前です。ストレージもネットワークも安価で利用できます。これらは「共有リソース」であり、メモリが足りないと、その負荷はストレージや、CPU負荷という形で表面化します。システム全体で見たとき、構成するこれらのリソースをまんべんなく利用されるべきです。
そしてこれらのリソースは、簡単に構成を変更することは困難です。つまり、ハードウェアに手を入れるチューニングは最初の段階、もしくはマシンのリース切れのタイミングで行うべきです。ここでシステムが持つ「潜在的な問題」を解決できます。
SQL Serverのエンジンに最適化したハードウェア構成、これをCATでは「バランスド・システム」と呼んでいます。OSまで含め、マイクロソフトが手がけている利点はここに出てきていますね。バランスの取れた状態を手に入れるには、SQL Server(特に、SQL OS)の内部動作を知り、ハードウェアとOSの知識が必須になります。では、プロセッサ、メモリ、ストレージごとに何をポイントに考えるべきかを解説しましょう。
Copyright © ITmedia, Inc. All Rights Reserved.