SCSK では AWS RDS サービスの１つである Aurora MySQL(以下、Aurora）の実力を図るべく、Aurora の検証を実施しております。
今回はその検証の一部で、クエリキャッシュに関する検証結果について紹介したいと思います。
クエリキャッシュとは
MySQL のクエリキャッシュとは、SELECT ステートメント結果セットのキャッシュです。
MySQL では2013年のバージョン5.6.8からクエリキャッシュの機能がデフォルトでは OFF となっており、次のメジャーバージョンアップのMySQL8 系では廃止がアナウンスされています。
対して、Aurora は MySQL5.6 互換とされていますが、AWS によればクエリキャッシュに大幅な改善を加えたとの事で、クエリキャッシュはデフォルトで ON となっています。
検証構成
今回のケースでは、Aurora の比較対象として検証当時の最新バージョンである RDS for MySQL の 5.7.17 バージョンを使用しました。
クエリキャッシュに注目した試験のため、両者非 Multi-AZ の構成です。
また、クライアント側には sysbench1 系を EC2 にインストールして使用しています。
パラメータ値の変更について、Aurora はシステム変数 performance_schema がデフォルト設定では OFF のため、ON に変更しています。加えて、MySQL5.6 対応の sys スキーマを作成しています。
この peformance_schema の設定は、RDS for MySQL ではデフォルトで設定されているものです。
また max_prepared_stmt_count の値を上限値最大にして、sysbench の prepared statement のエラーを回避しています。
検証の構成
テストシナリオ
テストシナリオについて説明します。
まず、クエリキャッシュの効果を検証するため、MySQL の query_cache_size を 0MB, 250MB, 500MB, 1GB, 1.5GB と変更していき、sysbench のテストを実行しています。
sysbench の負荷シナリオは、バンドルされている oltp_read_only.lua スクリプトを使用し、それぞれのデータベースにはデータ量が約5GBになるようテストデータを用意しました。また、テスト実行前には全てのデータをオンメモリの状態にしました。
thread 数は50とし、各テスト15分間実行しました。
結果
結果は以下の通りとなりました。
Aurora と RDS for MySQL スループット比較 (Query Per Sec)
Aurora はクエリキャッシュ増加に伴い、スループットが向上しました。
それに対して、RDS for MySQL ではクエリキャッシュ増加に伴ってスループットに悪影響を与えているのがわかります。
Aurora とRDS for MySQL レイテンシ比較 (95percentile)
レイテンシという点で見ると、Aurora はクエリキャッシュのサイズによって、レイテンシーが上下動しています。
対して、RDS for MySQL はクエリキャッシュサイズが大きくなるにつれて、レイテンシが上昇する傾向がはっきり出ました。
では、クエリキャッシュのヒット率はどうなったでしょうか。
以下のグラフは、AuroraとRDS for MySQL のクエリキャッシュヒット率です。
Aurora クエリキャッシュヒット率 ( % )
RDS for MySQL クエリキャッシュヒット率 ( % )
Aurora は時間の経過と共にクエリキャッシュの上昇が見られます。
1.5GB 時では最大でおよそ5割で、1GB と 500MB 時でも後半には5割へと上昇しました。また、250MB 時の最小値は3割程度のクエリキャッシュヒット率となりました。
対して RDS for MySQL を見るとクエリキャッシュのヒット率は、クエリキャッシュサイズ毎にほぼ横ばいを描いています。
1.5GB 時ではおよそ4割前後となり、250MB 時では、一割未満となりました。
次回は、この検証結果を踏まえてその要因について考えていきたいと思います。
