底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。Auroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。楽しい検証になって長くなりましたので、目次を置いておきます。何がボトルネックになるかはじめにいくつか前提的なものを。注意してください私はAWSの回し者ではないです、善良な一般ユーザーですクエリのレスポンスタイムデフォルト設定+1GBのデータがオンメモリの状態で計測した結果です。20ms以上、遅くなると読み取れます。MultiAZはほぼ必須なのでそれを悲観しても仕方ない、というのを含めおさらいでした。AuroraのReadReplica有りの特徴まずは軽くReadReplica(=Reader)について復習ですが、Auroraは単体で障害が起きても、フェイルオーバー開始から15分以内に自動復旧するとされています。Readerが1台あれば、1分以内に復旧するとされています。実際には障害検知の時間もあるでしょうから、もう少し長くなる可能性がありますが、主にインスタンス起動時間の分が短縮されるというわけです。RDSのMultiAZ用インスタンスと違い、1台目のReaderから参照クエリを実行することができます。DBデータの共有方法は、従来のレプリケーションではなく、直接同じストレージを利用しているためコピー処理は発生していません。MASTER(=Writer)との遅延時間も数十ミリ秒とされています。──などを踏まえた上で読み取れることの1つめですが、その仕組み上、Readerの有無にクエリ速度は影響されないことがわかります。1つは、AZ間のクエリ速度は単にネットワーク的なRTTが上乗せされるだけ、というのを確認しています。そのため、以降の検証では節約というか無意味なので、全てWriter単体でのものとしています。RDSとAuroraの比較データ保全を前提にしてMultiAZと比較すると、Auroraの更新クエリが速いことがわかります。これだけでは全然判断できませんが、移行メリットの良い匂いが立ち込めてきました。クエリキャッシュ1GBのデータがオンメモリの状態で、クエリキャッシュサイズを変動させた参照クエリの結果です。Auroraのクエリキャッシュは従来と全く別物である、と謳っているだけに、この検証をスルーするわけには参りませぬ。従来のMySQL使いにはわりと常識レベルかと思いますが、普通はQueryCacheはOFFにしてしまいます。これは、昨今のアプリケーションのデータ量やクエリ性質から、例えば1GBのQueryCacheSizeをこさえたとしても、キャッシュヒット率が全く上がらずに、キャッシュを保存するオーバーヘッドだけが残るという理由や、高スループットになるとCPUのContextSwitchなどが跳ね上がってボトルネックになるためです。久々にONにしてみた結果、やはりたいした効果は望めませんでした。Auroraの特徴ハイきました、なんじゃコレはの一言。公式資料でも改善をアピールしていますが、冗談は事業利益だけにせぇよという感じですね。いう仕組みになっているのでしょうか。{DBInstanceClassMemory/24}となっています。