RDS for MySQLからAuroraに移行した際に調査した拡張性, 可用性の面で優れている点をまとめました。
既存システムの課題
システムの構成はRDS for MySQL Master, Slave 複数台という構成だった。
RDSのスレーブへのコネクションをアプリケーション層で分散していたが, ヘルスチェックし障害が起きていないhealthyなslaveに接続するというチェックができていなかった。
=> 複数Slaveの構成にも関わらず死んでいるSlaveにも接続してしまう つらみ
この課題を解決することをきっかけにより可用性, 拡張性のあるDBの構成を考えるきっかけに。
最初はHAProxyを使用してヘルスチェック, ロードバランシングをしようとしていたがHAProxy自体の冗長化等のコストがあり他の実現方法を調査し, Auroraのリーダーエンドポイントで課題を解決できる
& 可用性, 拡張性の向上が見込めたAuroraへの移行を決めた。
Aurora
可用性, 拡張性にフォーカスして注目すべきところをまとめていきます。
MySQL/PostgreSQL 互換のリレーショナルデータベースエンジンでパフォーマンス, 可用性、信頼性がRDS for mysqlよりも高いAWSのマネージドデータベースサービス。
Amazon Aurora インスタンスを作成すると、DB クラスターが作成される。
DB クラスターは、1 つ以上のインスタンスと、これらのインスタンスのデータを管理する 1 つのクラスターボリュームで構成されWriter(Master)とReader(Slave)で立ち上がる。
Aurora クラスターボリュームは、複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリューム。各アベイラビリティーゾーンにはクラスターデータのコピーが格納される。
SSDベースのディスクで10GBから64TBまでダウンタイム無しで自動で拡張される。
インスタンス
プライマリインスタンス
読み取りと書き込みの操作をサポートし、クラスターボリュームに対するすべてのデータ変更を実行する。各 Aurora DB クラスターには 1 つのプライマリインスタンスがある。
Aurora レプリカ
読み取りのみをサポートする。各Aurora DB クラスターは、プライマリインスタンスに加えて最大15 台のレプリカを立ち上げれる。複数のAuroraレプリカはコネクションを分散し、別のアベイラビリティーゾーンにAuroraレプリカを立ち上げることで可用性を上げることができる。
プライマリインスタンスがフェイルオーバーした場合、Aurora レプリカが自動的にプライマリインスタンスに昇格される。尚どのレプリカを指定するかは各レプリカに優先度を設定することができ, 優先度が高いインスタンスからプライマリインスタンスに昇格される。
Auroraには プライマリインスタンス, Aurora レプリカそれぞれを指定するエンドポイントが用意されている。
エンドポイント
クラスターエンドポイント
プライマリインスタンスを指定するエンドポイント。
Read, Writeの両方を実行できる。
インスタンス毎に一意のエンドポイントがあるが, クラスターエンドポイントを利用するとプライマリインスタンスに障害が起きた場合に新しいプライマリインスタンスを参照するようになる。
読み込みエンドポイント
Aurora DB クラスターには読み込みエンドポイントがあり、これを使用して DB クラスターの Aurora レプリカの 1 つに接続できる。DB クラスターの読み込みエンドポイントは、DB クラスター内で使用できる Aurora レプリカ間で接続を負荷分散する。
Aurora DB クラスターで利用できる Aurora レプリカの 1 つに接続する、その DB クラスターのエンドポイント。
明示的にヘルスチェックしているとは言っていない(?)ので注意 
インスタンスエンドポイント
プライマリインスタンス, Auroraレプリカのすべての特定のインスタンスに直接接続するためのエンドポイントが用意されている。
Auto Scaling
指定したメトリクスの変更に応じて Aurora レプリカを自動的に追加または削除できるようになった。
CPU 平均使用率や平均アクティブ接続数などの Aurora レプリカの定義済みメトリクスに、必要な値を指定できる。
そのため無駄なコストがかからないようにスケールインすることもできる。
Zero Downtime Patching
私達の、新しいゼロダウンタイムパッチ機能により、Auroraインスタンスへのパッチ適用をダウンタイム無しで、可用性にも影響を及ぼさずオンラインで実行出来るようになりました。この機能は、現在の最新バージョン(1.10)が適用されたAuroraインスタンスで、ベストエフォートで機能します。シングルノードクラスタとマルチノードクラスタのWriterインスタンス双方で機能しますが、バイナリログが有効になっている場合は無効になります。
Multi-Master
つい先日のReinventで発表されたMulti-Master。
クラスタを構成するすべてのノードに対して読み書きが可能になる。
監視項目
Auroraで取れるメトリクス,結構RDSと比較すると監視項目細かく設定できそう。
Mackerelで以下のメトリクスでAuroraの監視している。
Mackerelで監視する項目
- Queries 1秒あたりに実行されたクエリの平均回数
- SelectThroughput (per second) 1秒あたりのSELECTの平均回数
- DMLThroughput (per second) 1秒あたりのINSERT,UPDATE,DELETEの平均回数
- SelectLatency SELECTクエリのレイテンシー(ミリ秒)
- DMLLatency INSERT,UPDATE,DELETEのレイテンシー(ミリ秒)
- Buffer cache hit ratio バッファキャッシュ（バッファプール）のヒット率
- Deadlocks デッドロック数
- Blocked Transactions ブロックされているトランザクション数
Migrate back to MySQL
ないとは思うがAuroraに移行し問題がありRDS for MySQLに戻さなければ行けない場合の手順。
Amazon's Aurora is MySQL wire compatible so you can always use tools such as mysqldump to get your data back out into a form that you could use to import back into a regular MySQL instance running in RDS, an EC2 instance or anywhere else for that matter.
Since posting this answer Amazon has also released the Database Migration Service which can be used to do zero downtime migrations between MySQL -> Aurora MySQL (Aurora also now supports PostgreSQL) and back. It also supports heterogeneous migrations such as from Oracle to Aurora MySQL or a number of other sources and targets.
普通にmysqldump を使ってRDSにデータを移行する。
または, Database Migration Serviceを使用するしかないようだ。
#まとめ
Auroraに移行したことで可用性が確実に上がったしパフォーマンス的にネックとなる部分も今は出てきていないので移行は成功だったのではないかと思う。
そしてこれからもAuroraの拡張性, 可用性の部分の改善となるリリースが行われるのではないか。
内部がきになる方はこの記事がとてもわかりやすかったので参考にしていただければ => https://qiita.com/kumagi/items/67f9ac0fb4e6f70c056d