Amazon Aurora MySQL をバージョンアップして性能が劣化した話
こんにちは。ビズパのプロダクト開発チームの吉留です。
今回の記事では先日行ったデータベースのバージョンアップについて触れたいと思います。
ビズパのデータベース
ビズパではインフラに主にAWSを利用しています。
データベースもAWSのサービスである Amazon Aurora を利用しております。
Aurora といえば昨年の11月にMySQL8.0をサポートしたことで少し話題になっておりましたね。
ビズパでもリリース当初から Aurora (MySQL5.7互換) を利用しており、今回のバージョンアップでAurora (MySQL8.0) 互換に対応しました。
今回の記事ではMySQL8.0互換にバージョンアップした時の様子を書きたいと思います。
バージョンアップするに際して気をつけたこと
バージョンアップを行う際はデータベースであれ、プログラムのライブラリであれ検証は必要不可欠だと思います。
ビズパでは開発環境にDockerを利用しており、Dockerで利用するイメージを変更するだけでMySQLのバージョンを変更させることが可能になっています。
まずローカル環境でバージョンアップを行い、検証を行いました。
その後、AWS上での検証環境でテストを行うというステップを踏みました。
バージョンアップで起こった問題
ビズパではMySQLの関数を使って緯度経度から距離を計算している処理があります。
この関数がMySQL8.0に変更したことにより、計算が遅くなるという現象が発生しました。
調査したところ、同様の現象が起こっている例も散見され、SQL自体のチューニングを行う必要性が出てきました。
パフォーマンスチューニングと負荷試験
パフォーマンスの改善は主にSQLのを改善することと、大量アクセスに備えてRedisによるキャッシュを導入しました。
以前のロジックでは保持している対象のデータ全件に対して特定のポイントからの距離を算出し、3Km圏内で絞り込みをするという処理を行なっていました。
WHERE
ST_Distance_Sphere(
ST_GeomFromText(CONCAT('POINT(', {{latitude}}, ' ', {{longitude}}, ')'), 4326),
ST_GeomFromText(CONCAT('POINT(', latitude, ' ', longitude, ')'), 4326)
) <= 3000以前のバージョンではそれほど処理の負荷が高くなく、何とかなっていた部分ではありますが、データの量が増えればいずれは処理速度が遅くなってしまう実装方法です。
今回の改善により、事前に3Kmのデータに絞り込みをした上で距離を計算するというロジックに変更しました。
WHERE
latitude BETWEEN ({{latitude}} - (3.0 / 111.045)) AND ({{latitude}} + (3.0 / 111.045))
AND longitude BETWEEN ({{longitude}} - (3.0 / (111.045 * cos(radians({{latitude}}))))) AND ({{longitude}} + (3.0 / (111.045 * cos(radians({{latitude}})))))
これにより、大幅な速度改善が実現できました！
また、これに付随してApache JMeterによる負荷試験も実施しました。
秒間xxリクエストのように、通常アクセスより高い負荷をかけるテストを行うことで、Auroraのインスタンスクラスの適正サイズや現在の構成でどれくらいの負荷に耐えることができるのかというラインを知っておくために実施しています。
負荷試験を実施すると、パフォーマンスの改善や適正なインスタンスクラスを選ぶ際には数値による裏付けが非常に大切になると再認識させられます。
負荷試験の詳細については、また別の記事にて触れたいと思います。
最後に
今回は先日実施したAmazon Aurora MySQLのバージョンアップについてでした。
データベースのバージョンアップは影響範囲が非常に大きく、検証に多くの時間を必要としますが、バージョンアップをすることで性能が向上したり、コストが結果的に安くなるというメリットもあります。
しかし、検証不十分なままバージョンを上げてしまうと被害がとても大きくなってしまうので気をつけていきたいところです。
また、ビズパは仲間を求めています！
ご興味のある方は是非、カジュアルに面談をしてみませんか。