Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databasesを読む(その6 PERFORMANCE RESULTS)
6 PERFORMANCE RESULTS
2015年7月にGAとなったAuroraを本番環境で稼働させた際の経験を紹介する。
6.1 標準的なベンチマークでの結果
SysBenchやTPC-C 亜種などの業界標準のベンチマークを用いて、AuroraとMySQLの性能を比較する。
特に記載のない限り、32 vCPU、244 GBのメモリを持つ r3.8xlarge EC2インスタンス(インテルXeon E5-2670 v2 (Ivy Bridge) プロセッサー)を使い、30k IOPSのEBSボリュームがアタッチされているインスタンスを使う。
r3.8xlargeのバッファキャッシュは170GBに設定されてる
6.1.1 インスタンスサイズによるスケール
r3ファミリーの5つのEC2インスタンス（large、xlarge、2xlarge、4xlarge、8xlarge）で、1GBのデータセット（250テーブル）のSysBenchのread-only と write-only のベンチマークの結果。
インスタンスサイズに応じてCPU、メモリは倍々に増えていく。
この論文の時点では、AuroraはMySQL 5.6のコードベースとなっている。
Auroraのパフォーマンスは、インスタンスサイズが大きくなるごとに2倍になる、つまり、Auroraのスループットはインスタンスサイズに応じてリニアにスケールすることがわかった。
r3.8xlargeでは121,000 write/sec、600,000 read/secを達成しました。
これは、r3.8xlargeでのMySQL 5.7の最高速度が20,000 read/sec、125,000 write/secであることと比較すると、大体5倍になる。
6.1.2 データサイズを変化させた場合のスループット
SysBenchのwrite-onlyのベンチマーク結果。
データベースサイズが100GBの場合、AuroraはMySQLよりも最大67倍高速になる。
データベースサイズが1TBでキャッシュに乗り切らない場合でも、AuroraはMySQLよりも34倍高速である。
6.1.3 ユーザーのコネクション数のスケーリング
接続数が50→500→5000と増やしていく中での、SysBench OLTPベンチマークにおけるwrites/secの結果。
Auroraが40,000 write/secから110,000 write/secまでスケールするのに対し、MySQLのスループットは500接続前後でピークに達し、5000接続になると急激に低下する。
参考 : MySQL 8.0などの状況
6.1.4 レプリカのスケール
レプリ遅延についての結果。
レプリ遅延は、コミットされたトランザクションがレプリカで見えるようになるまでの時間で測定する。
ワークロードが1,000から10,000 writes/secに増やしたときレプリ遅延をみる。
Auroraのレプリカラグは2.62 msから5.38 msに伸びる。
MySQLのレプリカラグは1000 ms以下から300000 msに延びる。
10,000 writes/secの状態では、AuroraのレプリカラグはMySQLのそれよりも数桁小さい。
6.1.5 行の競合が多い場合のスループット
TPC-C複雑な OLTP アプリケーションに対するベンチマーク。
https://japan.zdnet.com/glossary/exp/TPC-C/?s=4
Perconaが提供しているTPC-C の亜種でベンチマークをとった。
500 コネクション 10GB のデータから、 5000 コネクション 100GBのデータになるまでのスループットは、 MySQL 5.7と比較しAuroraは、2.3 倍から 16.3 倍のスループットがでる。
6.2 実際のユーザーでの結果
6.2.1 Auroraでのアプリケーション応答時間
とあるゲーム会社の例。
r3.4xlargeインスタンスのMySQLからAuroraへの移行。
移行前のウェブトランザクションの平均応答時間は15msで、移行後の平均応答時間は5.5msへ。
6.2.2 Auroraでのレイテンシー
とある教育テクノロジー会社の例。 本番環境のワークロードをMySQLからAuroraに移行。
移行前のP95遅延は40 ms 〜 80 msの間で、P50の約1 msよりもはるかに悪い。
このアプリケーションでは、この論文の最初にあるような外れ値によるパフォーマンス低下の問題が発生していた。
移行後、SELECT、INSERT操作のP95は劇的に改善され、P50とほぼ同じになった。
(これそもそもDBの設定とかが悪い可能性もある)
6.2.3 複数のレプリカを使用した場合のレプリ遅延
MySQLのレプリカは、ライターに比べて大幅に遅延することが多く、PinterestのWeiner氏が報告しているように「変なバグを引き起こす可能性がある」とされている。 (単純に考慮もれとかじゃないのかなあ、、、)
さきほどの教育テクノロジー会社では、レプリ遅延が12分になることもあり、アプリケーションの正確性に影響を与えるためレプリカはstand-byとしてしか使えていないかった。
Auroraに移行した後は、4つのレプリカの最大のレプリカラグが20msを超えることはなかった
．
Auroraによってレプリカラグが改善されたことで、同社はアプリケーションの負荷の大部分をレプリカに振り向けることができ、コスト削減と可用性の向上を実現できた。
(うーーーーーん 単純にMySQLの設定とかアプリの書き方じゃないのかなあああ、参考にしてはだめな気がする)
参照
ベンチマークの検証はよく考えようAuroraでTPC-Hってカミソリで薪割りしてるぐらいの誤用なのでそれぐらいもわからない現場では何使ってもダメかも…。 https://t.co/shrXmDu5Lg
— 分散処理に詳しいオタク (@kumagi) 2021年3月5日
先ほどのロック競合を起こしたワークロードは、テーブル名を見てピンとくる人はくると思うけど、TPC-C でよく使われるスキーマです。TPC-C は大量の競合トランザクションが発生するので、デフォルトでは commit 時まで排他ロックをとらない Cloud Spanner では、そのままだと大量の abort が発生する。
— takabow (@takabow) 2021年1月18日
こちらは2019年に出た論文ですけど、こちらを見ると
— Yoshiyuki Nakamura (@nakayoshix) 2020年9月5日
“FaRM with opacity can commit 5.4 million neworder transactions per second when running the TPC-C transaction mix on 90 machines with 3-way replication.”
と書いてあり、これは凄い…と思ってしまいました。https://t.co/a6Y7C9vMHO
