MySQL InnoDB Cluster（Group Replication）と非同期・準同期レプリケーションの書き込み性能の比較

こんにちは，S.T.です。今回はMySQL InnoDB Clusterと，通常の非同期レプリケーション，準同期レプリケーションの性能を比較します。結論から言うと，InnoDB Clusterは本来の目的どおり性能を少し犠牲にして可用性を高めたソリューションであることが確認できました。

1.MySQL InnoDB Cluster

MySQL InnoDB Clusterは，図1に示すようにGroup Replicationを組んだMySQL Server，クライアントの接続をルーティングするMySQL Routerで構成されたクラスタで，MySQL Shellを用いてオペレーションを行うことが可能です。とくに中心的な役割を担っている，Group Replicationのしくみが重要です。

Group Replicationは通常のバイナリログを用いて更新を複製するレプリケーションと異なり，分散システムとして動作するレプリケーションです。1台のみ書き込み可能なシングルプライマリ構成はもちろん，複数台で書き込みを可能とするマルチプライマリ構成とすることも可能です。Group Replicationは以下のような手順でレプリケーションを実現します。

1. トランザクションをコミットする直前に，そのトランザクションによる変更箇所などをまとめて表現した専用のデータ（書き込みセット）を作成する
2. 書き込みセットを他のノードに送信して，競合するトランザクションを受け入れる順序についてノード間で合意をとる
3. 合意した順番にトランザクションを処理する

ノード間の合意には分散合意アルゴリズムPaxosを使用しています。このように，トランザクションをコミットするたびにノード間で合意を取る，という動作を取るため，システム全体の可用性は向上しますが，1ノードで立ち上げているMySQLに比べてトランザクションの処理性能が低下することが予想できます。もちろん，InnoDB Clusterは可用性の向上を目的としたものであり，トランザクションの処理性能向上は目的ではありません。しかし，性能にどの程度の差が出るのかは気になるところです。

 

2.検証環境

今回はAWS上に以下のVMを建てて，3台構成のInnoDB Clusterを構築しました。EC2の設定や構築手順については，特別なことはせず一般的な手法を採ったため，省略します。また，同じスペックのインスタンスを別で用意し，MySQL Shellを用いてクラスタのオペレーション，MySQL Routerによるロードバランシング，mysqlslapによるパフォーマンス計測を行いました。比較のための通常のレプリケーションも同スペックのインスタンス2台で実施します。

• AWS EC2
• t3.medium（2vCPU/4GB RAM/gp2 SSD）全台 同一AZ
• Amazon Linux 2
• MySQL 8.0.29（innodb_buffer_pool_sizeを3GBに変更）

負荷試験はmysqlslapを用いて行います。mysqlslapはMySQLオフィシャルで提供されている負荷エミュレーションクライアントであり，簡単に負荷試験を行うことができます。mysqlslapは以下の設定をベースに，テーブルスキャン（read），挿入（write），PK SELECT（key），テーブルスキャンと挿入の混合（mixed），更新（update）を実行します

• auto-generate-sql-add-autoincrement
• number-int-cols=10
• number-char-cols=10
• iterations=10
• concurrency=30
• auto-generate-sql-write-number=1000
• number-of-queries=300

この設定でmysqlslapを実行すると，数値カラム10個，文字列カラム10個，AUTO INCREMENTつきカラムありのテーブルに，1000レコード，300クエリを30スレッドで負荷をかける，という操作を10回繰り返した結果を得ることができます。

3.Group Replicationの性能チューニング

MySQL Developer Zone – Tuning MySQL Group Replication for fun… and profit!で紹介されているように，Group Replicationの性能に寄与するパラメータが複数存在します。書き込みセットを圧縮して送信するサイズのしきい値，通信スレッドのスリープタイミングの調整などが主な設定項目です。記事中では，ワークロードやインフラ構成に応じて適切に調整することで良好な性能を得ることができると解説されています。

今回は複数の良さそうな設定を試してみましたが，デフォルトと同等か，10%程度遅くなる，という結果になりました。そのため，今回はこれらの設定はデフォルト設定を使用して検証を行います。

4.InnoDB Clusterとレプリケーションの性能比較

4.1.測定結果

mysqlshを用いて構築したInnoDB Clusterと，通常の非同期レプリケーション，準同期レプリケーションを組んだMySQLの性能を，mysqlslapを用いて測定し，比較します。InnoDB Clusterはシングルプライマリモード，マルチプライマリモードの両方を測定します。構築方法については公式ドキュメントなど信頼できる情報源が多く存在するため割愛します。

表1，図2，図3にMySQL InnoDB Clusterとレプリケーションの性能比較結果を示します。singleはInnoDB Clusterシングルプライマリモード，multiはマルチプライマリモード，asyncは非同期レプリケーション，semi syncは準同期レプリケーションを示します。各数値はmysqlslapが出力した平均時間（秒）です。read（テーブルスキャン）は処理にかかる時間のオーダが他と異なるため，別のグラフに抜き出しています。

表1：InnoDB Clusterとレプリケーションのmysqlslapによる性能測定結果

	single	multi	async	semi sync
key	0.214	0.214	0.158	0.152
read	3.916	3.928	3.4	3.402
write	0.295	0.33	0.146	0.163
mixed	0.264	0.26	0.181	0.198
update	0.322	0.3	0.151	0.172

 

 

 

事前の予想通り，もっとも性能が良いものが非同期レプリケーション，続いて準同期レプリケーション，InnoDB Clusterとなりました。InnoDB Clusterは，マルチプライマリ，シングルプライマリで大きな性能差は見られませんでした。とくにwrite（INSERT）は非同期レプリケーションがInnoDB Clusterの倍程度の速度で処理できており，InnoDB Clusterが書き込みのトランザクションのオーバヘッドが大きいことがわかります。

4.1.考察

InnoDB Clusterは，MySQL Routerを介して接続するため，ここの通信のオーバヘッドが発生します。理論的には，読み取りに関しては非同期レプリケーションもInnoDB Clusterも性能面での差が出ないはずですが，key（主キーアクセス）で約0.05秒，read（テーブルスキャン）で約0.5秒の差がでています。相対的な割合で見ると，それぞれ約24%，約13%の差となります。主キーアクセスはDBでの処理時間が短い分，それ以外の部分に要する時間の割合が高く，Routerを経由するオーバヘッドの影響も大きくなっています。

一方，write（INSERT）では，非同期レプリケーションがInnoDB Clusterに対して50%以上高速です。これは，単にMySQL Routerを経由する遅延のみが影響している，ということではなく，ノード間で合意を取る処理のオーバヘッドであることは明らかです。分散合意アルゴリズムを用いて合意をとるためには，必ず一度全ノードに対して通信を行う必要があります。一方で，非同期レプリケーションは単にバイナリログをレプリカに送りつけるだけで，特に合意を取るような処理はありません。その仕組みを考えても，書き込みの処理速度はレプリケーションよりも低速になるのは必然です。公式にそう言われているように，InnoDB Cluster（Group Replication）は（速度と引き換えに）可用性を大幅に高めたソリューションであることがわかります。

マルチプライマリモードとシングルプライマリモードの差は，最も大きいwriteで0.33秒（約11%）でマルチプライマリモードが低速でした。しかし，updateをみるとシングルプライマリモードのほうが低速になっており，単純にマルチプライマリモードのほうが書き込み性能が低い，ということはなさそうです。読み込みについてもほぼ同等の性能になっています。

InnoDB Clusterの可用性は大変魅力的ですが，このように性能面でも差があるという点は注意が必要です。ただし，例えば書き込みは巨大なトランザクションでまとめて実行する，というワークロードでは，先に述べたチューニングにより大幅に性能が改善する可能性もあります。InnoDB Clusterに限った話ではありませんが，使い所が重要です。

5.まとめ

AWS EC2上に構築した環境を用いて，MySQL InnoDB Clusterと，通常の非同期レプリケーション，準同期レプリケーションの性能をmysqlslapで測定して比較しました。writeでは非同期レプリケーションがInnoDB Clusterに対して50%以上高速であるという結果になりました。一方。マルチプライマリモードとシングルプライマリモードでは大きな差は見られませんでした。分散合意アルゴリズムを用いる都合上，書き込み性能が通常のレプリケーションよりも低下することが確認できました。

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。アプリケーション開発の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。

参考

MySQL 8.0 Reference Manual / InnoDB Cluster
MySQL Developer Zone – Tuning MySQL Group Replication for fun… and profit!