Servicesをベースにインフラを組んでいる。Auroraへと移行をした。それはAuroraがTokyoリージョンでの提供を開始した翌日のことで、中々勇気がいることであったが、結果「無難」に動いてそこそこ満足という評価。APIサーバーの平均レスポンスタイムを見ると10ミリ秒以上遅くなってしまったが、ユーザー体験とアプリケーションの性質上コストの兼ね合いで割り切ることとした。いう事情があり、MySQLとAuroraの比較が環境やコストの差で非常にしにくいが、いくつかの点で移行してよかったと感じる。詳細を以下に書きます。Auroraの公式ページでは「MySQLの5倍の性能」とあるが、これは「とある条件下」での最大計測値だと見た方が妥当という点で注意したい。実際状況によってはそれほどパフォーマンスが出る場合もあるとのことです。RDSにおいて、Auroraではディスクサイズを予め明示してからインスタンスを用意しなくとも、自動的にスケールでしてくれて大変助かる。Palanningする。その代わり、であるが、MySQLストレージエンジンではディスクサイズを大きくすればするほどディスクへのI/OアクセスであるIOPSが上がる。今回の件ではこのIOPSを「かなり」あげていた。クエリーによってはディスクアクセスが発生するものが存在した(CPU性能も加担しているかもしれない)。パフォーマンスが出ていた状態であった。Auroraの場合、IOPSのコントロールはしにくい。API」なのだが、結果前述した通り、全エンドポイントの平均レスポンスタイムが10ミリ秒上がった。遅くなったってことだが、同時に、インスタンスサイズを見直すいい機会になり、また、MySQLの時にIOPSを「かなり」あげて富豪的解決をしていたのに改めて気付かされた。よってパフォーマンスへの施策として、サボリ気味だった、いくつかのクエリーチューニングやインデックスの調整なども行った。結果、コスト削減の効果が実際出始めていて、特に利用者の多いモバイルアプリでのユーザービリティにも影響はほとんど出ていない。Zone」にまたがるということになっている。MySQLでの「Master-Replica」という文言は使わずに「Writer-Reader」という言葉を使う。ReplicaにあたるReaderを用意すれば冗長化は済んでしまう。レプリケーションの処理をストレージエンジン部分ではなく、確か、ディスクシステムレイヤーでやっちゃう、みたいな仕組みなんで、マスターとレプリカとのラグといった概念はほとんど存在しない。いうかラグは0と考えて良い。その都合も含め、この場合、Masterとして利用しているWriterがコケた場合に、ReaderがMasterへ昇格する際のフェイルオーバーが速いといった特徴がある。Planningという難しいことをせずとも、自動的にスケールしてくれるのが嬉しいところである。東京リージョンでの提供開始日の翌日に早速導入したわけだが、比較的すんなりいった。サービスはメンテ状態にしないといけないんだけれども、基本的にはMySQLのRDSからスナップショットをとり、そこから新たにAuroraを立ち上げる形になる。大きなテーブルでは2億ほどレコードがあるDBになるが、メンテ諸々の作業合わせて3時間ジャストくらいでイケた。Readerに関しては無停止でインスタンスを追加したり削除したり出来るので、一番負荷が高い「22時30分」頃のピーク時でのパフォーマンスをCloudWatch+Libratoで監視しつつサイズを合わせて行った。同時にクエリーやインデックスのチューニングも後々行ったので「パフォーマンスが落ちた」とはいえ、最小限に留めるように努力出来る余地があった。5.6」と互換性がある。Toolkit」のpt-online-schema-changeコマンドも問題無く動いた。これで「ある程度無停止」でスキーマを変更することが出来るので安心。まとめ正直「すっげーAuroraいいよ!」とは言えないが、MySQLとの互換性が今後保たれていくことが保証されるという前提で「特にAuroraじゃない理由はない」という具合でデフォルトで使う感じになる気がする。ポイントはスケーラブルMySQL互換(現状は5.6)冗長性が高いとなるだろう。現段階ではAuroraとして導入出来るインスタンスタイプがdb.r3.largeからとミニマムスタートには少々お高い感じになっているので、状況によっては敷居が高いが、Amazonの気合が感じられるプロダクトであるので今後スタンダードになるというジャッジで使うのはアリだと思います。