第2回はパフォーマンスチューニングの基本についてMySQLをベースに解説します。

データベースのパフォーマンスとは？

データベースの処理性能の善し悪しとしてパフォーマンスという言葉でまとめて語られることもありますが、いくつかの指標が期待された値となっているかの確認が必要となります。1つ目の要素は単位時間あたりの処理量であるスループット、もう1つの要素は処理の投入から応答までのレスポンスタイムです。スループットは秒間のSQL処理件数（クエリ／秒、QPS）やトランザクション数（トランザクション／秒、TPS）などが指標とされます。

処理の多重度の変化によってこれらの要素の値が変化していきます。スループットとレスポンスタイムはいずれも多重度の変化に対して単純に線形に変化するものではないので、特にユーザやデータベースのアクセスの増加が見込まれるシステムでは、テストを通じて多重度別の数値の推移を測定し、システムの要件に見合った状況になっているかを見極める必要性が出てきます。

パフォーマンス測定のポイント

パフォーマンスチューニングにあたって、最も重要なことはボトルネックを発見し改善していくことにあります。主にレスポンスタイムの観点からどのトランザクション、また複数のSQL文で構成されるトランザクションであればどのSQLが最も時間がかかっているのかを探し出していきます。また、その処理がシステムのどこで時間がかかっているのかを探す必要があります。処理にかかる時間の中には、実行待ちのキューに入っていていずれのリソースも使用していない時間も含まれます。処理の実行時間を直接的に計測することの他に、ハードウェアやOSのリソース利用状況、およびデータベース内部での処理を計測しておくことで、処理のボトルネックを見つける手がかりを得ます。

ハードウェアリソースについては、OS付属のツールや各種の監視ツールを活用して主に以下の点を計測します。

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. 基礎性能

1. 見積もり

まず、システムの運用後にどの程度のアクセスがあるかや、データサイズの推移などの見積もりを行います。既存システムを置き換えた場合には、それまでの状況を元に推測することもできます。業務システムなどの場合は従業員数の変化や特定の業務が発生する時期や頻度、生成されるデータ量などをおおむね見積もることができます。ただ新規に開発し、かつ広く公開して利用されるようなサービスの場合などは、利用者がどのように増加するかが想定しにくいシステムもあります。見積もりが難しい場合でも、類似の他のサービスを参考とするかビジネスの成長計画などから逆算していくこことなります。

業務システムの場合には利用者数の変動も企業の成長計画に照らし合わせることで見積もることがそこまで難しくはなく、公開型のサービスに比べて変動も小さいことが想定されます。想定される処理のパターンやフローも限られてきます。一方で公開型のサービスでは開始当初の予測だけではなく、将来的な成長を見積もるとともに、ベンチマークテストを通じてどのタイミングでシステムをどのように増強すべきか確認しておくができれば良いでしょう。

2. シナリオ

ベンチマークテストの中で実行する処理は、可能な限り実際の運用環境の状況に似せることが理想です。想定される処理パターンやフローの全てが再現できれば良いのですが、実際には処理の頻度が高い代表的な処理を選択してベンチマークテストに含めるパターンが多くなります。ただし、オンライン処理とデータの一括登録や洗い替え、集計など処理負荷の高いバッチ処理と同時に実行されるケースなどは、発生頻度は低いものの平常時の挙動や処理性能とは異なってくるため、注意すべき処理パターンとして個別に抽出してベンチマークテストを行うことが必要です。

3. 基礎性能

データベースを使ったベンチマークテストの前に、利用している環境の各リソースの基礎性能を把握しておかないと、そもそも見積もりに無理があったり、データベースソフトウェアの処理性能以前の問題でボトルネックとなってしまう可能性もあります。カタログスペックでおおよその性能は把握できますが、場合によっては「桁が合っている」程度のこともあり得るので、ツールを使用して測定するほうが良さそうです。ハードディスクの場合にはディスクの外周側と内周側で性能に差がある点も考慮したテストの実施も検討します。

MySQL関連のベンチマークツール

MySQLのベンチマークテストに利用できる代表的なツールは以下の通りです。

ベンチマークテストの失敗例

経験を積んだ方にとってはあり得ないことかもしれませんが、誤った方法でベンチマークテストを行うと誤ったチューニングにつながりかねません。

たとえば、実際には同時に100接続あるシステムなのに、1接続だけでテストをしてしまうと処理の競合による遅延が確認できません。データサイズが小さすぎると全てキャッシュに乗ってしまうことがありますが、本番のデータがキャッシュに載りきらない大きさの場合には応答性能が大幅に異なります。

少し考慮したようなケースでも誤った例になるのは、同じデータに繰り返しアクセスしないようにランダムにアクセスするテストを実施していても、実際にはごく一部のデータにアクセスが集中するシステムだと処理やロックの競合の状況が大きく異なってきます。

ベンチマークテストの目的を見失っているようなケースもあります。限界性能を見極めるなどの目的無しに実際にはあり得ないような高い負荷を掛けているケースや、本番のアクセスパターンとは全く関係なく手当たり次第様々なSQLのパターンを実行しているケースなどです。

最も避けるべきなのは、リソースの利用状況やデータベースの稼働状況を一切取得しないベンチマークテストで、仮に課題となりえる処理は見つけられてもボトルネックへの糸口は見つけられないので時間の無駄です。

チューニングの範囲

どのようなパフォーマンスチューニングでも、時間とコストがかかります。そのため必ず要件を確認しながら作業を進めていき、どの程度のコストを掛けることが許容され、次善策を取った場合のビジネス上のインパクトがどの程度なのか、チューニングの目標値のベースとなる見積もりが正しいのか、どこまで達成することが必須なのかなどを含めて検討していきます。

SQL文のチューニングに時間をかけるよりも、ハードウェアを置き換えることでトータルのコストを抑えられることが充分にあり得ます。チューニングの作業時に最も大事なことは、常に全体像を把握して「これが最大のリスク／ボトルネックなのか？」を問うことでしょう。

次回は

次回はMySQLサーバのチューニングの基本をご紹介いたします。