SQLも交えてベンチマークを採ってみました。内容は、適当にベンチマークツールを走らせて数値出たドーン!速い遅~いとキャッハウフフするものではなく、要所を検証するためのものなので、そんなに楽しいものではないかもしれません。上から順に、このくらいやれば十分かなーと考えていきました。SQLをサラッと見ただけでも気になるところがいくつもあります。SQLをとうに捨てていて、Datastoreを推奨しているのではないか。使ってみたら謎技術で高スループットが出たり、便利機能が盛り沢山なのでは。それらを払拭するために、まずは単体で十分かどうかを調べようと考えました。他の環境とも比較してみようせっかくベンチマークの手順も確立したのなら、そこそこ経験のあるRDSでも採取して比較してみようかと。Auroraも日本にきたし、やってしまえと。ついでに先日、旧Verより3倍速いという触れ込みでGAされたMySQL5.7もやってしまえと。いう感じで久々にウキウキウォッチンなベンチマークとなりました。あ、もちろん今回のRDSはMySQLですし、AuroraはRDSのエンジンの1つということは理解した上で、一般的にわかりやすいであろう表記にしているので、そういう突っ込みはいらんですたい。Zone間の差も知っておこうWEB/APサーバーと同AZにあるか、別AZかで、どのくらいのパフォーマンス差があるかを知っておくことで、余計な誤解を回避し、適切な設計と運用ができるためです。SQLだけ満足できない数値が出たため、その上のスペックも全部計測してみました。ついでに、レプリケーションデータの同期/非同期の違いもみることにしました。スペック今回のインスタンス・スペックは以下の条件を元に選定しています。テストデータ1GB以上のメモリがあること・・・2GB以上を目安CPUは2vCPU以上(GCPは不明)時間単位の価格が近いことで、こんな感じのインスタンスになりました。Dayの価格を24hourで割った価格にしています。メモリは2GBあれば検証としては十分なので格差は関係ありません。Purposeの1000GB*3で最大確保しています。その他、ネットワーク周りなどポイントがあれば都度、補足していきます。ベンチマークのデータ今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。こんなオレオレメモデータを見ても楽しくないでしょうから、1つ1つ考察していきましょう。データ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照/更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出します。CPU/転送量/IOPSを中心に、ボトルネックとなる項目の天井を確認できるまでリクエストを突っ込む感じです。QPSやIOPSを取得しています。この辺のコマンドベースの説明については、気が向いたら別途書こうと思います。3306ポートに対して計測したものになります。精度についてもちろん、同じ項目を何度か試行していますし、少々のバラつきがある結果もあるのですが、検証結果に大きな影響を与えない範囲で値をザックリ中間値で取ったり、適当に見やすく繰り上げています。あまりにバラつきが気になったポイントは補足していきます。クラウドにおいて、ボトルネックとして確信しづらいネットワーク・トラフィックですが、クライアントがボトルネックになっているとゴミ検証になってしまうので、そもそも高ネットワーク性能なインスタンスにしたり、それでも怪しければクライアント数を増やし、データベース・サーバー側がボトルネックとなるように気を使って調整しました。RDSについて考察オンメモリでは参照は正常にCPUボトルネックになりました。基準に他と比較していってよさ気な程度の数値は出た感じです。メモリ不足では参照はReadIOPSを3600出しているので、ここがボトルネックのようです。Purposeの説明では3IOPS/GBで3000上限に加えて、もう少しだけ性能が出るよ、と書いてあったので、そのチョイブースト部分がノッたようです。IOPSのわりにQPSが10000出ていい感じなので、ディスクの低レイテンシが伺えます。更新はReadIOPSが1600、WriteIOPSが2500、合計で4000超えしてボトルネックとなっています。QPSは1000とオンメモリに比べてだいぶ落ちますが、まぁこんなもんというか十分でしょう。試したのですが、ほとんど変わらず。STATUSを細かく見ないとわからない何かがあったかもしれません。AZ間の差は同クライアント条件において、QPSは約半減しました。いっても、どちらも十分に小さいRTTですし、なにより安定したRTTだったのが好感触でした。Auroraについて考察オンメモリでは参照は正常にCPUボトルネックになり、なんとRDSの倍以上の36000QPSを観測。これが、あの自信満々ぽいQueryCache周りの改善の成果でしょうか。その代わりか、更新QPSはRDSの半分以下の1800、かつCPU利用率も高めと不安要素も見えました。明確なボトルネックは見えていないため、テストデータが1GBであるためにIOPSがここ止まりな可能性が高く、むしろ自動拡張ストレージに1GBだけで、よくこんなに出させてくれたという感じです。大容量になった時の性能上限には期待したいところ。それとCPUについては、CPU利用率が高く見える、という事前情報がありますので、RDSとの比較は難しいところです。高く見えるのは我慢するとしても、じゃあどの程度をスケールアップのラインとして認識すべきか、という点が運用における重要課題となります。今のところは感覚で掴むしかないのでしょうか......メモリ不足では参照はRDSとほぼ同じQPSが出て、ReadIOPSが半減という内容。仕組みが完全にMySQLと異なるので、ファイルシステムやInnoDBのブロックサイズが違うかもしれないし、読み書きの手法がそもそも全く異なってそうなので、気にしてもしょうがないです。気になる人は、Auroraの詳しい公開資料を漁れば、悟りを開けると思います。IOPSが1200ずつ出ているので、これまでの単発Reads,単発Writesの最大1800と見比べると、合計2400は傾向的に上限値であると納得いくところ。少なくともAuroraでデータ容量が膨らんでメモリ不足になっても、異常な劣化や性能維持はなく、これまでのMySQLと近い感覚で対処していけばよさそうです。AZ間の差はRDSと同じ程度のRTTとQPSの低下なので、ネットワーク的には同じのようです。使って推測IOPS値を表示したりしていました。STATUSフィーリングは通用しないのでは疑惑が上がりました。一通り値をチェックして、感覚を磨く必要がありそうです。EC2について考察オンメモリでは3倍界王拳の噂は予想通り、RDSのv5.6とほぼ同じQPS(RTT差の分が低下?)でした。触れ込みでは1024コネクションで3倍ということなので、1クエリあたりの速度が3倍でもなく、CPUリソースが1/3でもなく、並列で処理できる上限QPSが3倍であると推測できます。いえ、これまで例えば50万QPS付近で喘いでいた人にとっては、100万をゆうに越せる希望が見えることなので凄いことではあります。更新はきっちりCPUリソースを使いきっての8400QPSということで、RDSの倍近くであり、ボトルネックがハッキリしない現象も解消されています。このあたりが、5.6ではハードウェアリソース外のところで詰まっていたけども、キッチリ捌けるようになった改善が感じられるところでしょうか。CPUリソースに対するQPSは5.6と同程度でも、全体のレイテンシが減るならば、ユーザーの体感を気持ち程度でも向上させることができるかもしれません。メモリ不足ではRDSに比べると参照・更新ともにQPSが劣っており、かつIOPSがボトルネックになったわけでもありません。IOPSを多く発生させる場合の、秘伝のタレ(my.cnf)に改良が必要な可能性が高いと思われます。AZ間の差はRDSとRTTが同じなので計測していません。SQLについて考察レプリケーションデータの同期と非同期CloudSQLでは設定で、AZ間のレプリケーションデータの同期と非同期を選択できます。同期にすると当然、更新QPSが低くなるので、両方を計測したところ、それらしい違いが認められました。同期ならば更新は600QPS程度まで、非同期ならば1000~3000QPSあたり。更新QPSが絶妙に微妙なところなので、1000以上の更新QPSを予定している場合は同期という選択を取れないか、DB分割という方針になりそうです。オンメモリではCPU情報がないのでボトルネックを断言できませんが、スケールアップしてもあまり参照QPSが増えず、最大のD32でRDSの2vCPUと同じ程度とは物足りない印象です。思えば、別AZにするとQPSが増えたりして、何回かやってもイマイチ納得する安定した数値になりませんでした。いえ、少なくともスペック名の数値に比例したCPU性能ではなさそうな可能性が高いです。詰まった理由がCPUではない場合、ネットワークトラフィックの可能性が非常に高いです。SQLサーバー側もあまりトラフィックに強くないのかもしれません。この辺は上限解放などの仕組みがないか調べる必要があります。任意の値にできなかったので計測しませんでした。一応、テストデータ容量を増やせばメモリ不足は演出できますが、インメモリの結果がそんなに良いとはいえなかったので、あえて劣化版も計測する必要はないと判断しました。変わりない速度となっています。CloudSQLにIPv4を付与するとグローバルIPアドレスになるので、よりフラットなネットワーク設計になっているのでしょう。どちらの場合も、RTTのMinが0.50~Maxが8.0msなどと頻繁にバラつきが起きたのが気になりました。AZ間の差が小さいのはメリットですが、AWSの安定感と同AZの速さはより魅力的といえるでしょう。QPSに対してIOPSが低い件これだけちゃんと追求するのを忘れてました。そもそもグラフが合ってんのか疑惑が強いですが、現時点ではなんとも言いがたいので、やらないかもしれない宿題で。RDSの忘れ物ここまでツラツラ書いておいてなんですが、RDSの環境は非MultiAZだったので、MultiAZにすると同期処理によって更新QPSが遅くなる可能性が高いです(やってしまった...)。SQLの非同期の2つ、そして参照全般ということになります。Auroraは4/6のHDD書き込み完了条件があるので、RDSをMultiAZにしたら同じくらいになるかもしれないですね...これによって、クラウドでの多種ベンチマークをもうやりたくない負け犬オーラがまとわりつきました。Platformの感想コンテナなだけあって、噂通りサーバーの起動は速いです。SQLのスペック変更やAZの切り替えもかなり速い印象でした。Engine上にMySQLを自前で立てたり、Datastoreで開発するなどの路線変更を検討することになりそうです。BigQueryなど素晴らしいシステムがあるだけに、RDBMSをもう少しなんとかしてくれないかな、それとも脱RDBMS的な思考のプラットフォームなのかな、といった初見の印象は変わらずでした。MySQL5.7の課題メモ5.7で他と同様のベンチマークを流し終わった後、何も実行していないのにiowaitが20~40%出るほどのディスクの読み書きが永久に続く現象に遭遇しました。昔のミドルウェアだと、こういう現象はそれほど珍しくなかったですが、現代で久々に見たので、本番投入する前には原因追求と解消をしなくてはいけないかもしれません。おわりにこの中から何を選べばいいのかは、適材適所だホイの逃げの一手を打ちたいところですが、あえて選ぶならば、もうAuroraでえぇんちゃうん、という印象です。次に、RDSが5.7対応したころには、それもえぇんちゃうんという感じかと。あとはGCPでのデータベースは皆どうしてんねん、という強い疑問が残ったくらいでしょうか。なんか、たいした比較結果にならなくて、スイマセン。何を選ぶにせよ、適切なクエリチューニングと、バックアップ・リストアの確立と、垂直・水平分割の手段を用意しておけば、そうそうクリティカルな事故には遭いませんよ、と適当に結べる程度には良い時代になってきたのではないでしょうか。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。