データベースに無償で利用可能なMySQLやPostgreSQLを利用しているシステムは多い印象があります。なぜならフリーのRDBMSの中では信頼性の高い分類に入るからでしょう。しかしアクセスが増えてきたときの処理能力としては有償のOracleやSQL Serverと比較すると劣ってしまいます。しかし有償のデータベースは高価ですので、スタートアップ企業のシステムには適していない場合が多いです。そのため無償のデータベースで何とかやりくりがしなければいけません。そこで、今回はAWS RDS上のMySQLを用いたパフォーマンスチューニングの事例を紹介しましょう。

キュー制御システム

今回紹介するシステムは、キュー制御システムです。あるシステムで取得したデータを、別のシステムに配信するため、データの出し入れを制御するためのものでした。

• システムA … キュー制御システムにデータを投入
• システムB … キュー制御システムよりデータを配信

システムAは通常5台のサーバでデータを生成しており、キュー制御システムにデータを投入します。一方、システムBは通常15台のサーバが稼働しており、キュー制御システムにデータを問い合わせます。そのためキュー制御システムでは合計20台のサーバからアクセスがあり、キュー制御システムの処理速度が全体のシステムのボトルネックとなっていました。特にキュー制御システムで利用しているMySQLが遅い状態でした。そこでパフォーマンスチューニングは次の手順で行いました。

1. キュー制御システムで利用しているクエリ文の整理

システムで利用しているクエリ文は全部で15個ありました。それぞれに対して最適なインデックスを貼ってもいいのですが、インデックスが多いとデータの追加・変更が遅くなるため、似ているクエリ文をシステムに影響が無いように変更したり、インデックスを共通化したりなど行いました。 またデータは複数件同時に追加したり、更新時も INSERT … ON DUPLICATE KEY UPDATE を利用し、複数件同時に更新するような工夫を行いました。 テスト時はインデックスが正常に利用されていたが、データが大量に挿入されることによりインデックスが効かなくなったり、全件検索になってしまうこともあったため、適した検索条件への変更も行いました。

2. リードレプリカの利用

このシステムでは、データの検索が頻繁に行われていましたが、データの追加が行われているときテーブルロックが掛かり、データの検索が待ち状態になることがありました。そのためリードレプリカを立ち上げ、データの検索時はそのリードレプリカから検索することで待ち状態がないようにしました（システム上問題ないことを確認済み）。

3. バッファの調整

本来であれば、MySQLのバッファの調整をするべきかと思いますが、次の理由によりバッファの調整は行いませんでした。

• No. 1, 2の対策で処理速度が早くなった
• AWS RDS標準でも問題ないレベルであった

結果

最終的にNo. 1, 2の対応によりシステム全体の処理時間が1/10になりました。AWS RDSのリードレプリカを追加しましたが、RDSのサーバスペックを落とすことができたため、金額的には同じです。

まとめ

パフォーマンスチューニングというと、No. 3をイメージするエンジニアが多いですが、No. 1, 2の対策を行ってからでないとNo. 3が効いてきません。まずはシステム全体を理解することから初めるましょう。