第2回はパフォーマンスチューニングの基本についてMySQLをベースに解説します。
データベースのパフォーマンスとは？
データベースの処理性能の善し悪しとしてパフォーマンスという言葉でまとめて語られることもありますが，いくつかの指標が期待された値となっているかの確認が必要となります。1つ目の要素は単位時間あたりの処理量であるスループット，もう1つの要素は処理の投入から応答までのレスポンスタイムです。スループットは秒間のSQL処理件数（クエリ／秒，QPS）やトランザクション数（トランザクション／秒，TPS）などが指標とされます。
処理の多重度の変化によってこれらの要素の値が変化していきます。スループットとレスポンスタイムはいずれも多重度の変化に対して単純に線形に変化するものではないので，特にユーザやデータベースのアクセスの増加が見込まれるシステムでは，テストを通じて多重度別の数値の推移を測定し，システムの要件に見合った状況になっているかを見極める必要性が出てきます。
図1 多重度を変化させた場合のスループットとレスポンスタイムの変化の例
パフォーマンス測定のポイント
パフォーマンスチューニングにあたって，最も重要なことはボトルネックを発見し改善していくことにあります。主にレスポンスタイムの観点からどのトランザクション，また複数のSQL文で構成されるトランザクションであればどのSQLが最も時間がかかっているのかを探し出していきます。また，その処理がシステムのどこで時間がかかっているのかを探す必要があります。処理にかかる時間の中には，実行待ちのキューに入っていていずれのリソースも使用していない時間も含まれます。処理の実行時間を直接的に計測することの他に，ハードウェアやOSのリソース利用状況，およびデータベース内部での処理を計測しておくことで，処理のボトルネックを見つける手がかりを得ます。
ハードウェアリソースについては，OS付属のツールや各種の監視ツールを活用して主に以下の点を計測します。
表1 主に計測する点
| リソース | 計測する項目 |
|---|---|
| CPU | CPU利用率（ユーザ，システム，IO待ちなど），処理待ちプロセス数 |
| メモリ | メモリ利用率，スワップの利用状況 |
| ストレージ | 帯域利用率，スループット，実行待ちキューサイズ |
| ネットワーク | 帯域利用率，スループット，送受信待ちキューサイズ |
UNIX系OSではvmstatやiostat，sar，top，mpstatなどのコマンドラインツール，WindowsではリソースモニタがOSに付属しているほか，オープンソースのGUIツールとしてはNagiosやCacti, Hinemosなどが利用できます。
MySQLサーバ内部での処理状況の確認は，SHOW STATUSコマンドを基本として，MySQL WorkbenchのパフォーマンスレポートやMySQL Enterprise Monitorなどが利用できます。これらのコマンドやツールの詳細は別途解説いたします。
ベンチマークテスト
構築したシステムが要件を満たしていることを検証するためにベンチマークテストを行います。MySQLのサポートエンジニアで“漢（オトコ）のコンピュータ道”で知られる奥野氏は「テストをしないことはリスクがあるということです。つまり，ベンチマークテストをしないということは，性能関係の問題が起きるリスクがあるということに他なりません。」と語っています。
このベンチマークテストの前に確認しておくべき点が3点あります。
- 見積もり
- シナリオ
- 基礎性能
1. 見積もり
まず，システムの運用後にどの程度のアクセスがあるかや，データサイズの推移などの見積もりを行います。既存システムを置き換えた場合には，それまでの状況を元に推測することもできます。業務システムなどの場合は従業員数の変化や特定の業務が発生する時期や頻度，生成されるデータ量などをおおむね見積もることができます。ただ新規に開発し，かつ広く公開して利用されるようなサービスの場合などは，利用者がどのように増加するかが想定しにくいシステムもあります。見積もりが難しい場合でも，類似の他のサービスを参考とするかビジネスの成長計画などから逆算していくこことなります。
業務システムの場合には利用者数の変動も企業の成長計画に照らし合わせることで見積もることがそこまで難しくはなく，公開型のサービスに比べて変動も小さいことが想定されます。想定される処理のパターンやフローも限られてきます。一方で公開型のサービスでは開始当初の予測だけではなく，将来的な成長を見積もるとともに，ベンチマークテストを通じてどのタイミングでシステムをどのように増強すべきか確認しておくができれば良いでしょう。
2. シナリオ
ベンチマークテストの中で実行する処理は，可能な限り実際の運用環境の状況に似せることが理想です。想定される処理パターンやフローの全てが再現できれば良いのですが，実際には処理の頻度が高い代表的な処理を選択してベンチマークテストに含めるパターンが多くなります。ただし，オンライン処理とデータの一括登録や洗い替え，集計など処理負荷の高いバッチ処理と同時に実行されるケースなどは，発生頻度は低いものの平常時の挙動や処理性能とは異なってくるため，注意すべき処理パターンとして個別に抽出してベンチマークテストを行うことが必要です。
3. 基礎性能
データベースを使ったベンチマークテストの前に，利用している環境の各リソースの基礎性能を把握しておかないと，そもそも見積もりに無理があったり，データベースソフトウェアの処理性能以前の問題でボトルネックとなってしまう可能性もあります。カタログスペックでおおよその性能は把握できますが，場合によっては「桁が合っている」程度のこともあり得るので，ツールを使用して測定するほうが良さそうです。ハードディスクの場合にはディスクの外周側と内周側で性能に差がある点も考慮したテストの実施も検討します。