前回、無様にも記事公開直前にRDSのMultiAZ分の検証が足りないことに気づいたものの、その時点では飽きてゲッソリしていたので、追試験する気力もなくゴメンナサイしてポチッてしまいました。が、やはり思い直しまして、というか自分でも気になるところなので、恥を忍んでRDSのMultiAZ版のデータも取得して比較考察してみることにしましたウェーイ（ごまかし）。

すぐに取り掛からなかったのは、息子の専用部屋を増やすために同マンション内での引っ越しをしていたからです（近況報告）。それでは、参りましょう。

RDS MultiAZのデータと考察

同期構成についての考察なので、前回データから一部非同期系を削除し、RDS MultiAZのデータを追加（赤枠）しました。
また、結果が思ったよりアレだったので、再びSingleAZでも実行してみましたが、結果はほぼ前回と同じだったのでそのままにしてあります。

RDS 非同期と同期(MultiAZ)を比較

まず参照性能は、当然のごとく同期と関係ないので同スループットとなりました。

次にワクテカ更新性能ですが、インメモリではSingleの 1/5以下のQPSとなり、CPUやWriteIOPSの感触的に、AZ間の同期待ち時間がそのままスループットに与えた結果と判断してよさそうです。

メモリ不足でも同じように、単純な待機時間によるスループット低下を診てとれますが、こちらはIOPSが忙しくなる分、SingleよりもQPSが1/2弱と、同期待ち時間の影響が少なくなっていると思われます。

ただ、今回の検証結果はスループットの低下を確認しただけであり、ボトルネックを確定させたわけではないことに注意したいです。つまり、クライアントの並列数を、CPU100% or WriteIOPS3,000+α でボトルネックになるまで増やし続ければ、同期でも非同期でも同程度のスループットを捌けることに変わりはないであろう、ということです。

MultiAZ自体はバックアップや冗長化でほぼ必須なのでデメリットをあげても仕方ないのですが、更新クエリのレイテンシ増加がそれなりにあり、ユーザー体感にこれくらいの影響がありそうだ、という認識を持っておくとよいでしょう、ということでインメモリにおけるクエリごとの平均レスポンスタイムはこんな感じでした。

大雑把には、MultiAZの更新クエリは 20ms ほど遅いということになります。この数値感覚を持っていれば、例えばクエリ数減少の改善を施した時の、自己満足度が２％くらい増えるのではないでしょうか。

Auroraとの比較

RDS MultiAZの更新QPSよりAuroraの方が２倍以上となっており、ここでようやくAuroraスゲェとなるのですが、CPU利用率が高く見えると言っても高すぎですし、WriteIOPSもかなり高い数値という印象です。

こちらもボトルネックは確定していないので、少なくとも並列数を増やせば、多少の粘りをみせつつもCPU100%で上限は見えるでしょう。しかし、真に知りたいのはCPU上限などではなく、QPS or WriteIOPSです。

しかしそれを知るには、テストデータを1GBぽっちではなく、少なくとも100GB以上にしたり、かつスペックも上げながら、性能上限を計測するという、不毛なクラウド・ファイトをすることになるでしょう。


なので、上限は見えなくともAuroraで運用してみて、スケールアップ含む何かのボトルネックがくる前に、垂直・水平分割の準備を済ませる。そして、機会があれば、中の人にAuroraのリソースグラフの癖やボトルネックの可能性について聞く！

──ことが我々パンピーに今できる無難な攻めの一手ではないでしょうか。